Extend memory provider API with commit/decommit and free/dalloc functions

[bratpiorka]

Extend memory provider API with commit/decommit and free/dalloc functions.

Rationale

This is needed to properly manage OS allocations on Windows and Linux. We should have 1:1 mapping with Jemalloc extent API and distinguish between free() which just annotates the memory as unavailable and destroy() which does the actual unmapping. Note that this API would also be useful to Coarse Provider that implements some kind of memory virtualization by itself. After the changes the OS provider should implement the following allocation and deallocation flows:

allocate <- zero memory (if needed) <- commit (windows only) <- mmap deallocate (mark page as inaccessible or NOP) -> decommit (windows only) -> purge lazy/force (linux) -> destroy (unmap)

API Changes

• dalloc() should invalidate pages - this could be done by either NOP or adding a page to the free list
• free() should do the unmap (release virtual addresses)
• in the deallocation flow, the providers should implement at least free() function. For if dalloc(), decommit(), or purge() are not implemented, UMF pools implementation should call a more "aggressive" version of the deallocation function up to the destroy()
• to handle scenarios, where the user expects or doesn't care if memory is zeroed after the alloc, we should add a flag UMF_PROVIDER_ZERO_MEMORY_ON_ALLOC that, if set guarantees that memory is zeroed. On Level Zero provider this would require calling memset kernel (using zeCommandListAppendMemoryFill)

[vinser52]

We should have 1:1 mapping with Jemalloc extent API

I disagree with such a statement. We should be able to implement Jemalloc extent API, but it does not require 1:1 mapping.

free() should just invalidate the page - this could be done by either NOP or adding a page to the free list. Also we should rename this method to dalloc() to not confuse users

So "dalloc() should just invalidate the page - this could be done by either NOP or adding a page to the free list", correct? And free will remain the same as it is right now?

UMF should call a more "aggressive" version of the deallocation function up to the destroy()

UMF is a framework that allows different heap mamangers. Each particular heap manager implementation calls corresponding memory provider API. Do you mean that if some memory provider does not implement some API (e.g. purge) UMF should recognize it and call another API silently?

[bratpiorka]

I made some updates to the description based on our discussion + added a flag that should zero-memory on alloc