Hi Volker, Happy New Year. I'd like to ask some question about hotspot of openjdk.

Tue Jan 6 03:04:53 PST 2009

Hi David,
Thanks for your reply.
I've check out the "Hotspot Runtime Overview", which says that slow-path 
means the lock state is inflated. In other words, it is locked or unlocked 
but shared and contented.

> InterpreterRuntime::monitorentry is the slow-path entry point for monitor 
> acquisition.
Where is the fast-path entry point in the template interpreter, as I need to 
know all information about each accessing of share variant?

Regards,
Alex Xie
--------------------------------------------------
From: "David Holmes - Sun Microsystems" <David.Holmes at Sun.COM>
Sent: Tuesday, January 06, 2009 3:08 PM
To: <xinweix at cse.unsw.edu.au>
Cc: <hotspot-dev at openjdk.java.net>
Subject: Re: Hi Volker,	Happy New Year. I'd like to ask some question about 
hotspot of	openjdk.

> Alex,
>
> -Xint runs only the interpreter, the JIT compiler is disabled.
>
> InterpreterRuntime::monitorentry is the slow-path entry point for monitor 
> acquisition. If you look in bytecodeInterpreter.cpp you will see the 
> fast-path code that is used - see line 612 for method calls for example. 
> If you search for the calls to InterpreterRuntime::monitorentry you will 
> see the fast-path code for the different cases preceding it. Note that 
> there are two different fast-paths depending on whether biased-locking is 
> enabled or not.
>
> If you want to track all monitor acquisitions then you will need to modify 
> the interpreter itself to add your tracking code.
>
> Hope this helps.
>
> David Holmes
>
>
> xinweix at cse.unsw.edu.au said the following on 01/06/09 16:48:
>> Hi Volker,
>>
>> Thanks very much for your great help. I'd like to discuss with you the 
>> following questions:
>>
>> 1. I've followed your advise of using '-XX:+TraceBytecodes' and identify 
>> the specific bytecode instruction. However, I encountered the problem of 
>> SEGV fault when it is executing in 'monitorenter' bytecode. I tried 
>> several times, but failed all the same.
>>
>> 2. If I follow the option of '-Xint', is the mechanism of JIT compiler 
>> working there? If not, is it in the mixed mode? How can it be activated? 
>> Are there some entry points? I found some compiler introductions and 
>> optimizations published in some papers, such as HIR(Highlevel 
>> Intermediate Representation), LIR and SSA forms, etc. The IR is another 
>> type of bytecode. If I want to instrument bytecode, such as 
>> 'monitorenter', 'monitorexit', is it feasible to work on the IR?
>>
>> 3. I tried to use '-XX:+PrintAssembly' option to get some ouputs, that 
>> are composed of the assembly codes with respect to each bytecode. Is it 
>> that each bunch of assembly codes will be executed when 'Interpreter' 
>> executes each bytecode?
>>
>> 4. Is it that the function InterpreterRuntime::monitor is the entry with 
>> respect to 'monitorenter' so that I can do something here?
>>
>> Regards,
>>
>> Alex Xie
>>
>> --------------------------------------------------
>> From: "Volker Simonis" <volker.simonis at gmail.com>
>> Sent: Monday, January 05, 2009 9:50 PM
>> To: <xinweix at cse.unsw.edu.au>
>> Cc: <hotspot-dev at openjdk.java.net>
>> Subject: Re: Hi Volker, Happy New Year. I'd like to ask some question 
>> about hotspot of openjdk.
>>
>>> Hi Alex,
>>>
>>> there are some things to consider if you want to debug the HotSpot 
>>> interpreter:
>>>
>>> - gdb should work fairy well, however for some historic reasons, the
>>> debug version of HotSpot on Linux/x86 is built with "-gstabs". To get
>>> a better debugging experience, you should change this to "-g" at the
>>> end of the file "hotspot/make/linux/makefiles/gcc.make" and rebuild
>>> the VM with these new settings.
>>>
>>> - in general, the "java" launcher will "execv()" itself to ensure it
>>> has the right LD_LIBRARY_PATH settings but this "execv()" can confuse
>>> gdb. To avoid it, you can either use the "gamma" launcher as explained
>>> in my blog ("gamma" does not execv, because the user is responsible to
>>> set the right LD_LIBRARY_PATH before calling "gamma"). The other
>>> possibility is to set the LD_LIBRARY_PATH manually before running
>>> "java" such that it begins with the prefix expected by the the
>>> launcher. In  this case the launcher does not need to do an "execv()".
>>> To achieve this, you can set a breakpoint in
>>> "CreateExecutionEnvironment()" in "src/solaris/bin/java_md.c" (solaris
>>> is no typo here!!!) and check the path the launcher expects to see for
>>> LD_LIBRARY_PATH (look for the value of "newpath").
>>>
>>> - even if you followed the two points above, you can not easily set a
>>> breakpoint in the interpreter, because the interpreter is generated at
>>> startup. This means that there are no C-sources for the interpretation
>>> of a bytecode (instead there's C-code which generates code which will
>>> execute a bytecode). You can display the generated interpreter and the
>>> various stubs with the options "-XX:+PrintInterpreter" and
>>> "-XX:+PrintStubCode". You should use this together with
>>> "-XX:+PrintAssembly" to get a disassembly of the generated templates
>>> and stubs. (Notice that you need to compile and use the additional
>>> library "disassembler.so" for this to work. More information on the
>>> disassembler library can be found under:
>>> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly).
>>>
>>> - I suggest you run the VM once with "-XX:+PrintAssembly
>>> -XX:+PrintInterpreter -XX:+PrintStubCode" and save the output to a
>>> file. You should do this in the debugger, such that the addresses of
>>> the generated code are the same like in the actual debug run. During a
>>> debugging session, you can then always cross check in which generated
>>> part of the interpreter you are. For a HotSpot debug build, you can
>>> also call the global "help()" function right from the debuger prompt.
>>> This will list some global helper functions from within libjvm.so
>>> which can be used during debugging (among them "find(<address>" which
>>> can be used to print out some information about an address which
>>> belongs to the VM (e.g. a compiled method, an interpreter template, a
>>> stub and s.o.)).
>>>
>>> - the "-XX:StopInterpreterAt=<bytecodenumber>" is implemented in such
>>> a way, that every generated Java bytecode template first of all
>>> increments a global bytecode counter and then checks its value against
>>> the argument of "StopInterpreterAt". If the two numbers are equal, the
>>> global function "breakpoint()" will be called. "breakpoint()" is an
>>> empty, global C-function defined in "src/os/linux/vm/os_linux.cpp". If
>>> you want to stop at the execution of a certain Java bytecode, you
>>> should first of all run your program with "-XX:+TraceBytecodes" to
>>> determine the exact position of the bytecode you're interested in
>>> (hopefully this won't take to long, because indeed the VM already
>>> executes about half a million bytecodes before even arriving to your
>>> program's "main()" method - this is all class loading and
>>> initialization stuff). Then start the VM again with the appropriate
>>> "StopInterpreterAt" option AND set a breakpoint for the global
>>> "breakpoint()" function. The VM will now stop just before the
>>> execution of the bytecode you're interested in, but it will stop in
>>> the "breakpoint()" function. Issuing a "finish" command in gdb, will
>>> return you to the code template you're interested in (you should be
>>> able to verify this by looking up the current address within the file
>>> which contains the generated interpreter that we've created in the
>>> previous step). Notice that at this point, all you can do in gdb is
>>> stepping at assembler level ("stepi", "nexti") because you're in
>>> generated code now and there is no associated symbolic information for
>>> this code ("next" and "step" won't work).
>>>
>>>
>>> - certain, complex functionality of some bytecodes isn't handled
>>> directly in the generated code. Instead, some helper methods
>>> implemented in C++ in the VM are called. This is the case for example
>>> for InterpreterRuntime::monitorenter. You can check the bytecode
>>> generators, to see where there are calls into the runtime.
>>>
>>> Hope this helps.
>>> Regards,
>>> Volker
>>>
>>> On Mon, Jan 5, 2009 at 6:32 AM,  <xinweix at cse.unsw.edu.au> wrote:
>>>> Hi Volker,
>>>>
>>>> Happy New Year.
>>>> Sorry to bother you. Thank you for your attention.
>>>>
>>>> I found your email about Hotspot build instruction from the hotspot-dev
>>>> maillist and your blog. I do appreciate your great help. However, I 
>>>> still
>>>> can't quite understand the mechanism of the interpreter in hotspot. May 
>>>> I
>>>> ask you some questions?
>>>>
>>>> 1) I used ddd, a graphic based client of gdb, to set up some 
>>>> breakpoints and
>>>> stepped into the hotspot jvm. I can find how exactly the bytecode is
>>>> executed, just like the following maillist:
>>>> http://markmail.org/message/lu6izmxpqzzej4lr?q=interpreter+openjdk&page=14#query:interpreter%20openjdk+page:14+mid:wvzcrnvxlqlj5oxa+state:results 
>>>> .Do
>>>> you have some idea about that?
>>>>
>>>> BTW, I successfully step into to breakpoint of StubRountes::call_stub 
>>>> while
>>>> using another debuger: "insight". I use '-XX:+TraceBytecode -Xint' to 
>>>> see
>>>> what is going in the Interpreter. However, it even generates a great
>>>> amount of bytecodes when it is initializing and load the system class. 
>>>> I
>>>> don't know when the interpreter runtime is initialized.
>>>>
>>>>
>>>> 2) I tried to use some options, as '-Xint', '-XX:StopInterpreterAt=1',
>>>> aiming at stopping at a specific bytecode when I can inspect the 
>>>> runtime
>>>> datastructure. Unfortunately I failed. I don't understand why
>>>> '-XX:StopInterpreterAt=1' doesn't work. The question is how to 
>>>> configure it
>>>> correctly that I can stop where exactly I want.
>>>>
>>>> 3) My object is to get some information, especially about the lock and
>>>> thread information when threads concurrently access a shared variant or 
>>>> try
>>>> to lock before access using monitorenter. Can you give me some advise 
>>>> how
>>>> and where I can start? Is it related to the
>>>> InterpreterRuntime::monitorenter?
>>>>
>>>> I am looking forward to hearing from you.
>>>>
>>>> Regards,
>>>>
>>>> Alex Xie,
>>>> University of New South Wales, Australia.
>>>
> 