Macos heapsize force jemalloc

[cheme]

This PR is a temporary fix for heapsize issue on mac.

It uses a fork of heapsize that uses jemallocator crate. The fork is currently on my repo, maybe creating paritytech/heapsize could be an idea, but it conflicts with target that is having
paritytech/parity-common#93 merged and remove heapsize from parity-ethereum (needs an other PR merged and crates published so this commit is probably safer regarding current deadlines).

The build pass https://gitlab.parity.io/parity/parity-ethereum/-/jobs/118084 on a modified ci config (I restore the original config in latest commit).

[ordian]

run cargo update -p heapsize to update Cargo.lock (it uses old heapsize commit 4dcb303d)

[cheme]

@ordian thanks I just realize it, I was running test on a deprecated hash.

[5chdn]

do you need a macos pipeline here?

[cheme]

yes, I temporarily put a 'test-build-darwin' as single test target, strange it doesn't launch on the last commit.
Edit : no seems like it is pending.

[cheme]

@ordian it ends up that the problem was indeed with

[target.'cfg(macos)'.dependencies]

it needed

[target.'cfg(target_os = "macos")'.dependencies]

and in code it also needed the target_os check.

[niklasad1]

LGTM, but this is only a temporary fix right?

We need create an issue to fix this so we don't forget but I guess this is ongoing in parity-common?

[cheme]

Yes it is temporary, the ongoing issue in 'parity-common' is paritytech/parity-common#93 it is mainly waiting for review, the actual fix will be master...cheme:rem_heapsize but it requires the crates update from parity-common pr (it has been a long time since I did not update the branch so it is a bit out of sync).

[ordian]

If we're going to release binaries with this fix, I think we should force jemalloc on every supported platform (not only on macOS). Alternatively, we could use rust 1.31, as suggested by @HCastano.

[cheme]

The code will indeed work also for linux. I activated it only for macos to be cautious (and tbh also to make sure we do not forget it is temporary).
Edit : if there is a consensus on applying it on linux to I have no objection.

[cheme]

One other thing to consider is that by including linux in the fix, we will avoid the slight performance drop related to the 1.32 allocator switch.
If there is no voice against it, I will add it this afternoon.

[cheme]

I am facing an issue (probably some cornercase between proc_macro, patching a crate and changing global alloc) when using the same method on linux, so I won't apply to linux too (using malloc_size_of it still behave properly but I do not use cargo patch).
Edit: my parity-ethereum branch macfix3 seems to circumvent the issue, but it is a bit more intrusive (sets the allocator in parity-ethereum), so I would rather stay with the current state of the pr

[5chdn]

do we want to keep this?

[cheme]

If we merge the PR : probably not (itwill really slowdown CI of every PR). I activated it last week because in some case with heapsize failures occurs after build and I wanted to assert it was not the case.
If we only use the PR to patch for the build (not sure if it is possible or even a good idea) we can keep it.

[cheme]

I switch it off, for reference https://gitlab.parity.io/parity/parity-ethereum/-/jobs/118672

[tomaka]

This hack is actually cleaner than I thought; it didn't come to my mind that jemallocator exposed the usable_size method.

[cheme]

@tomaka it actually run the same way as the parity-util-mem does with 'jemalloc-global' feature so any issue with this will be an issue in parity-common/parity-util-mem (except the linux issue from previous comments that I think is related to the use of cargo patch somehow).

[ordian]

Note, that it only enables jemalloc on macOS and not on linux (which may incur some perf regression). That was my only concern for approving this PR. But since this is a temporary fix, it's fine I guess?