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