Lazy memory initialization for Unsafe (calloc vs. malloc)

[Maurizio Cimadamore]

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 
really necessary).

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

Cheers
Maurizio

On 05/11/2018 19:49, mail.openjdk.java.net at lemmster.de wrote:
> Hi,
>
> lets assume an application A [1] 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
> performance.
>
> 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?
>
> Thanks
> Markus
>
> ¹ Lets assume the application logic cannot deal with uninitialized memory.
>
> [1] https://github.com/tlaplus/tlaplus
>
>
>
>
>
>