Question/Extension proposal: references to off-heap objects and support for multiple heaps

Krystal Mok rednaxelafx at
Thu Jul 26 16:16:09 UTC 2012

Hi Leo,

Thanks for being interested :-) I think it's time for Joseph to chime in,
if he will.
I don't work for Taobao anymore; it's better if someone from the inside to
share the details.

I could briefly cover the parts of the VM we touched. We tried a lot of
variants, and not all of them are meant to be **safe**.

GCIH as it is only works with ParNew+CMS configuration. We modified all
tracing actions that's involved in ParNew and CMS so that during GC it
wouldn't trace into objects within GCIH. We also modified the pointer
adjusting logic so that it would fix-up object pointers (oops) originated
from GCIH that point to moved objects.

Note that we actually only allow such pointers to be metadata pointers
pointing into the PermGen; after the PermGen elimination project is done,
such pointers wouldn't even exist anymore (but I'm not sure if the PermGen
elimination project allows metadata to move; it'd be nice for GCIH if
metadata doesn't move).
Otherwise, the object graph in GCIH must be self-contained, i.e. all object
pointers originating from GCIH should also point into GCIH. In addition,
objects in GCIH don't move. So, no pointer fix-ups other than the metadata
pointers are needed.

To enforce the invariant above, write-barriers also need to be modified.
Note that this could impact the throughput of normal Java programs, so it'd
be preferable if it could be turned off -- but we're talking about trading
safety for performance here, so umm...there really isn't a choice.


On Thu, Jul 26, 2012 at 11:43 PM, Leo Romanoff <romixlev at> wrote:

> Hi Kris,
> Thanks a lot for this link about GCIH and other JVM extensions done at
> Taobao. Very interesting!
> The GCIH use-cases are almost identical to what I had in mind.
> Krystal Mok wrote:
> >
> > We made deep modifications to the HotSpot VM to implement the features.
> As
> > you stated, it's unlikely to implement such feature without modifying the
> > internals of the VM, at least with the current standard APIs.
> >
> Very interesting. Is any general (or even better - detailed) information
> about those deep modifications available anywhere? It would be interesting
> to better understand which parts of the HotSpot are affected or impacted by
> such an extension and to which extent.
> Thanks again,
>   Leo
> --
> View this message in context:
> Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list