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

[Martin Hare Robertson]

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?

>> 
>> ___
>> 
>> NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs have been stable enough with the CMS collector in the testing which I have done.
>> 
>> org.myapp.AppClass.getBytes() reads from a DataInputStream. This could produce the following stack trace:
>> AppClass.getBytes()
>> AppClass.readByte()
>> 
>> DataInputStream.readByte()
>> SocketInputStream.read()
>> 
>> SocketInputStream.read(byte[],int,int)
>> 
>> PlainSocketImpl.aquireFD()
>> This final method grabs a lock. This could be the source of the eventual call into the JVM code listed above. This stack above has the convenient feature that there are 5 Java stack frames below getBytes(). This would match up neatly with the 5 lines of BufferBlob::Interpreter in the list of "Java frames".
>> 
>> ___
>> 
>> 2) Could these 5 BufferBlob::Interpreter frames correspond to the Java stack trace I identified above? Is it possible that the 5 lines of BufferBlob::Interpreter under the "Native frames" section refer to the same stack frames as the same lines under the "Java frames" section?
> 
> 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?

> 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.

> tom
> 
>> 
>> ___
>