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, [email protected] 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
