From volker.simonis at gmail.com  Mon Oct  1 10:41:23 2007
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 1 Oct 2007 19:41:23 +0200
Subject: C++ Interpreter
Message-ID: <d65861880710011041s6daa630co6155fb1d365284ab@mail.gmail.com>

Hi,
as announced in the Changes for build 20 (see:
http://download.java.net/jdk7/changes/jdk7-b20.html) the C++
Interpreter that was formerly only available for the meanwhile closed
IA64 version of the Hotspot VM was "reintroduced" into the OpenJDK
workspace to resolve the Bug/RFE 6571248 (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6571248)

I built a debug version of the VM (b20) on Solaris/SPARC with
CC_INTERP=1 to get a VM that uses the C++ Interpreter. The build
succeeded, however the VM crashes at the very beginning with a SIGBUS
if I call:

java -server -d64 -version

I started to debug the VM and found that everything seems to run fine
until the first call of BytecodeInterpreter::run() for the
'invokestatic' Bytecode for 'java/lang/Object::<clinit>' (well that's
really the very beginning:). It runs till line 2253 in
BytecodeInterpreter::run() where the interpreter finished the
interpretation of the invokestatic bytecode and returns, however this
return fails.

Here's the stack just before the return:

(dbx) where
current thread: t at 2
=>[1] BytecodeInterpreter::run(istate = 0xffffffff7adfe6b0), line 2253
in "bytecodeInterpreter.cpp"
  [2] 0xffffffff76c05ce4(0xffffffff7ad09970, 0x9800, 0x0, 0x0, 0x0,
0xffffffff7adfdf91), at 0xffffffff76c05ce4
  [3] 0xffffffff76c00318(0xffffffff7adfe960, 0xffffffff7adfecb8, 0xa,
0xfffffffef1007fa0, 0xffffffff76c058c0, 0xffffffff7adfecd0), at
0xffffffff76c00318
  [4] JavaCalls::call_helper(result = 0xffffffff7adfecb0, m =
0xffffffff7adfebd8, args = 0xffffffff7adfecc0, __the_thread__ =
0x10013c8f8), line 382 in "javaCalls.cpp"
  [5] os::os_exception_wrapper(f = 0xffffffff7d755e50 =
&JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),
value = 0xffffffff7adfecb0, method = 0xffffffff7adfebd8, args =
0xffffffff7adfecc0, thread = 0x10013c8f8), line 3908 in
"os_solaris.cpp"
  [6] JavaCalls::call(result = 0xffffffff7adfecb0, method = CLASS,
args = 0xffffffff7adfecc0, __the_thread__ = 0x10013c8f8), line 301 in
"javaCalls.cpp"
  [7] instanceKlass::call_class_initializer_impl(this_oop = CLASS,
__the_thread__ = 0x10013c8f8), line 629 in "instanceKlass.cpp"
  [8] instanceKlass::call_class_initializer(this = 0xfffffffef1008030,
__the_thread__ = 0x10013c8f8), line 609 in "instanceKlass.cpp"
  [9] instanceKlass::initialize_impl(this_oop = CLASS, __the_thread__
= 0x10013c8f8), line 359 in "instanceKlass.cpp"
  [10] instanceKlass::initialize(this = 0xfffffffef1008030,
__the_thread__ = 0x10013c8f8), line 101 in "instanceKlass.cpp"
  [11] instanceKlass::initialize_impl(this_oop = CLASS, __the_thread__
= 0x10013c8f8), line 336 in "instanceKlass.cpp"
  [12] instanceKlass::initialize(this = 0xfffffffef1013a38,
__the_thread__ = 0x10013c8f8), line 101 in "instanceKlass.cpp"
  [13] initialize_class(class_name = CLASS, __the_thread__ =
0x10013c8f8), line 835 in "thread.cpp"
  [14] Threads::create_vm(args = 0xffffffff7adffda8, canTryAgain =
0xffffffff7adffcaf), line 2922 in "thread.cpp"
  [15] JNI_CreateJavaVM(vm = 0xffffffff7adffef8, penv =
0xffffffff7adffef0, args = 0xffffffff7adffda8), line 3248 in "jni.cpp"
  [16] InitializeJVM(pvm = 0xffffffff7adffef8, penv =
0xffffffff7adffef0, ifn = 0xffffffff7adfff08), line 1255 in "java.c"
  [17] JavaMain(_args = 0xffffffff7fffebd8), line 404 in "java.c"


Further stepping gives:

(dbx) step
t at 2 (l at 2) stopped in BytecodeInterpreter::run at line 2671 in file
"bytecodeInterpreter.cpp"
 2671   }
(dbx) step
t at 2 (l at 2) signal BUS (invalid address alignment) in (unknown) at
0xffffffff76c05e80
0xffffffff76c05e80:     ldx      [%l4 + 52], %l3
Current function is JavaCalls::call_helper
  382         StubRoutines::call_stub()(


Any ideas or hints? Is the C++ Interpreter for Sparc really functional
as of now (b20) or has it just been integrated into OpenJDK as a hint
for developpers how it could work?

Any comments are highly welcome.

Regards,
Volker


From Steve.Goldman at Sun.COM  Mon Oct  1 12:44:55 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Mon, 01 Oct 2007 15:44:55 -0400
Subject: C++ Interpreter
In-Reply-To: <d65861880710011041s6daa630co6155fb1d365284ab@mail.gmail.com>
References: <d65861880710011041s6daa630co6155fb1d365284ab@mail.gmail.com>
Message-ID: <47014E37.2040000@sun.com>

Volker Simonis wrote:

> 
> 
> Any ideas or hints? Is the C++ Interpreter for Sparc really functional
> as of now (b20) or has it just been integrated into OpenJDK as a hint
> for developpers how it could work?

Well the 64bit version has been smoke tested in the past. I mostly only 
did 32bit versions. The 32bit version is pretty lightly tested. jvmti 
most certainly has problems.

Looking at the code in the frame manager there are several mistakes in 
loading the result_index. Here's bad code

ld_ptr(L2_scratch, in_bytes(methodOopDesc::result_index_offset()), 
L2_scratch);

and the fix.

ld(L2_scratch, in_bytes(methodOopDesc::result_index_offset()), L2_scratch);

[ It's hard to see how the smoke test ever passed with these kind of 
mistakes.]


-- 
Steve


From volker.simonis at gmail.com  Tue Oct  2 07:59:30 2007
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 2 Oct 2007 16:59:30 +0200
Subject: C++ Interpreter
In-Reply-To: <47014E37.2040000@sun.com>
References: <d65861880710011041s6daa630co6155fb1d365284ab@mail.gmail.com>
	<47014E37.2040000@sun.com>
Message-ID: <d65861880710020759x68685b9dh54aed444cb4fb63d@mail.gmail.com>

On 10/1/07, steve goldman <Steve.Goldman at sun.com> wrote:
> Volker Simonis wrote:
>
> >
> >
> > Any ideas or hints? Is the C++ Interpreter for Sparc really functional
> > as of now (b20) or has it just been integrated into OpenJDK as a hint
> > for developpers how it could work?
>
> Well the 64bit version has been smoke tested in the past. I mostly only
> did 32bit versions. The 32bit version is pretty lightly tested. jvmti
> most certainly has problems.
>
> Looking at the code in the frame manager there are several mistakes in
> loading the result_index. Here's bad code
>
> ld_ptr(L2_scratch, in_bytes(methodOopDesc::result_index_offset()),
> L2_scratch);
>
> and the fix.
>
> ld(L2_scratch, in_bytes(methodOopDesc::result_index_offset()), L2_scratch);
>
> [ It's hard to see how the smoke test ever passed with these kind of
> mistakes.]
>

Hi Steve,

thank you for the assistence. Although your fix helps a little, the
Interpreter dosn't run much further. After applying the fix, I got an
assertion, which claims that the last_Java_sp is biased:

#  Internal Error
(/sapmnt/us4312/a/priv/d046063/p4/bas2/j2se/17_adapted/control/sap/../../hotspot/src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp:90),
pid=3756, tid=2
#  Error: assert(((intptr_t)_last_Java_sp & 0xF) == 0,"Biased last_Java_sp")

However I dont think that the last_Java_SP is really biased. It seems
that it is just not 16-byte aligned as expected, because it's value at
the assertion point is 0x7adfe8a8. If it would be really biased, it
should have an odd value, right?

So here's the complete stack at the point of the assertion:

=>[17] JavaFrameAnchor::last_Java_sp(this = 0x10013cac8), line 90 in
"javaFrameAnchor_sparc.hpp"
  [18] JavaFrameAnchor::make_walkable(this = 0x10013cac8, thread =
0x10013c8f8), line 515 in "frame_sparc.cpp"
  [19] JavaThread::last_frame(this = 0x10013c8f8), line 1256 in "thread.hpp"
  [20] InterpreterRuntime::last_frame(thread = 0x10013c8f8), line 37
in "interpreterRuntime.hpp"
  [21] InterpreterRuntime::method(thread = 0x10013c8f8), line 38 in
"interpreterRuntime.hpp"
  [22] InterpreterRuntime::resolve_invoke(thread = 0x10013c8f8,
bytecode = _invokestatic), line 617 in "interpreterRuntime.cpp"
  [23] BytecodeInterpreter::run(istate = 0xffffffff7adfe988), line
2200 in "bytecodeInterpreter.cpp"
  [24] 0xffffffff76c05ce4(0xffffffff7ad09990, 0x9800, 0x0, 0xdeaf003,
0xdeaf004, 0xffffffff7adfe269), at 0xffffffff76c05ce4
  [25] RecursiveInterpreterActivation(istate = 0xffffffff7d6f0f14),
line 38 in "cppInterpreter_sparc.cpp"
  [26] 0xffffffff76c00318(0xffffffff7adfede0, 0xffffffff7adff138, 0xa,
0xfffffffef1034eb8, 0xffffffff76c058c0, 0xffffffff7adff150), at
0xffffffff76c00318
  [27] JavaCalls::call_helper(result = 0xffffffff7adff130, m =
0xffffffff7adff058, args = 0xffffffff7adff140, __the_thread__ =
0x10013c8f8), line 382 in "javaCalls.cpp"
  [28] os::os_exception_wrapper(f = 0xffffffff7d755e50 =
&JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),
value = 0xffffffff7adff130, method = 0xffffffff7adff058, args =
0xffffffff7adff140, thread = 0x10013c8f8), line 3908 in
"os_solaris.cpp"
  [29] JavaCalls::call(result = 0xffffffff7adff130, method = CLASS,
args = 0xffffffff7adff140, __the_thread__ = 0x10013c8f8), line 301 in
"javaCalls.cpp"
  [30] instanceKlass::call_class_initializer_impl(this_oop = CLASS,
__the_thread__ = 0x10013c8f8), line 629 in "instanceKlass.cpp"
  [31] instanceKlass::call_class_initializer(this =
0xfffffffef1034f48, __the_thread__ = 0x10013c8f8), line 609 in
"instanceKlass.cpp"
  [32] instanceKlass::initialize_impl(this_oop = CLASS, __the_thread__
= 0x10013c8f8), line 359 in "instanceKlass.cpp"
  [33] instanceKlass::initialize(this = 0xfffffffef1034f48,
__the_thread__ = 0x10013c8f8), line 101 in "instanceKlass.cpp"
  [34] initialize_class(class_name = CLASS, __the_thread__ =
0x10013c8f8), line 835 in "thread.cpp"
  [35] Threads::create_vm(args = 0xffffffff7adffda8, canTryAgain =
0xffffffff7adffcaf), line 2929 in "thread.cpp"
  [36] JNI_CreateJavaVM(vm = 0xffffffff7adffef8, penv =
0xffffffff7adffef0, args = 0xffffffff7adffda8), line 3248 in "jni.cpp"
  [37] InitializeJVM(pvm = 0xffffffff7adffef8, penv =
0xffffffff7adffef0, ifn = 0xffffffff7adfff08), line 1255 in "java.c"
  [38] JavaMain(_args = 0xffffffff7fffebc8), line 404 in "java.c"

After your 'encouraging words' about the state of the C++ Interpreter,
I tried a 32 bit build and it built and ran. So this seems to be yet
another 64 bit problem. Any idea what's wrong now?

I also tried a 32 bit build on Linux/Intel. The debug build succeeded
(and ran) out of the box, but the opt had some problems because of an
error in the labels array  " opclabels_data" in
bytecodeInterpreter.cpp. Attached you can find a patch that solves the
problem. So at least on Linux/x86 the C++ Interpreter seems to be
usabel (i.e. it runs JVM98 with -Xint).

What about the defects detected so far (the fix supplied by you and
the patch for bytecodeInterpreter.cpp). Would you be so kind to open a
Java bug report or should I do this myself?

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytecodeInterpreter.patch
Type: text/x-patch
Size: 1819 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071002/695169ac/attachment.bin 

From Steve.Goldman at Sun.COM  Tue Oct  2 09:53:46 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Tue, 02 Oct 2007 12:53:46 -0400
Subject: C++ Interpreter
In-Reply-To: <d65861880710020759x68685b9dh54aed444cb4fb63d@mail.gmail.com>
References: <d65861880710011041s6daa630co6155fb1d365284ab@mail.gmail.com>
	<47014E37.2040000@sun.com>
	<d65861880710020759x68685b9dh54aed444cb4fb63d@mail.gmail.com>
Message-ID: <4702779A.2060006@sun.com>

Volker Simonis wrote:
>
> 
> Hi Steve,
> 
> thank you for the assistence. Although your fix helps a little, the
> Interpreter dosn't run much further. After applying the fix, I got an
> assertion, which claims that the last_Java_sp is biased:
> 
> #  Internal Error
> (/sapmnt/us4312/a/priv/d046063/p4/bas2/j2se/17_adapted/control/sap/../../hotspot/src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp:90),
> pid=3756, tid=2
> #  Error: assert(((intptr_t)_last_Java_sp & 0xF) == 0,"Biased last_Java_sp")
> 
> However I dont think that the last_Java_SP is really biased. It seems
> that it is just not 16-byte aligned as expected, because it's value at
> the assertion point is 0x7adfe8a8. If it would be really biased, it
> should have an odd value, right?

Yep. I suspect in the ages since 64bit sparc ran it has had lots of bit 
rot. I'll look at getting it going but it isn't likely to be too soon.


> After your 'encouraging words' about the state of the C++ Interpreter,
> I tried a 32 bit build and it built and ran. So this seems to be yet
> another 64 bit problem. Any idea what's wrong now?

I suspect that the frame manager isn't doing proper alignment of the 
stack it is creating.

> 
> I also tried a 32 bit build on Linux/Intel. The debug build succeeded
> (and ran) out of the box, but the opt had some problems because of an
> error in the labels array  " opclabels_data" in
> bytecodeInterpreter.cpp. Attached you can find a patch that solves the
> problem. So at least on Linux/x86 the C++ Interpreter seems to be
> usabel (i.e. it runs JVM98 with -Xint).
> 
> What about the defects detected so far (the fix supplied by you and
> the patch for bytecodeInterpreter.cpp). Would you be so kind to open a
> Java bug report or should I do this myself?

I'll open a bug and work on getting them fixed. It will be a while 
(weeks) as the workspace situation is about to get quite interesting 
around here as we are switching from teamware to mercurial very shortly 
and my "real" work does have higher priority.

-- 
Steve


From twisti at complang.tuwien.ac.at  Fri Oct  5 13:09:50 2007
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Fri, 05 Oct 2007 22:09:50 +0200
Subject: UnsatisfiedLinkError and stracktraces
Message-ID: <1191614990.25199.13.camel@localhost.localdomain>

Hi!

I have two questions about stacktraces in general and the stacktrace of
an UnsatisfiedLinkError in particular.

The normal stacktrace generated by such an error is:

java.lang.UnsatisfiedLinkError: extest.nsub()V
        at extest.nsub(Native Method)
        at extest.main(extest.java:336)

Questions:

1. Is there somewhere a specification of what methods need to be in the
stacktrace?  Would it also be OK to print something like this:

java.lang.UnsatisfiedLinkError: nsub
        at java.lang.Throwable.fillInStackTrace(Native Method)
        at java.lang.Throwable.<init>(Throwable.java:214)
        at java.lang.Error.<init>(Error.java:67)
        at java.lang.LinkageError.<init>(LinkageError.java:54)
        at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedLinkError.java:53)
        at extest.nsub(Native Method)
        at extest.main(extest.java:336)

2. What is the reason the failing native method is in the stacktrace?
Actually it isn't called.  I guess it's something about the way native
methods are called in HotSpot (e.g. native stubs).  Would this be OK
too:

java.lang.UnsatisfiedLinkError: extest.nsub()V
        at extest.main(extest.java:336)

- twisti



From Thomas.Rodriguez at Sun.COM  Fri Oct  5 13:30:42 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Fri, 05 Oct 2007 13:30:42 -0700
Subject: UnsatisfiedLinkError and stracktraces
In-Reply-To: <1191614990.25199.13.camel@localhost.localdomain>
References: <1191614990.25199.13.camel@localhost.localdomain>
Message-ID: <47069EF2.2050000@sun.com>

> 1. Is there somewhere a specification of what methods need to be in the
> stacktrace?  Would it also be OK to print something like this:
> 
> java.lang.UnsatisfiedLinkError: nsub
>         at java.lang.Throwable.fillInStackTrace(Native Method)
>         at java.lang.Throwable.<init>(Throwable.java:214)
>         at java.lang.Error.<init>(Error.java:67)
>         at java.lang.LinkageError.<init>(LinkageError.java:54)
>         at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedLinkError.java:53)
>         at extest.nsub(Native Method)
>         at extest.main(extest.java:336)

I don't think there's a specification of what should be in a stack trace other 
than the vague language that they are precise.  The standard logic we use for 
recording stack traces skips the exception constructor frames since they're 
really just noise.  I think some printing functions for chained exceptions will 
only dump a few frames of the stack trace and wasting five of them may make 
those printouts less useful.  With the Throwable.getStackTrace API it's possible 
to programmatically inspect trace information which could conceivably expose 
differences between implementations but that seems like stretch.

> 2. What is the reason the failing native method is in the stacktrace?
> Actually it isn't called.  I guess it's something about the way native
> methods are called in HotSpot (e.g. native stubs).  Would this be OK
> too:
> 
> java.lang.UnsatisfiedLinkError: extest.nsub()V
>         at extest.main(extest.java:336)

I believe that at the point we throw it we've already pushed a frame for the 
native method so we could start invoking it and then we discover that we can't 
link it which is why it shows up in the call stack.  I can't think of any reason 
why one would be preferred over the other.

tom


From twisti at complang.tuwien.ac.at  Fri Oct  5 15:02:32 2007
From: twisti at complang.tuwien.ac.at (Christian Thalinger)
Date: Sat, 06 Oct 2007 00:02:32 +0200
Subject: UnsatisfiedLinkError and stracktraces
In-Reply-To: <47069EF2.2050000@sun.com>
References: <1191614990.25199.13.camel@localhost.localdomain>
	<47069EF2.2050000@sun.com>
Message-ID: <1191621752.25199.16.camel@localhost.localdomain>

On Fri, 2007-10-05 at 13:30 -0700, Tom Rodriguez wrote:
> > 1. Is there somewhere a specification of what methods need to be in the
> > stacktrace?  Would it also be OK to print something like this:
> > 
> > java.lang.UnsatisfiedLinkError: nsub
> >         at java.lang.Throwable.fillInStackTrace(Native Method)
> >         at java.lang.Throwable.<init>(Throwable.java:214)
> >         at java.lang.Error.<init>(Error.java:67)
> >         at java.lang.LinkageError.<init>(LinkageError.java:54)
> >         at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedLinkError.java:53)
> >         at extest.nsub(Native Method)
> >         at extest.main(extest.java:336)
> 
> I don't think there's a specification of what should be in a stack trace other 
> than the vague language that they are precise.  The standard logic we use for 
> recording stack traces skips the exception constructor frames since they're 
> really just noise.  I think some printing functions for chained exceptions will 
> only dump a few frames of the stack trace and wasting five of them may make 
> those printouts less useful.  With the Throwable.getStackTrace API it's possible 
> to programmatically inspect trace information which could conceivably expose 
> differences between implementations but that seems like stretch.

Yes, I agree they are just noise.  I only showed this example to make my
point clear.

> 
> > 2. What is the reason the failing native method is in the stacktrace?
> > Actually it isn't called.  I guess it's something about the way native
> > methods are called in HotSpot (e.g. native stubs).  Would this be OK
> > too:
> > 
> > java.lang.UnsatisfiedLinkError: extest.nsub()V
> >         at extest.main(extest.java:336)
> 
> I believe that at the point we throw it we've already pushed a frame for the 
> native method so we could start invoking it and then we discover that we can't 
> link it which is why it shows up in the call stack.  I can't think of any reason 
> why one would be preferred over the other.

So we could simply leave the native one out.

- twisti



From Thomas.Rodriguez at Sun.COM  Mon Oct  8 13:52:18 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Mon, 08 Oct 2007 13:52:18 -0700
Subject: UnsatisfiedLinkError and stracktraces
In-Reply-To: <1191621752.25199.16.camel@localhost.localdomain>
References: <1191614990.25199.13.camel@localhost.localdomain>
	<47069EF2.2050000@sun.com>
	<1191621752.25199.16.camel@localhost.localdomain>
Message-ID: <470A9882.6030609@sun.com>

>>> java.lang.UnsatisfiedLinkError: extest.nsub()V
>>>         at extest.main(extest.java:336)
>> I believe that at the point we throw it we've already pushed a frame for the 
>> native method so we could start invoking it and then we discover that we can't 
>> link it which is why it shows up in the call stack.  I can't think of any reason 
>> why one would be preferred over the other.
> 
> So we could simply leave the native one out.

That would seems reasonable to me.

tom


From ted at tedneward.com  Sun Oct 14 13:33:58 2007
From: ted at tedneward.com (Ted Neward)
Date: Sun, 14 Oct 2007 13:33:58 -0700
Subject: JVM internals documentation?
Message-ID: <09ec01c80ea1$8e8c6bf0$aba543d0$@com>

I?m looking to start crawling through the JVM sources, and was just looking
for documentation to help keep the major parts (GC, JIT compiler,
Reflection, ClassLoaders, etc) straight. John Rose mentioned that there may
be some ?internals? documentation/specs that describe some of the internal
data structures and such?are those available, and if not, is there a plan to
open-source them real-soon-now?

 

 

Ted Neward

Java, .NET, XML Services

Consulting, Teaching, Speaking, Writing

HYPERLINK "http://www.tedneward.com"http://www.tedneward.com

 


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date: 10/14/2007
9:22 AM
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071014/c64c44fc/attachment.html 

From James.Melvin at Sun.COM  Sun Oct 14 13:40:05 2007
From: James.Melvin at Sun.COM (James Melvin)
Date: Sun, 14 Oct 2007 16:40:05 -0400
Subject: JVM internals documentation?
In-Reply-To: <09ec01c80ea1$8e8c6bf0$aba543d0$@com>
References: <09ec01c80ea1$8e8c6bf0$aba543d0$@com>
Message-ID: <47127EA5.6080308@sun.com>

Hi Ted,

Here is a good place to start...

http://openjdk.java.net/groups/hotspot

There are several docs covering various Hotspot subsystems and
internals, including a glossary of terms.


Thanks,

Jim


Ted Neward wrote:
> 
> 
> I?m looking to start crawling through the JVM sources, and was just 
> looking for documentation to help keep the major parts (GC, JIT 
> compiler, Reflection, ClassLoaders, etc) straight. John Rose mentioned 
> that there may be some ?internals? documentation/specs that describe 
> some of the internal data structures and such?are those available, and 
> if not, is there a plan to open-source them real-soon-now?
> 
>  
> 
>  
> 
> Ted Neward
> 
> Java, .NET, XML Services
> 
> Consulting, Teaching, Speaking, Writing
> 
> http://www.tedneward.com
> 
>  
> 
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date: 
> 10/14/2007 9:22 AM
> 


From ted at tedneward.com  Mon Oct 15 18:46:51 2007
From: ted at tedneward.com (Ted Neward)
Date: Mon, 15 Oct 2007 18:46:51 -0700
Subject: JVM internals documentation?
In-Reply-To: <47127EA5.6080308@sun.com>
References: <09ec01c80ea1$8e8c6bf0$aba543d0$@com> <47127EA5.6080308@sun.com>
Message-ID: <002501c80f96$6f0c5790$4d2506b0$@com>

I knew about that already; is there anything "deeper" and/or more detailed?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: James.Melvin at Sun.COM [mailto:James.Melvin at Sun.COM]
> Sent: Sunday, October 14, 2007 1:40 PM
> To: Ted Neward
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: JVM internals documentation?
> 
> Hi Ted,
> 
> Here is a good place to start...
> 
> http://openjdk.java.net/groups/hotspot
> 
> There are several docs covering various Hotspot subsystems and
> internals, including a glossary of terms.
> 
> 
> Thanks,
> 
> Jim
> 
> 
> Ted Neward wrote:
> >
> >
> > I?m looking to start crawling through the JVM sources, and was just
> > looking for documentation to help keep the major parts (GC, JIT
> > compiler, Reflection, ClassLoaders, etc) straight. John Rose
> mentioned
> > that there may be some ?internals? documentation/specs that describe
> > some of the internal data structures and such?are those available,
> and
> > if not, is there a plan to open-source them real-soon-now?
> >
> >
> >
> >
> >
> > Ted Neward
> >
> > Java, .NET, XML Services
> >
> > Consulting, Teaching, Speaking, Writing
> >
> > http://www.tedneward.com
> >
> >
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date:
> > 10/14/2007 9:22 AM
> >
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.14.10/1070 - Release Date:
> 10/14/2007 9:22 AM
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.14.11/1071 - Release Date: 10/15/2007
6:48 AM
 



From gbenson at redhat.com  Tue Oct 16 02:29:43 2007
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 16 Oct 2007 10:29:43 +0100
Subject: Bug?
Message-ID: <20071016092943.GC3597@redhat.com>

Hi all,

I'm looking at hotspot/src/share/vm/runtime/signature.hpp from b22.
Is line 285 really correct?

Cheers,
Gary


From sunils at cs.ucsb.edu  Tue Oct 16 06:05:17 2007
From: sunils at cs.ucsb.edu (Sunil Soman)
Date: Tue, 16 Oct 2007 06:05:17 -0700
Subject: Bug?
In-Reply-To: <20071016092943.GC3597@redhat.com>
References: <20071016092943.GC3597@redhat.com>
Message-ID: <2E76F5E1-FE37-48ED-86B9-65C24AEBDC44@cs.ucsb.edu>

Hi Gary,

I suppose that you mean the call to "pass_int" instead of  
"pass_float" when LP64 is undefd? Not entirely sure about intel, but  
from interpreter_sparc.cpp:

"   301 // LP64 passes floating point arguments in F1, F3, F5, etc.  
instead of
     302 // O0, O1, O2 etc..
     303 // Doubles are passed in D0, D2, D4
     304 // We store the signature of the first 16 arguments in the  
first argument
     305 // slot because it will be overwritten prior to calling the  
native
     306 // function, with the pointer to the JNIEnv.
     307 // If LP64 there can be up to 16 floating point arguments in  
registers
     308 // or 6 integer registers."


Hope that helps.
Sunil

On Oct 16, 2007, at 2:29 AM, Gary Benson wrote:

> Hi all,
>
> I'm looking at hotspot/src/share/vm/runtime/signature.hpp from b22.
> Is line 285 really correct?
>
> Cheers,
> Gary
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071016/f68f7754/attachment.html 

From Steve.Goldman at Sun.COM  Tue Oct 16 06:19:07 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Tue, 16 Oct 2007 09:19:07 -0400
Subject: Bug?
In-Reply-To: <20071016092943.GC3597@redhat.com>
References: <20071016092943.GC3597@redhat.com>
Message-ID: <4714BA4B.4030500@sun.com>

Gary Benson wrote:
> Hi all,
> 
> I'm looking at hotspot/src/share/vm/runtime/signature.hpp from b22.
> Is line 285 really correct?
> 

for the current platforms, yes. On 32bit sparc and any x86 floats aren't 
passed in registers so they can be treated like int (I refuse to go look 
at the ia64 abi). No doubt it would be cleaner here to make the abstract 
code here use float/double to let the implemenation decide what to do.

-- 
Steve


From gbenson at redhat.com  Tue Oct 16 06:29:05 2007
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 16 Oct 2007 14:29:05 +0100
Subject: Bug?
In-Reply-To: <4714BA4B.4030500@sun.com>
References: <20071016092943.GC3597@redhat.com> <4714BA4B.4030500@sun.com>
Message-ID: <20071016132905.GE3597@redhat.com>

steve goldman wrote:
> Gary Benson wrote:
> > I'm looking at hotspot/src/share/vm/runtime/signature.hpp from b22.
> > Is line 285 really correct?
> 
> for the current platforms, yes. On 32bit sparc and any x86 floats
> aren't passed in registers so they can be treated like int (I
> refuse to go look at the ia64 abi). No doubt it would be cleaner
> here to make the abstract code here use float/double to let the
> implemenation decide what to do.

I had to change this for PPC32 as they're passed in registers there.
I guess I'll end up patching the other platforms once my stuff goes
into IcedTea or wherever.

Cheers,
Gary


From bccheng at google.com  Thu Oct 18 17:48:23 2007
From: bccheng at google.com (Ben Cheng)
Date: Thu, 18 Oct 2007 17:48:23 -0700
Subject: inspecting hotspot code using gdb
Message-ID: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>

Hello,

I tried to set a breakpoint in a Hotspot function, say
"ciEnv::register_method", under gdb, but gdb couldn't seem to find the
symbols. I am using my locally built libjvm.so so symbols should be there,
so I am thinking that feeding the java launcher to gdb is the wrong thing to
do here.

Can someone explain the procedures to debug hotspot under gdb?

Thanks,
-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071018/0c037417/attachment.html 

From Thomas.Rodriguez at Sun.COM  Thu Oct 18 18:09:40 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 18 Oct 2007 18:09:40 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
Message-ID: <471803D4.3080303@sun.com>

Using a debugger with the java launcher can be a little tricky since it normally 
sets up the LD_LIBRARY_PATH and relaunches the VM to select the right libjvm.so 
which makes debuggers unhappy.  libjvm.so is also dynamically loaded so they 
symbols won't be available until you've at least run it once.  Your 
LD_LIBRARY_PATH should be set to the value of the java.library.path property 
from the VM you want to run.  gdb will get into various bad states if you don't 
do this part.  Also by default you also want to suppress a lot of signals that 
the JVM uses.

I attached the script I use for launching the VM under a debugger.  It works for 
dbx and gdb and has a little Java class for getting the java.library.path 
property from a VM.  You just prefix dbxr onto the full command line you want to 
debug and it sets everything up for you.  The script is a little ugly and has 
some special bits to deal with getting properties from a JVM which might be at 
least a little broken.  Obviously if you are trying to debug a JVM which won't 
even boot then it will be hard to get properties from it.  It's possible to 
derive the proper LD_LIBRARY_PATH setting from the location of the JDK but that 
was error prone enough that I switched to using a class to read it out.  Anyway, 
hopefully it will be useful.

tom

Ben Cheng wrote:
> Hello,
> 
> I tried to set a breakpoint in a Hotspot function, say 
> "ciEnv::register_method", under gdb, but gdb couldn't seem to find the 
> symbols. I am using my locally built libjvm.so so symbols should be 
> there, so I am thinking that feeding the java launcher to gdb is the 
> wrong thing to do here.
> 
> Can someone explain the procedures to debug hotspot under gdb?
> 
> Thanks,
> -Ben
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dbxr
Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071018/bd5b2712/attachment.ksh 

From neojia at gmail.com  Thu Oct 18 22:21:23 2007
From: neojia at gmail.com (Neo Jia)
Date: Thu, 18 Oct 2007 22:21:23 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <471803D4.3080303@sun.com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
	<471803D4.3080303@sun.com>
Message-ID: <5d649bdb0710182221u3713519dpd4ad68b00e410a61@mail.gmail.com>

Ben,

I have used gdb a lot on Linux platform to debug VM, which works great
(X86-64 and 32bit).

I would suggest you to add the following  to file
hotspot/build/linux/makefiles/gcc.make

DEBUG_CFLAGS += -ggdb3, which will make gdb much happier for C++ code.

For the LD path problem, I think that is just a workaround for the old
gdb version since the jvm will execve another process if it cannot
find something expected from the LD path. But that bug is already
fixed in gdb 6.5.

Once, you build your VM first time. You may then do an incremental
build from hotspot/build/linux, which will only create the .so you
need.

BTW, if you use ccache, it will speed up your work greatly.

Thanks,
Neo


On 10/18/07, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> Using a debugger with the java launcher can be a little tricky since it normally
> sets up the LD_LIBRARY_PATH and relaunches the VM to select the right libjvm.so
> which makes debuggers unhappy.  libjvm.so is also dynamically loaded so they
> symbols won't be available until you've at least run it once.  Your
> LD_LIBRARY_PATH should be set to the value of the java.library.path property
> from the VM you want to run.  gdb will get into various bad states if you don't
> do this part.  Also by default you also want to suppress a lot of signals that
> the JVM uses.
>
> I attached the script I use for launching the VM under a debugger.  It works for
> dbx and gdb and has a little Java class for getting the java.library.path
> property from a VM.  You just prefix dbxr onto the full command line you want to
> debug and it sets everything up for you.  The script is a little ugly and has
> some special bits to deal with getting properties from a JVM which might be at
> least a little broken.  Obviously if you are trying to debug a JVM which won't
> even boot then it will be hard to get properties from it.  It's possible to
> derive the proper LD_LIBRARY_PATH setting from the location of the JDK but that
> was error prone enough that I switched to using a class to read it out.  Anyway,
> hopefully it will be useful.
>
> tom
>
> Ben Cheng wrote:
> > Hello,
> >
> > I tried to set a breakpoint in a Hotspot function, say
> > "ciEnv::register_method", under gdb, but gdb couldn't seem to find the
> > symbols. I am using my locally built libjvm.so so symbols should be
> > there, so I am thinking that feeding the java launcher to gdb is the
> > wrong thing to do here.
> >
> > Can someone explain the procedures to debug hotspot under gdb?
> >
> > Thanks,
> > -Ben
>
> #!/bin/sh
> tmpdir=/tmp/dbxr.$$
> tmpcmd=$tmpdir/cmd
>
> rm -fr $tmpdir
> mkdir -p $tmpdir
> clean_tmp_files() {
>     rm -fr $tmpdir
> }
>
> arch=
> if [ -f /proc/cpuinfo ] ; then
>   arch=`uname -m`
>   if [ "$arch" = i686 ]; then
>     arch=i386
>   fi
> else
>   arch=`uname -p`
> fi
> if [ -z "$arch" ]; then
>   echo "Unknown architecture.  Exiting..."
>   exit 1
> fi
>
> exe=$1
> if [ ! -x "$1" ]; then
>   exe=`which $1`
> fi
> shift
>
> trap clean_tmp_files 2
>
> usage() {
>   echo "Usage: dbxr [ -dbx | -gdb ] [ -window ] [ -core ] [ -corefile <file> ] command ..."
>   exit
> }
>
> if [ `uname` = "SunOS" ]; then
>     debugger=dbx
> else
>     which dbx 2>&1 > /dev/null
>     if [ $? -eq 0 ]; then
>       debugger=dbx
>     else
>       debugger=gdb
>     fi
> fi
>
> debugargs=
> debugprecmd=
> fastdebug=
> while [ $# -gt 0 ]; do
>     if [ $1 = -core ] ; then
>         debugargs=core
>         shift
>     elif [ $1 = -corefile ] ; then
>         debugargs="$2"
>         shift 2
>     elif [ $1 = -help ] ; then
>         usage
>     elif [ $1 = -dbx ] ; then
>         debugger=dbx
>         shift
>     elif [ $1 = -gdb ] ; then
>         debugger=gdb
>         shift
>     elif [ $1 = -window ] ; then
>         if [ -x /usr/dt/bin/dtterm ]; then
>             debugprecmd="/usr/dt/bin/dtterm -e"
>         else
>             debugprecmd="xterm -e"
>         fi
>         shift
>     elif [ $1 = -echo ] ; then
>         debugprecmd="echo"
>         shift
>     else
>         break;
>     fi
> done
>
> cat - > $tmpdir/props.class.uu <<'EOF'
> begin 644 props.class
> MROZZO@   "X )0H !P 0"0 1 !(* !$ $PH %  5"@ 6 !<' !@' !D!  8\
> M:6YI=#X!  ,H*58!  1#;V1E 0 /3&EN94YU;6)E<E1A8FQE 0 $;6%I;@$
> M%BA;3&IA=F$O;&%N9R]3=')I;F<[*58!  I3;W5R8V5&:6QE 0 *<')O<',N
> M:F%V80P "  )!P :#  ; !P, !T '@< 'PP (  A!P B#  C "0!  5P<F]P
> M<P$ $&IA=F$O;&%N9R]/8FIE8W0! !!J879A+VQA;F<O4WES=&5M 0 #;W5T
> M 0 53&IA=F$O:6\O4')I;G13=')E86T[ 0 -9V5T4')O<&5R=&EE<P$ &"@I
> M3&IA=F$O=71I;"]0<F]P97)T:65S.P$ %&IA=F$O=71I;"]0<F]P97)T:65S
> M 0 #9V5T 0 F*$QJ879A+VQA;F<O3V)J96-T.RE,:F%V82]L86YG+T]B:F5C
> M=#L! !-J879A+VEO+U!R:6YT4W1R96%M 0 '<')I;G1L;@$ %2A,:F%V82]L
> M86YG+T]B:F5C=#LI5@ A  8 !P       @ !  @ "0 !  H    =  $  0
> M  4JMP !L0    $ "P    8  0    $ "0 ,  T  0 *    0@ $  (    >
> M SP;*KZB !BR  *X  ,J&S*V  2V  6$ 0&G_^BQ     0 +    $@ $
> 7 P (  0 %P # !T !@ !  X    "  ^$
>
> end
> EOF
>
> (cd $tmpdir; uudecode props.class.uu)
>
> jvmver() {
>   jvmargs=
>   while [ "$#" -gt 0 ]; do
>     case "$1" in
>     "-client")   jvmargs="$jvmargs $1"; shift;;
>     "-server")   jvmargs="$jvmargs $1"; shift;;
>     "-d64")      jvmargs="$jvmargs $1";
>                  j=`basename $exe`
>                  nog=`basename $exe _g`
>                  d=`dirname $exe`
>                  if [ -f $d/sparcv9/$j ]; then
>                     exe=$d/sparcv9/$j
>                  elif [ -f $d/../fastdebug/bin/sparcv9/$nog ]; then
>                     exe=$d/../fastdebug/bin/sparcv9/$nog
>                  fi
>                  if [ -f $d/amd64/$j ]; then
>                     exe=$d/amd64/$j
>                  elif [ -f $d/../fastdebug/bin/amd64/$nog ]; then
>                     exe=$d/../fastdebug/bin/amd64/$nog
>                  fi
>                  shift;;
>      -*) shift;;
>      *) break;;
>     esac
>   done
> }
>
> jvmver $*
>
> # use -Xint in case the VM won't boot with the compiler
> LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions -XX:-DisplayVMOutput props java.library.path 2>/dev/null | grep -v "VM option"`
> if [ $? -ne 0 ]; then
>   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions -XX:-DisplayVMOutput -XX:+Debugging props java.library.path 2>/dev/null | grep -v "VM option"`
> fi
> if [ $? -ne 0 ]; then
>   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir  -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -XX:-DisplayVMOutput -XX:-PrintVMOptions -XX:-DisplayVMOutput props java.library.path 2>/dev/null | grep -v "VM option"`
> fi
> if [ $? -ne 0 ]; then
>   echo "Error getting LD_LIBRARY_PATH"
>   $exe $jvmargs -Xint -cp $tmpdir -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -XX:-DisplayVMOutput props java.library.path
>   exit 1
> fi
> export LD_LIBRARY_PATH
>
> if [ $debugger = "gdb" ] ; then
>     echo "handle SIGSEGV noprint nostop pass" >> $tmpcmd
>     echo "handle SIGUSR2 noprint nostop pass" >> $tmpcmd
>     echo "handle SIGILL  noprint nostop pass" >> $tmpcmd
>     echo "handle SIGFPE  noprint nostop pass" >> $tmpcmd
>     echo "handle SIG32   noprint nostop pass" >> $tmpcmd
>     echo "handle SIGABRT print stop nopass" >> $tmpcmd
>     echo "shell rm -fr $tmpdir" >> $tmpcmd
>     echo "set args $*" >> $tmpcmd
>     exec $debugprecmd $debugger --command=$tmpcmd $exe
> else
>     rm -f $tmpcmd
>     if [ "$debugargs" != "" ]; then
>         echo "debug $exe $debugargs" > $tmpcmd
>     else
>         echo "debug $exe" >> $tmpcmd
>         echo "runargs $*" >> $tmpcmd
>     fi
>     echo "if [ -f ~/.dbxr.rc ]; then source ~/.dbxr.rc; fi" >> $tmpcmd
>     echo "sh rm -fr $tmpdir" >> $tmpcmd
>     exec $debugprecmd $debugger -c "source $tmpcmd"
> fi
>
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From bccheng at google.com  Thu Oct 18 23:10:04 2007
From: bccheng at google.com (Ben Cheng)
Date: Thu, 18 Oct 2007 23:10:04 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <5d649bdb0710182221u3713519dpd4ad68b00e410a61@mail.gmail.com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
	<471803D4.3080303@sun.com>
	<5d649bdb0710182221u3713519dpd4ad68b00e410a61@mail.gmail.com>
Message-ID: <bcf6f6d40710182310l2f9d7636i39761c00151c4b50@mail.gmail.com>

Thanks guys. I am seeing improvements, but gdb still doesn't accept my
breakpoint through typing "b 'ciEnv::register_method':

(gdb) b 'ciEnv::register_method'
Can't find member of namespace, class, struct, or union named
"ciEnv::register_method"
Hint: try 'ciEnv::register_method'<TAB> or 'ciEnv::register_method'<ESC-?>
(Note leading single quote.)

I am using gdb6.6, and locally compiled libjvm.so with the -ggdb3 flag added
on linux.

After adding the various handle instructions in gdb I was able to run my
java code all the way to the end, which is a major progress! I then hacked
ciEnv::register_method() to have the following line added:

  printf("ciEnv::register_method: %p\n", &ciEnv::register_method);

and in my gdb session I see a lot of invocations of it:

ciEnv::register_method: 0x2aaaaaf5326e
ciEnv::register_method: 0x2aaaaaf5326e
        :
        :

However, the only way to break there is using the hex address directly. The
symbolic name is still not recognized by gdb. It will be pretty dumb if I
used the wrong gdb command to set breakpoints. Just to rule out the case
could you share with me the exact command you used in gdb to set up such a
breakpoint?

Thanks,
-Ben

On 10/18/07, Neo Jia <neojia at gmail.com> wrote:
>
> Ben,
>
> I have used gdb a lot on Linux platform to debug VM, which works great
> (X86-64 and 32bit).
>
> I would suggest you to add the following  to file
> hotspot/build/linux/makefiles/gcc.make
>
> DEBUG_CFLAGS += -ggdb3, which will make gdb much happier for C++ code.
>
> For the LD path problem, I think that is just a workaround for the old
> gdb version since the jvm will execve another process if it cannot
> find something expected from the LD path. But that bug is already
> fixed in gdb 6.5.
>
> Once, you build your VM first time. You may then do an incremental
> build from hotspot/build/linux, which will only create the .so you
> need.
>
> BTW, if you use ccache, it will speed up your work greatly.
>
> Thanks,
> Neo
>
>
> On 10/18/07, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> > Using a debugger with the java launcher can be a little tricky since it
> normally
> > sets up the LD_LIBRARY_PATH and relaunches the VM to select the right
> libjvm.so
> > which makes debuggers unhappy.  libjvm.so is also dynamically loaded so
> they
> > symbols won't be available until you've at least run it once.  Your
> > LD_LIBRARY_PATH should be set to the value of the java.library.pathproperty
> > from the VM you want to run.  gdb will get into various bad states if
> you don't
> > do this part.  Also by default you also want to suppress a lot of
> signals that
> > the JVM uses.
> >
> > I attached the script I use for launching the VM under a debugger.  It
> works for
> > dbx and gdb and has a little Java class for getting the
> java.library.path
> > property from a VM.  You just prefix dbxr onto the full command line you
> want to
> > debug and it sets everything up for you.  The script is a little ugly
> and has
> > some special bits to deal with getting properties from a JVM which might
> be at
> > least a little broken.  Obviously if you are trying to debug a JVM which
> won't
> > even boot then it will be hard to get properties from it.  It's possible
> to
> > derive the proper LD_LIBRARY_PATH setting from the location of the JDK
> but that
> > was error prone enough that I switched to using a class to read it
> out.  Anyway,
> > hopefully it will be useful.
> >
> > tom
> >
> > Ben Cheng wrote:
> > > Hello,
> > >
> > > I tried to set a breakpoint in a Hotspot function, say
> > > "ciEnv::register_method", under gdb, but gdb couldn't seem to find the
> > > symbols. I am using my locally built libjvm.so so symbols should be
> > > there, so I am thinking that feeding the java launcher to gdb is the
> > > wrong thing to do here.
> > >
> > > Can someone explain the procedures to debug hotspot under gdb?
> > >
> > > Thanks,
> > > -Ben
> >
> > #!/bin/sh
> > tmpdir=/tmp/dbxr.$$
> > tmpcmd=$tmpdir/cmd
> >
> > rm -fr $tmpdir
> > mkdir -p $tmpdir
> > clean_tmp_files() {
> >     rm -fr $tmpdir
> > }
> >
> > arch=
> > if [ -f /proc/cpuinfo ] ; then
> >   arch=`uname -m`
> >   if [ "$arch" = i686 ]; then
> >     arch=i386
> >   fi
> > else
> >   arch=`uname -p`
> > fi
> > if [ -z "$arch" ]; then
> >   echo "Unknown architecture.  Exiting..."
> >   exit 1
> > fi
> >
> > exe=$1
> > if [ ! -x "$1" ]; then
> >   exe=`which $1`
> > fi
> > shift
> >
> > trap clean_tmp_files 2
> >
> > usage() {
> >   echo "Usage: dbxr [ -dbx | -gdb ] [ -window ] [ -core ] [ -corefile
> <file> ] command ..."
> >   exit
> > }
> >
> > if [ `uname` = "SunOS" ]; then
> >     debugger=dbx
> > else
> >     which dbx 2>&1 > /dev/null
> >     if [ $? -eq 0 ]; then
> >       debugger=dbx
> >     else
> >       debugger=gdb
> >     fi
> > fi
> >
> > debugargs=
> > debugprecmd=
> > fastdebug=
> > while [ $# -gt 0 ]; do
> >     if [ $1 = -core ] ; then
> >         debugargs=core
> >         shift
> >     elif [ $1 = -corefile ] ; then
> >         debugargs="$2"
> >         shift 2
> >     elif [ $1 = -help ] ; then
> >         usage
> >     elif [ $1 = -dbx ] ; then
> >         debugger=dbx
> >         shift
> >     elif [ $1 = -gdb ] ; then
> >         debugger=gdb
> >         shift
> >     elif [ $1 = -window ] ; then
> >         if [ -x /usr/dt/bin/dtterm ]; then
> >             debugprecmd="/usr/dt/bin/dtterm -e"
> >         else
> >             debugprecmd="xterm -e"
> >         fi
> >         shift
> >     elif [ $1 = -echo ] ; then
> >         debugprecmd="echo"
> >         shift
> >     else
> >         break;
> >     fi
> > done
> >
> > cat - > $tmpdir/props.class.uu <<'EOF'
> > begin 644 props.class
> > MROZZO@   "X )0H !P 0"0 1 !(* !$ $PH %  5"@ 6 !<' !@' !D!  8\
> > M:6YI=#X!  ,H*58!  1#;V1E 0 /3&EN94YU;6)E<E1A8FQE 0 $;6%I;@$
> > M%BA;3&IA=F$O;&%N9R]3=')I;F<[*58!  I3;W5R8V5&:6QE 0 *<')O<',N
> > M:F%V80P "  )!P :#  ; !P, !T '@< 'PP (  A!P B#  C "0!  5P<F]P
> > M<P$ $&IA=F$O;&%N9R]/8FIE8W0! !!J879A+VQA;F<O4WES=&5M 0 #;W5T
> > M 0 53&IA=F$O:6\O4')I;G13=')E86T[ 0 -9V5T4')O<&5R=&EE<P$ &"@I
> > M3&IA=F$O=71I;"]0<F]P97)T:65S.P$ %&IA=F$O=71I;"]0<F]P97)T:65S
> > M 0 #9V5T 0 F*$QJ879A+VQA;F<O3V)J96-T.RE,:F%V82]L86YG+T]B:F5C
> > M=#L! !-J879A+VEO+U!R:6YT4W1R96%M 0 '<')I;G1L;@$ %2A,:F%V82]L
> > M86YG+T]B:F5C=#LI5@ A  8 !P       @ !  @ "0 !  H    =  $  0
> > M  4JMP !L0    $ "P    8  0    $ "0 ,  T  0 *    0@ $  (    >
> > M SP;*KZB !BR  *X  ,J&S*V  2V  6$ 0&G_^BQ     0 +    $@ $
> > 7 P (  0 %P # !T !@ !  X    "  ^$
> >
> > end
> > EOF
> >
> > (cd $tmpdir; uudecode props.class.uu)
> >
> > jvmver() {
> >   jvmargs=
> >   while [ "$#" -gt 0 ]; do
> >     case "$1" in
> >     "-client")   jvmargs="$jvmargs $1"; shift;;
> >     "-server")   jvmargs="$jvmargs $1"; shift;;
> >     "-d64")      jvmargs="$jvmargs $1";
> >                  j=`basename $exe`
> >                  nog=`basename $exe _g`
> >                  d=`dirname $exe`
> >                  if [ -f $d/sparcv9/$j ]; then
> >                     exe=$d/sparcv9/$j
> >                  elif [ -f $d/../fastdebug/bin/sparcv9/$nog ]; then
> >                     exe=$d/../fastdebug/bin/sparcv9/$nog
> >                  fi
> >                  if [ -f $d/amd64/$j ]; then
> >                     exe=$d/amd64/$j
> >                  elif [ -f $d/../fastdebug/bin/amd64/$nog ]; then
> >                     exe=$d/../fastdebug/bin/amd64/$nog
> >                  fi
> >                  shift;;
> >      -*) shift;;
> >      *) break;;
> >     esac
> >   done
> > }
> >
> > jvmver $*
> >
> > # use -Xint in case the VM won't boot with the compiler
> > LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions
> -XX:-DisplayVMOutput props java.library.path 2>/dev/null | grep -v "VM
> option"`
> > if [ $? -ne 0 ]; then
> >   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions
> -XX:-DisplayVMOutput -XX:+Debugging props java.library.path 2>/dev/null |
> grep -v "VM option"`
> > fi
> > if [ $? -ne 0 ]; then
> >   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp
> $tmpdir  -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
> -XX:-DisplayVMOutput -XX:-PrintVMOptions -XX:-DisplayVMOutput props
> java.library.path 2>/dev/null | grep -v "VM option"`
> > fi
> > if [ $? -ne 0 ]; then
> >   echo "Error getting LD_LIBRARY_PATH"
> >   $exe $jvmargs -Xint -cp $tmpdir -XX:+UnlockDiagnosticVMOptions
> -XX:-LogVMOutput -XX:-DisplayVMOutput props java.library.path
> >   exit 1
> > fi
> > export LD_LIBRARY_PATH
> >
> > if [ $debugger = "gdb" ] ; then
> >     echo "handle SIGSEGV noprint nostop pass" >> $tmpcmd
> >     echo "handle SIGUSR2 noprint nostop pass" >> $tmpcmd
> >     echo "handle SIGILL  noprint nostop pass" >> $tmpcmd
> >     echo "handle SIGFPE  noprint nostop pass" >> $tmpcmd
> >     echo "handle SIG32   noprint nostop pass" >> $tmpcmd
> >     echo "handle SIGABRT print stop nopass" >> $tmpcmd
> >     echo "shell rm -fr $tmpdir" >> $tmpcmd
> >     echo "set args $*" >> $tmpcmd
> >     exec $debugprecmd $debugger --command=$tmpcmd $exe
> > else
> >     rm -f $tmpcmd
> >     if [ "$debugargs" != "" ]; then
> >         echo "debug $exe $debugargs" > $tmpcmd
> >     else
> >         echo "debug $exe" >> $tmpcmd
> >         echo "runargs $*" >> $tmpcmd
> >     fi
> >     echo "if [ -f ~/.dbxr.rc ]; then source ~/.dbxr.rc; fi" >> $tmpcmd
> >     echo "sh rm -fr $tmpdir" >> $tmpcmd
> >     exec $debugprecmd $debugger -c "source $tmpcmd"
> > fi
> >
> >
>
>
> --
> I would remember that if researchers were not ambitious
> probably today we haven't the technology we are using!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071018/3ae7a507/attachment.html 

From neojia at gmail.com  Fri Oct 19 01:23:35 2007
From: neojia at gmail.com (Neo Jia)
Date: Fri, 19 Oct 2007 01:23:35 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <bcf6f6d40710182310l2f9d7636i39761c00151c4b50@mail.gmail.com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
	<471803D4.3080303@sun.com>
	<5d649bdb0710182221u3713519dpd4ad68b00e410a61@mail.gmail.com>
	<bcf6f6d40710182310l2f9d7636i39761c00151c4b50@mail.gmail.com>
Message-ID: <5d649bdb0710190123g1be72937v8fb38e8b32e5a631@mail.gmail.com>

Ben,

gdb cannot break on your code because you do not provide function
signature information for it. The simplest way is to use the filename
and line number.

This is what I got from a old jdk7 build code:

722 // ------------------------------------------------------------------
723 // ciEnv::register_method
724 void ciEnv::register_method(ciMethod* target,
725                 int entry_bci,
726                             CodeOffsets* offsets,
727                 int orig_pc_offset,
728                 CodeBuffer* code_buffer,
729                 int frame_words,
730                 OopMapSet* oop_map_set,
731                 ExceptionHandlerTable* handler_table,
732                 ImplicitExceptionTable* inc_table,
733                             AbstractCompiler* compiler,
734                             bool has_debug_info,
735                             bool has_unsafe_access) {

Obviously, gdb cannot locate the symbols only by giving ciEnv::register_method.

Thanks,
Neo

On 10/18/07, Ben Cheng <bccheng at google.com> wrote:
> Thanks guys. I am seeing improvements, but gdb still doesn't accept my
> breakpoint through typing "b 'ciEnv::register_method':
>
> (gdb) b 'ciEnv::register_method'
> Can't find member of namespace, class, struct, or union named
> "ciEnv::register_method"
> Hint: try 'ciEnv::register_method'<TAB> or 'ciEnv::register_method'<ESC-?>
> (Note leading single quote.)
>
> I am using gdb6.6, and locally compiled libjvm.so with the -ggdb3 flag added
> on linux.
>
> After adding the various handle instructions in gdb I was able to run my
> java code all the way to the end, which is a major progress! I then hacked
> ciEnv::register_method() to have the following line added:
>
>    printf("ciEnv::register_method: %p\n", &ciEnv::register_method);
>
> and in my gdb session I see a lot of invocations of it:
>
> ciEnv::register_method: 0x2aaaaaf5326e
> ciEnv::register_method: 0x2aaaaaf5326e
>         :
>         :
>
> However, the only way to break there is using the hex address directly. The
> symbolic name is still not recognized by gdb. It will be pretty dumb if I
> used the wrong gdb command to set breakpoints. Just to rule out the case
> could you share with me the exact command you used in gdb to set up such a
> breakpoint?
>
> Thanks,
> -Ben
>
>
> On 10/18/07, Neo Jia <neojia at gmail.com> wrote:
> > Ben,
> >
> > I have used gdb a lot on Linux platform to debug VM, which works great
> > (X86-64 and 32bit).
> >
> > I would suggest you to add the following  to file
> > hotspot/build/linux/makefiles/gcc.make
> >
> > DEBUG_CFLAGS += -ggdb3, which will make gdb much happier for C++ code.
> >
> > For the LD path problem, I think that is just a workaround for the old
> > gdb version since the jvm will execve another process if it cannot
> > find something expected from the LD path. But that bug is already
> > fixed in gdb 6.5.
> >
> > Once, you build your VM first time. You may then do an incremental
> > build from hotspot/build/linux, which will only create the .so you
> > need.
> >
> > BTW, if you use ccache, it will speed up your work greatly.
> >
> > Thanks,
> > Neo
> >
> >
> > On 10/18/07, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> > > Using a debugger with the java launcher can be a little tricky since it
> normally
> > > sets up the LD_LIBRARY_PATH and relaunches the VM to select the right
> libjvm.so
> > > which makes debuggers unhappy.  libjvm.so is also dynamically loaded so
> they
> > > symbols won't be available until you've at least run it once.  Your
> > > LD_LIBRARY_PATH should be set to the value of the java.library.path
> property
> > > from the VM you want to run.  gdb will get into various bad states if
> you don't
> > > do this part.  Also by default you also want to suppress a lot of
> signals that
> > > the JVM uses.
> > >
> > > I attached the script I use for launching the VM under a debugger.  It
> works for
> > > dbx and gdb and has a little Java class for getting the
> java.library.path
> > > property from a VM.  You just prefix dbxr onto the full command line you
> want to
> > > debug and it sets everything up for you.  The script is a little ugly
> and has
> > > some special bits to deal with getting properties from a JVM which might
> be at
> > > least a little broken.  Obviously if you are trying to debug a JVM which
> won't
> > > even boot then it will be hard to get properties from it.  It's possible
> to
> > > derive the proper LD_LIBRARY_PATH setting from the location of the JDK
> but that
> > > was error prone enough that I switched to using a class to read it out.
> Anyway,
> > > hopefully it will be useful.
> > >
> > > tom
> > >
> > > Ben Cheng wrote:
> > > > Hello,
> > > >
> > > > I tried to set a breakpoint in a Hotspot function, say
> > > > "ciEnv::register_method", under gdb, but gdb couldn't seem to find the
> > > > symbols. I am using my locally built libjvm.so so symbols should be
> > > > there, so I am thinking that feeding the java launcher to gdb is the
> > > > wrong thing to do here.
> > > >
> > > > Can someone explain the procedures to debug hotspot under gdb?
> > > >
> > > > Thanks,
> > > > -Ben
> > >
> > > #!/bin/sh
> > > tmpdir=/tmp/dbxr.$$
> > > tmpcmd=$tmpdir/cmd
> > >
> > > rm -fr $tmpdir
> > > mkdir -p $tmpdir
> > > clean_tmp_files() {
> > >     rm -fr $tmpdir
> > > }
> > >
> > > arch=
> > > if [ -f /proc/cpuinfo ] ; then
> > >   arch=`uname -m`
> > >   if [ "$arch" = i686 ]; then
> > >     arch=i386
> > >   fi
> > > else
> > >   arch=`uname -p`
> > > fi
> > > if [ -z "$arch" ]; then
> > >   echo "Unknown architecture.  Exiting..."
> > >   exit 1
> > > fi
> > >
> > > exe=$1
> > > if [ ! -x "$1" ]; then
> > >   exe=`which $1`
> > > fi
> > > shift
> > >
> > > trap clean_tmp_files 2
> > >
> > > usage() {
> > >   echo "Usage: dbxr [ -dbx | -gdb ] [ -window ] [ -core ] [ -corefile
> <file> ] command ..."
> > >   exit
> > > }
> > >
> > > if [ `uname` = "SunOS" ]; then
> > >     debugger=dbx
> > > else
> > >     which dbx 2>&1 > /dev/null
> > >     if [ $? -eq 0 ]; then
> > >       debugger=dbx
> > >     else
> > >       debugger=gdb
> > >     fi
> > > fi
> > >
> > > debugargs=
> > > debugprecmd=
> > > fastdebug=
> > > while [ $# -gt 0 ]; do
> > >     if [ $1 = -core ] ; then
> > >         debugargs=core
> > >         shift
> > >     elif [ $1 = -corefile ] ; then
> > >         debugargs="$2"
> > >         shift 2
> > >     elif [ $1 = -help ] ; then
> > >         usage
> > >     elif [ $1 = -dbx ] ; then
> > >         debugger=dbx
> > >         shift
> > >     elif [ $1 = -gdb ] ; then
> > >         debugger=gdb
> > >         shift
> > >     elif [ $1 = -window ] ; then
> > >         if [ -x /usr/dt/bin/dtterm ]; then
> > >             debugprecmd="/usr/dt/bin/dtterm -e"
> > >         else
> > >             debugprecmd="xterm -e"
> > >         fi
> > >         shift
> > >     elif [ $1 = -echo ] ; then
> > >         debugprecmd="echo"
> > >         shift
> > >     else
> > >         break;
> > >     fi
> > > done
> > >
> > > cat - > $tmpdir/props.class.uu <<'EOF'
> > > begin 644 props.class
> > > MROZZO@   "X )0H !P 0"0 1 !(* !$ $PH %  5"@ 6 !<' !@' !D!  8\
> > > M:6YI=#X!  ,H*58!  1#;V1E 0 /3&EN94YU;6)E<E1A8FQE 0 $;6%I;@$
> > > M%BA;3&IA=F$O;&%N9R]3=')I;F<[*58!  I3;W5R8V5&:6QE 0
> *<')O<',N
> > > M:F%V80P "  )!P :#  ; !P, !T '@< 'PP (  A!P B#  C "0!  5P<F]P
> > > M<P$ $&IA=F$O;&%N9R]/8FIE8W0! !!J879A+VQA;F<O4WES=&5M 0 #;W5T
> > > M 0 53&IA=F$O:6\O4')I;G13=')E86T[ 0 -9V5T4')O<&5R=&EE<P$ &"@I
> > > M3&IA=F$O=71I;"]0<F]P97)T:65S.P$ %&IA=F$O=71I;"]0<F]P97)T:65S
> > > M 0 #9V5T 0 F*$QJ879A+VQA;F<O3V)J96-T.RE,:F%V82]L86YG+T]B:F5C
> > > M=#L! !-J879A+VEO+U!R:6YT4W1R96%M 0 '<')I;G1L;@$ %2A,:F%V82]L
> > > M86YG+T]B:F5C=#LI5@ A  8 !P       @ !  @ "0 !  H    =  $  0
> > > M  4JMP !L0    $ "P    8  0    $ "0 ,  T  0 *    0@ $  (    >
> > > M SP;*KZB !BR  *X  ,J&S*V  2V  6$ 0&G_^BQ     0 +    $@ $
> > > 7 P (  0 %P # !T !@ !  X    "  ^$
> > >
> > > end
> > > EOF
> > >
> > > (cd $tmpdir; uudecode props.class.uu)
> > >
> > > jvmver() {
> > >   jvmargs=
> > >   while [ "$#" -gt 0 ]; do
> > >     case "$1" in
> > >     "-client")   jvmargs="$jvmargs $1"; shift;;
> > >     "-server")   jvmargs="$jvmargs $1"; shift;;
> > >     "-d64")      jvmargs="$jvmargs $1";
> > >                  j=`basename $exe`
> > >                  nog=`basename $exe _g`
> > >                  d=`dirname $exe`
> > >                  if [ -f $d/sparcv9/$j ]; then
> > >                     exe=$d/sparcv9/$j
> > >                  elif [ -f
> $d/../fastdebug/bin/sparcv9/$nog ]; then
> > >
> exe=$d/../fastdebug/bin/sparcv9/$nog
> > >                  fi
> > >                  if [ -f $d/amd64/$j ]; then
> > >                     exe=$d/amd64/$j
> > >                  elif [ -f $d/../fastdebug/bin/amd64/$nog ]; then
> > >                     exe=$d/../fastdebug/bin/amd64/$nog
> > >                  fi
> > >                  shift;;
> > >      -*) shift;;
> > >      *) break;;
> > >     esac
> > >   done
> > > }
> > >
> > > jvmver $*
> > >
> > > # use -Xint in case the VM won't boot with the compiler
> > > LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions
> -XX:-DisplayVMOutput props java.library.path 2>/dev/null | grep -v "VM
> option"`
> > > if [ $? -ne 0 ]; then
> > >   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions
> -XX:-DisplayVMOutput -XX:+Debugging props java.library.path 2>/dev/null |
> grep -v "VM option"`
> > > fi
> > > if [ $? -ne 0 ]; then
> > >   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir
> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
> -XX:-DisplayVMOutput -XX:-PrintVMOptions -XX:-DisplayVMOutput props
> java.library.path 2>/dev/null | grep -v "VM option"`
> > > fi
> > > if [ $? -ne 0 ]; then
> > >   echo "Error getting LD_LIBRARY_PATH"
> > >   $exe $jvmargs -Xint -cp $tmpdir -XX:+UnlockDiagnosticVMOptions
> -XX:-LogVMOutput -XX:-DisplayVMOutput props java.library.path
> > >   exit 1
> > > fi
> > > export LD_LIBRARY_PATH
> > >
> > > if [ $debugger = "gdb" ] ; then
> > >     echo "handle SIGSEGV noprint nostop pass" >> $tmpcmd
> > >     echo "handle SIGUSR2 noprint nostop pass" >> $tmpcmd
> > >     echo "handle SIGILL  noprint nostop pass" >> $tmpcmd
> > >     echo "handle SIGFPE  noprint nostop pass" >> $tmpcmd
> > >     echo "handle SIG32   noprint nostop pass" >> $tmpcmd
> > >     echo "handle SIGABRT print stop nopass" >> $tmpcmd
> > >     echo "shell rm -fr $tmpdir" >> $tmpcmd
> > >     echo "set args $*" >> $tmpcmd
> > >     exec $debugprecmd $debugger --command=$tmpcmd $exe
> > > else
> > >     rm -f $tmpcmd
> > >     if [ "$debugargs" != "" ]; then
> > >         echo "debug $exe $debugargs" > $tmpcmd
> > >     else
> > >         echo "debug $exe" >> $tmpcmd
> > >         echo "runargs $*" >> $tmpcmd
> > >     fi
> > >     echo "if [ -f ~/.dbxr.rc ]; then source ~/.dbxr.rc; fi" >> $tmpcmd
> > >     echo "sh rm -fr $tmpdir" >> $tmpcmd
> > >     exec $debugprecmd $debugger -c "source $tmpcmd"
> > > fi
> > >
> > >
> >
> >
> > --
> > I would remember that if researchers were not ambitious
> > probably today we haven't the technology we are using!
> >
>
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!


From bccheng at google.com  Fri Oct 19 11:53:54 2007
From: bccheng at google.com (Ben Cheng)
Date: Fri, 19 Oct 2007 11:53:54 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <5d649bdb0710190123g1be72937v8fb38e8b32e5a631@mail.gmail.com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
	<471803D4.3080303@sun.com>
	<5d649bdb0710182221u3713519dpd4ad68b00e410a61@mail.gmail.com>
	<bcf6f6d40710182310l2f9d7636i39761c00151c4b50@mail.gmail.com>
	<5d649bdb0710190123g1be72937v8fb38e8b32e5a631@mail.gmail.com>
Message-ID: <bcf6f6d40710191153r75d85c68k93239eccf3ddf707@mail.gmail.com>

Actually the signature information is in the .so file, as I was able to set
such breakpoints in other programs. A colleague showed me the command
"sharedlibrary libjvm" to force gdb to reload the symbol table, and gdb
happily acknowledges with the following message:

(gdb) sharedlibrary libjvm
Reading symbols from
/usr/local/google/home/bccheng/java-6-sun_64/jre/lib/amd64/server/libjvm.so...done.

We think the automatic symbol loading is disabled after a certain size
threshold is hit.

However, yet a new failure pops up as gdb crashes with a segmentation fault
once the break point is hit. So more digging is required.

-Ben

On 10/19/07, Neo Jia <neojia at gmail.com> wrote:
>
> Ben,
>
> gdb cannot break on your code because you do not provide function
> signature information for it. The simplest way is to use the filename
> and line number.
>
> This is what I got from a old jdk7 build code:
>
> 722 // ------------------------------------------------------------------
> 723 // ciEnv::register_method
> 724 void ciEnv::register_method(ciMethod* target,
> 725                 int entry_bci,
> 726                             CodeOffsets* offsets,
> 727                 int orig_pc_offset,
> 728                 CodeBuffer* code_buffer,
> 729                 int frame_words,
> 730                 OopMapSet* oop_map_set,
> 731                 ExceptionHandlerTable* handler_table,
> 732                 ImplicitExceptionTable* inc_table,
> 733                             AbstractCompiler* compiler,
> 734                             bool has_debug_info,
> 735                             bool has_unsafe_access) {
>
> Obviously, gdb cannot locate the symbols only by giving
> ciEnv::register_method.
>
> Thanks,
> Neo
>
> On 10/18/07, Ben Cheng <bccheng at google.com> wrote:
> > Thanks guys. I am seeing improvements, but gdb still doesn't accept my
> > breakpoint through typing "b 'ciEnv::register_method':
> >
> > (gdb) b 'ciEnv::register_method'
> > Can't find member of namespace, class, struct, or union named
> > "ciEnv::register_method"
> > Hint: try 'ciEnv::register_method'<TAB> or
> 'ciEnv::register_method'<ESC-?>
> > (Note leading single quote.)
> >
> > I am using gdb6.6, and locally compiled libjvm.so with the -ggdb3 flag
> added
> > on linux.
> >
> > After adding the various handle instructions in gdb I was able to run my
> > java code all the way to the end, which is a major progress! I then
> hacked
> > ciEnv::register_method() to have the following line added:
> >
> >    printf("ciEnv::register_method: %p\n", &ciEnv::register_method);
> >
> > and in my gdb session I see a lot of invocations of it:
> >
> > ciEnv::register_method: 0x2aaaaaf5326e
> > ciEnv::register_method: 0x2aaaaaf5326e
> >         :
> >         :
> >
> > However, the only way to break there is using the hex address directly.
> The
> > symbolic name is still not recognized by gdb. It will be pretty dumb if
> I
> > used the wrong gdb command to set breakpoints. Just to rule out the case
> > could you share with me the exact command you used in gdb to set up such
> a
> > breakpoint?
> >
> > Thanks,
> > -Ben
> >
> >
> > On 10/18/07, Neo Jia <neojia at gmail.com> wrote:
> > > Ben,
> > >
> > > I have used gdb a lot on Linux platform to debug VM, which works great
> > > (X86-64 and 32bit).
> > >
> > > I would suggest you to add the following  to file
> > > hotspot/build/linux/makefiles/gcc.make
> > >
> > > DEBUG_CFLAGS += -ggdb3, which will make gdb much happier for C++ code.
> > >
> > > For the LD path problem, I think that is just a workaround for the old
> > > gdb version since the jvm will execve another process if it cannot
> > > find something expected from the LD path. But that bug is already
> > > fixed in gdb 6.5.
> > >
> > > Once, you build your VM first time. You may then do an incremental
> > > build from hotspot/build/linux, which will only create the .so you
> > > need.
> > >
> > > BTW, if you use ccache, it will speed up your work greatly.
> > >
> > > Thanks,
> > > Neo
> > >
> > >
> > > On 10/18/07, Tom Rodriguez <Thomas.Rodriguez at sun.com> wrote:
> > > > Using a debugger with the java launcher can be a little tricky since
> it
> > normally
> > > > sets up the LD_LIBRARY_PATH and relaunches the VM to select the
> right
> > libjvm.so
> > > > which makes debuggers unhappy.  libjvm.so is also dynamically loaded
> so
> > they
> > > > symbols won't be available until you've at least run it once.  Your
> > > > LD_LIBRARY_PATH should be set to the value of the java.library.path
> > property
> > > > from the VM you want to run.  gdb will get into various bad states
> if
> > you don't
> > > > do this part.  Also by default you also want to suppress a lot of
> > signals that
> > > > the JVM uses.
> > > >
> > > > I attached the script I use for launching the VM under a
> debugger.  It
> > works for
> > > > dbx and gdb and has a little Java class for getting the
> > java.library.path
> > > > property from a VM.  You just prefix dbxr onto the full command line
> you
> > want to
> > > > debug and it sets everything up for you.  The script is a little
> ugly
> > and has
> > > > some special bits to deal with getting properties from a JVM which
> might
> > be at
> > > > least a little broken.  Obviously if you are trying to debug a JVM
> which
> > won't
> > > > even boot then it will be hard to get properties from it.  It's
> possible
> > to
> > > > derive the proper LD_LIBRARY_PATH setting from the location of the
> JDK
> > but that
> > > > was error prone enough that I switched to using a class to read it
> out.
> > Anyway,
> > > > hopefully it will be useful.
> > > >
> > > > tom
> > > >
> > > > Ben Cheng wrote:
> > > > > Hello,
> > > > >
> > > > > I tried to set a breakpoint in a Hotspot function, say
> > > > > "ciEnv::register_method", under gdb, but gdb couldn't seem to find
> the
> > > > > symbols. I am using my locally built libjvm.so so symbols should
> be
> > > > > there, so I am thinking that feeding the java launcher to gdb is
> the
> > > > > wrong thing to do here.
> > > > >
> > > > > Can someone explain the procedures to debug hotspot under gdb?
> > > > >
> > > > > Thanks,
> > > > > -Ben
> > > >
> > > > #!/bin/sh
> > > > tmpdir=/tmp/dbxr.$$
> > > > tmpcmd=$tmpdir/cmd
> > > >
> > > > rm -fr $tmpdir
> > > > mkdir -p $tmpdir
> > > > clean_tmp_files() {
> > > >     rm -fr $tmpdir
> > > > }
> > > >
> > > > arch=
> > > > if [ -f /proc/cpuinfo ] ; then
> > > >   arch=`uname -m`
> > > >   if [ "$arch" = i686 ]; then
> > > >     arch=i386
> > > >   fi
> > > > else
> > > >   arch=`uname -p`
> > > > fi
> > > > if [ -z "$arch" ]; then
> > > >   echo "Unknown architecture.  Exiting..."
> > > >   exit 1
> > > > fi
> > > >
> > > > exe=$1
> > > > if [ ! -x "$1" ]; then
> > > >   exe=`which $1`
> > > > fi
> > > > shift
> > > >
> > > > trap clean_tmp_files 2
> > > >
> > > > usage() {
> > > >   echo "Usage: dbxr [ -dbx | -gdb ] [ -window ] [ -core ] [
> -corefile
> > <file> ] command ..."
> > > >   exit
> > > > }
> > > >
> > > > if [ `uname` = "SunOS" ]; then
> > > >     debugger=dbx
> > > > else
> > > >     which dbx 2>&1 > /dev/null
> > > >     if [ $? -eq 0 ]; then
> > > >       debugger=dbx
> > > >     else
> > > >       debugger=gdb
> > > >     fi
> > > > fi
> > > >
> > > > debugargs=
> > > > debugprecmd=
> > > > fastdebug=
> > > > while [ $# -gt 0 ]; do
> > > >     if [ $1 = -core ] ; then
> > > >         debugargs=core
> > > >         shift
> > > >     elif [ $1 = -corefile ] ; then
> > > >         debugargs="$2"
> > > >         shift 2
> > > >     elif [ $1 = -help ] ; then
> > > >         usage
> > > >     elif [ $1 = -dbx ] ; then
> > > >         debugger=dbx
> > > >         shift
> > > >     elif [ $1 = -gdb ] ; then
> > > >         debugger=gdb
> > > >         shift
> > > >     elif [ $1 = -window ] ; then
> > > >         if [ -x /usr/dt/bin/dtterm ]; then
> > > >             debugprecmd="/usr/dt/bin/dtterm -e"
> > > >         else
> > > >             debugprecmd="xterm -e"
> > > >         fi
> > > >         shift
> > > >     elif [ $1 = -echo ] ; then
> > > >         debugprecmd="echo"
> > > >         shift
> > > >     else
> > > >         break;
> > > >     fi
> > > > done
> > > >
> > > > cat - > $tmpdir/props.class.uu <<'EOF'
> > > > begin 644 props.class
> > > > MROZZO@   "X )0H !P 0"0 1 !(* !$ $PH %  5"@ 6 !<' !@' !D!  8\
> > > > M:6YI=#X!  ,H*58!  1#;V1E 0 /3&EN94YU;6)E<E1A8FQE 0 $;6%I;@$
> > > > M%BA;3&IA=F$O;&%N9R]3=')I;F<[*58!  I3;W5R8V5&:6QE 0
> > *<')O<',N
> > > > M:F%V80P "  )!P :#  ; !P, !T '@< 'PP (  A!P B#  C "0!  5P<F]P
> > > > M<P$ $&IA=F$O;&%N9R]/8FIE8W0! !!J879A+VQA;F<O4WES=&5M 0 #;W5T
> > > > M 0 53&IA=F$O:6\O4')I;G13=')E86T[ 0 -9V5T4')O<&5R=&EE<P$ &"@I
> > > > M3&IA=F$O=71I;"]0<F]P97)T:65S.P$ %&IA=F$O=71I;"]0<F]P97)T:65S
> > > > M 0 #9V5T 0 F*$QJ879A+VQA;F<O3V)J96-T.RE,:F%V82]L86YG+T]B:F5C
> > > > M=#L! !-J879A+VEO+U!R:6YT4W1R96%M 0 '<')I;G1L;@$ %2A,:F%V82]L
> > > > M86YG+T]B:F5C=#LI5@ A  8 !P       @ !  @ "0 !  H    =  $  0
> > > > M  4JMP !L0    $ "P    8  0    $ "0 ,  T  0 *    0@ $  (    >
> > > > M SP;*KZB !BR  *X  ,J&S*V  2V  6$ 0&G_^BQ     0 +    $@ $
> > > > 7 P (  0 %P # !T !@ !  X    "  ^$
> > > >
> > > > end
> > > > EOF
> > > >
> > > > (cd $tmpdir; uudecode props.class.uu)
> > > >
> > > > jvmver() {
> > > >   jvmargs=
> > > >   while [ "$#" -gt 0 ]; do
> > > >     case "$1" in
> > > >     "-client")   jvmargs="$jvmargs $1"; shift;;
> > > >     "-server")   jvmargs="$jvmargs $1"; shift;;
> > > >     "-d64")      jvmargs="$jvmargs $1";
> > > >                  j=`basename $exe`
> > > >                  nog=`basename $exe _g`
> > > >                  d=`dirname $exe`
> > > >                  if [ -f $d/sparcv9/$j ]; then
> > > >                     exe=$d/sparcv9/$j
> > > >                  elif [ -f
> > $d/../fastdebug/bin/sparcv9/$nog ]; then
> > > >
> > exe=$d/../fastdebug/bin/sparcv9/$nog
> > > >                  fi
> > > >                  if [ -f $d/amd64/$j ]; then
> > > >                     exe=$d/amd64/$j
> > > >                  elif [ -f $d/../fastdebug/bin/amd64/$nog ]; then
> > > >                     exe=$d/../fastdebug/bin/amd64/$nog
> > > >                  fi
> > > >                  shift;;
> > > >      -*) shift;;
> > > >      *) break;;
> > > >     esac
> > > >   done
> > > > }
> > > >
> > > > jvmver $*
> > > >
> > > > # use -Xint in case the VM won't boot with the compiler
> > > > LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir -XX:-PrintVMOptions
> > -XX:-DisplayVMOutput props java.library.path 2>/dev/null | grep -v "VM
> > option"`
> > > > if [ $? -ne 0 ]; then
> > > >   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir
> -XX:-PrintVMOptions
> > -XX:-DisplayVMOutput -XX:+Debugging props java.library.path 2>/dev/null
> |
> > grep -v "VM option"`
> > > > fi
> > > > if [ $? -ne 0 ]; then
> > > >   LD_LIBRARY_PATH=`$exe $jvmargs -Xint -cp $tmpdir
> > -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
> > -XX:-DisplayVMOutput -XX:-PrintVMOptions -XX:-DisplayVMOutput props
> > java.library.path 2>/dev/null | grep -v "VM option"`
> > > > fi
> > > > if [ $? -ne 0 ]; then
> > > >   echo "Error getting LD_LIBRARY_PATH"
> > > >   $exe $jvmargs -Xint -cp $tmpdir -XX:+UnlockDiagnosticVMOptions
> > -XX:-LogVMOutput -XX:-DisplayVMOutput props java.library.path
> > > >   exit 1
> > > > fi
> > > > export LD_LIBRARY_PATH
> > > >
> > > > if [ $debugger = "gdb" ] ; then
> > > >     echo "handle SIGSEGV noprint nostop pass" >> $tmpcmd
> > > >     echo "handle SIGUSR2 noprint nostop pass" >> $tmpcmd
> > > >     echo "handle SIGILL  noprint nostop pass" >> $tmpcmd
> > > >     echo "handle SIGFPE  noprint nostop pass" >> $tmpcmd
> > > >     echo "handle SIG32   noprint nostop pass" >> $tmpcmd
> > > >     echo "handle SIGABRT print stop nopass" >> $tmpcmd
> > > >     echo "shell rm -fr $tmpdir" >> $tmpcmd
> > > >     echo "set args $*" >> $tmpcmd
> > > >     exec $debugprecmd $debugger --command=$tmpcmd $exe
> > > > else
> > > >     rm -f $tmpcmd
> > > >     if [ "$debugargs" != "" ]; then
> > > >         echo "debug $exe $debugargs" > $tmpcmd
> > > >     else
> > > >         echo "debug $exe" >> $tmpcmd
> > > >         echo "runargs $*" >> $tmpcmd
> > > >     fi
> > > >     echo "if [ -f ~/.dbxr.rc ]; then source ~/.dbxr.rc; fi" >>
> $tmpcmd
> > > >     echo "sh rm -fr $tmpdir" >> $tmpcmd
> > > >     exec $debugprecmd $debugger -c "source $tmpcmd"
> > > > fi
> > > >
> > > >
> > >
> > >
> > > --
> > > I would remember that if researchers were not ambitious
> > > probably today we haven't the technology we are using!
> > >
> >
> >
>
>
> --
> I would remember that if researchers were not ambitious
> probably today we haven't the technology we are using!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071019/29bc7281/attachment.html 

From ted at tedneward.com  Wed Oct 24 02:25:14 2007
From: ted at tedneward.com (Ted Neward)
Date: Wed, 24 Oct 2007 02:25:14 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
Message-ID: <003801c8161f$cb2e1010$618a3030$@com>

At the risk of stating the obvious? Are you using the debug or fastdebug
builds? Are you sure the java launcher you?re firing up is the right one?

 

I can?t imagine how else you?d debug Hotspot under gdb *except* to fire up
the launcher? Here?s a thought: fire up gdb against the launcher, and set a
breakpoint on JNI_CreateJVM() or another JNI method used in the launcher,
preferably as early as possible. When you hit that breakpoint, *then* set
the breakpoint for ciEnv::register_method(). (The fact that the Hotspot
DLLs/.sos are loaded dynamically?rather than at load time?may be throwing
gdb off when you try to set that breakpoint prior to execution. I know it
does for WinDbg when trying to debug Rotor?)

 

Ted Neward

Java, .NET, XML Services

Consulting, Teaching, Speaking, Writing

HYPERLINK "http://www.tedneward.com"http://www.tedneward.com

 

From: hotspot-dev-bounces at openjdk.java.net
[mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Ben Cheng
Sent: Thursday, October 18, 2007 5:48 PM
To: hotspot-dev at openjdk.java.net
Subject: inspecting hotspot code using gdb

 

Hello,

I tried to set a breakpoint in a Hotspot function, say
"ciEnv::register_method", under gdb, but gdb couldn't seem to find the
symbols. I am using my locally built libjvm.so so symbols should be there,
so I am thinking that feeding the java launcher to gdb is the wrong thing to
do here. 

Can someone explain the procedures to debug hotspot under gdb?

Thanks,
-Ben

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.15.0/1077 - Release Date: 10/18/2007
9:54 AM


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.15.3/1082 - Release Date: 10/20/2007
2:59 PM
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071024/3a7803ab/attachment.html 

From bccheng at google.com  Wed Oct 24 11:10:09 2007
From: bccheng at google.com (Ben Cheng)
Date: Wed, 24 Oct 2007 11:10:09 -0700
Subject: inspecting hotspot code using gdb
In-Reply-To: <003801c8161f$cb2e1010$618a3030$@com>
References: <bcf6f6d40710181748v65c08ca2jf267a9b0a1b45dc1@mail.gmail.com>
	<003801c8161f$cb2e1010$618a3030$@com>
Message-ID: <bcf6f6d40710241110k6f8c9358p8e4564b38d6b5b96@mail.gmail.com>

I tried both the debug and fastdebug versions and the outcomes were the
same. I agree that debugging the launcher is the right way to do; I second
guessed that because for debugging gcc one ought to debug cc1. I think it is
because gcc forks a new process for cc1, but java opens shared libraries to
start the VM.

Apparently the gdb I used was having problems handling the symbol size
associated with libjvm.so so I saw all kinds of weird problems. Things
should be all cool after the problems in gdb are fixed.

Thanks,
-Ben


On 10/24/07, Ted Neward <ted at tedneward.com> wrote:
>
>  At the risk of stating the obvious? Are you using the debug or fastdebug
> builds? Are you sure the java launcher you're firing up is the right one?
>
>
>
> I can't imagine how else you'd debug Hotspot under gdb **except** to fire
> up the launcher? Here's a thought: fire up gdb against the launcher, and set
> a breakpoint on JNI_CreateJVM() or another JNI method used in the launcher,
> preferably as early as possible. When you hit that breakpoint, **then**
> set the breakpoint for ciEnv::register_method(). (The fact that the Hotspot
> DLLs/.sos are loaded dynamically?rather than at load time?may be throwing
> gdb off when you try to set that breakpoint prior to execution. I know it
> does for WinDbg when trying to debug Rotor?)
>
>
>
> Ted Neward
>
> Java, .NET, XML Services
>
> Consulting, Teaching, Speaking, Writing
>
> http://www.tedneward.com
>
>
>
> *From:* hotspot-dev-bounces at openjdk.java.net [mailto:
> hotspot-dev-bounces at openjdk.java.net] *On Behalf Of *Ben Cheng
> *Sent:* Thursday, October 18, 2007 5:48 PM
> *To:* hotspot-dev at openjdk.java.net
> *Subject:* inspecting hotspot code using gdb
>
>
>
> Hello,
>
> I tried to set a breakpoint in a Hotspot function, say
> "ciEnv::register_method", under gdb, but gdb couldn't seem to find the
> symbols. I am using my locally built libjvm.so so symbols should be there,
> so I am thinking that feeding the java launcher to gdb is the wrong thing to
> do here.
>
> Can someone explain the procedures to debug hotspot under gdb?
>
> Thanks,
> -Ben
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.15.0/1077 - Release Date:
> 10/18/2007 9:54 AM
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.15.3/1082 - Release Date:
> 10/20/2007 2:59 PM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071024/10e204e9/attachment.html 

From Peter.Kessler at Sun.COM  Wed Oct 24 16:39:15 2007
From: Peter.Kessler at Sun.COM (Peter B. Kessler)
Date: Wed, 24 Oct 2007 16:39:15 -0700
Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual Machine
Message-ID: <471FD7A3.1010806@Sun.COM>

On Oct 9 14:27:22 PDT 2007 John Rose proposed a multi-language
virtual machine project[1] to be hosted by the HotSpot group.

It's time to vote:  Should the HotSpot Group sponsor this Project?

Please cast your vote by replying to this message with either

      Vote: yes

or

      Vote: no

as the first line of the message body.  Your reply should go to me,
Peter.Kessler at Sun.COM, as I'm the current HotSpot group moderator.
That should happen if you reply to this message.

You may indicate the reason for your decision, if you wish, on
subsequent lines.  You need not give a reason for your vote.

Votes are due by Oct 29 12:00:00 PDT 2007 (1900 UTC).  That's this
coming Monday.  I will tally the votes and post a summary to this
list and to discuss at openjdk.java.net.

Only Members of the HotSpot Group are eligible to vote on this
proposal[2].  At this early date, that means engineers on the Sun
HotSpot project.

			... peter

[1] http://mail.openjdk.java.net/pipermail/announce/2007-October/000016.html
[2] http://blogs.sun.com/mr/entry/cosmology


From Peter.Kessler at Sun.COM  Mon Oct 29 17:13:34 2007
From: Peter.Kessler at Sun.COM (Peter B. Kessler)
Date: Mon, 29 Oct 2007 17:13:34 -0700
Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual
	Machine
In-Reply-To: <471FD7A3.1010806@Sun.COM>
References: <471FD7A3.1010806@Sun.COM>
Message-ID: <4726772E.4080004@Sun.COM>

The Multi-Language Virtual Machine project is approved by a
unanimous vote.

For the historians: 8 people voted in favor of the MLVM project,
6 of whom can be considered Members of the HotSpot group.  No
one opposed the formation of the project.  A couple of people
sent me mail asking how the voting was going.

			... peter

Peter B. Kessler wrote:

> On Oct 9 14:27:22 PDT 2007 John Rose proposed a multi-language
> virtual machine project[1] to be hosted by the HotSpot group.
> 
> It's time to vote:  Should the HotSpot Group sponsor this Project?
> 
> Please cast your vote by replying to this message with either
> 
>      Vote: yes
> 
> or
> 
>      Vote: no
> 
> as the first line of the message body.  Your reply should go to me,
> Peter.Kessler at Sun.COM, as I'm the current HotSpot group moderator.
> That should happen if you reply to this message.
> 
> You may indicate the reason for your decision, if you wish, on
> subsequent lines.  You need not give a reason for your vote.
> 
> Votes are due by Oct 29 12:00:00 PDT 2007 (1900 UTC).  That's this
> coming Monday.  I will tally the votes and post a summary to this
> list and to discuss at openjdk.java.net.
> 
> Only Members of the HotSpot Group are eligible to vote on this
> proposal[2].  At this early date, that means engineers on the Sun
> HotSpot project.
> 
>             ... peter
> 
> [1] http://mail.openjdk.java.net/pipermail/announce/2007-October/000016.html
> [2] http://blogs.sun.com/mr/entry/cosmology




From mark at klomp.org  Tue Oct 30 04:23:39 2007
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 30 Oct 2007 12:23:39 +0100
Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual
	Machine
In-Reply-To: <4726772E.4080004@Sun.COM>
References: <471FD7A3.1010806@Sun.COM>  <4726772E.4080004@Sun.COM>
Message-ID: <1193743419.3801.24.camel@dijkstra.wildebeest.org>

Hi Peter,

On Mon, 2007-10-29 at 17:13 -0700, Peter B. Kessler wrote:
> The Multi-Language Virtual Machine project is approved by a
> unanimous vote.

Cool! Looking forward to this.

> For the historians: 8 people voted in favor of the MLVM project,
> 6 of whom can be considered Members of the HotSpot group.

Do you have a list of people "whom can be considered Members"?
And should we just make them official Members to bootstrap things a
little?

Cheers,

Mark



From Peter.Kessler at Sun.COM  Tue Oct 30 13:29:49 2007
From: Peter.Kessler at Sun.COM (Peter B. Kessler)
Date: Tue, 30 Oct 2007 13:29:49 -0700
Subject: Call For Votes (CFV): Project proposal: Multi-Language Virtual
	Machine
In-Reply-To: <1193743419.3801.24.camel@dijkstra.wildebeest.org>
References: <471FD7A3.1010806@Sun.COM> <4726772E.4080004@Sun.COM>
	<1193743419.3801.24.camel@dijkstra.wildebeest.org>
Message-ID: <4727943D.1020908@Sun.COM>

Mark Wielaard wrote:

> Hi Peter,
> 
> On Mon, 2007-10-29 at 17:13 -0700, Peter B. Kessler wrote:
>> The Multi-Language Virtual Machine project is approved by a
>> unanimous vote.
> 
> Cool! Looking forward to this.
> 
>> For the historians: 8 people voted in favor of the MLVM project,
>> 6 of whom can be considered Members of the HotSpot group.
> 
> Do you have a list of people "whom can be considered Members"?
> And should we just make them official Members to bootstrap things a
> little?
> 
> Cheers,
> 
> Mark

Those voting in favor of the Multi-Language Virtual Machine
project were:

     Peter Kessler
     Tom Rodriguez
     Dave Cox
     John Coomes
     John Rose
     Tony Printezis
     Raja Reddy
     Oscar Victorio Calixto Bacho

No one voted against the project.

My understanding is that the current Members of the HotSpot Group
are the members of Sun's HotSpot engineering team.  That includes
the first 6 people on the list above.  If that's wrong, I expect
to be corrected by the IGB.

			... peter