[concurrency-interest] jni effectively immutable "constructor" guarded by java volatile for safe publishing
stanimir at riflexo.com
Mon Aug 27 21:26:00 EDT 2012
The direct buffer itself resides IN the java heap, it has a native C
pointer to (pre) allocated memory (malloc/mmap) outside the heap.
When there are no references left (sun.misc.Cleaner extends
PhantomReference) the finalizer thread frees the allocated memory
So basically the handling is left to phantom reference and clean-up code
(similar to finalization)
On Tue, Aug 28, 2012 at 3:18 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
> just curious - an object is created on a direct ByteBuffer, which
> resides outside java heap. how would garbage collector treat the
> On Mon, Aug 27, 2012 at 12:16 PM, Andy Nuss <andrew_nuss at yahoo.com> wrote:
> > Hi,
> > 1) I have a native function which passes several params and uses a native
> > C++ constructor in-place constructor relative to a saved nio direct
> > bytebuffer to create an object, returning a long which is cast from the
> > pointer to object. This object's constructed values are effectively
> > immutable in that only that native call sets the members of the obect.
> > C++ object then can do work based on its constructed state.
> > 2) java code that makes the above calls safely publishes the longified
> > version of the C++ pointer (created above) somewhere (without mutex) and
> > changes a volatile variable to hopefully publish the memory changes made
> > the "constructor" above to other threads.
> > Now another java thread reads that volatile fence variable of 2), and
> > picks up that published long, and calls another native function that
> > accesses that effectively immutable object in the C++ memory space to do
> > some work.
> > Is that other thread guaranteed to see the fully constructed native
> > because of the Java Memory Model guarantees about volatiles and fences?
> > would bet the answer is yes on some platforms, but I see that different
> > chips work different ways with using fences, and was wondering about all
> > platforms for which java is available. I couldn't tell by googling
> > the Java Memory Model made guarantees relative to changes in *all*
> > not just that of the virtual machine. Maybe sun.misc.Unsafe might come
> > the rescue?
> > (By the way, I need to use mutexes in my native code too for the purpose
> > subdividing the nio bytebuffer of 1), and found that JNI MontorEnter()
> > extraordinarily slow, as are all callbacks into java code. I saw
> > that it is safe to use POSIX threads' or Windows threads' semaphores as
> > as during the critical section, there are no callbacks into jvm. But I
> > wonder if anyone can answer this other question?)
> > Andy
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest