Moving objects between safepoints in hotspot?

Erik Österlund erik.osterlund at lnu.se
Wed Mar 5 18:39:20 UTC 2014


Hi guys,

My name is Erik Österlund and I'm new to this mailing list. So first of all, hi everyone! Here's a short introduction of what I'm up to:
I intend to make a real-time GC for OpenJDK. My main focus is concurrent wait-free compaction. I made a wait-free compaction algorithm which is wait-free both for mutators (memory accesses, no safepoints) but also for the GC (no need for handshakes either and hence alloc() can be made wait-free if root sampling, tracing and their transitions can be made wait-free which I can but that's a different story). This was all implemented in my own prototype VM and now my intention is to give my GC a new home: hotspot.

This brings me to my first question in this mailing list: In order for an object comparison (o1 == o2) to work correctly, it is currently assumed in hotspot that the location of objects do not change between any two GC checkpoints.

Assuming o1 and o2 are pointing to the same object, I need to avoid the following race:

1. mutator thread: r1 = load o1 (resulting in from-space address of the object)
2. collector thread: move o1 to to-space, installing to-space object and copying it completely
3. mutator thread: r2 = load o2 (resulting in to-space address of the object)
4. mutator thread: compare (resulting in false negative since fromspace and tospace addresses are not equal even though it is the same object)

For this reason, I would need to either 1) conservatively cancel any object movement for objects touched by the mutator between any two GC checkpoints (which is a bit sad) or 2) emit a custom object equals function that deals with this properly and hence allows objects to move between checkpoints.

Therefore I'm wondering, how deep does this assumption go and how modular is the current implementation of object equals in hotspot? Is there just a few entry points used everywhere or quite many all over the place?

Thanks,
/Erik


More information about the hotspot-gc-dev mailing list