Lazy memory initialization for Unsafe (calloc vs. malloc)
maurizio.cimadamore at oracle.com
Wed Jan 16 12:07:34 UTC 2019
Hi Markus, (moving to panama-dev)
I've been pointed at your message by a colleague, I believe it is very
relevant to the context of the Panama offheap API, since that API is
internally using unsafe to allocate native memory.
As far as I'm aware, our Scope class is internally just calling
Unsafe::allocateMemory, and leaving memory uninitialized, as per malloc
(which means it's up to the application to initialize the memory if
Adding an alternate way to initialize memory doesn't sound bad - but I
have some questions over the proposed approach
* while adding a new method to Unsafe seems like the most natural path,
please be aware that we have committed to reduce the footprint of that
API over time; your proposal goes in the opposite direction. That said,
we could still have some internal functionality for performing calloc
that is only used internally by the Panama offheap API
* I'm not an expert in the area, but I'm wondering whether the lazy
zeroing scheme is truly cross-platform as opposed to being just a Linux
optimization; of course adding a new functionality that adds benefit on
a single platform has a different cost compared to adding something that
provides advantages across the board
On 05/11/2018 19:49, mail.openjdk.java.net at lemmster.de wrote:
> lets assume an application A  which is optimized for throughput, not
> latency. Additionally, A reverts to sun.misc.Unsafe to store gigabytes
> of data on off-heap memory to e.g. improved memory utilization and
> Due to the fact that Unsafe#allocateMemory returns an uninitialized
> (malloc) memory region R, app A has to explicitly initialize R by e.g.
> calling Unsafe#setMemory¹.
> Since app A is optimized for throughput, there is no real need to
> eagerly allocate R. Instead - on OSes with an optimistic memory
> allocator such as Linux - app A could benefit from lazy allocation. This
> would reduce app startup time that - that today is linear in the size of
> R - to constant time. Assuming Unsafe (or some other API) would expose
> memory allocation with calloc instead of malloc one would get away
> without explicitly calling Unsafe#setMemory or implementing (complex)
> lazy initialization into A itself.
> To check this idea, I added sun.misc.Unsafe#callocateMemory (notice the
> "c") to a local jdk12 build. It works as intended. Is this feature a
> candidate to be added to the JVM, e.g. as part of project Panama or am I
> better off rolling my own solution via JNI?
> ¹ Lets assume the application logic cannot deal with uninitialized memory.
>  https://github.com/tlaplus/tlaplus
More information about the core-libs-dev