Preventing Class Definitions from Compacting At GC Cycle
Mikael Gerdin
mikael.gerdin at oracle.com
Tue Nov 5 08:33:40 UTC 2013
On 11/04/2013 08:13 PM, serkan özal wrote:
> Hi Mikael,
>
> Thanks for your answer.
>
> Can you explain these a little bit more?
>
> * keep JNI Handles (jobject) to the objects instead of the "oop" object
> pointers.
Say that you have some sort of datastructure which keeps pointers into
the java heap.
class MyClass {
oop _java_object;
int _some_value;
};
Instead of keeping the _java_object as an "oop" you could use the type
jobject, which is a handle to an oop. As long as you use the jobject you
should be able to handle garbage collection
> * add hooks to the garbage collectors through a "oops_do"-style callback
> interface. Look at other implementors of oops_do to see how to do it.
With this approach you would need to add a method to your class:
void MyClass::oops_do(OopClosure* cl) {
cl->do_oop(&_java_object);
}
and add code which calls oops_do on _all_ instances of MyClass to the
garbage collection code (several places).
/Mikael
>
> --
>
> Serkan OZAL
>
> > From: mikael.gerdin at oracle.com
> > To: hotspot-gc-dev at openjdk.java.net
> > CC: david.holmes at oracle.com; serkanozal86 at hotmail.com
> > Subject: Re: Preventing Class Definitions from Compacting At GC Cycle
> > Date: Mon, 4 Nov 2013 09:38:13 +0100
> >
> > On Monday 04 November 2013 11.33.40 David Holmes wrote:
> > > Adding hotspot-gc and (hopefully) bcc'ing the discuss list.
> > >
> > > David
> > >
> > > On 3/11/2013 5:18 AM, serkan özal wrote:
> > > > Hi all,
> > > > I am not sure that target of mail is this group or not but I
> don't know
> > > > better one for asking :) I am currently working on an OffHeap
> solution
> > > > and I have a problem with "Compact" phase of GC.As I see at "Compact"
> > > > phase, location of classes these not loaded by bootloader may be
> changed.
> > > > However, location of classes these loaded by bootloader
> (classloaders are
> > > > null) are not changed.Changing memory location of class
> definition fails
> > > > my OffHeap solution. Compacting can be disabled by VM arguments but I
> > > > don't want to use these arguments. Because disabling compaction
> for all
> > > > objects causes increasing of fragmentation. In addition, I tried
> class
> > > > pinning with JNI by "NewGlobalRef" method but it doesn't prevent
> > > > compacting. As I understood, it only hides object from garbage
> collected.
> > > > In brief, is there any way to prevent compacting of any specific
> class
> > > > defition (or object) at GC cycle?Is there any bit, offset or
> field (such
> > > > as mark_oop) in object header to prevent compacting of fully from
> GC for
> > > > any specific object or class? Thanks in advance.
> >
> > There is no way to prevent the objects from moving.
> >
> > You need to either:
> > * keep JNI Handles (jobject) to the objects instead of the "oop" object
> > pointers.
> > * add hooks to the garbage collectors through a "oops_do"-style callback
> > interface. Look at other implementors of oops_do to see how to do it.
> >
> >
> > Also, your observation about classes loaded in by the null
> classloader not
> > moving is not technically correct. They can move as well, but since a
> lot of
> > them are loaded early they may not need to move.
> >
> > All of this has changed as of JDK 8, when we removed the perm gen and
> the
> > whole concept of moving classes.
> >
> > /Mikael
> >
> >
> > > > --
> > > > Serkan ÖZAL
> >
More information about the hotspot-gc-dev
mailing list