merge front/back padding after allocate current hole

[yodalee]

When we allocate a memory chunk, there may be some memory paddings
in front/back of the allocated chunk. Before this change, these paddings
are dealed by calling function deallocate.
However the implementation is inefficient since deallocate function will
search from the beginning of the linked-list and find the right place to
insert these paddings.
With this change, the paddings are linked to linked-list right after
they are generated. We don't have to deal with merge continuous since
paddings are guaranteed to be separated between them and to previous and
next holes.

Fixes #53

[phil-opp]

Thanks a lot for the PR and sorry for the late review. Looks good to me!

Unfortunately I missed the time window to approve the CI run, which is required by GitHub because this is your first contribution here. Could you push some dummy update to this PR (e.g. an empty commit or a no-op rebase) so that we retry this? Please ping me when you do.

[yodalee]

@phil-opp
Done. I use rebase/reword to change the commit. It is updated now.

[phil-opp]

Thanks a lot! Looks like there is a minor rustfmt issue, otherwise this seems good to go

[yodalee]

@phil-opp
Updated.
Out-of-curious, why the CI need approval to run? Usually it should automatically check PR that is being pushed.

[phil-opp]

Thanks!

Out-of-curious, why the CI need approval to run? Usually it should automatically check PR that is being pushed.

See https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/. Basically, there were some people that abused the automatic CI runs to mine cryptocurrency, so GitHub made manual approvals for first-time contributors manditory.

[phil-opp]

I'll publish this together with #55 as soon as its merged.

[yodalee]

See. Glad to being accepted.