What is the reason for the additional indirection in Handle?

Keith McGuigan Keith.McGuigan at Sun.COM
Mon Sep 8 11:42:49 PDT 2008


Ramón García wrote:
>> Like Keith said, it does both [tracking that pointer is being used and updating the references if the pointer is moved].
> 
> Then there is something that I do not understand.
> 
> If one is inside a member function of, say, KlassHandle. That
> functions receive the value of this as the first (hidden) parameter,
> like any C++ method. If the address of KlassHandle changes, how can
> this be handled? If it is imposible, why?

In order for garbage collection to happen, all threads (except those 
running external native code) must first be brought to a safepoint. 
Only then can garbage collection proceed (and only then are object 
references changed).

Entering a safepoint happens cooperatively for all threads, i.e., the 
system must wait for all threads to get to the safepoint and block 
before any actions can occur.  Threads in Java code have occasional 
checks for a safepoint (like in method entries and backedges of loops); 
Threads running VM code explicitly check for a safepoint in certain code 
paths.  Transistions from Java -> native code (VM or library) and back 
also have checks for safepoints.

Maintaining a unhandled object pointer value in the locals, globals, or 
even the 'this' pointer, beyond a location where a safepoint is 
possible, is an error in the VM, precisely for the reason you stated -- 
if a safepoint is reached and GC occurs, the value will have changed 
from under you.  If an object pointer value is required beyond where a 
safepoint might occur, it needs to be "handlized" before the safepoint 
and "dehandled" after, to pick up the right value if a change occurred.

Having an unhandled oop in the code is sometimes a difficult error to 
diagnose, since the bug may only turn up occasionally (when a GC happens 
at the exact wrong time), so we have an in-code auditing system 
(available in debug mode) which trashes the oops at every possible 
safepoint in order to flush out problems like this.  Look at the code 
for -XX:+CheckUnhandledOops

(I left out a lot of details, but that's the gist of it).

--
- Keith



More information about the hotspot-runtime-dev mailing list