Consider add dlmalloc-rs as allocator or opt-out the BumpAllocator

[kvinwang]

Since wee_alloc has been removed in https://github.com/paritytech/ink/pull/1403, BumpAllocator is the only choice now. However, BumpAllocator is not suitable for our off-chain execution env, because it doesn't free any memory at all.

There are two options to resolve it in my mind:

• Support dlmalloc-rs, which is the allocator for wasm in std, as an opt-in replacement to the bump allocator.
• Add a feature no_allocator to crate ink_allocator to allow downstream to opt-out of the bump allocator.

[HCastano]

@kvinwang can you give us a couple more details as to why a non-freeing allocator is a problem for your off-chain env?

[kvinwang]

@kvinwang can you give us a couple more details as to why a non-freeing allocator is a problem for your off-chain env?

In our case, we run the contract with off-chain workers inside TEE. When a user calls a contract via RPC, it is not only for metering the gas but also for business serving. It can do much more heavy computing than the on-chain env. For example, we can do HTTP requests, parse the response, GET/PUT S3 storage, and make oracles in the contract. Those abilities may cause contracts to allocate and free heap memory frequently. If the allocator doesn't free memory at all, it would run out of memory soon.

[tolak]

@kvinwang can you give us a couple more details as to why a non-freeing allocator is a problem for your off-chain env?

And I found a new reason for this kind of requirement, see comment in PR

[kvinwang]

Another issue with the bump allocator. Should we consider this feature request?

[HCastano]

@kvinwang yeah we should consider this.

We initially removed wee_alloc due to size constrains, but for off-chain execution that's a bit less of a concern. We can still bring it back and keep it behind a feature flag.

Can I ask you to compare the contract sizes of contracts which use a) our bump allocator b) wee_alloc and c) dlmalloc-rs?

[kvinwang]

Can I ask you to compare the contract sizes of contracts which use a) our bump allocator b) wee_alloc and c) dlmalloc-rs?

Sorry for the latency to reply due to my Covid-19. I just compiled 3 versions with different allocators, and got result below:

$ ll *.wasm
-rw-r--r--  1 kvin  staff  2015  1 18 15:02 bump.wasm
-rw-r--r--  1 kvin  staff  6206  1 18 15:08 dl.wasm
-rw-r--r--  1 kvin  staff  2950  1 18 15:05 wee.wasm

However, I think the preferred way is to add a way to disable the BumpAllocator rather than to bring back the wee_alloc or dlmalloc. Something like this PR. Benefits in this way:

• ink itself needn't worry about the allocator size overhead.
• It would get more flexibility. For example, we did bring the QuickJS to ink in this project. If we can't disable the allocator in ink, we have to remove the allocator in C which QuickJS uses, and make a new one to delegate it to the Rust allocator (which causes us to encounter issue #1535). If we can disable the allocator in ink, then we can delegate Rust's allocator to the C allocator which is much easier.