What does BufferBlob::Interpreter in a JVM crash log mean

[Tom Rodriguez]

On Nov 14, 2011, at 2:00 PM, Martin Hare Robertson wrote:

> Thanks for your quick response. 
> 
> See inline below. 
> 
> On 14 Nov 2011, at 21:02, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
>>> 
>>> ___
>>> 
>>> 1) What do the BufferBlob::Interpreter lines in the stack mean? 
>>> 
>>> - Are these Java stack frames? 
>>> 
>>> - JVM stack frames? 
>>> 
>>> - Is it possible to work out what was being called in these stack frames?
>> 
>> These are Java interpreter frames and normally they should be printed as Java method names and bci instead of setting the name BufferBlob::interpreter.  That's the internal name of the chunk of memory where the assembly for the interpreter resides.  The fact they you are seeing it probably represents a bug.  I have a vague memory of a bug in the error reporting like this a while back but I can't remember off hand what it was.
> 
> Ok that makes sense to me. How about my guess regarding the fact that the BufferBlob::interpreter lines appear in both the Java and Native stacks? Is it likely that these frames refer to the same stack or is there really 5 frames of Java code above 5 frames of Native code?

It's five+ frames of Java calling 6 frames of native code and then crashing.

>> 
>> The native frames you see in gdb correspond to the libjvm.so frames in the crash log and I suspect the BufferBlob frames correspond roughly to the Java call stack you posited above.
>> 
>> The crash isn't in biased locking itself but in part of the logic that's walking the stack to revoke biases.  So it may not have anything to do with biased locking itself.  Turning it off and seeing if it fails in another way might be informative.
> 
> Presumably if I turn off biased locking then the logic which walks the stack to revoke biases shouldn't be run? Or is the stack walking code more generic?

The stack walk is pretty generic so the fact that it's failing there suggests it might not be a biased locking issue.  That's why I think you might get a different failure with it turned off.

> 
>> If you aren't able to move to a more recent JVM then your only option is to try turning stuff off in hopes of making it go away, though it's possible it's a CMS issue.  If you are having specific problems with hotspot that keep you from upgrading then I'd encourage to raise those issues so that we can get them resolved.
> 
> The biggest unresolved problem was reported under bug 7066603. Sadly this seems to have been marked as low priority.

It seems to have gotten stuck over in the wrong category.  I've moved into the proper category and updated it.  It appears CMS isn't visiting some regular Java objects held in perm so they are missing from the dump.  The recent changes to move Strings and Classes out of perm make this problem disappear in JDK7.  So it only affects JDK6 at this point.  I believe the bug is in the obj_is_alive logic that CMS uses to visit only live objects in perm.

tom

> 
>> tom
>> 
>>> 
>>> ___
>> 
>