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

Tue Jan 6 05:11:32 PST 2009

The fast path monitorenter in the template interpreter is in the
generated assembly code.  You can find how objects are locked in
interp_masm_<cpu type>.cpp in the function "lock_object()".
This function is called for the monitorenter bytecode in the template
interpreter, and in for synchronized methods for both the template and
cpp interpreters.
If you look in templateTable_<cpu type>.cpp for the function called
monitorenter, that is the code that the template interpreter generates
for monitorenter bytecode.
If the lock needs to be inflated or cannot go through the fast path it
will call the runtime function InterpreterRuntime::monitorenter().

To actually stop in the debugger for the "lock_object" call is tricky
since it's generated code.  One thing you can do is add 5 nops to the
monitorenter bytecode at the beginning of the template function and
recompile.  Then

Start the "gamma" command in gdb/dbx. 
Set a breakpoint in templateInterpreter right after the PrintInterpreter
line.  In current hotspot-rt repository that line is 599.
Run with -XX:+PrintInterpreter and redirect to a file.
Edit the file and find the monitorenter bytecode with your nops.
Use stopi at the hex address for the nops. The code before the nops is
entry points depending on the type that's on top of stack used by the
dispatcher.
Continue to breakpoint and stepi into the bytecode.

This is not much fun but hope it helps.
Coleen

On Tue, 2009-01-06 at 19:04 +0800, xinweix at cse.unsw.edu.au wrote:
> 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.
> >>>
> > 