[jmm-dev] finalization

Doug Lea dl at cs.oswego.edu
Wed Aug 6 23:23:16 UTC 2014

Relatedly, I was asked recently whether there are any
memory ordering guarantees at all surrounding JNI calls with respect
to locations accessible to both native and Java code.
Right now, I think the answer is no, which makes Hans's
native free() example example even riskier.

But we should some time take a look at the JNI spec
(and/or other native/foreign mechanisms)
and see if we could add something about compatibility
of, at the very least, C++/C11 atomic seq_cst mode and
Java volatiles.


On 08/05/2014 02:34 PM, Hans Boehm wrote:
> I think a good specific example to think about is a, not entirely
> hypothetical, implementation of java.math.BigInteger that just forwards
> calls to an underlying native library that actually manages the memory for
> the number representations.  The BigInteger finalizer deallocates native
> memory.  Currently every BigInteger operation needs a synchronized(this){}
> at the end of the method, in order to prevent the underlying native
> representation from getting deallocated by a finalizer while the native
> arithmetic operation is still running, but the enclosing Java object is
> potentially no longer needed.

More information about the jmm-dev mailing list