Keeping oops

[Y Srinivas Ramakrishna]

And of course Tom is right. You can't use HandleMark in (a),
only JNIHandle::make_global() to make the global handle to
use there. Sorry for any confusion from
my having not pointed this out in my email (and for myself
having implicitly conflated the two in my email).

-- ramki

----- Original Message -----
From: Y Srinivas Ramakrishna <Y.S.Ramakrishna at Sun.COM>
Date: Tuesday, December 11, 2007 1:49 pm
Subject: Re: Keeping oops
To: Peter Helfer <peter.helfer.java at gmail.com>
Cc: hotspot-runtime-dev <hotspot-runtime-dev at openjdk.java.net>


> Hi Peter --
> 
> > I'm having a hashtable, which should keep two oops 'grouped' 
> together. 
> 
> As far as GC is concerned it doesn't matter whether your oops come in
> pairs, triples, or any other structure. What matters is that you have 
> a
> table of "weak roots", i.e. oops to which you hold references from outside
> the heap. Notice that i said "weak" -- my assumption is that your references
> from this hashtable do not keep an otherwise unreachable oop alive across
> a GC. If you do want them to keep the oops alive (when they are the sole
> reference to that object) you would call your table a source of 
> "strong roots".
> 
> With that short preamble behind us, let us answer the question you
> were asking, about whether it's more efficient to "register" the
> existence of these roots with GC via creating handles to them
> which are then used by the code that manipulates your table,
> or by registering the table itself as a source of roots and
> have the table keep the oops.
> 
> I guess the answer is, it depends. If you expect this table to
> be in every thread and there to be at least a handful of these
> references in each table, I would just register the table in the
> manner you said in (b) below  (Look at Threads::oops_do()).
> Recall that approach (a) is preferred when the references are
> more "fleeting" and not "bound" to any static or long-lived
> structure; appraoch (a) imposes the overhead of dereferencing
> the handle to get to the oop and of the (minimal) space for the
> handle itself.
> 
> I would think that the difference in performance would, for most
> cases, be in the noise (at least as far as GC load is concerned),
> and ease of use should dictate choice. From the sounds of it,
> (i.e. if i can guess at the way you are going to be using these)
> i'd suggest using approach (b).
> 
> Just a nit ...
> 
> > This
> > should keep those oops or handles or whatever accross a Safept / GC. 
> Either:
> > 
> > a) I need to create a HandleMark, somewhere really low in the stack 
> - 
> > say in
> > the constructor of a thread or one of its first functions, and have
> > something like hashtable<handle, handle>
> > 
> > b) Keep pointers to oops (oop*) allocated, and pass them to the GC 
> > when it
> > comes by, like  hashtable<oop*, oop*>::oops_do(OopClosure* f) ? As 
> > long as
> > the oop* still points to that particular oop, it is not moved by GC, 
> 
> > right ?
> 
> I guess you meant "recycled" (not "moved") in the last sentence above.
> 
> That would make it a strong root. (If on the other hand you don;t want 
> the
> hashtable to be a source of strong roots, then it's a table of weak roots
> and if the only references to an object is from this table then all of 
> those
> references would be cleared when the object was recycled.)
> 
> HTHS, and thanks others for any corrections/comments to what i
> said above.
> 
> -- ramki
> 
> > 
> > Which one of those is feasible / recommended ?
> > 
> > Regards & sorry again
> > Peter
> > 
> > 
> > 
> > 2007/12/11, Peter Helfer <peter.helfer.java at gmail.com>:
> > >
> > > I'm having a hashtable, which should keep two oops 'grouped' together.
> > > This
> > >