Hi Alan,
Thanks for the response and apologies for failing to notice you had
posted it some days ago (doh!).
Jonathan Halliday has already explained how Red Hat might want to use
this API. Well, what he said, essentially! In particular, this model
provides a way of ensuring that raw byte data is able to be persisted
coherently from Java with the minimal possible overhead. It would be up
to client code above this layer to implement structuring mechanisms for
how those raw bytes get populated with data and to manage any associated
issues regarding atomicity, consistency and isolation (i.e. to provide
the A, C and I of ACID to this API's D).
The main point of the JEP is to ensure that this such a performant base
capability is available for known important cases where that is needed
such as, for example, a transaction manager or a distributed cache. If
equivalent middleware written in C can use persistent memory to bring
the persistent storage tier nearer to the CPU and, hence, lower data
durability overheads then we really need an equivalently performant
option in Java or risk Java dropping out as a player in those middleware
markets.
I am glad to hear that other alternatives might be available and would
be happy to consider them. However, I'm not sure that this means this
option is not still desirable, especially if it is orthogonal to those
other alternatives. Most importantly, this one has the advantage that we
know it is ready to use and will provide benefits (we have already
implemented a journaled transaction log over it with promising results
and someone from our messaging team has already been looking into using
it to persist log messages). Indeed, we also know we can use it to
provide a base for supporting all the use cases addressed by Intel's
libpmem and available to C programmers, e.g. a block store, simply by
implementing Java client libraries that provide managed access to the
persistent buffer along the same lines as the Intel C libraries.
I'm afraid I am not familiar with Panama 'scopes' and 'pointers' so I
can't really compare options here. Can you point me at any info that
explains what those terms mean and how it might be possible to use them
to access off-heap, persistent data.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
