Keeping oops

Y Srinivas Ramakrishna Y.S.Ramakrishna at Sun.COM
Tue Dec 11 13:49:38 PST 2007

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 < at>:
> >
> > I'm having a hashtable, which should keep two oops 'grouped' together.
> > This
> >

More information about the hotspot-runtime-dev mailing list