[jmm-dev] finalization

[Doug Lea]

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
(http://docs.oracle.com/javase/7/docs/technotes/guides/jni/)
(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.

-Doug

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.