Staffan,
On Monday 02 December 2013 17.30.00 Staffan Larsen wrote:
> The problem here happens when SA wants to walk every object in the heap, to
> do that it needs to figure out what parts of the heap are in active use
> (the "live regions"). It gets the list of GC spaces as a start. It then
> maps out the TLABs in these spaces so that it will not walk un-allocated
> memory in the TLABs.
>
> In this case, it misses one (or more) active TLABs and so tries to walk
> memory that is part of a TLAB, but that has not been allocated to an object
> yet. In a fast debug build this will be filled with 0xbaadbabe and while
> dereferencing this memory it fails with a WrongTypeException. Sometimes it
> will also fail with an UnmappedAddressException, but these exceptions are
> ignored in this part of SA (for some reason).
>
> The TLAB that SA misses is one in a compiler thread. The code in SA does:
>
> if (VM.getVM().getUseTLAB()) {
> for (JavaThread thread = VM.getVM().getThreads().first(); thread !=
> null; thread = thread.next()) { if (thread.isJavaThread()) {
> ThreadLocalAllocBuffer tlab = thread.tlab();
> ....
>
> The problem is that thread.isJavaThread() will return false for
> CompilerThread (and some others) although they can have TLABs that we need
> to look at. The solution is to remove that check.
>
> I’ve left some debugging code in place in the code that I think can be
> useful for other problems. The real fix is just two lines of code.
>
> webrev: http://cr.openjdk.java.net/~sla/8029395/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8029395
The fix looks good to me, good catch finding that isJavaThread() in the SA is
lying.
I had a quick look through the other uses of isJavaThread() and some of them
seem to require that the thread has a Java SP. Not enough to warrant not using
a "isRealJavaThread()" or whatever to signal that it's in fact lying about
being a Java thread, but I guess there's a lot of ugly code in the SA :(
/Mikael
>
> Thanks,
> /Staffan
