C++ Interpreter

[Volker Simonis]

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