From volker.simonis at gmail.com Mon Nov 5 10:58:04 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Nov 2007 19:58:04 +0100 Subject: C++ Interpreter In-Reply-To: <471CE98A.5010502@sun.com> References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> Message-ID: Hi folks, here finally comes the patche-set to get the C++-Interpreter running under Solaris/SPARC in 64-bit mode. The file 'bytecodeInterpreter.cpp.patch' contains a patch to get the C++ Interpreter working in the opt-build on 'i486' machines. I include it here just for your convenience, as I already posted it to this list before. The other three files bytecodeInterpreter_sparc.hpp.patch cppInterpreter_sparc.cpp.patch parseHelper.cpp.patch contain the patches for Solaris/SPARC in 64-bit mode. Now, everything in 64-bit should work as in the 32-bit mode (at least JVM98 passes without errors). There was an error with OSR in 64-bit mode that I could only fixed in shared code (in 'parseHelper.cpp'). The problem is related to the fact that the counters are 64-bit values in 64-bit mode, but are updated as 32-bit values in JITed code. This led to errors on big-endian archtectures like SPARC because the wrong half of the 64-bit counter was incremented. There are probably other ways to handle this in architecture specific code, however the current fix should work for other 64-bit architectures as well. Hope this helps, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: bytecodeInterpreter.cpp.patch Type: text/x-patch Size: 1713 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071105/99021a92/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bytecodeInterpreter_sparc.hpp.patch Type: text/x-patch Size: 671 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071105/99021a92/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: cppInterpreter_sparc.cpp.patch Type: text/x-patch Size: 4631 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071105/99021a92/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: parseHelper.cpp.patch Type: text/x-patch Size: 2101 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071105/99021a92/attachment-0003.bin From landonf at threerings.net Wed Nov 7 14:04:56 2007 From: landonf at threerings.net (Landon Fuller) Date: Wed, 7 Nov 2007 14:04:56 -0800 Subject: Mac OS X i486 ABI -- 16-byte stack alignment Message-ID: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> I've been working on getting the JDK running on Mac OS X Leopard / x86, based on the BSD's JDK16 porting work -- so far I've gotten 'Hello World' running, while anything more complex quickly runs into stack alignment issues -- Mac OS X's x86 calling conventions require a 16-byte aligned stack pointer at function entry. The first issue I've hit is alignment in the MacroAssembler::call_VM_base() code generation. It doesn't look like I can determine the current stack alignment within the call_VM() methods, and there's no gaurantee that the frame started 16-byte aligned, either. Given that, I was thinking that doing an alignment fixup in call_VM_base() might be a workable solution -- something like: /* Arguments */ int argSize = arg_count * wordSize; pushl %esi ; save %esi, we'll use it to store the current sp movl %esp, %esi andl $-16, %esp ; force sp to a known (16-byte) alignment if (argSize & 15) { // Pad SP for alignment if the pushed args aren't going to leave us 16-byte aligned subl $((argSize + 15) & -16) - argSize, %esp; } ... push arguments ... call movl %esi, %esp ; restore pre-alignment sp popl %esi ; restore esi However, this means that call_VM_base() needs to push the arguments on to the stack itself, rather than relying on the call_VM() implementations to do so. Thus, I was thinking about modifying call_VM_base() to accept an arg array: virtual void call_VM_base( // returns the register containing the thread upon return Register oop_result, // where an oop-result ends up if any; use noreg otherwise Register java_thread, // the thread if computed before ; use noreg otherwise Register last_java_sp, // to set up last_Java_frame in stubs; use noreg otherwise address entry_point, // the entry point int number_of_arguments, // the number of arguments (w/ o thread) to pop after the call Register args[], // call arguments, left-to- right ordered <-- NEW ARGUMENT bool check_exceptions // whether to check for pending exceptions after return ); That way, call_VM can fixup the alignment, push the args, do the call, and restore esp. Thoughts, criticism, and suggestions are very much appreciated, as are suggestions on where else I should be worrying about stack alignment. This is the first I've looked at the hotspot code, so hopefully my evaluation is not completely off in the weeds. Thanks! -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071107/61a00eb1/attachment.bin From Paul.Hohensee at Sun.COM Wed Nov 7 14:16:53 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 07 Nov 2007 17:16:53 -0500 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> Message-ID: <47323955.5090105@sun.com> Take a look at the x64 code. The x64 ABI requires 16-byte alignment at call sites. Compiler-generated code maintains 16-byte alignment at all times, but the template interpreter doesn't, so calling out from it means aligning the stack. See, e.g., call_VM_base in assembler_x86_64.cpp. Paul Landon Fuller wrote: > I've been working on getting the JDK running on Mac OS X Leopard / > x86, based on the BSD's JDK16 porting work -- so far I've gotten > 'Hello World' running, while anything more complex quickly runs into > stack alignment issues -- Mac OS X's x86 calling conventions require a > 16-byte aligned stack pointer at function entry. > > The first issue I've hit is alignment in the > MacroAssembler::call_VM_base() code generation. It doesn't look like I > can determine the current stack alignment within the call_VM() > methods, and there's no gaurantee that the frame started 16-byte > aligned, either. Given that, I was thinking that doing an alignment > fixup in call_VM_base() might be a workable solution -- something like: > > /* Arguments */ > int argSize = arg_count * wordSize; > > pushl %esi ; save %esi, we'll use it to store the current sp > movl %esp, %esi > andl $-16, %esp ; force sp to a known (16-byte) alignment > if (argSize & 15) { > // Pad SP for alignment if the pushed args aren't going to > leave us 16-byte aligned > subl $((argSize + 15) & -16) - argSize, %esp; > } > ... push arguments ... > call > movl %esi, %esp ; restore pre-alignment sp > popl %esi ; restore esi > > However, this means that call_VM_base() needs to push the arguments on > to the stack itself, rather than relying on the call_VM() > implementations to do so. Thus, I was thinking about modifying > call_VM_base() to accept an arg array: > > virtual void call_VM_base( // returns the register > containing the thread upon return > Register oop_result, // where an oop-result ends up > if any; use noreg otherwise > Register java_thread, // the thread if computed > before ; use noreg otherwise > Register last_java_sp, // to set up last_Java_frame in > stubs; use noreg otherwise > address entry_point, // the entry point > int number_of_arguments, // the number of arguments (w/o > thread) to pop after the call > Register args[], // call arguments, > left-to-right ordered <-- NEW ARGUMENT > bool check_exceptions // whether to check for pending > exceptions after return > ); > > That way, call_VM can fixup the alignment, push the args, do the call, > and restore esp. > > Thoughts, criticism, and suggestions are very much appreciated, as are > suggestions on where else I should be worrying about stack alignment. > This is the first I've looked at the hotspot code, so hopefully my > evaluation is not completely off in the weeds. > > Thanks! > -landonf From landonf at threerings.net Wed Nov 7 14:46:09 2007 From: landonf at threerings.net (Landon Fuller) Date: Wed, 7 Nov 2007 14:46:09 -0800 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <47323955.5090105@sun.com> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> Message-ID: On Nov 7, 2007, at 14:16, Paul Hohensee wrote: > Take a look at the x64 code. The x64 ABI requires 16-byte > alignment at > call sites. Compiler-generated code maintains 16-byte alignment at > all > times, but the template interpreter doesn't, so calling out from it > means > aligning the stack. > > See, e.g., call_VM_base in assembler_x86_64.cpp. x64's call_VM_base() can assume 8 bytes in either direction will align the stack, as it uses 8-byte word size. It also looks like all call_VM_base() arguments must be register-passed. x64's 16-byte alignment looks like: testl(rsp, 15); jcc(Assembler::zero, L); subq(rsp, 8); call(entry_point, relocInfo::runtime_call_type); addq(rsp, 8); Am I mistaken? -- On x86-32, the stack can be 4, 8, or 12 bytes offset from 16 byte alignment, and the stack has to be padded to ensure that it's still aligned once all the arguments have been pushed on the stack -- I'm not sure how to make the Darwin x86-32 alignment simplier. Thank you, -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071107/1e057955/attachment.bin From Thomas.Rodriguez at Sun.COM Wed Nov 7 15:16:34 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 07 Nov 2007 15:16:34 -0800 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> Message-ID: <47324752.2060605@sun.com> I think your initial inclination might be the right one. You could put that logic into the each of the call_VM wrappers but that doesn't seem right. Alternatively you could predefine what registers are used for argument passing so that the number of arguments essentially determines the contents of your Register args[]. That would make it a bit more like the 64-bit code. You'd have to rule out the use of esi for arguments since you're using that to preserve esp so making them fixed doesn't seem so bad. In the end I think I'd lean to your original suggestion since it seems like a localized solution. tom Landon Fuller wrote: > > On Nov 7, 2007, at 14:16, Paul Hohensee wrote: > >> Take a look at the x64 code. The x64 ABI requires 16-byte alignment at >> call sites. Compiler-generated code maintains 16-byte alignment at all >> times, but the template interpreter doesn't, so calling out from it means >> aligning the stack. >> >> See, e.g., call_VM_base in assembler_x86_64.cpp. > > x64's call_VM_base() can assume 8 bytes in either direction will align > the stack, as it uses 8-byte word size. It also looks like all > call_VM_base() arguments must be register-passed. x64's 16-byte > alignment looks like: > testl(rsp, 15); > jcc(Assembler::zero, L); > > subq(rsp, 8); > call(entry_point, relocInfo::runtime_call_type); > addq(rsp, 8); > > Am I mistaken? -- On x86-32, the stack can be 4, 8, or 12 bytes offset > from 16 byte alignment, and the stack has to be padded to ensure that > it's still aligned once all the arguments have been pushed on the stack > -- I'm not sure how to make the Darwin x86-32 alignment simplier. > > Thank you, > -landonf From John.Rose at Sun.COM Wed Nov 7 20:16:35 2007 From: John.Rose at Sun.COM (John Rose) Date: Wed, 07 Nov 2007 20:16:35 -0800 Subject: C++ Interpreter In-Reply-To: References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> Message-ID: <10E2F238-BBB8-49B7-B561-7C2BFE5F27EB@sun.com> Quick comment on parseHelper.cpp: In the opto directory (C2) we try to avoid using #ifdef or LP64 when dealing with wordSize issues. Instead, there is a pseudo-type "X" defined in opto/ type.hpp, as a series of macros for names which occur in both "int" and "long" versions. Your change can probably be rewritten to use this convention. You might need to add a symbol or two to type.hpp, such as "T_X" for T_INT/T_LONG. (Yes, the naming could use a cleanup. But it's what we have, and it's far better than #ifdef.) Thanks for doing this. I'm going to try it out (which is why I had the comment). -- John From Steve.Goldman at Sun.COM Thu Nov 8 08:58:50 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Thu, 08 Nov 2007 11:58:50 -0500 Subject: C++ Interpreter In-Reply-To: References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> Message-ID: <4733404A.9000102@sun.com> Volker Simonis wrote: > Hi folks, > > here finally comes the patche-set to get the C++-Interpreter running > under Solaris/SPARC in 64-bit mode. great. > > The file 'bytecodeInterpreter.cpp.patch' contains a patch to get the > C++ Interpreter working in the opt-build on 'i486' machines. I include > it here just for your convenience, as I already posted it to this list > before. > > The other three files > > bytecodeInterpreter_sparc.hpp.patch > cppInterpreter_sparc.cpp.patch > parseHelper.cpp.patch > > contain the patches for Solaris/SPARC in 64-bit mode. Now, everything > in 64-bit should work as in the 32-bit mode (at least JVM98 passes > without errors). thanks. > > There was an error with OSR in 64-bit mode that I could only fixed in > shared code (in 'parseHelper.cpp'). The problem is related to the fact > that the counters are 64-bit values in 64-bit mode, but are updated as > 32-bit values in JITed code. This led to errors on big-endian > archtectures like SPARC because the wrong half of the 64-bit counter > was incremented. In my work on producing a 64bit c1 on x86 I've also found that counters are being treated in a dubious manner between 32/64 bit. I don't believe the mdo really needs 64bit counters in the first place so in the end I think the proper fix will be to clean everything up to be 32bits. At the moment I have my own set of hacks for c1. BTW 64bit c1 is working fairly well at the moment. Unfortunately It'll be a while before it shows up what with reviews and the switch to mercurial. -- Steve From Paul.Hohensee at Sun.COM Fri Nov 9 07:49:02 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 09 Nov 2007 10:49:02 -0500 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <47324752.2060605@sun.com> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> <47324752.2060605@sun.com> Message-ID: <4734816E.2040806@sun.com> You're right about x64. My bad. Another possibility is to adopt the sparc paradigm whereby the max size java expression stack is allocated in the top interpreter frame and cut back on calls. You can maintain 16-byte stack alignment at all times in the interpreter that way, which would allow you to properly align the stack at call sites before you push arguments onto the stack, rather than in the call_VM wrappers. Paul Tom Rodriguez wrote: > I think your initial inclination might be the right one. You could > put that logic into the each of the call_VM wrappers but that doesn't > seem right. Alternatively you could predefine what registers are used > for argument passing so that the number of arguments essentially > determines the contents of your Register args[]. That would make it a > bit more like the 64-bit code. You'd have to rule out the use of esi > for arguments since you're using that to preserve esp so making them > fixed doesn't seem so bad. In the end I think I'd lean to your > original suggestion since it seems like a localized solution. > > tom > > > > Landon Fuller wrote: >> >> On Nov 7, 2007, at 14:16, Paul Hohensee wrote: >> >>> Take a look at the x64 code. The x64 ABI requires 16-byte alignment at >>> call sites. Compiler-generated code maintains 16-byte alignment at all >>> times, but the template interpreter doesn't, so calling out from it >>> means >>> aligning the stack. >>> >>> See, e.g., call_VM_base in assembler_x86_64.cpp. >> >> x64's call_VM_base() can assume 8 bytes in either direction will >> align the stack, as it uses 8-byte word size. It also looks like all >> call_VM_base() arguments must be register-passed. x64's 16-byte >> alignment looks like: >> testl(rsp, 15); >> jcc(Assembler::zero, L); >> >> subq(rsp, 8); >> call(entry_point, relocInfo::runtime_call_type); >> addq(rsp, 8); >> >> Am I mistaken? -- On x86-32, the stack can be 4, 8, or 12 bytes >> offset from 16 byte alignment, and the stack has to be padded to >> ensure that it's still aligned once all the arguments have been >> pushed on the stack -- I'm not sure how to make the Darwin x86-32 >> alignment simplier. >> >> Thank you, >> -landonf From Steve.Goldman at Sun.COM Fri Nov 9 08:03:15 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Fri, 09 Nov 2007 11:03:15 -0500 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <4734816E.2040806@sun.com> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> <47324752.2060605@sun.com> <4734816E.2040806@sun.com> Message-ID: <473484C3.8060406@sun.com> Paul Hohensee wrote: > You're right about x64. My bad. > > Another possibility is to adopt the sparc paradigm whereby the max size > java expression stack is allocated in the top interpreter frame and cut > back > on calls. You can maintain 16-byte stack alignment at all times in the > interpreter > that way, which would allow you to properly align the stack at call > sites before > you push arguments onto the stack, rather than in the call_VM wrappers. > Ack. This would be exceedingly painful on 32bit because sp takes on the role of SP and Lesp from sparc. It's not like 32bit has any spare registers laying around to become the equivalent of Lesp. Now if you were using the c++ based interpreter that would be another story. :-) (BTW sparc doesn't cut back the stack on interpreter calls except when using the c++ interpreter. sparc is an interpreter stack space hog.) -- Steve From Paul.Hohensee at Sun.COM Fri Nov 9 09:14:36 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 09 Nov 2007 12:14:36 -0500 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <473484C3.8060406@sun.com> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> <47324752.2060605@sun.com> <4734816E.2040806@sun.com> <473484C3.8060406@sun.com> Message-ID: <4734957C.8080101@sun.com> I didn't say it'd be easy. :) btw, Steve of course knows this :) , but sparc doesn't cut back the stack on calls because of the register save area at the top of the frame, which latter doesn't exist on x86. Paul steve goldman wrote: > Paul Hohensee wrote: >> You're right about x64. My bad. >> >> Another possibility is to adopt the sparc paradigm whereby the max size >> java expression stack is allocated in the top interpreter frame and >> cut back >> on calls. You can maintain 16-byte stack alignment at all times in >> the interpreter >> that way, which would allow you to properly align the stack at call >> sites before >> you push arguments onto the stack, rather than in the call_VM wrappers. >> > > Ack. This would be exceedingly painful on 32bit because sp takes on > the role of SP and Lesp from sparc. It's not like 32bit has any spare > registers laying around to become the equivalent of Lesp. Now if you > were using the c++ based interpreter that would be another story. :-) > > (BTW sparc doesn't cut back the stack on interpreter calls except when > using the c++ interpreter. sparc is an interpreter stack space hog.) > From Steve.Goldman at Sun.COM Fri Nov 9 09:18:56 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Fri, 09 Nov 2007 12:18:56 -0500 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <4734957C.8080101@sun.com> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> <47324752.2060605@sun.com> <4734816E.2040806@sun.com> <473484C3.8060406@sun.com> <4734957C.8080101@sun.com> Message-ID: <47349680.1050106@sun.com> Paul Hohensee wrote: > I didn't say it'd be easy. :) > > btw, Steve of course knows this :) , but sparc doesn't cut back the > stack on calls > because of the register save area at the top of the frame, which latter > doesn't > exist on x86. > > The sparc version of the c++ interpreter does cutback and deals with the window area, template could too. Although the truth be told back in the last millenium when I did the initial implementation of the c++ interpreter on sparc I had it cut back the stack because I mistakenly thought that the template interpreter did it that way and I wanted it to use similar amounts of stack space. :-) -- Steve From John.Rose at Sun.COM Fri Nov 9 11:46:08 2007 From: John.Rose at Sun.COM (John Rose) Date: Fri, 09 Nov 2007 11:46:08 -0800 Subject: Mac OS X i486 ABI -- 16-byte stack alignment In-Reply-To: <47349680.1050106@sun.com> References: <25746091-BAEA-494E-BF60-16923A30042E@threerings.net> <47323955.5090105@sun.com> <47324752.2060605@sun.com> <4734816E.2040806@sun.com> <473484C3.8060406@sun.com> <4734957C.8080101@sun.com> <47349680.1050106@sun.com> Message-ID: On Nov 9, 2007, at 9:18 AM, steve goldman wrote: > Paul Hohensee wrote: >> I didn't say it'd be easy. :) >> btw, Steve of course knows this :) , but sparc doesn't cut back >> the stack on calls >> because of the register save area at the top of the frame, which >> latter doesn't >> exist on x86. >> > The sparc version of the c++ interpreter does cutback and deals > with the window area, template could too. Although the truth be > told back in the last millenium when I did the initial > implementation of the c++ interpreter on sparc I had it cut back > the stack because I mistakenly thought that the template > interpreter did it that way and I wanted it to use similar amounts > of stack space. :-) On sparc the register window save area is completely volatile from the user point of view, so it's easy to move it: Just bump the native %sp. The place where it *was* may contain old spills and/or garbage, and the place it *now* points can collect spills on any interrupt. To avoid copying incoming arguments, interpreters usually create their locals arrays (on method entry) by cutting back the unused part of the caller's JVM stack and also adding space for non-argument locals. After that comes any CPU-required stuff (like caller's register window save area), and then more JVM state of the callee, including JVM stack, and finally any additional CPU-required stuff (like callee's RWSA on sparc). See the ASCII-grams before generate_method_entry in interpreter_sparc.cpp. On sparc, the callee changes the caller's native stack pointer. There's an odd handshake where the caller saves his %sp in 'I5_savedSP', and the callee reasserts it on exit. So the callee can optionally move the caller's RWSA. Later on, exit paths back to the interpreter move 'savedSP' back to %sp. The alternatives to this clever reuse of the caller's JVM stack would be copying incoming arguments, or segmenting the callee's locals array (requiring an extra range check for local reference bytecodes). Yes, interpreter speed is not our primary goal, but this is probably one of those high-leverage decisions that makes a significant difference in start-up performance. Because sparc has lots of registers, it can afford to have an unaligned Lesp just for the JVM, while keeping various strong invariants true on the native %sp. For 32-bit Intel, because there are not enough registers to have a separate JVM sp and native esp, I think the interpreter needs to have an unaligned calling convention, with alignment fixups (esp invariant reassertion) on calls to C code. I suppose 64-bit Intel could do it either way. -- John From feng.xian at gmail.com Sat Nov 10 20:52:44 2007 From: feng.xian at gmail.com (Feng Xian) Date: Sat, 10 Nov 2007 22:52:44 -0600 Subject: JVM internals documentation? In-Reply-To: <002501c80f96$6f0c5790$4d2506b0$@com> References: <09ec01c80ea1$8e8c6bf0$aba543d0$@com> <47127EA5.6080308@sun.com> <002501c80f96$6f0c5790$4d2506b0$@com> Message-ID: <610b3d450711102052j65db2c13x12c14faa4e90bd6a@mail.gmail.com> Hi, I am doing a project which needs to make a system call at monitor_enter bytecode and monitor_exit bytecode. The system call is made by myself, which is used to inform the kernel of monitor events. Currently, I inserted the system call at ObjectSynchronizer::fast_enter(). Will it cause any problem since the code comments say that the implementation is extremely sensitive to race condition? Thanks! Feng From feng.xian at gmail.com Sun Nov 11 11:06:44 2007 From: feng.xian at gmail.com (Feng Xian) Date: Sun, 11 Nov 2007 13:06:44 -0600 Subject: Add system call at monitor_enter Message-ID: <610b3d450711111106u701e4d3fjc838685960668695@mail.gmail.com> Hi, Sorry I used a wrong subject in my last post. So I re-post it again. I am doing a project which needs to make a system call at monitor_enter bytecode and monitor_exit bytecode. The system call is made by myself, which is used to inform the kernel of monitor events. Currently, I inserted the system call at ObjectSynchronizer::fast_enter(). Will it cause any problem since the code comments say that the implementation is extremely sensitive to race condition? Thanks! Feng -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian From pieter.libin at mybiodata.eu Wed Nov 14 02:03:41 2007 From: pieter.libin at mybiodata.eu (Pieter Libin) Date: Wed, 14 Nov 2007 11:03:41 +0100 Subject: Port coordination? In-Reply-To: <46BB6485.3070406@reservoir.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> Message-ID: <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> Dear all, nowadays it seems that quite some people/organizations are working on various ports of the j2se platform. However, porting the virtual machine to new architectures requires the writing of quite some non-trivial platform specific code (os, os_cpu dir). I think it would make sense to provide a more portable replacement for this native part. This would help porting the j2se platform a lot, and might make the transition from j2me > j2se easier as well (http://www.news.com/8301-13580_3-9800679-39.html). Does anyone know wether such a mechanism could be technically feasible? Kind regards, Pieter On Aug 9, 2007 8:01 PM, Jonathan Springer wrote: > James.Melvin at Sun.COM wrote: > > > Hi, > > > > From this forum and others, I can see there are a number of people > > working on the same port of HotSpot? Would it make sense to coordinate > > these efforts to reduce duplication, speed up time-to-market, and > > increase quality? Is this happening already, perhaps beyond my > > visibility? Can I see a show of hands from anyone working on the > > following ports... > > > > PPC > > MIPS > > Linux on SPARC > > ARM > > MacOSX > > > > Other? > > Hi Jim, > > Reservoir Labs is working on a MIPS port of OpenJDK. Specifically, we are targeting > MIPS64 right now, but we're interested in generalizing to other MIPS variants too, > especially MIPS32. We are also interested in other possible architecture ports. > > > Perhaps this email can seed a more common, dedicated area somewhere on > > the OpenJDK website. Would this be helpful? > > Yes, something like this sounds useful as an organizational tool. > > -Jonathan > > -- > Jonathan Springer | > Reservoir Labs, Inc. | http://www.reservoir.com/ > From springer at reservoir.com Wed Nov 14 09:23:33 2007 From: springer at reservoir.com (Jonathan Springer) Date: Wed, 14 Nov 2007 11:23:33 -0600 Subject: Port coordination? In-Reply-To: <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> Message-ID: <473B2F15.9030102@reservoir.com> Pieter Libin wrote: > Dear all, > > nowadays it seems that quite some people/organizations are working on > various ports of the j2se platform. > However, porting the virtual machine to new architectures requires the > writing of quite some non-trivial platform specific code (os, os_cpu > dir). > I think it would make sense to provide a more portable replacement for > this native part. > This would help porting the j2se platform a lot, and might make the > transition from j2me > j2se easier as well > (http://www.news.com/8301-13580_3-9800679-39.html). > > Does anyone know wether such a mechanism could be technically feasible? To support the compilers (c1, c2), there's just no getting around the need to describe how to generate code for a specific architecture. Maybe you could do something outlandish like call gcc every time you wanted to generate a blob, but.... You could come a lot closer with something interpreter-only using CC_INTERP, though still there is asm for some things. Unfortunately the CORE target was removed around b12, and it would be some work to get it back. -Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From gbenson at redhat.com Wed Nov 14 10:33:17 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Nov 2007 18:33:17 +0000 Subject: Port coordination? In-Reply-To: <473B2F15.9030102@reservoir.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> <473B2F15.9030102@reservoir.com> Message-ID: <20071114183317.GA10004@redhat.com> Jonathan Springer wrote: > Pieter Libin wrote: > > nowadays it seems that quite some people/organizations are working > > on various ports of the j2se platform. > > However, porting the virtual machine to new architectures requires > > the writing of quite some non-trivial platform specific code (os, > > os_cpu dir). > > I think it would make sense to provide a more portable replacement > > for this native part. > > This would help porting the j2se platform a lot, and might make > > the transition from j2me > j2se easier as well > > (http://www.news.com/8301-13580_3-9800679-39.html). > > > > Does anyone know wether such a mechanism could be technically > > feasible? > > To support the compilers (c1, c2), there's just no getting around > the need to describe how to generate code for a specific > architecture. Maybe you could do something outlandish like call > gcc every time you wanted to generate a blob, but.... > > You could come a lot closer with something interpreter-only using > CC_INTERP, though still there is asm for some things. Unfortunately > the CORE target was removed around b12, and it would be some work to > get it back. The core stuff is actually mostly still there: I use it for IcedTea on PPC, which is as you say interpreter-only with CC_INTERP. Have a look in icedtea-ports.patch, the stuff to do core builds is all in there. Cheers, Gary From Thomas.Rodriguez at Sun.COM Wed Nov 14 11:58:53 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 14 Nov 2007 11:58:53 -0800 Subject: Port coordination? In-Reply-To: <20071114183317.GA10004@redhat.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> <473B2F15.9030102@reservoir.com> <20071114183317.GA10004@redhat.com> Message-ID: <473B537D.6050405@sun.com> core wasn't removed, it was just redefined. Previously core attempted to be a pure interpreter only system which meant that it didn't include anything needed by the compilers. This made maintenance of it a bit of pain because anytime to made changes the related to the compilers in the runtime you had to remember to ifndef CORE them. Now core is just a system without a compiler but still including the classes needed by the compiler like nmethod so it's slightly less minimal. Basically not defining COMPILER1 or COMPILER2 gives you core and the core makefile targets should still work. tom Gary Benson wrote: > Jonathan Springer wrote: >> Pieter Libin wrote: >>> nowadays it seems that quite some people/organizations are working >>> on various ports of the j2se platform. >>> However, porting the virtual machine to new architectures requires >>> the writing of quite some non-trivial platform specific code (os, >>> os_cpu dir). >>> I think it would make sense to provide a more portable replacement >>> for this native part. >>> This would help porting the j2se platform a lot, and might make >>> the transition from j2me > j2se easier as well >>> (http://www.news.com/8301-13580_3-9800679-39.html). >>> >>> Does anyone know wether such a mechanism could be technically >>> feasible? >> To support the compilers (c1, c2), there's just no getting around >> the need to describe how to generate code for a specific >> architecture. Maybe you could do something outlandish like call >> gcc every time you wanted to generate a blob, but.... >> >> You could come a lot closer with something interpreter-only using >> CC_INTERP, though still there is asm for some things. Unfortunately >> the CORE target was removed around b12, and it would be some work to >> get it back. > > The core stuff is actually mostly still there: I use it for IcedTea > on PPC, which is as you say interpreter-only with CC_INTERP. Have > a look in icedtea-ports.patch, the stuff to do core builds is all in > there. > > Cheers, > Gary From gbenson at redhat.com Wed Nov 14 12:05:28 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Nov 2007 20:05:28 +0000 Subject: Port coordination? In-Reply-To: <473B537D.6050405@sun.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> <473B2F15.9030102@reservoir.com> <20071114183317.GA10004@redhat.com> <473B537D.6050405@sun.com> Message-ID: <20071114200528.GA10519@redhat.com> As indeed they do :) Cheers, Gary Tom Rodriguez wrote: > core wasn't removed, it was just redefined. Previously core > attempted to be a pure interpreter only system which meant that it > didn't include anything needed by the compilers. This made > maintenance of it a bit of pain because anytime to made changes the > related to the compilers in the runtime you had to remember to > ifndef CORE them. Now core is just a system without a compiler but > still including the classes needed by the compiler like nmethod so > it's slightly less minimal. Basically not defining COMPILER1 or > COMPILER2 gives you core and the core makefile targets should still > work. From springer at reservoir.com Wed Nov 14 12:18:30 2007 From: springer at reservoir.com (Jonathan Springer) Date: Wed, 14 Nov 2007 14:18:30 -0600 Subject: Port coordination? In-Reply-To: <473B537D.6050405@sun.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> <473B2F15.9030102@reservoir.com> <20071114183317.GA10004@redhat.com> <473B537D.6050405@sun.com> Message-ID: <473B5816.8040100@reservoir.com> I think you need to stub out a number of things in cpu/ that you didn't have to before, but I guess it's true it's not that much. I just recalled it being a bit of extra work around b12. Good to know that people are still taking it into consideration upstream. Also, thanks for the pointer, Gary. -Jonathan Tom Rodriguez wrote: > core wasn't removed, it was just redefined. Previously core attempted > to be a pure interpreter only system which meant that it didn't include > anything needed by the compilers. This made maintenance of it a bit of > pain because anytime to made changes the related to the compilers in the > runtime you had to remember to ifndef CORE them. Now core is just a > system without a compiler but still including the classes needed by the > compiler like nmethod so it's slightly less minimal. Basically not > defining COMPILER1 or COMPILER2 gives you core and the core makefile > targets should still work. > > tom > > Gary Benson wrote: >> Jonathan Springer wrote: >>> Pieter Libin wrote: >>>> nowadays it seems that quite some people/organizations are working >>>> on various ports of the j2se platform. >>>> However, porting the virtual machine to new architectures requires >>>> the writing of quite some non-trivial platform specific code (os, >>>> os_cpu dir). >>>> I think it would make sense to provide a more portable replacement >>>> for this native part. >>>> This would help porting the j2se platform a lot, and might make >>>> the transition from j2me > j2se easier as well >>>> (http://www.news.com/8301-13580_3-9800679-39.html). >>>> >>>> Does anyone know wether such a mechanism could be technically >>>> feasible? >>> To support the compilers (c1, c2), there's just no getting around >>> the need to describe how to generate code for a specific >>> architecture. Maybe you could do something outlandish like call >>> gcc every time you wanted to generate a blob, but.... >>> >>> You could come a lot closer with something interpreter-only using >>> CC_INTERP, though still there is asm for some things. Unfortunately >>> the CORE target was removed around b12, and it would be some work to >>> get it back. >> >> The core stuff is actually mostly still there: I use it for IcedTea >> on PPC, which is as you say interpreter-only with CC_INTERP. Have >> a look in icedtea-ports.patch, the stuff to do core builds is all in >> there. >> >> Cheers, >> Gary -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From gbenson at redhat.com Thu Nov 15 02:36:25 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Nov 2007 10:36:25 +0000 Subject: Port coordination? In-Reply-To: <473B5816.8040100@reservoir.com> References: <46B843D1.9090605@lemote.com> <20070808120708.GA3742@redhat.com> <46B9D3C2.9060401@lemote.com> <46BA322C.2060703@Sun.COM> <46BB6485.3070406@reservoir.com> <50be7b020711140203g52861d2etcf1afe048ba34a8d@mail.gmail.com> <473B2F15.9030102@reservoir.com> <20071114183317.GA10004@redhat.com> <473B537D.6050405@sun.com> <473B5816.8040100@reservoir.com> Message-ID: <20071115103625.GA4362@redhat.com> Jonathan Springer wrote: > I think you need to stub out a number of things in cpu/ that you > didn't have to before, but I guess it's true it's not that much. > I just recalled it being a bit of extra work around b12. Good to > know that people are still taking it into consideration upstream. Ah, that would explain why I need to have so many files and methods that don't seem relevant without a JIT :) > Also, thanks for the pointer, Gary. You're welcome. Cheers, Gary From volker.simonis at gmail.com Fri Nov 16 05:34:52 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Nov 2007 14:34:52 +0100 Subject: C++ Interpreter In-Reply-To: <4733404A.9000102@sun.com> References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> Message-ID: If you are interested in a performance comparison between the C++ and the Template Interpreter you may want to read the following blog: http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html "Template- vs. C++-Interpreter shootout: This blog discusses the main differences between the C++ and the Template Interpreter which are both available within the Hotspot sources of the OpenJDK project. Some performance tests with the DaCapo benchmark suite which compare the two interpreters in mixed and interpreted mode on Linux/x86 and Solaris/SPARC conclude the presentation." Volker From linuxhippy at gmail.com Fri Nov 16 06:16:48 2007 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 16 Nov 2007 15:16:48 +0100 Subject: C++ Interpreter In-Reply-To: References: <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> Message-ID: <194f62550711160616g1b49a94brc221c8725dbc52fb@mail.gmail.com> Thanks for the comparison, quite interesting :) lg Clemens From John.Rose at Sun.COM Wed Nov 21 19:24:03 2007 From: John.Rose at Sun.COM (John Rose) Date: Wed, 21 Nov 2007 19:24:03 -0800 Subject: C++ Interpreter In-Reply-To: References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> Message-ID: Here's a bit more that helps me keep my build flavors straight. -- John On Nov 5, 2007, at 10:58 AM, Volker Simonis wrote: > here finally comes the patche-set to get the C++-Interpreter running > under Solaris/SPARC in 64-bit mode. > -------------- next part -------------- A non-text attachment was scrubbed... Name: buildtree.make.patch Type: application/octet-stream Size: 867 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071121/3e5d7eb4/attachment.obj From Steve.Goldman at sun.com Mon Nov 26 13:04:41 2007 From: Steve.Goldman at sun.com (steve goldman) Date: Mon, 26 Nov 2007 16:04:41 -0500 Subject: C++ Interpreter In-Reply-To: References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> Message-ID: <474B34E9.8030101@sun.com> Volker Simonis wrote: > If you are interested in a performance comparison between the C++ and > the Template Interpreter you may want to read the following blog: > > http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html > > "Template- vs. C++-Interpreter shootout: This blog discusses the main > differences between the C++ and the Template Interpreter which are > both available within the Hotspot sources of the OpenJDK project. Some > performance tests with the DaCapo benchmark suite which compare the > two interpreters in mixed and interpreted mode on Linux/x86 and > Solaris/SPARC conclude the presentation." > Very cool. So the results are much different (worse) for Xmixed than I got in the long distant past. Server has certainly changed a lot in the interim. So what compiler did you use on Solaris? Considering how similar the numbers are between x86/sparc for -Xint it would seem that you might have used gcc. I used to see worse behavior on sparc because with gcc the interpreter could do the computed goto trick for the dispatch loop and that is worth a lot. Second if you have the time it would interesting to see the comparison using client. -- Steve From Thomas.Rodriguez at Sun.COM Mon Nov 26 14:18:47 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 26 Nov 2007 14:18:47 -0800 Subject: C++ Interpreter In-Reply-To: <474B34E9.8030101@sun.com> References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> <474B34E9.8030101@sun.com> Message-ID: <474B4647.9070601@sun.com> Also the ProfileInterpreter option does nothing with the C++ interpreter so any benchmarks which benefit from type profiling will run more slowly with the C++ interpreter. tom steve goldman wrote: > Volker Simonis wrote: >> If you are interested in a performance comparison between the C++ and >> the Template Interpreter you may want to read the following blog: >> >> http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html >> >> >> "Template- vs. C++-Interpreter shootout: This blog discusses the main >> differences between the C++ and the Template Interpreter which are >> both available within the Hotspot sources of the OpenJDK project. Some >> performance tests with the DaCapo benchmark suite which compare the >> two interpreters in mixed and interpreted mode on Linux/x86 and >> Solaris/SPARC conclude the presentation." >> > > Very cool. So the results are much different (worse) for Xmixed than I > got in the long distant past. Server has certainly changed a lot in the > interim. So what compiler did you use on Solaris? Considering how > similar the numbers are between x86/sparc for -Xint it would seem that > you might have used gcc. I used to see worse behavior on sparc because > with gcc the interpreter could do the computed goto trick for the > dispatch loop and that is worth a lot. > > Second if you have the time it would interesting to see the comparison > using client. > > From volker.simonis at gmail.com Tue Nov 27 02:15:12 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Nov 2007 11:15:12 +0100 Subject: C++ Interpreter In-Reply-To: <474B34E9.8030101@sun.com> References: <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> <474B34E9.8030101@sun.com> Message-ID: On 11/26/07, steve goldman wrote: > Volker Simonis wrote: > > If you are interested in a performance comparison between the C++ and > > the Template Interpreter you may want to read the following blog: > > > > http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html > > > > "Template- vs. C++-Interpreter shootout: This blog discusses the main > > differences between the C++ and the Template Interpreter which are > > both available within the Hotspot sources of the OpenJDK project. Some > > performance tests with the DaCapo benchmark suite which compare the > > two interpreters in mixed and interpreted mode on Linux/x86 and > > Solaris/SPARC conclude the presentation." > > > > Very cool. So the results are much different (worse) for Xmixed than I > got in the long distant past. Server has certainly changed a lot in the > interim. So what compiler did you use on Solaris? Considering how > similar the numbers are between x86/sparc for -Xint it would seem that > you might have used gcc. I used to see worse behavior on sparc because > with gcc the interpreter could do the computed goto trick for the > dispatch loop and that is worth a lot. > On Solaris I used SunStudio 11 (Sun C++ 5.8). So it seems SunStudio has also improved... On Linux I used gcc 4.1.0. > Second if you have the time it would interesting to see the comparison > using client. We only use and supoprt C2, but let's see what I can do. I'll drop you a note if I'll have the results... > > -- > Steve > From volker.simonis at gmail.com Tue Nov 27 02:21:33 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Nov 2007 11:21:33 +0100 Subject: C++ Interpreter In-Reply-To: <474B4647.9070601@sun.com> References: <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> <474B34E9.8030101@sun.com> <474B4647.9070601@sun.com> Message-ID: On 11/26/07, Tom Rodriguez wrote: > Also the ProfileInterpreter option does nothing with the C++ interpreter > so any benchmarks which benefit from type profiling will run more slowly > with the C++ interpreter. > Thats right. But we use the C++-Interpreter for our IA64, PPC and s390 ports and we have extended the C++-Interpreter to use profiling. Unfortunately this is still in Java 5. So the plan is to downport the C++-Interpreter from Java 7 to Java 6 and integrate our changes from Java 5 into Java 6. Than we can do a new shootout and compare the template interpreter with a profiling C++-Interpreter to see what we really loose by using the C++-Interpreter. > tom > > steve goldman wrote: > > Volker Simonis wrote: > >> If you are interested in a performance comparison between the C++ and > >> the Template Interpreter you may want to read the following blog: > >> > >> http://weblogs.java.net/blog/simonis/archive/2007/11/template_vs_cin_1.html > >> > >> > >> "Template- vs. C++-Interpreter shootout: This blog discusses the main > >> differences between the C++ and the Template Interpreter which are > >> both available within the Hotspot sources of the OpenJDK project. Some > >> performance tests with the DaCapo benchmark suite which compare the > >> two interpreters in mixed and interpreted mode on Linux/x86 and > >> Solaris/SPARC conclude the presentation." > >> > > > > Very cool. So the results are much different (worse) for Xmixed than I > > got in the long distant past. Server has certainly changed a lot in the > > interim. So what compiler did you use on Solaris? Considering how > > similar the numbers are between x86/sparc for -Xint it would seem that > > you might have used gcc. I used to see worse behavior on sparc because > > with gcc the interpreter could do the computed goto trick for the > > dispatch loop and that is worth a lot. > > > > Second if you have the time it would interesting to see the comparison > > using client. > > > > > From Steve.Goldman at Sun.COM Tue Nov 27 07:37:09 2007 From: Steve.Goldman at Sun.COM (steve goldman) Date: Tue, 27 Nov 2007 10:37:09 -0500 Subject: C++ Interpreter In-Reply-To: <474B4647.9070601@sun.com> References: <47014E37.2040000@sun.com> <4702779A.2060006@sun.com> <471652C3.8000508@sun.com> <471CE98A.5010502@sun.com> <4733404A.9000102@sun.com> <474B34E9.8030101@sun.com> <474B4647.9070601@sun.com> Message-ID: <474C39A5.8000101@sun.com> Tom Rodriguez wrote: > Also the ProfileInterpreter option does nothing with the C++ interpreter > so any benchmarks which benefit from type profiling will run more slowly > with the C++ interpreter. > One other thing that is missing from the c++ interpreter is support for biased locking. I started to hack that in a while ago but never finished it. So a fairer comparison would turn of biased locking when using the template interpreter not that I think this is likely to be the culprit. -- Steve