[concurrency-interest] jni effectively immutable "constructor" guarded by java volatile for safe publishing

Stanimir Simeonoff 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
(free/munmap).

So basically the handling is left to phantom reference and clean-up code
(similar to finalization)

Stanimir

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
> object?
>
> 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.
>  The
> > 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
> in
> > the "constructor" above to other threads.
> >
> > Now another java thread reads that volatile fence variable of 2), and
> then
> > 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
> object
> > because of the Java Memory Model guarantees about volatiles and fences?
>  I
> > 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
> whether
> > the Java Memory Model made guarantees relative to changes in *all*
> memory,
> > not just that of the virtual machine.  Maybe sun.misc.Unsafe might come
> to
> > the rescue?
> >
> > (By the way, I need to use mutexes in my native code too for the purpose
> of
> > subdividing the nio bytebuffer of 1), and found that JNI MontorEnter()
> was
> > extraordinarily slow, as are all callbacks into java code.  I saw
> somewhere
> > that it is safe to use POSIX threads' or Windows threads' semaphores as
> long
> > 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120828/23c8fd28/attachment.html>


More information about the Concurrency-interest mailing list