From raffaello.giulietti at gmail.com Tue Sep 1 04:03:10 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 01 Sep 2009 13:03:10 +0200 Subject: jump to case label ... crosses initialization Message-ID: <4A9CFF6E.2080003@gmail.com> Hello, the gcc compiler (I'm using 4.3.3) correctly complains about "jump to case label ... crosses initialization" twice. In fact, when declaring a var "inside" a case in a switch, braces are needed to make a block out of the statements. Otherwise the declaration has a wider scope than the case. I'm in $davinci/sources/hotspot/src/share/vm/prims and here's a --git patch: diff --git a/src/share/vm/prims/methodHandleWalk.cpp b/src/share/vm/prims/methodHandleWalk.cpp --- a/src/share/vm/prims/methodHandleWalk.cpp +++ b/src/share/vm/prims/methodHandleWalk.cpp @@ -621,11 +621,12 @@ void MethodHandleCompiler::emit_load_constant(ArgToken arg) { switch (arg.basic_type()) { - case T_OBJECT: - int index = cpool_object_put(arg.object()); - _bytecode.push(Bytecodes::_ldc); - _bytecode.push(index); - _max_stack++; + case T_OBJECT: { + int index = cpool_object_put(arg.object()); + _bytecode.push(Bytecodes::_ldc); + _bytecode.push(index); + _max_stack++; + } break; default: ShouldNotReachHere(); @@ -665,13 +666,14 @@ index = new_local(type); emit_store(type, index); break; - case Bytecodes::_checkcast: - emit_load(srctype, index); - int class_index = cpool_klass_put(tk); - _bytecode.push(op); - _bytecode.push(class_index >> 8); - _bytecode.push(class_index); - emit_store(srctype, index); + case Bytecodes::_checkcast: { + emit_load(srctype, index); + int class_index = cpool_klass_put(tk); + _bytecode.push(op); + _bytecode.push(class_index >> 8); + _bytecode.push(class_index); + emit_store(srctype, index); + } break; default: ShouldNotReachHere(); From Christian.Thalinger at Sun.COM Tue Sep 1 04:54:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 01 Sep 2009 13:54:56 +0200 Subject: jump to case label ... crosses initialization In-Reply-To: <4A9CFF6E.2080003@gmail.com> References: <4A9CFF6E.2080003@gmail.com> Message-ID: <4A9D0B90.7030203@Sun.COM> Raffaello Giulietti wrote: > Hello, > > the gcc compiler (I'm using 4.3.3) correctly complains about "jump to > case label ... crosses initialization" twice. > > In fact, when declaring a var "inside" a case in a switch, braces are > needed to make a block out of the statements. Otherwise the declaration > has a wider scope than the case. Right, thanks for the finding. I will push these changes with my next commit. -- Christian From Christian.Thalinger at Sun.COM Tue Sep 1 05:33:50 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 01 Sep 2009 14:33:50 +0200 Subject: javac/client compiler crashes fixed In-Reply-To: <4A9BDB19.1060206@Sun.COM> References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> <4A9BDB19.1060206@Sun.COM> Message-ID: <4A9D14AE.5030205@Sun.COM> Christian Thalinger wrote: > Charles Oliver Nutter wrote: >> client still crashes for me with bench_fib_recursive, but server runs > > This crash happens because of the non-static final field changes I made, > the client compiler does not know about them. I will fix that. Well... since C1 does not have invokedynamic support at all, did this ever work? -- Christian From raffaello.giulietti at gmail.com Tue Sep 1 06:01:12 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 01 Sep 2009 15:01:12 +0200 Subject: Is -XX:+EnableMethodHandles still there? Message-ID: <4A9D1B18.4090503@gmail.com> Hello, I just built a (nondebug) da Vinci machine with the guards 4256b1662add buildable However, it complains that it does neither recognize +EnableInvokeDynamic nor +EnableMethodHandles. But when I remove the options, it complains that to use method handles I should enable them with +EnableMethodHandles. I'm also using -server and the bootclasspath/p options. Should I also select the "testable" guard to build a nondebug machine? Thanks From Christian.Thalinger at Sun.COM Tue Sep 1 06:09:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 01 Sep 2009 15:09:21 +0200 Subject: Is -XX:+EnableMethodHandles still there? In-Reply-To: <4A9D1B18.4090503@gmail.com> References: <4A9D1B18.4090503@gmail.com> Message-ID: <4A9D1D01.8050702@Sun.COM> Raffaello Giulietti wrote: > Hello, > > I just built a (nondebug) da Vinci machine with the guards > 4256b1662add > buildable > > However, it complains that it does neither recognize > +EnableInvokeDynamic nor +EnableMethodHandles. > But when I remove the options, it complains that to use method handles I > should enable them with +EnableMethodHandles. These options are now experimental options and you have to use: -XX:+UnlockExperimentalVMOptions to be enable to use them. -- Christian From raffaello.giulietti at gmail.com Tue Sep 1 09:25:49 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 01 Sep 2009 18:25:49 +0200 Subject: C/C++ mismatches with PTR_FORMAT Message-ID: <4A9D4B0D.9070706@gmail.com> Hi, the 4.3.3 gcc compiler I'm using statically checks format specifications in the *printf family of functions. While building the *debug* version of the mlvm, the build stops with 4 errors about a mismatch between a format specification and the actual arguments. I'm in $davinci/sources/hotspot/src/cpu/x86/vm The output of hg diff --git methodHandles_x86.cpp is in the enclosed attachment. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: methodHandles_x86.cpp.patch Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090901/03195b81/attachment.ksh From Christian.Thalinger at Sun.COM Wed Sep 2 07:44:34 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 02 Sep 2009 16:44:34 +0200 Subject: MethodHandle.vmentry offset problem on 64-bit Message-ID: <4A9E84D2.4010309@Sun.COM> Hi John! I'm currently porting the interpreter to x86_64 and there is a problem that took me almost two days to find: it's the MethodHandle.vmentry field-type change. For whatever reason on 64-bit it calculates the offset to 24, which actually should be 16, and that results to this: sun.dyn.DirectMethodHandle - klass: 'sun/dyn/DirectMethodHandle' - ---- fields (total size 6 words): - private 'vmentry' 'J' @24 4329412000 (20d95a0 1) - protected 'vmtarget' 'Ljava/lang/Object;' @24 ### BAD OOP 0x1020d95a0 ### (20d95a0 1) - private 'type' 'Ljava/dyn/MethodType;' @32 a 'java/dyn/MethodType' = (II)I (5040e38 1) - private final 'vmindex' 'I' @40 -2 (fffffffe) Nice, isn't it? :-) So, there is a problem somewhere in ClassFileParser::java_dyn_MethodHandle_fix_pre and the attached patch fix it. But I'm very sure this is not correct as the field should really be a double field and not a word field. What is the "correct" fix for this problem? -- Christian diff --git a/src/share/vm/classfile/classFileParser.cpp b/src/share/vm/classfile/classFileParser.cpp --- a/src/share/vm/classfile/classFileParser.cpp +++ b/src/share/vm/classfile/classFileParser.cpp @@ -2514,23 +2514,23 @@ fac_ptr->nonstatic_byte_count -= 1; (*fields_ptr)->ushort_at_put(i + instanceKlass::signature_index_offset, word_sig_index); - if (wordSize == jintSize) { +// if (wordSize == jintSize) { fac_ptr->nonstatic_word_count += 1; - } else { - fac_ptr->nonstatic_double_count += 1; - } - - FieldAllocationType atype = (FieldAllocationType) (*fields_ptr)->ushort_at(i+4); +// } else { +// fac_ptr->nonstatic_double_count += 1; +// } + + FieldAllocationType atype = (FieldAllocationType) (*fields_ptr)->ushort_at(i + instanceKlass::low_offset); assert(atype == NONSTATIC_BYTE, ""); FieldAllocationType new_atype = NONSTATIC_WORD; - if (wordSize > jintSize) { - if (Universe::field_type_should_be_aligned(T_LONG)) { - atype = NONSTATIC_ALIGNED_DOUBLE; - } else { - atype = NONSTATIC_DOUBLE; - } - } - (*fields_ptr)->ushort_at_put(i+4, new_atype); +// if (wordSize > jintSize) { +// if (Universe::field_type_should_be_aligned(T_LONG)) { +// atype = NONSTATIC_ALIGNED_DOUBLE; +// } else { +// atype = NONSTATIC_DOUBLE; +// } +// } + (*fields_ptr)->ushort_at_put(i + instanceKlass::low_offset, new_atype); found_vmentry = true; break; From John.Rose at Sun.COM Wed Sep 2 10:47:28 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 02 Sep 2009 10:47:28 -0700 Subject: MethodHandle.vmentry offset problem on 64-bit In-Reply-To: <4A9E84D2.4010309@Sun.COM> References: <4A9E84D2.4010309@Sun.COM> Message-ID: <0CA094A4-8425-422B-928D-FEA324D10CB3@sun.com> On Sep 2, 2009, at 7:44 AM, Christian Thalinger wrote: > I'm currently porting the interpreter to x86_64 and there is a problem > that took me almost two days to find: it's the MethodHandle.vmentry > field-type change. > > For whatever reason on 64-bit it calculates the offset to 24, which > actually should be 16, and that results to this: > > sun.dyn.DirectMethodHandle > - klass: 'sun/dyn/DirectMethodHandle' > - ---- fields (total size 6 words): > - private 'vmentry' 'J' @24 4329412000 (20d95a0 1) > - protected 'vmtarget' 'Ljava/lang/Object;' @24 ### BAD OOP > 0x1020d95a0 ### (20d95a0 1) > - private 'type' 'Ljava/dyn/MethodType;' @32 a 'java/dyn/ > MethodType' = > (II)I (5040e38 1) > - private final 'vmindex' 'I' @40 -2 (fffffffe) > > Nice, isn't it? :-) I didn't know we had unions in Java! :-) > So, there is a problem somewhere in > ClassFileParser::java_dyn_MethodHandle_fix_pre and the attached patch > fix it. But I'm very sure this is not correct as the field should > really be a double field and not a word field. What is the "correct" > fix for this problem? The MH.vmentry fields needs to be an unmanaged void* field, which means (as far as Java is concerned) either I or J (not L). The current implementation of sun.dyn.MHI patches the type this way. I'm surprised that the layout logic fails after that. Probably the patching is inconsistent somehow. But in the longer run, this doesn't matter, since MHI has to go away. This is the bug: 6839872 remove implementation inheritance from JSR 292 APIs The vmentry field needs to disappear from Java code and get automagically installed on java.dyn.MethodHandle, the same way the hidden klassOop field gets installed on java.lang.Class. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090902/b2bc9421/attachment.html From John.Rose at Sun.COM Wed Sep 2 14:20:48 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 02 Sep 2009 14:20:48 -0700 Subject: Is -XX:+EnableMethodHandles still there? In-Reply-To: <4A9D1D01.8050702@Sun.COM> References: <4A9D1B18.4090503@gmail.com> <4A9D1D01.8050702@Sun.COM> Message-ID: On Sep 1, 2009, at 6:09 AM, Christian Thalinger wrote: > These options are now experimental options and you have to use: > > -XX:+UnlockExperimentalVMOptions > > to be enable to use them. This change was made for HS16; see bug #6868487. The next change to those flags will be to turn them on by default and recategorize them as diagnostic (to allow them to be turned off). Sorry for any inconvenience. -- John From szegedia at gmail.com Fri Sep 4 01:57:36 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 4 Sep 2009 10:57:36 +0200 Subject: Bug in catchException() Message-ID: Hi folks, This small testcase fails in MethodHandles.catchException() on MLVM: import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; public class TestCatchException { public static void main(String[] args) throws Throwable { MethodHandle throwing = findStatic("throwing"); MethodHandle catching = findStatic("catching"); MethodHandles.catchException(throwing, MyException.class, MethodHandles.dropArguments(catching, 0, MyException.class)); } private static class MyException extends RuntimeException { } private static MethodHandle findStatic(String name) { return MethodHandles.publicLookup().findStatic( TestCatchException.class, name, MethodType.make(int.class, Object.class)); } public static int throwing(Object o) { throw new MyException(); } public static int catching(Object o) { return 0; } } Notably, it fails with: Exception in thread "main" java.dyn.NoAccessException: cannot access: *.java.dyn.MethodHandle.invoke(TestCatchException $MyException,java.lang.Object)int at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) at sun.dyn.MemberName.newNoAccessException(MemberName.java:412) at sun.dyn.MemberName$Factory.resolveOrFail(MemberName.java:517) at java.dyn.MethodHandles$Lookup.findVirtual(MethodHandles.java:267) at sun.dyn.Invokers.exactInvoker(Invokers.java:66) at java.dyn.MethodHandles.exactInvoker(MethodHandles.java:761) at sun.dyn.FromGeneric.computeUnboxingInvoker(FromGeneric.java:137) at sun.dyn.FromGeneric.makeInstance(FromGeneric.java:160) at sun.dyn.FromGeneric.make(FromGeneric.java:174) at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:460) at sun.dyn.MethodHandleImpl.makeGuardWithCatch(MethodHandleImpl.java: 840) at java.dyn.MethodHandles.catchException(MethodHandles.java:1397) at TestCatchException.main(TestCatchException.java:12) However, if I replace "MyException" with an exception on the boot classpath, i.e. IllegalArgumentException, then catchException() will succeed. Any advice for a workaround? Attila. From forax at univ-mlv.fr Fri Sep 4 03:44:41 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 04 Sep 2009 12:44:41 +0200 Subject: Bug in catchException() In-Reply-To: References: Message-ID: <4AA0EF99.9050602@univ-mlv.fr> Le 04/09/2009 10:57, Attila Szegedi a ?crit : > Hi folks, > > This small testcase fails in MethodHandles.catchException() on MLVM: > > import java.dyn.MethodHandle; > import java.dyn.MethodHandles; > import java.dyn.MethodType; > > public class TestCatchException > { > public static void main(String[] args) throws Throwable > { > MethodHandle throwing = findStatic("throwing"); > MethodHandle catching = findStatic("catching"); > MethodHandles.catchException(throwing, MyException.class, > MethodHandles.dropArguments(catching, 0, > MyException.class)); > } > > private static class MyException extends RuntimeException > { > } > > private static MethodHandle findStatic(String name) > { > return MethodHandles.publicLookup().findStatic( > TestCatchException.class, name, > MethodType.make(int.class, > Object.class)); > } > > > public static int throwing(Object o) > { > throw new MyException(); > } > > public static int catching(Object o) > { > return 0; > } > } > > Notably, it fails with: > > Exception in thread "main" java.dyn.NoAccessException: cannot access: > *.java.dyn.MethodHandle.invoke(TestCatchException > $MyException,java.lang.Object)int > at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) > at sun.dyn.MemberName.newNoAccessException(MemberName.java:412) > at sun.dyn.MemberName$Factory.resolveOrFail(MemberName.java:517) > at java.dyn.MethodHandles$Lookup.findVirtual(MethodHandles.java:267) > at sun.dyn.Invokers.exactInvoker(Invokers.java:66) > at java.dyn.MethodHandles.exactInvoker(MethodHandles.java:761) > at sun.dyn.FromGeneric.computeUnboxingInvoker(FromGeneric.java:137) > at sun.dyn.FromGeneric.makeInstance(FromGeneric.java:160) > at sun.dyn.FromGeneric.make(FromGeneric.java:174) > at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:460) > at sun.dyn.MethodHandleImpl.makeGuardWithCatch(MethodHandleImpl.java: > 840) > at java.dyn.MethodHandles.catchException(MethodHandles.java:1397) > at TestCatchException.main(TestCatchException.java:12) > > However, if I replace "MyException" with an exception on the boot > classpath, i.e. IllegalArgumentException, then catchException() will > succeed. Any advice for a workaround? > If your signature isn't variant (you know the number of arguments) and have no primitive type in your signature (or don't mind the overhead), you can create a static method like that static void catchException(MethodHandle target, Class c, MethodHandle exceptionHandler, Object o) throws Throwable { try { target.invoke(o); } catch(Throwable t) { if (c.isInstance(t)) exceptionHandler.invoke(o); else throw t; } } Create a mh with lookup.findVirtual() and bound (insertArguments) the target, the exception class and the exception handler. > Attila. > R?mi From john.rose at sun.com Sun Sep 6 00:10:16 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sun, 06 Sep 2009 07:10:16 +0000 Subject: hg: mlvm/mlvm/hotspot: nonperm: update integration patch (+UseParallelGC is still broken) Message-ID: <20090906071016.EB85BE08A@hg.openjdk.java.net> Changeset: b75e4437b2c4 Author: jrose Date: 2009-09-06 00:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b75e4437b2c4 nonperm: update integration patch (+UseParallelGC is still broken) ! indy.compiler.inline.patch ! nonperm-6863023.patch From Christian.Thalinger at Sun.COM Sun Sep 6 08:50:32 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Sun, 06 Sep 2009 15:50:32 +0000 Subject: hg: mlvm/mlvm/hotspot: nonperm: Fixed product compile error. Message-ID: <20090906155032.E0BF3E093@hg.openjdk.java.net> Changeset: ad3509e0f062 Author: twisti Date: 2009-09-06 17:45 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ad3509e0f062 nonperm: Fixed product compile error. ! nonperm-6863023.patch From john.rose at sun.com Mon Sep 7 04:07:28 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 07 Sep 2009 11:07:28 +0000 Subject: hg: mlvm/mlvm/hotspot: nonperm: update integration patch (+UseParallelGC & -Xcomp works) Message-ID: <20090907110729.485B3E0CD@hg.openjdk.java.net> Changeset: 57e23a026b6a Author: jrose Date: 2009-09-07 04:03 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/57e23a026b6a nonperm: update integration patch (+UseParallelGC & -Xcomp works) ! nonperm-6863023.patch From Christian.Thalinger at Sun.COM Tue Sep 8 10:07:00 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 08 Sep 2009 17:07:00 +0000 Subject: hg: mlvm/mlvm/hotspot: Rebase to bsd-port jdk7-b71. Message-ID: <20090908170700.F3940E1F2@hg.openjdk.java.net> Changeset: 515c6ecdf54d Author: twisti Date: 2009-09-08 18:58 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/515c6ecdf54d Rebase to bsd-port jdk7-b71. - 6833129.patch ! indy.compiler.inline.patch ! indy.compiler.patch ! meth-6815692.patch - meth-6862576.patch ! meth.walker.patch ! series From Christian.Thalinger at Sun.COM Tue Sep 8 10:10:53 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 08 Sep 2009 17:10:53 +0000 Subject: hg: mlvm/mlvm/jdk: Rebase to bsd-port jdk7-b71. Message-ID: <20090908171053.CE8C5E1FE@hg.openjdk.java.net> Changeset: 4c362ea1caa5 Author: twisti Date: 2009-09-08 18:59 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4c362ea1caa5 Rebase to bsd-port jdk7-b71. ! indy.patch ! series From Christian.Thalinger at Sun.COM Tue Sep 8 10:15:18 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 08 Sep 2009 17:15:18 +0000 Subject: hg: mlvm/mlvm/langtools: Rebase to bsd-port jdk7-b71. Message-ID: <20090908171519.32CCDE20B@hg.openjdk.java.net> Changeset: 4524a655b64e Author: twisti Date: 2009-09-08 18:59 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/4524a655b64e Rebase to bsd-port jdk7-b71. ! meth.patch ! series From Christian.Thalinger at Sun.COM Tue Sep 8 11:07:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 08 Sep 2009 20:07:05 +0200 Subject: hg: mlvm/mlvm/hotspot: nonperm: update integration patch (+UseParallelGC & -Xcomp works) In-Reply-To: <20090907110729.485B3E0CD@hg.openjdk.java.net> References: <20090907110729.485B3E0CD@hg.openjdk.java.net> Message-ID: <4AA69D49.6030903@Sun.COM> John.Rose at Sun.COM wrote: > Changeset: 57e23a026b6a > Author: jrose > Date: 2009-09-07 04:03 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/57e23a026b6a > > nonperm: update integration patch (+UseParallelGC & -Xcomp works) Just for the record, +UseParallelGC still does not work for me on x86_32 with inline patch: # Internal Error (/Users/twisti/mlvm/hotspot/src/share/vm/runtime/handles.cpp:32), pid=65676, tid=2690041632 # Error: assert(SharedSkipVerify || obj->is_oop(),"sanity check") -- Christian From Christian.Thalinger at Sun.COM Tue Sep 8 12:11:48 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 08 Sep 2009 19:11:48 +0000 Subject: hg: mlvm/mlvm/hotspot: indy-amd64: Initial interpreter support. Message-ID: <20090908191149.19FF2E260@hg.openjdk.java.net> Changeset: 60c425aa6014 Author: twisti Date: 2009-09-08 21:07 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/60c425aa6014 indy-amd64: Initial interpreter support. ! indy-amd64.patch ! series From Christian.Thalinger at Sun.COM Tue Sep 8 13:11:06 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 08 Sep 2009 22:11:06 +0200 Subject: x86_64 interpreter support [Was: Re: hg: mlvm/mlvm/hotspot: indy-amd64: Initial interpreter support.] In-Reply-To: <20090908191149.19FF2E260@hg.openjdk.java.net> References: <20090908191149.19FF2E260@hg.openjdk.java.net> Message-ID: <4AA6BA5A.70900@Sun.COM> Christian.Thalinger at Sun.COM wrote: > Changeset: 60c425aa6014 > Author: twisti > Date: 2009-09-08 21:07 +0200 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/60c425aa6014 > > indy-amd64: Initial interpreter support. > > ! indy-amd64.patch > ! series This commit adds initial interpreter support for x86_64. I ran all JRuby benchmarks with this patch and the results were equal to x86_32, so it looks pretty good. It seems we still have some problems with UseParallelGC, which might be the default on 64-bit Darwin, so using UseSerialGC might be a good idea. Compiler support is yet to come. Please report all problems you see. -- Christian From John.Rose at Sun.COM Tue Sep 8 15:15:15 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 15:15:15 -0700 Subject: Bug in catchException() In-Reply-To: References: Message-ID: <6E2E8C3C-56A6-451A-9C4E-AB3833DB7159@sun.com> The root cause is a known bug. One workaround is to put your app. classes on the boot CP. The bug happens when app. class names appear in signatures of methods referred to by direct MHs or by MH.invoke. The 292 runtime shouldn't be using such a signature, I think, so there's another bug. Thanks for the report. -- John (on my iPhone) On Sep 4, 2009, at 1:57 AM, Attila Szegedi wrote: > Hi folks, > > This small testcase fails in MethodHandles.catchException() on MLVM: > > import java.dyn.MethodHandle; > import java.dyn.MethodHandles; > import java.dyn.MethodType; > > public class TestCatchException > { > public static void main(String[] args) throws Throwable > { > MethodHandle throwing = findStatic("throwing"); > MethodHandle catching = findStatic("catching"); > MethodHandles.catchException(throwing, MyException.class, > MethodHandles.dropArguments(catching, 0, > MyException.class)); > } > > private static class MyException extends RuntimeException > { > } > > private static MethodHandle findStatic(String name) > { > return MethodHandles.publicLookup().findStatic( > TestCatchException.class, name, > MethodType.make(int.class, > Object.class)); > } > > > public static int throwing(Object o) > { > throw new MyException(); > } > > public static int catching(Object o) > { > return 0; > } > } > > Notably, it fails with: > > Exception in thread "main" java.dyn.NoAccessException: cannot access: > *.java.dyn.MethodHandle.invoke(TestCatchException > $MyException,java.lang.Object)int > at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) > at sun.dyn.MemberName.newNoAccessException(MemberName.java:412) > at sun.dyn.MemberName$Factory.resolveOrFail(MemberName.java:517) > at java.dyn.MethodHandles$Lookup.findVirtual(MethodHandles.java: > 267) > at sun.dyn.Invokers.exactInvoker(Invokers.java:66) > at java.dyn.MethodHandles.exactInvoker(MethodHandles.java:761) > at sun.dyn.FromGeneric.computeUnboxingInvoker(FromGeneric.java:137) > at sun.dyn.FromGeneric.makeInstance(FromGeneric.java:160) > at sun.dyn.FromGeneric.make(FromGeneric.java:174) > at sun.dyn.MethodHandleImpl.convertArguments > (MethodHandleImpl.java:460) > at sun.dyn.MethodHandleImpl.makeGuardWithCatch > (MethodHandleImpl.java: > 840) > at java.dyn.MethodHandles.catchException(MethodHandles.java:1397) > at TestCatchException.main(TestCatchException.java:12) > > However, if I replace "MyException" with an exception on the boot > classpath, i.e. IllegalArgumentException, then catchException() will > succeed. Any advice for a workaround? > > Attila. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From szegedia at gmail.com Wed Sep 9 00:01:30 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 9 Sep 2009 09:01:30 +0200 Subject: Bug in catchException() In-Reply-To: <6E2E8C3C-56A6-451A-9C4E-AB3833DB7159@sun.com> References: <6E2E8C3C-56A6-451A-9C4E-AB3833DB7159@sun.com> Message-ID: <639F5AE8-067C-4946-84DB-DCFDA6F5329E@gmail.com> On 2009.09.09., at 0:15, John Rose wrote: > The root cause is a known bug. One workaround is to put your app. > classes on the boot CP. The bug happens when app. class names appear > in signatures of methods referred to by direct MHs or by MH.invoke. Yeah, I noticed that elsewhere too -- tried to get around the java.lang.Object in place of receiver class returned from findVirtual/ unreflect by doing a convertArguments(), only to be surprised with this exact exception when I passed thus converted MH back to some other MethodHandles method (I think it was guardWithTest, doesn't matter really). Sticking with Object receivers for now -- that's actually not much of a problem. As for this problem, I solved it by catching IllegalArgumentException, eliminating dropArguments, and using a catch method that explicitly receives the exception object in its parameter list, and does a check on it, and if it ain't what it expected, rethrows it. Attila. > The 292 runtime shouldn't be using such a signature, I think, so > there's another bug. Thanks for the report. > > -- John (on my iPhone) > > On Sep 4, 2009, at 1:57 AM, Attila Szegedi wrote: > >> Hi folks, >> >> This small testcase fails in MethodHandles.catchException() on MLVM: >> >> import java.dyn.MethodHandle; >> import java.dyn.MethodHandles; >> import java.dyn.MethodType; >> >> public class TestCatchException >> { >> public static void main(String[] args) throws Throwable >> { >> MethodHandle throwing = findStatic("throwing"); >> MethodHandle catching = findStatic("catching"); >> MethodHandles.catchException(throwing, MyException.class, >> MethodHandles.dropArguments(catching, 0, >> MyException.class)); >> } >> >> private static class MyException extends RuntimeException >> { >> } >> >> private static MethodHandle findStatic(String name) >> { >> return MethodHandles.publicLookup().findStatic( >> TestCatchException.class, name, >> MethodType.make(int.class, >> Object.class)); >> } >> >> >> public static int throwing(Object o) >> { >> throw new MyException(); >> } >> >> public static int catching(Object o) >> { >> return 0; >> } >> } >> >> Notably, it fails with: >> >> Exception in thread "main" java.dyn.NoAccessException: cannot access: >> *.java.dyn.MethodHandle.invoke(TestCatchException >> $MyException,java.lang.Object)int >> at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) >> at sun.dyn.MemberName.newNoAccessException(MemberName.java:412) >> at sun.dyn.MemberName$Factory.resolveOrFail(MemberName.java:517) >> at java.dyn.MethodHandles$Lookup.findVirtual(MethodHandles.java: >> 267) >> at sun.dyn.Invokers.exactInvoker(Invokers.java:66) >> at java.dyn.MethodHandles.exactInvoker(MethodHandles.java:761) >> at sun.dyn.FromGeneric.computeUnboxingInvoker(FromGeneric.java:137) >> at sun.dyn.FromGeneric.makeInstance(FromGeneric.java:160) >> at sun.dyn.FromGeneric.make(FromGeneric.java:174) >> at sun.dyn.MethodHandleImpl.convertArguments >> (MethodHandleImpl.java:460) >> at sun.dyn.MethodHandleImpl.makeGuardWithCatch >> (MethodHandleImpl.java: >> 840) >> at java.dyn.MethodHandles.catchException(MethodHandles.java:1397) >> at TestCatchException.main(TestCatchException.java:12) >> >> However, if I replace "MyException" with an exception on the boot >> classpath, i.e. IllegalArgumentException, then catchException() will >> succeed. Any advice for a workaround? >> >> Attila. From Christian.Thalinger at Sun.COM Wed Sep 9 06:08:28 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 09 Sep 2009 13:08:28 +0000 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Various bugfixes and improvements. Message-ID: <20090909130828.9C4CEE350@hg.openjdk.java.net> Changeset: 992cf4a18b98 Author: twisti Date: 2009-09-09 15:04 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/992cf4a18b98 indy.compiler.inline: Various bugfixes and improvements. ! indy.compiler.inline.patch From Christian.Thalinger at Sun.COM Wed Sep 9 06:25:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 09 Sep 2009 15:25:40 +0200 Subject: C/C++ mismatches with PTR_FORMAT In-Reply-To: <4A9D4B0D.9070706@gmail.com> References: <4A9D4B0D.9070706@gmail.com> Message-ID: <4AA7ACD4.7010808@Sun.COM> Raffaello Giulietti wrote: > Hi, > > the 4.3.3 gcc compiler I'm using statically checks format specifications > in the *printf family of functions. While building the *debug* version > of the mlvm, the build stops with 4 errors about a mismatch between a > format specification and the actual arguments. Right, that's a long-standing problem we have. I have just commited a fix. I hope this one lasts forever. -- Christian From Christian.Thalinger at Sun.COM Wed Sep 9 06:27:32 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 09 Sep 2009 13:27:32 +0000 Subject: hg: mlvm/mlvm/hotspot: meth.walker: Fixed GCC compile problem. Message-ID: <20090909132732.D9D4CE357@hg.openjdk.java.net> Changeset: bdf19b7a46a2 Author: twisti Date: 2009-09-09 15:23 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/bdf19b7a46a2 meth.walker: Fixed GCC compile problem. ! meth.walker.patch From blackdrag at gmx.org Wed Sep 9 11:42:17 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 09 Sep 2009 20:42:17 +0200 Subject: still no fun with invokedynamic Message-ID: <4AA7F709.4020707@gmx.org> hi all, I am in urgend need of an actual VM with MethodHandles, but this is as always quuite complicated. This time I created a chroot envrionment for 32 bit, that was where I last time had to stop. I managed to get it compiled by the patch that was provided here 5 months ago and finally had a VM to run. So I did: davinci/sources/jdk/build/linux-i586/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic FidgetDemo and got: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (methodHandles.cpp:98), pid=8548, tid=4149795728 > # Error: guarantee(z && EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") > # > # JRE version: 7.0 > # Java VM: OpenJDK Client VM (16.0-b08 mixed mode linux-x86 ) > # An error report file with more information is saved as: > # /tmp/t/hs_err_pid8548.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > Aborted No idea why this fails like this. What I now need is either a workaround for this problem here, or a running JVM with method handles that I can download somewhere. As long as it is linux it should be fine, whatever it is. Who can help me here? bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From forax at univ-mlv.fr Wed Sep 9 11:59:08 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 09 Sep 2009 20:59:08 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA7F709.4020707@gmx.org> References: <4AA7F709.4020707@gmx.org> Message-ID: <4AA7FAFC.5050207@univ-mlv.fr> Le 09/09/2009 20:42, Jochen Theodorou a ?crit : > hi all, > > I am in urgend need of an actual VM with MethodHandles, but this is as > always quuite complicated. This time I created a chroot envrionment for > 32 bit, that was where I last time had to stop. I managed to get it > compiled by the patch that was provided here 5 months ago and finally > had a VM to run. So I did: > > davinci/sources/jdk/build/linux-i586/bin/java > -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles > -XX:+EnableInvokeDynamic FidgetDemo > > and got: > >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (methodHandles.cpp:98), pid=8548, tid=4149795728 >> # Error: guarantee(z&& EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Client VM (16.0-b08 mixed mode linux-x86 ) >> # An error report file with more information is saved as: >> # /tmp/t/hs_err_pid8548.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> Aborted >> > No idea why this fails like this. What I now need is either a workaround > for this problem here, or a running JVM with method handles that I can > download somewhere. As long as it is linux it should be fine, whatever > it is. > > Who can help me here? > Hi jochen, just try to remove -XX:+EnableMethodHandles. This line works for me: davinci/sources/jdk/build/linux-i586/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo > bye blackdrag > R?mi From blackdrag at gmx.org Wed Sep 9 11:51:20 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 09 Sep 2009 20:51:20 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA7FAFC.5050207@univ-mlv.fr> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> Message-ID: <4AA7F928.90407@gmx.org> R?mi Forax schrieb: > Le 09/09/2009 20:42, Jochen Theodorou a ?crit : >> hi all, >> >> I am in urgend need of an actual VM with MethodHandles, but this is as >> always quuite complicated. This time I created a chroot envrionment for >> 32 bit, that was where I last time had to stop. I managed to get it >> compiled by the patch that was provided here 5 months ago and finally >> had a VM to run. So I did: >> >> davinci/sources/jdk/build/linux-i586/bin/java >> -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles >> -XX:+EnableInvokeDynamic FidgetDemo >> >> and got: >> >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error (methodHandles.cpp:98), pid=8548, tid=4149795728 >>> # Error: guarantee(z&& EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") >>> # >>> # JRE version: 7.0 >>> # Java VM: OpenJDK Client VM (16.0-b08 mixed mode linux-x86 ) >>> # An error report file with more information is saved as: >>> # /tmp/t/hs_err_pid8548.log >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://java.sun.com/webapps/bugreport/crash.jsp >>> # The crash happened outside the Java Virtual Machine in native code. >>> # See problematic frame for where to report the bug. >>> # >>> Aborted >>> >> No idea why this fails like this. What I now need is either a workaround >> for this problem here, or a running JVM with method handles that I can >> download somewhere. As long as it is linux it should be fine, whatever >> it is. >> >> Who can help me here? >> > > Hi jochen, > just try to remove -XX:+EnableMethodHandles. > > This line works for me: > > davinci/sources/jdk/build/linux-i586/bin/java > -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles FidgetDemo OpenJDK Server VM warning: JSR 292 invokedynamic is disabled in this JVM. Use -XX:+EnableInvokeDynamic to enable. Fidgety self-modifying call site... --- loop #0 Exception in thread "main" java.lang.IncompatibleClassChangeError at FidgetDemo.main(FidgetDemo.java:13) doesn't look good bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From blackdrag at gmx.org Wed Sep 9 11:55:44 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 09 Sep 2009 20:55:44 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA7F928.90407@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> Message-ID: <4AA7FA30.30702@gmx.org> Jochen Theodorou schrieb: > R?mi Forax schrieb: >> Le 09/09/2009 20:42, Jochen Theodorou a ?crit : >>> hi all, >>> >>> I am in urgend need of an actual VM with MethodHandles, but this is as >>> always quuite complicated. This time I created a chroot envrionment for >>> 32 bit, that was where I last time had to stop. I managed to get it >>> compiled by the patch that was provided here 5 months ago and finally >>> had a VM to run. So I did: >>> >>> davinci/sources/jdk/build/linux-i586/bin/java >>> -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles >>> -XX:+EnableInvokeDynamic FidgetDemo >>> >>> and got: >>> >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # Internal Error (methodHandles.cpp:98), pid=8548, tid=4149795728 >>>> # Error: guarantee(z&& EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") >>>> # >>>> # JRE version: 7.0 >>>> # Java VM: OpenJDK Client VM (16.0-b08 mixed mode linux-x86 ) >>>> # An error report file with more information is saved as: >>>> # /tmp/t/hs_err_pid8548.log >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>> # The crash happened outside the Java Virtual Machine in native code. >>>> # See problematic frame for where to report the bug. >>>> # >>>> Aborted >>>> >>> No idea why this fails like this. What I now need is either a workaround >>> for this problem here, or a running JVM with method handles that I can >>> download somewhere. As long as it is linux it should be fine, whatever >>> it is. >>> >>> Who can help me here? >>> >> Hi jochen, >> just try to remove -XX:+EnableMethodHandles. >> >> This line works for me: >> >> davinci/sources/jdk/build/linux-i586/bin/java >> -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo > > > java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles FidgetDemo > OpenJDK Server VM warning: JSR 292 invokedynamic is disabled in this > JVM. Use -XX:+EnableInvokeDynamic to enable. > Fidgety self-modifying call site... > --- loop #0 > Exception in thread "main" java.lang.IncompatibleClassChangeError > at FidgetDemo.main(FidgetDemo.java:13) > > doesn't look good wrong one... still: java -XX:+UnlockExperimentalVMOptions FidgetDemoOpenJDK Server VM warning: JSR 292 method handles are disabled in this JVM. Use -XX:+EnableMethodHandles to enable. > Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.dyn.MethodHandleNatives.getConstant(I)I > at sun.dyn.MethodHandleNatives.getConstant(Native Method) > at sun.dyn.MethodHandleNatives.(MethodHandleNatives.java:125) > at sun.dyn.MethodHandleImpl.init(MethodHandleImpl.java:113) > at sun.dyn.MethodTypeImpl.initForm(MethodTypeImpl.java:375) > at java.dyn.MethodType.makeImpl(MethodType.java:186) > at java.dyn.MethodType.access$200(MethodType.java:51) > at java.dyn.MethodType$1.makeImpl(MethodType.java:76) > at sun.dyn.MethodTypeImpl.canonicalize(MethodTypeImpl.java:418) > at sun.dyn.MethodTypeImpl.findForm(MethodTypeImpl.java:380) > at sun.dyn.MethodTypeImpl.initForm(MethodTypeImpl.java:371) > at java.dyn.MethodType.makeImpl(MethodType.java:186) > at java.dyn.MethodType.make(MethodType.java:151) > at sun.dyn.MethodHandleImpl.(MethodHandleImpl.java:861) > at sun.dyn.MethodTypeImpl.initForm(MethodTypeImpl.java:375) > at java.dyn.MethodType.makeImpl(MethodType.java:186) > at java.dyn.MethodType.access$200(MethodType.java:51) > at java.dyn.MethodType$1.makeImpl(MethodType.java:76) > at sun.dyn.MethodTypeImpl.canonicalize(MethodTypeImpl.java:418) > at sun.dyn.MethodTypeImpl.findForm(MethodTypeImpl.java:380) > at sun.dyn.MethodTypeImpl.initForm(MethodTypeImpl.java:371) > at java.dyn.MethodType.makeImpl(MethodType.java:186) > at java.dyn.MethodType.make(MethodType.java:135) > at java.dyn.Linkage.(Linkage.java:148) > at FidgetDemo.(FidgetDemo.java:68) > bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From forax at univ-mlv.fr Wed Sep 9 12:16:34 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 09 Sep 2009 21:16:34 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA7FA30.30702@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> Message-ID: <4AA7FF12.3030906@univ-mlv.fr> Le 09/09/2009 20:55, Jochen Theodorou a ?crit : > Jochen Theodorou schrieb: > >> R?mi Forax schrieb: >> >>> Le 09/09/2009 20:42, Jochen Theodorou a ?crit : >>> >>>> hi all, >>>> >>>> I am in urgend need of an actual VM with MethodHandles, but this is as >>>> always quuite complicated. This time I created a chroot envrionment for >>>> 32 bit, that was where I last time had to stop. I managed to get it >>>> compiled by the patch that was provided here 5 months ago and finally >>>> had a VM to run. So I did: >>>> >>>> davinci/sources/jdk/build/linux-i586/bin/java >>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles >>>> -XX:+EnableInvokeDynamic FidgetDemo >>>> >>>> and got: >>>> >>>> >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # Internal Error (methodHandles.cpp:98), pid=8548, tid=4149795728 >>>>> # Error: guarantee(z&& EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") >>>>> # >>>>> # JRE version: 7.0 >>>>> # Java VM: OpenJDK Client VM (16.0-b08 mixed mode linux-x86 ) >>>>> # An error report file with more information is saved as: >>>>> # /tmp/t/hs_err_pid8548.log >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>> # See problematic frame for where to report the bug. >>>>> # >>>>> Aborted >>>>> >>>>> >>>> No idea why this fails like this. What I now need is either a workaround >>>> for this problem here, or a running JVM with method handles that I can >>>> download somewhere. As long as it is linux it should be fine, whatever >>>> it is. >>>> >>>> Who can help me here? >>>> >>>> >>> Hi jochen, >>> just try to remove -XX:+EnableMethodHandles. >>> >>> This line works for me: >>> >>> davinci/sources/jdk/build/linux-i586/bin/java >>> -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo >>> >> >> java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles FidgetDemo >> OpenJDK Server VM warning: JSR 292 invokedynamic is disabled in this >> JVM. Use -XX:+EnableInvokeDynamic to enable. >> Fidgety self-modifying call site... >> --- loop #0 >> Exception in thread "main" java.lang.IncompatibleClassChangeError >> at FidgetDemo.main(FidgetDemo.java:13) >> >> doesn't look good >> > wrong one... still: > > java -XX:+UnlockExperimentalVMOptions FidgetDemoOpenJDK Server VM > warning: JSR 292 method handles are disabled in this JVM. Use > -XX:+EnableMethodHandles to enable. > and java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo R?mi From blackdrag at gmx.org Wed Sep 9 12:20:57 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 09 Sep 2009 21:20:57 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA7FF12.3030906@univ-mlv.fr> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> Message-ID: <4AA80019.5040305@gmx.org> R?mi Forax schrieb: [...] > and > > java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (methodHandles.cpp:98), pid=9997, tid=4146412432 > # Error: guarantee(z && EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") > # > # JRE version: 7.0 > # Java VM: OpenJDK Server VM (16.0-b08 mixed mode linux-x86 ) > # An error report file with more information is saved as: > # /tmp/t/hs_err_pid9997.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > Aborted bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From headius at headius.com Wed Sep 9 15:47:03 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 10 Sep 2009 07:47:03 +0900 Subject: still no fun with invokedynamic In-Reply-To: <4AA7F709.4020707@gmx.org> References: <4AA7F709.4020707@gmx.org> Message-ID: Client often crashes for me still. Try -server. On Thu, Sep 10, 2009 at 3:42 AM, Jochen Theodorou wrote: > hi all, > > I am in urgend need of an actual VM with MethodHandles, but this is as > always quuite complicated. This time I created a chroot envrionment for > 32 bit, that was where I last time had to stop. I managed to get it > compiled by the patch that was provided here 5 months ago and finally > had a VM to run. So I did: > > davinci/sources/jdk/build/linux-i586/bin/java > -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles > -XX:+EnableInvokeDynamic FidgetDemo > > and got: >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # ?Internal Error (methodHandles.cpp:98), pid=8548, tid=4149795728 >> # ?Error: guarantee(z && EnableMethodHandles,"can only enable once, and only if -XX:+EnableMethodHandles") >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Client VM (16.0-b08 mixed mode linux-x86 ) >> # An error report file with more information is saved as: >> # /tmp/t/hs_err_pid8548.log >> # >> # If you would like to submit a bug report, please visit: >> # ? http://java.sun.com/webapps/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> Aborted > > No idea why this fails like this. What I now need is either a workaround > for this problem here, or a running JVM with method handles that I can > download somewhere. As long as it is linux it should be fine, whatever > it is. > > Who can help me here? > > bye blackdrag > > -- > Jochen "blackdrag" Theodorou > The Groovy Project Tech Lead (http://groovy.codehaus.org) > http://blackdragsview.blogspot.com/ > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From blackdrag at gmx.org Wed Sep 9 16:21:47 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 10 Sep 2009 01:21:47 +0200 Subject: still no fun with invokedynamic In-Reply-To: References: <4AA7F709.4020707@gmx.org> Message-ID: <4AA8388B.904@gmx.org> Charles Oliver Nutter schrieb: > Client often crashes for me still. Try -server. same game bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From forax at univ-mlv.fr Wed Sep 9 17:23:04 2009 From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=) Date: Thu, 10 Sep 2009 02:23:04 +0200 Subject: [jvm-l] Re: are there any invokedynamic enabled JVMs out there? In-Reply-To: <4AA8409C.2080002@gmx.org> References: <4AA82216.9000807@gmx.org> <4AA83B2A.6000904@univ-mlv.fr> <4AA83DA5.4090102@univ-mlv.fr> <4AA8409C.2080002@gmx.org> Message-ID: <4AA846E8.6030804@univ-mlv.fr> Le 10/09/2009 01:56, Jochen Theodorou a ?crit : > R?mi Forax schrieb: > [...] >> Try with this jar :) >> (it contains java.dyn/sun.dyn) >> >> /usr/jdk/jdk1.7.0/bin/java -davinci-server >> -Xbootclasspath/p:jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions >> -XX:+EnableInvokeDynamic FidgetDemo > > -davinci-server is not recognized here. Sorry, a personnal alias. > Besides that it does not solve anything. Hotspot still crashes. It seems there is a problem on BSD. It works on linux 32bits. > > bye Jochen > R?mi From Christian.Thalinger at Sun.COM Thu Sep 10 00:05:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 10 Sep 2009 09:05:17 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA80019.5040305@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> Message-ID: <4AA8A52D.4080706@Sun.COM> Jochen Theodorou wrote: > R?mi Forax schrieb: > [...] >> and >> >> java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo > > > java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic FidgetDemo > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (methodHandles.cpp:98), pid=9997, tid=4146412432 > > # Error: guarantee(z && EnableMethodHandles,"can only enable once, > and only if -XX:+EnableMethodHandles") > > # > > # JRE version: 7.0 > > # Java VM: OpenJDK Server VM (16.0-b08 mixed mode linux-x86 ) > > # An error report file with more information is saved as: > > # /tmp/t/hs_err_pid9997.log > > # > > # If you would like to submit a bug report, please visit: > > # http://java.sun.com/webapps/bugreport/crash.jsp > > # The crash happened outside the Java Virtual Machine in native code. > > # See problematic frame for where to report the bug. > > # > > Aborted I think that was a bug we had once. Is your mlvm repository up-to-date? Btw. if the interpreter is fast enough for you, you can now build a 64-bit VM. I've pushed the changes a few days ago. -- Christian From blackdrag at gmx.org Thu Sep 10 15:22:22 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 11 Sep 2009 00:22:22 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA8A52D.4080706@Sun.COM> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> Message-ID: <4AA97C1E.9080603@gmx.org> Christian Thalinger schrieb: [...] > I think that was a bug we had once. Is your mlvm repository up-to-date? from the same day, so I would say: yes. > Btw. if the interpreter is fast enough for you, you can now build a > 64-bit VM. I've pushed the changes a few days ago. no, the interpreter is not what I need. bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From headius at headius.com Thu Sep 10 17:58:23 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 11 Sep 2009 09:58:23 +0900 Subject: still no fun with invokedynamic In-Reply-To: <4AA97C1E.9080603@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> Message-ID: You could certainly use the interpreter to start prototyping whatever you are working on. I used interpreted mode for much of the JRuby invokedynamic work. On Friday, September 11, 2009, Jochen Theodorou wrote: > Christian Thalinger schrieb: > [...] >> I think that was a bug we had once. ?Is your mlvm repository up-to-date? > > from the same day, so I would say: yes. > >> Btw. if the interpreter is fast enough for you, you can now build a >> 64-bit VM. ?I've pushed the changes a few days ago. > > no, the interpreter is not what I need. > > bye Jochen > > -- > Jochen "blackdrag" Theodorou > The Groovy Project Tech Lead (http://groovy.codehaus.org) > http://blackdragsview.blogspot.com/ > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From blackdrag at gmx.org Thu Sep 10 18:08:39 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 11 Sep 2009 03:08:39 +0200 Subject: still no fun with invokedynamic In-Reply-To: References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> Message-ID: <4AA9A317.9060401@gmx.org> Charles Oliver Nutter schrieb: > You could certainly use the interpreter to start prototyping whatever > you are working on. I used interpreted mode for much of the JRuby > invokedynamic work. well I wanted to run an optimized Groovy against Methodhandles+invokedynamic and comparing both in the interpreted mode will not help much here. If I run normal Groovy with the server hotspot against the program with interpreter mode, the other one has no chance of winning. bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From headius at headius.com Thu Sep 10 19:16:42 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 10 Sep 2009 21:16:42 -0500 Subject: still no fun with invokedynamic In-Reply-To: <4AA9A317.9060401@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> Message-ID: 2009/9/10 Jochen Theodorou : > well I wanted to run an optimized Groovy against > Methodhandles+invokedynamic and comparing both in the interpreted mode > will not help much here. If I run normal Groovy with the server hotspot > against the program with interpreter mode, the other one has no chance > of winning. So you already have method handle support done in Groovy? - Charlie From john.rose at sun.com Thu Sep 10 19:20:42 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 11 Sep 2009 02:20:42 +0000 Subject: hg: mlvm/mlvm/hotspot: nonperm: passes bench_assert.rb (if +UseSerialGC), more PITs Message-ID: <20090911022042.A7976E603@hg.openjdk.java.net> Changeset: f7b9b9d12594 Author: jrose Date: 2009-09-10 19:16 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f7b9b9d12594 nonperm: passes bench_assert.rb (if +UseSerialGC), more PITs ! indy-6858164.patch ! nonperm-6863023.patch From forax at univ-mlv.fr Fri Sep 11 01:34:50 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 11 Sep 2009 10:34:50 +0200 Subject: Surinx + backport Message-ID: <4AAA0BAA.9080106@univ-mlv.fr> Hi all, I've done some benchs with Surinx + backport First, Charles, there is a bug in compiler.rb that prevent me to use Surinx. This bug was already present in Duby but I don't remember if I report it or not. The compiler generate a LDC + forName with a name containing slash ('/') instead of dot ('.') --- compiler.rb 2009-09-11 09:33:39.000000000 +0200 +++ compiler.old.rb 2009-09-11 10:19:15.000000000 +0200 @@ -245,7 +245,7 @@ def bootstrap @cb.static_init do - ldc this.name.gsub(/\//, '.') + ldc this.name invokestatic java.lang.Class, "forName", [java.lang.Class, string] invokestatic com.headius.surinx.SimpleJavaBootstrap, "registerBootstrap", [void, java.lang.Class] returnvoid Here are the result with the backport: [forax at localhost surinx]$ /usr/jdk/jdk1.6.0_11/bin/java -cp .:src -javaagent:../indy-backport2/lib/jsr292-backport.jar examples/fib hello 1.001 0.051 0.052 0.078 0.074 0.073 0.071 0.059 0.049 0.049 And with davinci VM (without inlining patch) [forax at localhost surinx]$ java -J-davinci-server -cp .:src -Xbootclasspath/p:/tmp/jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic examples/fib hello 0.288 0.273 0.277 0.277 0.272 0.271 0.272 0.272 0.271 0.272 Before trying to apply the inlining patch, is there a reason why it is guarded by testable ? R?mi From forax at univ-mlv.fr Fri Sep 11 01:41:42 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 11 Sep 2009 10:41:42 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA9A317.9060401@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> Message-ID: <4AAA0D46.6070708@univ-mlv.fr> Le 11/09/2009 03:08, Jochen Theodorou a ?crit : > Charles Oliver Nutter schrieb: > >> You could certainly use the interpreter to start prototyping whatever >> you are working on. I used interpreted mode for much of the JRuby >> invokedynamic work. >> > well I wanted to run an optimized Groovy against > Methodhandles+invokedynamic and comparing both in the interpreted mode > will not help much here. If I run normal Groovy with the server hotspot > against the program with interpreter mode, the other one has no chance > of winning. > > bye Jochen > You can also try the backport :) http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport R?mi From blackdrag at gmx.org Fri Sep 11 02:36:36 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 11 Sep 2009 11:36:36 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AAA0D46.6070708@univ-mlv.fr> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> Message-ID: <4AAA1A24.2040201@gmx.org> R?mi Forax schrieb: > Le 11/09/2009 03:08, Jochen Theodorou a ?crit : >> Charles Oliver Nutter schrieb: >> >>> You could certainly use the interpreter to start prototyping whatever >>> you are working on. I used interpreted mode for much of the JRuby >>> invokedynamic work. >>> >> well I wanted to run an optimized Groovy against >> Methodhandles+invokedynamic and comparing both in the interpreted mode >> will not help much here. If I run normal Groovy with the server hotspot >> against the program with interpreter mode, the other one has no chance >> of winning. >> > You can also try the backport :) > http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport well, I will most probably do, since there is nothing else and the VM implementation is hopefully faster than or of equal speed. In functionality I trust your backport very much ;) bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From Christian.Thalinger at Sun.COM Fri Sep 11 02:42:41 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 11 Sep 2009 11:42:41 +0200 Subject: Surinx + backport In-Reply-To: <4AAA0BAA.9080106@univ-mlv.fr> References: <4AAA0BAA.9080106@univ-mlv.fr> Message-ID: <4AAA1B91.6040208@Sun.COM> R?mi Forax wrote: > Before trying to apply the inlining patch, is there a reason why it is > guarded by testable ? Not really, it's working quite good. But we still have these GC issues, which also apply to the compiler patch... :-/ -- Christian From headius at headius.com Fri Sep 11 05:43:38 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 11 Sep 2009 07:43:38 -0500 Subject: Surinx + backport In-Reply-To: <4AAA0BAA.9080106@univ-mlv.fr> References: <4AAA0BAA.9080106@univ-mlv.fr> Message-ID: On Fri, Sep 11, 2009 at 3:34 AM, R?mi Forax wrote: > First, Charles, there is a bug in compiler.rb that prevent me to use Surinx. > > This bug was already present in Duby but I don't remember if I report it or > not. > The compiler generate a LDC + forName with a name containing slash ('/') > instead of dot ('.') Ahh, thanks for this :) I will patch it. > Here are the result with the backport: > [forax at localhost surinx]$ /usr/jdk/jdk1.6.0_11/bin/java -cp .:src > -javaagent:../indy-backport2/lib/jsr292-backport.jar examples/fib > hello > 1.001 > 0.051 > 0.052 > 0.078 > 0.074 These are definitely good results, comparable to what I was getting with MLVM + the inlining patch! I need to spend some time playing with backport + JRuby soon. - Charlie From forax at univ-mlv.fr Fri Sep 11 07:07:48 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 11 Sep 2009 16:07:48 +0200 Subject: Surinx + backport In-Reply-To: References: <4AAA0BAA.9080106@univ-mlv.fr> Message-ID: <4AAA59B4.1070209@univ-mlv.fr> Le 11/09/2009 14:43, Charles Oliver Nutter a ?crit : > On Fri, Sep 11, 2009 at 3:34 AM, R?mi Forax wrote: > >> First, Charles, there is a bug in compiler.rb that prevent me to use Surinx. >> >> This bug was already present in Duby but I don't remember if I report it or >> not. >> The compiler generate a LDC + forName with a name containing slash ('/') >> instead of dot ('.') >> > Ahh, thanks for this :) I will patch it. > > >> Here are the result with the backport: >> [forax at localhost surinx]$ /usr/jdk/jdk1.6.0_11/bin/java -cp .:src >> -javaagent:../indy-backport2/lib/jsr292-backport.jar examples/fib >> hello >> 1.001 >> 0.051 >> 0.052 >> 0.078 >> 0.074 >> > These are definitely good results, comparable to what I was getting > with MLVM + the inlining patch! > Cool ! I will try that this evening. > I need to spend some time playing with backport + JRuby soon. > The problem with JRuby is that the code blob generated by the backport optimizer from the mh adapter tree is too big to be inlined. This is partially my fault because sometimes the backport doesn't generate the most efficient code. > - Charlie > R?mi From forax at univ-mlv.fr Fri Sep 11 15:35:15 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 12 Sep 2009 00:35:15 +0200 Subject: Surinx + backport In-Reply-To: <4AAA1B91.6040208@Sun.COM> References: <4AAA0BAA.9080106@univ-mlv.fr> <4AAA1B91.6040208@Sun.COM> Message-ID: <4AAAD0A3.90004@univ-mlv.fr> Le 11/09/2009 11:42, Christian Thalinger a ?crit : > R?mi Forax wrote: > >> Before trying to apply the inlining patch, is there a reason why it is >> guarded by testable ? >> > Not really, it's working quite good. But we still have these GC issues, > which also apply to the compiler patch... :-/ > > -- Christian > Christian, the inlining patch currently doesn't work :( in methodHandleWalk.hpp (line 322) : int cpool_oop_reference_put(int tag, int first_index, int second_index) { if (index == 0) return 0; // this line doesn't compile ConstantValue* cv = new ConstantValue(tag, first_index, second_index); return _constants.append(cv); } I think it should be: int cpool_oop_reference_put(int tag, int first_index, int second_index) { if (first_index == 0 && second_index == 0) return 0; ConstantValue* cv = new ConstantValue(tag, first_index, second_index); return _constants.append(cv); } R?mi From John.Rose at Sun.COM Fri Sep 11 16:32:45 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 11 Sep 2009 16:32:45 -0700 Subject: Surinx + backport In-Reply-To: <4AAAD0A3.90004@univ-mlv.fr> References: <4AAA0BAA.9080106@univ-mlv.fr> <4AAA1B91.6040208@Sun.COM> <4AAAD0A3.90004@univ-mlv.fr> Message-ID: <6AE10DA6-35BA-4287-A95C-B7B467F932F4@sun.com> On Sep 11, 2009, at 3:35 PM, R?mi Forax wrote: > Christian, > the inlining patch currently doesn't work :( > > in methodHandleWalk.hpp (line 322) : > > int cpool_oop_reference_put(int tag, int first_index, int > second_index) { > if (index == 0) return 0; // this line doesn't compile That's pretty funny: On some platforms index is an old alias for strchr, after the a function name is auto-converted to a pointer and the zero is auto-converted to a null, causes the expression to be "valid". Thanks, I'll roll this into my next push if Christian doesn't get there first. -- John From Christian.Thalinger at Sun.COM Sat Sep 12 01:03:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sat, 12 Sep 2009 10:03:58 +0200 Subject: Surinx + backport In-Reply-To: <6AE10DA6-35BA-4287-A95C-B7B467F932F4@sun.com> References: <4AAA0BAA.9080106@univ-mlv.fr> <4AAA1B91.6040208@Sun.COM> <4AAAD0A3.90004@univ-mlv.fr> <6AE10DA6-35BA-4287-A95C-B7B467F932F4@sun.com> Message-ID: <4AAB55EE.6020901@Sun.COM> John Rose wrote: > On Sep 11, 2009, at 3:35 PM, R?mi Forax wrote: > >> Christian, >> the inlining patch currently doesn't work :( >> >> in methodHandleWalk.hpp (line 322) : >> >> int cpool_oop_reference_put(int tag, int first_index, int >> second_index) { >> if (index == 0) return 0; // this line doesn't compile > > That's pretty funny: On some platforms index is an old alias for > strchr, after the a function name is auto-converted to a pointer and > the zero is auto-converted to a null, causes the expression to be > "valid". Ha! Thanks for the explanation, I didn't understand how this compiles for me :-) -- Christian From john.rose at sun.com Sat Sep 12 01:16:05 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 12 Sep 2009 08:16:05 +0000 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: <20090912081605.8AC4B12049@hg.openjdk.java.net> Changeset: ee07ee0ed86f Author: jrose Date: 2009-09-12 01:14 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ee07ee0ed86f indy.compiler.inline: minor bug fixes ! indy.compiler.inline.patch Changeset: 9f5f4ee14324 Author: jrose Date: 2009-09-12 01:15 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9f5f4ee14324 nonperm: passes PITs, runs bench_assert.rb (all GC modes) ! indy-6858164.patch ! nonperm-6863023.patch From John.Rose at Sun.COM Sat Sep 12 01:21:22 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 12 Sep 2009 01:21:22 -0700 Subject: Surinx + backport In-Reply-To: <4AAB55EE.6020901@Sun.COM> References: <4AAA0BAA.9080106@univ-mlv.fr> <4AAA1B91.6040208@Sun.COM> <4AAAD0A3.90004@univ-mlv.fr> <6AE10DA6-35BA-4287-A95C-B7B467F932F4@sun.com> <4AAB55EE.6020901@Sun.COM> Message-ID: I just pushed that fix. I also pushed (what I hope are) the fixes for the last GC bugs. Please let me know what happens. -- John On Sep 12, 2009, at 1:03 AM, Christian Thalinger wrote: > Ha! Thanks for the explanation, I didn't understand how this compiles > for me :-) From headius at headius.com Sat Sep 12 02:47:16 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 12 Sep 2009 04:47:16 -0500 Subject: Surinx + backport In-Reply-To: References: <4AAA0BAA.9080106@univ-mlv.fr> <4AAA1B91.6040208@Sun.COM> <4AAAD0A3.90004@univ-mlv.fr> <6AE10DA6-35BA-4287-A95C-B7B467F932F4@sun.com> <4AAB55EE.6020901@Sun.COM> Message-ID: On Sat, Sep 12, 2009 at 3:21 AM, John Rose wrote: > I just pushed that fix. ?I also pushed (what I hope are) the fixes for > the last GC bugs. ?Please let me know what happens. Updated numbers for Surinx, new build as of a few minutes ago: ~/projects/surinx ? jruby --server -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableInvokeDynamic bin/surinx examples/fib.sx 0.091 0.068 0.066 0.067 0.067 0.066 0.066 0.065 0.069 0.066 I don't have Remi's backport handy, but it's obviously very close. JRuby numbers are nearly as fast as non-indy now too: ~/projects/jruby ? jruby --server bench/bench_fib_recursive.rb 100 0.473000 0.000000 0.473000 ( 0.421000) 0.241000 0.000000 0.241000 ( 0.241000) 0.239000 0.000000 0.239000 ( 0.239000) 0.242000 0.000000 0.242000 ( 0.242000) 0.239000 0.000000 0.239000 ( 0.239000) 0.236000 0.000000 0.236000 ( 0.236000) 0.236000 0.000000 0.236000 ( 0.236000) ~/projects/jruby ? jruby --server -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableInvokeDynamic -J-XX:InlineSmallCode=1500 -J-XX:MaxInlineSize=150 bench/bench_fib_recursive.rb 100 0.444000 0.000000 0.444000 ( 0.378000) 0.236000 0.000000 0.236000 ( 0.236000) 0.231000 0.000000 0.231000 ( 0.231000) 0.234000 0.000000 0.234000 ( 0.234000) 0.233000 0.000000 0.233000 ( 0.233000) 0.235000 0.000000 0.235000 ( 0.235000) 0.235000 0.000000 0.235000 ( 0.236000) If I remove some special-case code for math operations, indy actually improves, beating stock JRuby: ~/projects/jruby ? jruby --server -J-XX:+UnlockExperimentalVMOptions -J-XX:+EnableInvokeDynamic -J-XX:InlineSmallCode=1500 -J-XX:MaxInlineSize=150 bench/bench_fib_recursive.rb 100 0.429000 0.000000 0.429000 ( 0.365000) 0.237000 0.000000 0.237000 ( 0.237000) 0.231000 0.000000 0.231000 ( 0.230000) 0.231000 0.000000 0.231000 ( 0.230000) 0.229000 0.000000 0.229000 ( 0.230000) 0.229000 0.000000 0.229000 ( 0.229000) 0.227000 0.000000 0.227000 ( 0.227000) 0.226000 0.000000 0.226000 ( 0.227000) It's time for that blog post I've been promising about "how to" and "why it's awesome". - Charlie From john.rose at sun.com Sat Sep 12 03:25:51 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 12 Sep 2009 10:25:51 +0000 Subject: hg: mlvm/mlvm/hotspot: nonperm: trivial naming tweak Message-ID: <20090912102552.2B15E1204E@hg.openjdk.java.net> Changeset: d9f1750f4e74 Author: jrose Date: 2009-09-12 03:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d9f1750f4e74 nonperm: trivial naming tweak ! nonperm-6863023.patch From forax at univ-mlv.fr Sat Sep 12 15:32:16 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 13 Sep 2009 00:32:16 +0200 Subject: Surinx + backport In-Reply-To: References: <4AAA0BAA.9080106@univ-mlv.fr> <4AAA1B91.6040208@Sun.COM> <4AAAD0A3.90004@univ-mlv.fr> <6AE10DA6-35BA-4287-A95C-B7B467F932F4@sun.com> <4AAB55EE.6020901@Sun.COM> Message-ID: <4AAC2170.2060904@univ-mlv.fr> Le 12/09/2009 11:47, Charles Oliver Nutter a ?crit : > On Sat, Sep 12, 2009 at 3:21 AM, John Rose wrote: > >> I just pushed that fix. I also pushed (what I hope are) the fixes for >> the last GC bugs. Please let me know what happens. >> > Updated numbers for Surinx, new build as of a few minutes ago: > > ~/projects/surinx ? jruby --server -J-XX:+UnlockExperimentalVMOptions > -J-XX:+EnableInvokeDynamic bin/surinx examples/fib.sx > 0.091 > 0.068 > 0.066 > 0.067 > 0.067 > 0.066 > 0.066 > 0.065 > 0.069 > 0.066 > > I don't have Remi's backport handy, but it's obviously very close. > [forax at localhost surinx]$ /usr/jdk/jdk1.6.0_11/bin/java -server -cp .:src -javaagent:../indy-backport2/lib/jsr292-backport.jar examples/fib hello 0.914 <-- Oups, bytecode generation is not cheap ! 0.071 0.072 0.064 0.072 0.071 0.067 0.068 0.065 0.06 [forax at localhost surinx]$ java -davinci-server-inlining -cp .:src -Xbootclasspath/p:/tmp/jdk7-jsr292.jar -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic examples/fib hello 0.084 0.065 0.06 0.062 0.064 0.06 0.063 0.061 0.064 0.063 As you say, it's very close :) > - Charlie > R?mi From John.Rose at Sun.COM Sat Sep 12 17:38:39 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 12 Sep 2009 17:38:39 -0700 Subject: still no fun with invokedynamic In-Reply-To: <4AAA1A24.2040201@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> <4AAA1A24.2040201@gmx.org> Message-ID: On Sep 11, 2009, at 2:36 AM, Jochen Theodorou wrote: >> You can also try the backport :) >> http://code.google.com/p/jvm-language-runtime/source/browse/#svn/ >> trunk/invokedynamic-backport > > well, I will most probably do, since there is nothing else and the VM > implementation is hopefully faster than or of equal speed. In > functionality I trust your backport very much ;) The backport a great option for experimentation, since it does not require a pre-release JVM. Its performance seems to be comparable to the current MLVM JVM. Basically what you get is a backend that performs JRuby-like rewrites of JSR 292 bytecodes. As we work on code quality (JIT optimizer) in the MLVM JVM, I expect that the native JSR 292 implementations will be decisively faster, since the JSR 292 version of the code has (potentially) more quasi-static knowledge for the JIT optimizer to exploit. Also, note that the JVM and the JDK are tightly coupled in the JSR 292 implementations. At least during JDK7 development, you can't mix and match JVMs and JDKs. The best bet will be to use an JDK7 build updated with the current MLVM stuff, when that becomes available. But MLVM will always be ahead of the curve. I wonder if our friends over at EngineYard are making builds from it? (Hint, hint.) I know Attila Szegedi also has been making MLVM builds and posting the bits. The other question, of course, is when the MLVM stuff will get into the JDK7 builds. That work has been road-blocked by implementation problems in the GC; it's what I've been working on for several weeks (plus vacation). GC extensions are behind many of the crashes we've been seeing in the MLVM. As of last night, I have a set of GC changes that pass the JDK7 pre-integration testing, and also begin to support the JRuby tests (the benchmarks, actually). Pushing these into the JDK7 pipeline will open the way to committing the other pending MLVM changes, so we can get standard builds that are beyond the JavaOne preview functionality. See you at the Summit! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090912/7c751588/attachment.html From john.rose at sun.com Sat Sep 12 19:25:19 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sun, 13 Sep 2009 02:25:19 +0000 Subject: hg: mlvm/mlvm/hotspot: hotswap: initial version from Thomas Wuerthinger Message-ID: <20090913022519.DB02B12087@hg.openjdk.java.net> Changeset: 8800c1fd00fd Author: jrose Date: 2009-09-12 19:24 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8800c1fd00fd hotswap: initial version from Thomas Wuerthinger + hotswap.patch + hotswap.txt ! series From headius at headius.com Sat Sep 12 20:54:34 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 12 Sep 2009 22:54:34 -0500 Subject: still no fun with invokedynamic In-Reply-To: References: <4AA7F709.4020707@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> <4AAA1A24.2040201@gmx.org> Message-ID: On Sat, Sep 12, 2009 at 7:38 PM, John Rose wrote: > Also, note that the JVM and the JDK are tightly coupled in the JSR 292 > implementations. ?At least during JDK7 development, you can't mix and match > JVMs and JDKs. ?The best bet will be to use an JDK7 build updated with the > current MLVM stuff, when that becomes available. ?But MLVM will always be > ahead of the curve. ?I wonder if our friends over at EngineYard are making > builds from it? ?(Hint, hint.) ?I know Attila Szegedi also has been making > MLVM builds and posting the bits. Yes yes, I'm behind on my promises :) I'll push a binary for OS X build tonight and see about setting up a linux32 env as well. Promise! - Charlie From headius at headius.com Sat Sep 12 23:51:26 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 13 Sep 2009 01:51:26 -0500 Subject: still no fun with invokedynamic In-Reply-To: References: <4AA7F709.4020707@gmx.org> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> <4AAA1A24.2040201@gmx.org> Message-ID: I know it doesn't help Jochen, but I did push latest MLVM build on darwin x86-32 to my "invoke dynamic tests" project on Kenai: http://kenai.com/projects/invoke-dynamic-tests/downloads I had some trouble with my linux build I'll need to poke at for a while. On Sat, Sep 12, 2009 at 10:54 PM, Charles Oliver Nutter wrote: > On Sat, Sep 12, 2009 at 7:38 PM, John Rose wrote: >> Also, note that the JVM and the JDK are tightly coupled in the JSR 292 >> implementations. ?At least during JDK7 development, you can't mix and match >> JVMs and JDKs. ?The best bet will be to use an JDK7 build updated with the >> current MLVM stuff, when that becomes available. ?But MLVM will always be >> ahead of the curve. ?I wonder if our friends over at EngineYard are making >> builds from it? ?(Hint, hint.) ?I know Attila Szegedi also has been making >> MLVM builds and posting the bits. > > Yes yes, I'm behind on my promises :) > > I'll push a binary for OS X build tonight and see about setting up a > linux32 env as well. > > Promise! > > - Charlie > From pdoubleya at gmail.com Sun Sep 13 00:22:36 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Sun, 13 Sep 2009 09:22:36 +0200 Subject: Hotswap patch? Message-ID: <64efa1ba0909130022o7050f5c0h1e44aa29c461baa8@mail.gmail.com> Hi John I just saw that you pushed a changeset from Thomas Wuerthinger related to expanding hotswap--from the unit tests included, it looks pretty nice--add/remove fields and methods etc. Anything you can tell us about it, status etc? I didn't know anyone was working on this in the Da Vinci Machine. Thanks! Patrick From forax at univ-mlv.fr Sun Sep 13 05:05:06 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 13 Sep 2009 14:05:06 +0200 Subject: still no fun with invokedynamic In-Reply-To: References: <4AA7F709.4020707@gmx.org> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> <4AAA1A24.2040201@gmx.org> Message-ID: <4AACDFF2.2050508@univ-mlv.fr> Le 13/09/2009 08:51, Charles Oliver Nutter a ?crit : > I know it doesn't help Jochen, but I did push latest MLVM build on > darwin x86-32 to my "invoke dynamic tests" project on Kenai: > > http://kenai.com/projects/invoke-dynamic-tests/downloads > > I had some trouble with my linux build I'll need to poke at for a while. > I've uploaded a linux x86 server VM with inlining patch enable and the jsr292 jdk classes. http://www-igm.univ-mlv.fr/~forax/tmp/davinci/ (the VM is compiled on a fedora 11, libstc++ 6.0.12) To use it, download JDK7 b71 binaries, http://download.java.net/jdk7/binaries/ Install it untar http://www-igm.univ-mlv.fr/~forax/tmp/davinci/linux-x86-server-vm.tgz in /tmp copy the directory 'server' in jdk1.7.0/jre/lib/i386 under the name 'davinci-server' Add a line the following line in jdk1.7.0/jre/lib/i386/jvm.cfg '-davinci-server KNOWN' after the line '-server KNOWN' download the jar: jdk7-jsr292.jar to run an example: jdk1.7.0/bin/java -davinci-server -Xbootclasspath/p:jdk7-jsr292.jar YourClass R?mi > On Sat, Sep 12, 2009 at 10:54 PM, Charles Oliver Nutter > wrote: > >> On Sat, Sep 12, 2009 at 7:38 PM, John Rose wrote: >> >>> Also, note that the JVM and the JDK are tightly coupled in the JSR 292 >>> implementations. At least during JDK7 development, you can't mix and match >>> JVMs and JDKs. The best bet will be to use an JDK7 build updated with the >>> current MLVM stuff, when that becomes available. But MLVM will always be >>> ahead of the curve. I wonder if our friends over at EngineYard are making >>> builds from it? (Hint, hint.) I know Attila Szegedi also has been making >>> MLVM builds and posting the bits. >>> >> Yes yes, I'm behind on my promises :) >> >> I'll push a binary for OS X build tonight and see about setting up a >> linux32 env as well. >> >> Promise! >> >> - Charlie >> >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From forax at univ-mlv.fr Sun Sep 13 06:53:02 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 13 Sep 2009 15:53:02 +0200 Subject: still no fun with invokedynamic In-Reply-To: References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> <4AAA1A24.2040201@gmx.org> Message-ID: <4AACF93E.6040704@univ-mlv.fr> Le 13/09/2009 02:38, John Rose a ?crit : > On Sep 11, 2009, at 2:36 AM, Jochen Theodorou wrote: > >>> You can also try the backport :) >>> http://code.google.com/p/jvm-language-runtime/source/browse/#svn/trunk/invokedynamic-backport >> >> well, I will most probably do, since there is nothing else and the VM >> implementation is hopefully faster than or of equal speed. In >> functionality I trust your backport very much ;) > > The backport a great option for experimentation, since it does not > require a pre-release JVM. Its performance seems to be comparable to > the current MLVM JVM. Basically what you get is a backend that > performs JRuby-like rewrites of JSR 292 bytecodes. As we work on code > quality (JIT optimizer) in the MLVM JVM, I expect that the native JSR > 292 implementations will be decisively faster, since the JSR 292 > version of the code has (potentially) more quasi-static knowledge for > the JIT optimizer to exploit. John, I don't agree with you :) The backport provide you more than the JRuby-like optimisation, or perhaps not more but something different. In fact the backport can be split in two parts, a part that is like the JRuby optimisations on method calls, i.e an abstract class that contains one abstract method by arity. Another part, named optimizer, works more like the indy compiler inlining patch, it is triggered when a method handle/call site is used often and try to produce from the method handle adapter tree a simple sequence of bytecode that the VM JIT will be able to inline. Unlike JRuby, the backport neither controls the signature of the invokedynamic bytecode at call site nor it controls the signature of the functions/methods of the language. So at call site the backport may have to do some boxing/unboxing and at callee part the backport may rely on reflection. The backport optimizer has the same knowledge (almost) than the MLVM JIT but because it produce raw bytecode, it can't send its knowledge to the JIT. So I agree with John that in one year (perhaps less) the MLVM compiler is/will be faster. > > Also, note that the JVM and the JDK are tightly coupled in the JSR 292 > implementations. At least during JDK7 development, you can't mix and > match JVMs and JDKs. The best bet will be to use an JDK7 build > updated with the current MLVM stuff, when that becomes available. But > MLVM will always be ahead of the curve. I wonder if our friends over > at EngineYard are making builds from it? (Hint, hint.) I know Attila > Szegedi also has been making MLVM builds and posting the bits. > > The other question, of course, is when the MLVM stuff will get into > the JDK7 builds. That work has been road-blocked by implementation > problems in the GC; it's what I've been working on for several weeks > (plus vacation). GC extensions are behind many of the crashes we've > been seeing in the MLVM. As of last night, I have a set of GC changes > that pass the JDK7 pre-integration testing, and also begin to support > the JRuby tests (the benchmarks, actually). Pushing these into the > JDK7 pipeline will open the way to committing the other pending MLVM > changes, so we can get standard builds that are beyond the JavaOne > preview functionality. > > See you at the Summit! > -- John See you there, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090913/b9d95c40/attachment-0001.html From Christian.Thalinger at Sun.COM Mon Sep 14 06:52:46 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 14 Sep 2009 13:52:46 +0000 Subject: hg: mlvm/mlvm/hotspot: Rebase to bsd-port revision af57fa28a975. Message-ID: <20090914135247.59B1B120EC@hg.openjdk.java.net> Changeset: c87e0466e03c Author: twisti Date: 2009-09-14 15:50 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c87e0466e03c Rebase to bsd-port revision af57fa28a975. ! indy.compiler.patch ! series From Christian.Thalinger at Sun.COM Mon Sep 14 06:53:04 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 14 Sep 2009 13:53:04 +0000 Subject: hg: mlvm/mlvm/jdk: Rebase to bsd-port revision b9385025025d. Message-ID: <20090914135305.1DB82120F1@hg.openjdk.java.net> Changeset: 661ea69a387d Author: twisti Date: 2009-09-14 15:51 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/661ea69a387d Rebase to bsd-port revision b9385025025d. ! series From Christian.Thalinger at Sun.COM Mon Sep 14 07:53:50 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 14 Sep 2009 14:53:50 +0000 Subject: hg: mlvm/mlvm/hotspot: indy.compiler: AMD64 support added. Message-ID: <20090914145350.4543C120FC@hg.openjdk.java.net> Changeset: e397cf760b83 Author: twisti Date: 2009-09-14 16:46 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e397cf760b83 indy.compiler: AMD64 support added. indy.compiler.inline: Updated. ! indy.compiler.inline.patch ! indy.compiler.patch From Christian.Thalinger at Sun.COM Mon Sep 14 08:20:48 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 14 Sep 2009 17:20:48 +0200 Subject: Linux, Solaris and AMD64 support Message-ID: <4AAE5F50.6070309@Sun.COM> Hi! My today's commits enable a couple of things that might help some people here. First, I updated to the newest bsd-port revision since Greg Lewis commited some patches so that it's possible to build the bsd-port source on Linux and Solaris without any patches. The other commit adds AMD64 compiler support. I did another JRuby benchmark run today and the results look very good (on both 32 and 64-bit). It seems John has fixed most problems. Here is the current list of all benchmarks: --- bench_assert.rb: failed on both # Internal Error (/Users/twisti/mlvm/hotspot-amd64/src/share/vm/compiler/oopMap.cpp:425), pid=82389, tid=2953318400 # Error: assert(Universe::heap()->is_in_or_null(*loc),"found non oop pointer") --- bench_attr_reader.rb: OK --- bench_bigdecimal.rb: OK --- bench_chmod.rb: OK --- bench_compiled_load.rb: OK --- bench_concat.rb OK --- bench_constantize.rb OK --- bench_define_method_methods.rb OK --- bench_delegate.rb OK --- bench_each_line.rb OK --- bench_each_line_from_file.rb OK --- bench_enumerable.rb OK --- bench_erb.rb OK --- bench_erb_rendering.rb OK --- bench_erubis.rb: `require': no such file to load -- rbench (LoadError) --- bench_euler_hash_default.rb: OK --- bench_eval.rb: OK --- bench_exceptions_stack_depth.rb: OK --- bench_fib_chained.rb: OK --- bench_fib_iterative.rb: OK --- bench_fib_recursive.rb: OK --- bench_fib_stack_depth.rb: Segmentation fault --- bench_file_writing.rb: OK --- bench_float_math.rb: OK --- bench_fractal.rb: OK --- bench_full_startup.rb: OK --- bench_hash_each.rb: OK --- bench_instance_eval.rb: OK --- bench_io_foreach.rb: failed on both # Internal Error (/Users/twisti/mlvm/hotspot-amd64/src/share/vm/code/nmethod.cpp:2017), pid=82799, tid=4995690496 # Error: guarantee(pd != __null,"pc descriptor must be present") --- bench_io_gets.rb OK --- bench_io_open.rb OK --- bench_io_read.rb OK --- bench_io_sysread.rb OK --- bench_io_tcpsocket.rb OK --- bench_jruby_init.rb OK --- bench_kind_of.rb OK --- bench_lazy_method_triggers.rb `require': no such file to load -- rbench (LoadError) --- bench_loop_versus_while.rb 32-bit OK, 64-bit failed # Internal Error (/Users/twisti/mlvm/hotspot/src/share/vm/code/nmethod.cpp:2004), pid=91087, tid=2953318400 # Error: guarantee(pd != __null,"pc descriptor must be present") --- bench_loops.rb OK --- bench_marshal.rb OK --- bench_method_missing.rb OK --- bench_method_to_proc.rb OK --- bench_nsieve.rb OK --- bench_object_extend.rb OK --- bench_object_id.rb OK --- bench_parser.rb OK --- bench_proc_invocation.rb OK --- bench_process_times.rb OK --- bench_pythag.rb OK --- bench_quicksort.rb OK --- bench_rails_regexen.rb OK --- bench_rake_install.rb undefined method `manage_gems' for Gem:Module (NoMethodError) --- bench_regex.rb OK --- bench_regex_caching.rb OK --- bench_respond_to.rb OK --- bench_rexml.rb failed on both # Internal Error (/Users/twisti/mlvm/hotspot-amd64/src/share/vm/compiler/oopMap.cpp:425), pid=83412, tid=4995690496 # Error: assert(Universe::heap()->is_in_or_null(*loc),"found non oop pointer") --- bench_richards.rb OK --- bench_sclass.rb OK --- bench_send.rb OK --- bench_singleton_dispatch.rb OK --- bench_stack_depth.rb Segmentation fault --- bench_stat.rb OK --- bench_string_ops.rb OK --- bench_string_pack.rb OK --- bench_string_scan.rb OK --- bench_stringio_puts.rb OK --- bench_stringio_write.rb OK --- bench_stringscanner.rb OK --- bench_strptime.rb 32-bit failed, 64-bit OK # Internal Error (/Users/twisti/mlvm/hotspot-amd64/src/share/vm/compiler/oopMap.cpp:425), pid=85370, tid=2953318400 # Error: assert(Universe::heap()->is_in_or_null(*loc),"found non oop pointer") --- bench_struct.rb OK --- bench_symbol_to_proc.rb OK --- bench_symbol_to_s.rb OK --- bench_tak.rb OK --- bench_tempfile.rb OK --- bench_thread_creation.rb OK --- bench_threaded_reverse.rb 10 failed on both # Internal Error (/Users/twisti/mlvm/hotspot/src/cpu/x86/vm/frame_x86.inline.hpp:232), pid=82215, tid=2953318400 # Error: assert(last_sp < fp() && last_sp >= sp(),"bad tos") --- bench_time.rb OK --- bench_time_require.rb `report_activate_error': Could not find RubyGem activerecord (>= 0) (Gem::LoadError) --- bench_timeout.rb 32-bit OK, 64-bit failed # Internal Error (/Users/twisti/mlvm/hotspot-amd64/src/cpu/x86/vm/frame_x86.inline.hpp:232), pid=83697, tid=4995690496 # Error: assert(last_sp < fp() && last_sp >= sp(),"bad tos") --- bench_up_downto_times.rb OK --- bench_wide_finder.rb bench/o10k.ap OK --- bench_xml_builder.rb `require': no such file to load -- builder (LoadError) --- bench_yaml.rb 32-bit failed, 64-bit OK # Internal Error (/Users/twisti/mlvm/hotspot-amd64/src/share/vm/compiler/oopMap.cpp:425), pid=85549, tid=2953318400 # Error: assert(Universe::heap()->is_in_or_null(*loc),"found non oop pointer") Some of the fails are intermittent and need a couple of runs to actually trigger. -- Christian From Christian.Thalinger at Sun.COM Mon Sep 14 08:24:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 14 Sep 2009 17:24:10 +0200 Subject: still no fun with invokedynamic In-Reply-To: <4AA9A317.9060401@gmx.org> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> Message-ID: <4AAE601A.5070406@Sun.COM> Jochen Theodorou wrote: > Charles Oliver Nutter schrieb: >> You could certainly use the interpreter to start prototyping whatever >> you are working on. I used interpreted mode for much of the JRuby >> invokedynamic work. > > well I wanted to run an optimized Groovy against > Methodhandles+invokedynamic and comparing both in the interpreted mode > will not help much here. If I run normal Groovy with the server hotspot > against the program with interpreter mode, the other one has no chance > of winning. I just commited AMD64 compiler support and some patches from the bsd-port to be able to build on Linux. That should fit your needs. Let me know how it works. -- Christian From John.Rose at Sun.COM Tue Sep 15 14:31:40 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 15 Sep 2009 14:31:40 -0700 Subject: Hotswap patch? In-Reply-To: <64efa1ba0909130022o7050f5c0h1e44aa29c461baa8@mail.gmail.com> References: <64efa1ba0909130022o7050f5c0h1e44aa29c461baa8@mail.gmail.com> Message-ID: On Sep 13, 2009, at 12:22 AM, Patrick Wright wrote: > I just saw that you pushed a changeset from Thomas Wuerthinger related > to expanding hotswap--from the unit tests included, it looks pretty > nice--add/remove fields and methods etc. Anything you can tell us > about it, status etc? I didn't know anyone was working on this in the > Da Vinci Machine. The design of the hotswap patch is described in the PDF linked from this page: http://wikis.sun.com/display/mlvm/HotSwap I believe (under correction from you, Thomas!) that the patch is the initial result of a research project that he did earlier this year at JKU Linz, that he is now working on other things, and that he doesn't have specific plans (yet) to extend it further. See the message below. Thomas will be talking about this work at Sun on Wednesday, and InfoQ will be taping the talk (like most of the talks at the Summit). -- John Begin forwarded message: From: Thomas Wuerthinger Date: April 1, 2009 8:49:07 AM PDT To: c1cr at sun.com Subject: Dynamic Code Evolution - Patch and Documentation Hi! This is the first (pre-alpha) version of the dynamic code evolution implementation. The attachment contains: - A patch that can be used upon jdk7-b51 with the sources for dynamic code evolution as well as the test cases (37 of 41 should be OK); please consider that it is still a prototype implementation. - A high-level technical description of the implementation with pointers to the source code and TODO sections that inform about future plans. Any kind of feedback most welcome! Let me know if you have any issues compiling the code or running the test cases. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090915/e5223345/attachment.html From John.Rose at Sun.COM Tue Sep 15 17:56:11 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 15 Sep 2009 17:56:11 -0700 Subject: [jsr-292-eg] updated RI code and API javadoc In-Reply-To: References: <549DBE08-42DC-466A-A0FB-03D76241DA41@Sun.COM> Message-ID: <14D67DAE-68E7-4084-BD8E-FA795D3441DF@sun.com> (Getting a round of EG work in before the Summit, so we'll have more to talk about. :-) On Jul 15, 2009, at 6:02 AM, Daniel Heidinga wrote: > Regarding keeping MHs.methodType, it seems cleaner to keep the > MethodHandles factory and the MethodType factory separate. The > static import concerns can be addressed by renaming MethodType's > make() methods to have a more descriptive name such as methodType(). > It'll look a little silly for people not using static import > (MethodType.methodType()), but I can live with that. > That seems like a good compromise. I'll add those methods and deprecate the others, and see what comments we get. I think the factory pattern "SomeType.make" makes less sense in a Java world with static import. I guess the adjusted pattern "SomeType.someType" is better. I'm open to other suggestions... > I'm glad that you agree that we should remove the _# from the > MHs.invoke() methods. Using invokeVarargs rather than > invokeWithArguments is fine. > Good. It looks much better that way. > Regarding the LDC proposal, it came to my attention that JSR 294 > (Modularity) is planning to add new ConstantPool types as well. This > makes me very opposed to the idea of trying to overload the existing > CONSTANT_* rather than adding CONSTANT_MethodHandleref_info and > CONSTANT_MethodTyperef_info. > That seems right. Let's talk about this at the Summit. The advantage of using constants rather than reflective factory methods is the ability of tools (or the JVM) to see ahead of time how the app. is going to link itself. There may also be compactness benefits. > Dan Heidinga > J9 VM Software Developer > IBM Ottawa Lab > 613-356-5036 > daniel_heidinga at ca.ibm.com > > > > Thanks a lot for the detailed comments. I've forwarded it to a couple > observer lists. > > To deal with API bloat, instead of getting rid of MHs.methodType, I'd > prefer to get rid of MethodType.make. Now that we have static import > in the language, I'd like to profit from it, and methodType is a much > more reasonable thing to import than "make". > > I like your idea about getting rid of invoke_2. Since "varargs" is > the Java term, let's make the varargs guy "invokeVarargs". > > Many more responses later. > > -- John > > On Jul 8, 2009, at 1:39 PM, Daniel Heidinga wrote: > > We've taken a look through the Javadoc and have some comments. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090915/15f1184f/attachment.html From forax at univ-mlv.fr Tue Sep 15 21:35:17 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 16 Sep 2009 06:35:17 +0200 Subject: [jsr-292-eg] updated RI code and API javadoc In-Reply-To: <14D67DAE-68E7-4084-BD8E-FA795D3441DF@sun.com> References: <549DBE08-42DC-466A-A0FB-03D76241DA41@Sun.COM> <14D67DAE-68E7-4084-BD8E-FA795D3441DF@sun.com> Message-ID: <4AB06B05.4090308@univ-mlv.fr> Le 16/09/2009 02:56, John Rose a ?crit : > (Getting a round of EG work in before the Summit, so we'll have more > to talk about. :-) [...] >> Regarding the LDC proposal, it came to my attention that JSR 294 >> (Modularity) is planning to add new ConstantPool types as well. This >> makes me very opposed to the idea of trying to overload the existing >> CONSTANT_* rather than adding CONSTANT_MethodHandleref_info and >> CONSTANT_MethodTyperef_info. >> > That seems right. Let's talk about this at the Summit. The advantage > of using constants rather than reflective factory methods is the > ability of tools (or the JVM) to see ahead of time how the app. is > going to link itself. There may also be compactness benefits. Knowing the method handle before runtime will allow, by example, to avoid the method type check in case of MethodHandle.invoke(). R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090916/e45e82ca/attachment.html From forax at univ-mlv.fr Tue Sep 15 21:41:06 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 16 Sep 2009 06:41:06 +0200 Subject: List of things I think we should talk In-Reply-To: <14D67DAE-68E7-4084-BD8E-FA795D3441DF@sun.com> References: <549DBE08-42DC-466A-A0FB-03D76241DA41@Sun.COM> <14D67DAE-68E7-4084-BD8E-FA795D3441DF@sun.com> Message-ID: <4AB06C62.7080802@univ-mlv.fr> Here is the list of points that I think we should talk during the submit :) - method handle invocation - john: check == againt method type - fredrik: allow all conversions described in MHs.convertArguments() - r?mi: allow all already existing JVM conversions parameter types covariance, return type contravariance - JavaMethodHandle constructors describe an uncommon method lookup algorithm - revisit all adapters like spread/collect and allow conversions for all - slim call site to store only the target mh and the declaring class (let bootstrap method as is, if language developer need method name, etc. it can subclass CallSite) and the declaring class should be a Class not an Object - remove one-to-one limitation between invokedynamic and its CallSite, many CallSite are allowed (allow instruction splitting) - remove CallSite.nameComponents() or specify it - specify the type used for the signature of Lookup.findVirtual()/bind(), and MethodHandles.insertArguments() if type is not accessible. - bootstrap method can be called by multiple thread at the same time for a same callsite, what is the exact semantics - have a CallSite constructor that take the target MH - provide access to field/object creation without using reflection. minor improvements: - MethodHandle.combine() last parameter should be a int... R?mi From wuerthinger at ssw.jku.at Tue Sep 15 23:44:45 2009 From: wuerthinger at ssw.jku.at (Thomas Wuerthinger) Date: Tue, 15 Sep 2009 23:44:45 -0700 Subject: Hotswap patch? In-Reply-To: References: <64efa1ba0909130022o7050f5c0h1e44aa29c461baa8@mail.gmail.com> Message-ID: <4AB0895D.9020706@ssw.jku.at> > The design of the hotswap patch is described in the PDF linked from > this page: > http://wikis.sun.com/display/mlvm/HotSwap > > I believe (under correction from you, Thomas!) that the patch is the > initial result of a research project that he did earlier this year at > JKU Linz, that he is now working on other things, and that he doesn't > have specific plans (yet) to extend it further. See the message below. > > Thomas will be talking about this work at Sun on Wednesday, and InfoQ > will be taping the talk (like most of the talks at the Summit). Yes - during the talk I will also outline future directions that I am currently considering and I would be happy about any kind of feedback! - thomas From pdoubleya at gmail.com Wed Sep 16 00:15:38 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Wed, 16 Sep 2009 09:15:38 +0200 Subject: Hotswap patch? In-Reply-To: <4AB0895D.9020706@ssw.jku.at> References: <64efa1ba0909130022o7050f5c0h1e44aa29c461baa8@mail.gmail.com> <4AB0895D.9020706@ssw.jku.at> Message-ID: <64efa1ba0909160015sad5b844y71454563e4655a36@mail.gmail.com> Thanks for the links to the Wiki and PDF. It looks like a lot of what we've been asking for. Thomas--is any special flag required to enable this when launching the JVM if I build MLVM with your changeset in it? Also, I assume that if classes are redefined we will eventually run into the standard problems of PermGen limits on loaded classes? Thanks Patrick From John.Rose at Sun.COM Wed Sep 16 02:06:42 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 16 Sep 2009 02:06:42 -0700 Subject: still no fun with invokedynamic In-Reply-To: <4AACF93E.6040704@univ-mlv.fr> References: <4AA7F709.4020707@gmx.org> <4AA7FAFC.5050207@univ-mlv.fr> <4AA7F928.90407@gmx.org> <4AA7FA30.30702@gmx.org> <4AA7FF12.3030906@univ-mlv.fr> <4AA80019.5040305@gmx.org> <4AA8A52D.4080706@Sun.COM> <4AA97C1E.9080603@gmx.org> <4AA9A317.9060401@gmx.org> <4AAA0D46.6070708@univ-mlv.fr> <4AAA1A24.2040201@gmx.org> <4AACF93E.6040704@univ-mlv.fr> Message-ID: <34DD6365-AB59-48E6-A13D-4B3A2C3C0CD0@sun.com> ?? Sep 13, 2009, ??? ?? 6:53 AM, R?mi Forax ??????: > Le 13/09/2009 02:38, John Rose a ?crit : >> >> The backport a great option for experimentation, since it does not >> require a pre-release JVM. Its performance seems to be comparable >> to the current MLVM JVM. Basically what you get is a backend that >> performs JRuby-like rewrites of JSR 292 bytecodes. As we work on >> code quality (JIT optimizer) in the MLVM JVM, I expect that the >> native JSR 292 implementations will be decisively faster, since the >> JSR 292 version of the code has (potentially) more quasi-static >> knowledge for the JIT optimizer to exploit. > > John, I don't agree with you :) > The backport provide you more than the JRuby-like optimisation, > or perhaps not more but something different. > > In fact the backport can be split in two parts, a part that is like > the JRuby optimisations on method calls, i.e an abstract class > that contains one abstract method by arity. Another part, named > optimizer, works more like the indy compiler inlining patch, > it is triggered when a method handle/call site is used often and try > to produce from the method handle adapter tree > a simple sequence of bytecode that the VM JIT will be able to inline. I had forgotten about the inlining part, which is very cool, and more than JRuby does. (It's the job of the JVM or backport to do this kind of magic.) So, I agree with your disagreement with me. :-) -- John From Christian.Thalinger at Sun.COM Wed Sep 16 03:13:10 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 16 Sep 2009 12:13:10 +0200 Subject: adapter pushes too many parameters Message-ID: <4AB0BA36.6090309@Sun.COM> Hi! I just wanted to write a testcase with an invokedynamic that takes 6 arguments, like: sum += InvokeDynamic.unknown(i, i, i, i, i, i); and I get: java.lang.IllegalArgumentException: bad adapter (conversion=0xfffab300): adapter pushes too many parameters Increasing the MethodHandlePushLimit results in: java.lang.InternalError: too many bound parameters I'm not an expert but this should work, right? -- Christian From John.Rose at Sun.COM Wed Sep 16 03:25:05 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 16 Sep 2009 03:25:05 -0700 Subject: adapter pushes too many parameters In-Reply-To: <4AB0BA36.6090309@Sun.COM> References: <4AB0BA36.6090309@Sun.COM> Message-ID: <409A6D3A-1943-41C1-9A72-E6BF4FB82410@sun.com> On Sep 16, 2009, at 3:13 AM, Christian Thalinger wrote: > I just wanted to write a testcase with an invokedynamic that takes 6 > arguments, like: > > sum += InvokeDynamic.unknown(i, i, i, i, i, i); > > and I get: > > java.lang.IllegalArgumentException: bad adapter > (conversion=0xfffab300): adapter pushes too many parameters I don't see why that expression must create an adapter that pushes lots of parameters. It must be created by your bootstrap method? > Increasing the MethodHandlePushLimit results in: > > java.lang.InternalError: too many bound parameters There's a limit on interpreter stack expansion in the current implementation, MHPL. The rationale is that we don't want to push too many extra arguments without running through a method entry, with its associated stack overflow check. However, this might be overcautious. Even if you were to insert the maximum number (255 arguments) that probably would not render the next overflow check invalid. You might try commenting out the check, if it's keeping you from other work. But, I think increasing the MHPL should allow the additional number of bound params to be pushed. So that final error looks like a plain bug. -- John From Christian.Thalinger at Sun.COM Wed Sep 16 03:38:09 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 16 Sep 2009 12:38:09 +0200 Subject: adapter pushes too many parameters In-Reply-To: <409A6D3A-1943-41C1-9A72-E6BF4FB82410@sun.com> References: <4AB0BA36.6090309@Sun.COM> <409A6D3A-1943-41C1-9A72-E6BF4FB82410@sun.com> Message-ID: <4AB0C011.7060002@Sun.COM> John Rose wrote: > On Sep 16, 2009, at 3:13 AM, Christian Thalinger wrote: > >> I just wanted to write a testcase with an invokedynamic that takes 6 >> arguments, like: >> >> sum += InvokeDynamic.unknown(i, i, i, i, i, i); >> >> and I get: >> >> java.lang.IllegalArgumentException: bad adapter >> (conversion=0xfffab300): adapter pushes too many parameters > > I don't see why that expression must create an adapter that pushes > lots of parameters. It must be created by your bootstrap method? I forgot to mention that the call site is a GWT. > >> Increasing the MethodHandlePushLimit results in: >> >> java.lang.InternalError: too many bound parameters > > There's a limit on interpreter stack expansion in the current > implementation, MHPL. The rationale is that we don't want to push too > many extra arguments without running through a method entry, with its > associated stack overflow check. > > However, this might be overcautious. Even if you were to insert the > maximum number (255 arguments) that probably would not render the next > overflow check invalid. You might try commenting out the check, if > it's keeping you from other work. > > But, I think increasing the MHPL should allow the additional number of > bound params to be pushed. So that final error looks like a plain bug. I will try to comment it out. -- Christian From Christian.Thalinger at Sun.COM Wed Sep 16 06:42:16 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 16 Sep 2009 15:42:16 +0200 Subject: adapter pushes too many parameters In-Reply-To: <4AB0C011.7060002@Sun.COM> References: <4AB0BA36.6090309@Sun.COM> <409A6D3A-1943-41C1-9A72-E6BF4FB82410@sun.com> <4AB0C011.7060002@Sun.COM> Message-ID: <4AB0EB38.5040603@Sun.COM> Christian Thalinger wrote: >> But, I think increasing the MHPL should allow the additional number of >> bound params to be pushed. So that final error looks like a plain bug. > > I will try to comment it out. Commenting this check: if (slots_pushed + target_pushes > MethodHandlePushLimit) makes, obviously, the error go away and the test runs OK. -- Christian From Christian.Thalinger at Sun.COM Wed Sep 16 08:21:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 16 Sep 2009 17:21:37 +0200 Subject: insertArguments asserts Message-ID: <4AB10281.8070203@Sun.COM> Hi (John)! While writing some tests for the compiler I stumbled over this assert in the interpreter: # Internal Error (/Users/twisti/mlvm/hotspot/src/share/vm/runtime/sharedRuntime.cpp:591), pid=19342, tid=2690041632 # Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)") The code that causes the assert is: static int foo() throws Throwable { return InvokeDynamic.unknown(0); } static int target(int a0, int a1) { return a0 + a1; } private static CallSite bootstrapDynamic(Class caller, String name, MethodType type) { MethodHandle target = MethodHandles.lookup().findStatic(ia.class, "target", MethodType.make(int.class, int.class, int.class)); CallSite site = new CallSite(caller, name, type); site.setTarget(MethodHandles.insertArguments(target, 0, Integer.valueOf(10))); return site; } I think there is a typo in MethodHandles::generate_method_handle_stub(): diff --git a/src/cpu/x86/vm/methodHandles_x86.cpp b/src/cpu/x86/vm/methodHandles_x86.cpp --- a/src/cpu/x86/vm/methodHandles_x86.cpp +++ b/src/cpu/x86/vm/methodHandles_x86.cpp @@ -544,7 +544,6 @@ __ movl(Address(rax_argslot, Interpreter::stackElementSize()), rbx_temp); } #endif //_LP64 - break; } if (direct_to_method) { John, am I correct? -- Christian From John.Rose at Sun.COM Thu Sep 17 14:16:36 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 17 Sep 2009 14:16:36 -0700 Subject: JVM Language Summit happenings... Message-ID: <4CC36E55-5621-4C3A-914D-784B80A16573@Sun.COM> Folks, the informal "proceedings" of the JVM Language Summit (including slides in many cases) may be accessed in real time through the wiki: http://wiki.jvmlangsummit.com Initial links into the wiki are on the agenda: http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.html (BTW, the wiki is writable by Summit attendees.) Best wishes, -- John From lukas.stadler at jku.at Fri Sep 18 16:04:40 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Fri, 18 Sep 2009 23:04:40 +0000 Subject: hg: mlvm/mlvm/hotspot: callcc: new implementation Message-ID: <20090918230441.5A82C125AC@hg.openjdk.java.net> Changeset: e238e03d8993 Author: lstadler Date: 2009-09-19 01:02 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e238e03d8993 callcc: new implementation ! callcc.patch ! callcc.txt ! series From lukas.stadler at jku.at Fri Sep 18 16:05:42 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Fri, 18 Sep 2009 23:05:42 +0000 Subject: hg: mlvm/mlvm/jdk: callcc: new implementation Message-ID: <20090918230542.89335125B1@hg.openjdk.java.net> Changeset: 9c5f72a3578d Author: lstadler Date: 2009-09-19 01:00 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9c5f72a3578d callcc: new implementation ! callcc.patch ! series From james_ladd at hotmail.com Fri Sep 18 16:52:09 2009 From: james_ladd at hotmail.com (James Ladd) Date: Sat, 19 Sep 2009 09:52:09 +1000 Subject: instruction timings / optimization ? Message-ID: Hi All, A couple of questions which I hope are appropriate for this list: 1. Is there a document that details each VM instruction and the time it takes in cycles on a particular architecture? I ask because often on the http://www.masm32.com/board/index.php forum they provide CPU cycle timings for x86 instructions enabling you to modify code for better performance. I'd like to use this information when generating bytecode for my Smalltalk implementation for the JVM. 2. Would anyone else find this information useful ? Rgs, James. _________________________________________________________________ Use Messenger in your Hotmail inbox Find out how here http://windowslive.ninemsn.com.au/article.aspx?id=823454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090919/74c8f37f/attachment.html From headius at headius.com Fri Sep 18 21:37:47 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 18 Sep 2009 21:37:47 -0700 Subject: instruction timings / optimization ? In-Reply-To: References: Message-ID: On Fri, Sep 18, 2009 at 4:52 PM, James Ladd wrote: > 1. Is there a document that details each VM instruction and the time it > takes in cycles on > ??? a particular architecture? I don't think it's possible to accurately measure this information. The JVM bytecode is essentially an intermediate representation that the JVM takes and optimizes when compiling to native code. The cycles a given instruction takes will have little relation to the actual native code generated. > 2. Would anyone else find this information useful ? If it were possible to determine, yes :) But it's not. - Charlie From mbana.lists at googlemail.com Sat Sep 19 09:02:26 2009 From: mbana.lists at googlemail.com (Mohamed Bana) Date: Sat, 19 Sep 2009 17:02:26 +0100 Subject: JVM Language Summit happenings... In-Reply-To: <4CC36E55-5621-4C3A-914D-784B80A16573@Sun.COM> References: <4CC36E55-5621-4C3A-914D-784B80A16573@Sun.COM> Message-ID: <4AB50092.70803@googlemail.com> Hello, Thanks for sharing the slides. It'd be great if the talks were downloadable like Lang.NET . John Rose wrote: > Folks, the informal "proceedings" of the JVM Language Summit > (including slides in many cases) may be accessed in real time through > the wiki: > http://wiki.jvmlangsummit.com > > Initial links into the wiki are on the agenda: > http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.html > > (BTW, the wiki is writable by Summit attendees.) > > Best wishes, > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090919/1ef988f5/attachment.html From emmanuel.castro at laposte.net Sat Sep 19 10:53:49 2009 From: emmanuel.castro at laposte.net (Emmanuel Castro) Date: Sat, 19 Sep 2009 19:53:49 +0200 Subject: hg: mlvm/mlvm/jdk: callcc: new implementation In-Reply-To: <20090918230542.89335125B1@hg.openjdk.java.net> References: <20090918230542.89335125B1@hg.openjdk.java.net> Message-ID: <736021ac0909191053h2b3d7788mdeaaf1f8f6bf089c@mail.gmail.com> I plan to test it soon. Dear Mr Stadler, what is your reference compile environment for the patch? Linux? Solaris? 32bit? 64bit? I would like to start testing with the same one. Merci d'avance. 2009/9/19 > > > Changeset: 9c5f72a3578d > Author: lstadler > Date: 2009-09-19 01:00 +0200 > URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9c5f72a3578d > > callcc: new implementation > > ! callcc.patch > ! series > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090919/bf000e16/attachment.html From emmanuel.castro at laposte.net Sat Sep 19 11:00:35 2009 From: emmanuel.castro at laposte.net (Emmanuel Castro) Date: Sat, 19 Sep 2009 20:00:35 +0200 Subject: instruction timings / optimization ? In-Reply-To: References: Message-ID: <736021ac0909191100i67a899caqf880f789662df483@mail.gmail.com> Is there a not too complicated way to get the x86 (or other processor) instructions produced by the JVM? Maybe there is a link to some Wiki explaining that? 2009/9/19 Charles Oliver Nutter > On Fri, Sep 18, 2009 at 4:52 PM, James Ladd > wrote: > > 1. Is there a document that details each VM instruction and the time it > > takes in cycles on > > a particular architecture? > > I don't think it's possible to accurately measure this information. > > The JVM bytecode is essentially an intermediate representation that > the JVM takes and optimizes when compiling to native code. The cycles > a given instruction takes will have little relation to the actual > native code generated. > > > 2. Would anyone else find this information useful ? > > If it were possible to determine, yes :) But it's not. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090919/5fb111b1/attachment.html From John.Rose at Sun.COM Sat Sep 19 11:43:30 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 19 Sep 2009 11:43:30 -0700 Subject: instruction timings / optimization ? In-Reply-To: <736021ac0909191100i67a899caqf880f789662df483@mail.gmail.com> References: <736021ac0909191100i67a899caqf880f789662df483@mail.gmail.com> Message-ID: <2CD506D6-BA7E-46DE-A07D-DDFDB2EE5C85@sun.com> On Sep 19, 2009, at 11:00 AM, Emmanuel Castro wrote: > Is there a not too complicated way to get the x86 (or other > processor) instructions produced by the JVM? > > Maybe there is a link to some Wiki explaining that? Indeed: Google "hotspot disassembler", or look at these links: http://wikis.sun.com/display/HotSpotInternals/PrintAssembly http://kenai.com/projects/base-hsdis It's a separate plugin rather than a built-in feature, for reasons of history and software ownership. But having a plugin at that point is actually a pretty powerful hook. -- John From headius at headius.com Sat Sep 19 12:59:15 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 19 Sep 2009 12:59:15 -0700 Subject: instruction timings / optimization ? In-Reply-To: <2CD506D6-BA7E-46DE-A07D-DDFDB2EE5C85@sun.com> References: <736021ac0909191100i67a899caqf880f789662df483@mail.gmail.com> <2CD506D6-BA7E-46DE-A07D-DDFDB2EE5C85@sun.com> Message-ID: On Sat, Sep 19, 2009 at 11:43 AM, John Rose wrote: > Indeed: ?Google "hotspot disassembler", or look at these links: > > ? http://wikis.sun.com/display/HotSpotInternals/PrintAssembly > ? http://kenai.com/projects/base-hsdis > > It's a separate plugin rather than a built-in feature, for reasons of > history and software ownership. ?But having a plugin at that point is > actually a pretty powerful hook. I finally gave this a try and it seriously only took three steps to install: 1. Download the binaries linked from the first link (hosted on Kenai). Only OS X and Solaris are there (someone should contrib a linux one) 2. Copy to JDK7/jre/lib/i386/client and /server as libhsdis-i386.{so|dylib} 3. Run with -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly I'm looking at fib output right now :) - Charlie From james_ladd at hotmail.com Sat Sep 19 14:14:26 2009 From: james_ladd at hotmail.com (James Ladd) Date: Sun, 20 Sep 2009 07:14:26 +1000 Subject: instruction timings / optimization ? In-Reply-To: References: Message-ID: Hi All, I do believe getting the timings is possible. >From working in x86 assembler I know that there are ways to get timings from your own code, so finding out the timings for the bytecode execution would require instrumenting the bytecode execution routines and carrying out a test. I'll look into this further and into the links given by John. I'll also post links to a tool for x86 that will capture the CPU cycles for a block of instructions. Rgs, James. _________________________________________________________________ View photos of singles in your area Click Here http://clk.atdmt.com/NMN/go/150855801/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090920/f7692cb4/attachment.html From pdoubleya at gmail.com Sat Sep 19 15:22:23 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Sun, 20 Sep 2009 00:22:23 +0200 Subject: JVM Language Summit happenings... In-Reply-To: <4AB50092.70803@googlemail.com> References: <4CC36E55-5621-4C3A-914D-784B80A16573@Sun.COM> <4AB50092.70803@googlemail.com> Message-ID: <64efa1ba0909191522j42f605c6w28c58028ce250d73@mail.gmail.com> On Sat, Sep 19, 2009 at 6:02 PM, Mohamed Bana wrote: > Hello, > > Thanks for sharing the slides. > > It'd be great if the talks were downloadable like Lang.NET. They have been recorded, by InfoQ I think. Should be available shortly. Most of the ones from last year were available within a few weeks of the conference. Patrick From james_ladd at hotmail.com Sun Sep 20 15:13:12 2009 From: james_ladd at hotmail.com (James Ladd) Date: Mon, 21 Sep 2009 08:13:12 +1000 Subject: instruction timings / optimization ? (Charles Oliver Nutter) In-Reply-To: References: Message-ID: Hi Charlie, Thanks for the notes. Would you mind sending me the assembler for fib? While this information is very useful Im also keen to see the assembler produced for the VM itself, especially around the the instruction loop. This is just a disassembler so no help required here. I have a hunch I could help speed up the JVM. More to come when I get time. Rgs, James. > From: mlvm-dev-request at openjdk.java.net > Subject: mlvm-dev Digest, Vol 22, Issue 19 > To: mlvm-dev at openjdk.java.net > Date: Sun, 20 Sep 2009 12:00:12 -0700 > > Send mlvm-dev mailing list submissions to > mlvm-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > or, via email, send a message with subject or body 'help' to > mlvm-dev-request at openjdk.java.net > > You can reach the person managing the list at > mlvm-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mlvm-dev digest..." > > > Today's Topics: > > 1. Re: instruction timings / optimization ? (Charles Oliver Nutter) > 2. Re: instruction timings / optimization ? (James Ladd) > 3. Re: JVM Language Summit happenings... (Patrick Wright) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 19 Sep 2009 12:59:15 -0700 > From: Charles Oliver Nutter > Subject: Re: instruction timings / optimization ? > To: Da Vinci Machine Project > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Sat, Sep 19, 2009 at 11:43 AM, John Rose wrote: > > Indeed: ?Google "hotspot disassembler", or look at these links: > > > > ? http://wikis.sun.com/display/HotSpotInternals/PrintAssembly > > ? http://kenai.com/projects/base-hsdis > > > > It's a separate plugin rather than a built-in feature, for reasons of > > history and software ownership. ?But having a plugin at that point is > > actually a pretty powerful hook. > > I finally gave this a try and it seriously only took three steps to install: > > 1. Download the binaries linked from the first link (hosted on Kenai). > Only OS X and Solaris are there (someone should contrib a linux one) > 2. Copy to JDK7/jre/lib/i386/client and /server as libhsdis-i386.{so|dylib} > 3. Run with -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly > > I'm looking at fib output right now :) > > - Charlie > > > ------------------------------ > > Message: 2 > Date: Sun, 20 Sep 2009 07:14:26 +1000 > From: James Ladd > Subject: Re: instruction timings / optimization ? > To: > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > Hi All, > > I do believe getting the timings is possible. > > >From working in x86 assembler I know that there are ways to get timings > from your own code, so finding out the timings for the bytecode execution > would require instrumenting the bytecode execution routines and carrying > out a test. > > I'll look into this further and into the links given by John. > I'll also post links to a tool for x86 that will capture the CPU cycles for a block > of instructions. > > Rgs, James. > > > _________________________________________________________________ > View photos of singles in your area Click Here > http://clk.atdmt.com/NMN/go/150855801/direct/01/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090920/f7692cb4/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Sun, 20 Sep 2009 00:22:23 +0200 > From: Patrick Wright > Subject: Re: JVM Language Summit happenings... > To: Da Vinci Machine Project > Message-ID: > <64efa1ba0909191522j42f605c6w28c58028ce250d73 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Sep 19, 2009 at 6:02 PM, Mohamed Bana > wrote: > > Hello, > > > > Thanks for sharing the slides. > > > > It'd be great if the talks were downloadable like Lang.NET. > > They have been recorded, by InfoQ I think. Should be available > shortly. Most of the ones from last year were available within a few > weeks of the conference. > > > Patrick > > > ------------------------------ > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > End of mlvm-dev Digest, Vol 22, Issue 19 > **************************************** _________________________________________________________________ Use Messenger in your Hotmail inbox Find out how here http://windowslive.ninemsn.com.au/article.aspx?id=823454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090921/6fa37f35/attachment.html From james_ladd at hotmail.com Mon Sep 21 15:14:43 2009 From: james_ladd at hotmail.com (James Ladd) Date: Tue, 22 Sep 2009 08:14:43 +1000 Subject: Which file is the interpreter? In-Reply-To: References: Message-ID: Hi All, I'm wading through the openJDK source and I'm wondering, which file or files are responsible for executing each bytecode ? ie: the loop that gets a bytecode, works out what is it and then dispatches it. Rgs, James. _________________________________________________________________ Use Messenger in your Hotmail inbox Find out how here http://windowslive.ninemsn.com.au/article.aspx?id=823454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090922/d969e5fc/attachment.html From Christian.Thalinger at Sun.COM Tue Sep 22 00:34:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 22 Sep 2009 09:34:31 +0200 Subject: Which file is the interpreter? In-Reply-To: References: Message-ID: <4AB87E07.5050508@Sun.COM> James Ladd wrote: > Hi All, > > I'm wading through the openJDK source and I'm wondering, which file or > files are responsible for executing each bytecode ? > > ie: the loop that gets a bytecode, works out what is it and then dispatches > it. I think what you are searching for is templateTable_.cpp in src/cpu//vm/. -- Christian From pdoubleya at gmail.com Tue Sep 22 00:39:51 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Tue, 22 Sep 2009 09:39:51 +0200 Subject: Which file is the interpreter? In-Reply-To: References: Message-ID: <64efa1ba0909220039u11fbba5dhe537fd0d4c37bca0@mail.gmail.com> James You might take a look at Gary Benson's blog, as he's documented his experience (as an outsider) working on a "zero-assembly" port of the HotSpot interpreter (called Zero) and another compiler which targets LLVM. His blog is at http://gbenson.net/; he's been documenting his work for over a year, so it's helpful to page back through older entries. HTH Patrick On Tue, Sep 22, 2009 at 12:14 AM, James Ladd wrote: > Hi All, > > I'm wading through the openJDK source and I'm wondering, which file or > files are responsible for executing each bytecode ? > > ie: the loop that gets a bytecode, works out what is it and then dispatches > it. > > Rgs, James. > > ________________________________ > Find out how here Use Messenger in your Hotmail inbox > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > From james_ladd at hotmail.com Tue Sep 22 02:04:22 2009 From: james_ladd at hotmail.com (James Ladd) Date: Tue, 22 Sep 2009 19:04:22 +1000 Subject: instruction timings / optimization ? In-Reply-To: References: Message-ID: Hi All, As promised here are two links to resources to help you time pieces of code with a very high resolution. Using this approach it is theoretically possible to determine the CPU cycles each virtual machine instruction takes, thus enabling further optimization at the bytecode level or in the VM itself. http://www.masm32.com/board/index.php?topic=770.0 http://www.agner.org/optimize/ Rgs, James. _________________________________________________________________ Get Hotmail on your iPhone Find out how here http://windowslive.ninemsn.com.au/article.aspx?id=845706 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090922/582c1398/attachment.html From Christian.Thalinger at Sun.COM Tue Sep 22 03:13:19 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 22 Sep 2009 10:13:19 +0000 Subject: hg: mlvm/mlvm/hotspot: indy.compiler: Fixed debug compilation, fixed bugs for bound Message-ID: <20090922101319.C51821270C@hg.openjdk.java.net> Changeset: 0db826e1d6d4 Author: twisti Date: 2009-09-22 12:12 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0db826e1d6d4 indy.compiler: Fixed debug compilation, fixed bugs for bound MethodHandle adapters, fixed a problem with -Xcomp. ! indy.compiler.patch From Christian.Thalinger at Sun.COM Tue Sep 22 03:16:01 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 22 Sep 2009 10:16:01 +0000 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: A couple of fixes and enhancements. Message-ID: <20090922101601.50CDE12711@hg.openjdk.java.net> Changeset: fa3093f02b0e Author: twisti Date: 2009-09-22 12:15 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/fa3093f02b0e indy.compiler.inline: A couple of fixes and enhancements. ! indy.compiler.inline.patch From raffaello.giulietti at gmail.com Tue Sep 22 04:39:43 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 22 Sep 2009 13:39:43 +0200 Subject: backport Message-ID: <4AB8B77F.6000603@gmail.com> I must confess that I never took a deep look at R?mi's backport. But after having seen his report at the JVM Language Summit last Friday, I must state that the results are quite impressing, given that it is a library solution for indy rather than a JVM patch, as also noted by Neal Gafter. Pour ?a, mes compliments ? R?mi pour son travail et l'intuition qu'il a eue de ne pas toucher le code original de la JVM mais de poursuivre une solution alternative. Kudos to R?mi. Cheers Raffaello From John.Rose at Sun.COM Tue Sep 22 13:16:14 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 22 Sep 2009 13:16:14 -0700 Subject: backport In-Reply-To: <4AB8B77F.6000603@gmail.com> References: <4AB8B77F.6000603@gmail.com> Message-ID: <65519B9D-09E2-4261-B030-1FA48D50D098@sun.com> Je conviens compl?tement. Vive le backport! -- John On Sep 22, 2009, at 4:39 AM, Raffaello Giulietti wrote: > I must confess that I never took a deep look at R?mi's backport. But > after having seen his report at the JVM Language Summit last Friday, I > must state that the results are quite impressing, given that it is a > library solution for indy rather than a JVM patch, as also noted by > Neal > Gafter. > > Pour ?a, mes compliments ? R?mi pour son travail et l'intuition > qu'il a > eue de ne pas toucher le code original de la JVM mais de poursuivre > une > solution alternative. > > Kudos to R?mi. From thomas.wuerthinger at gmx.at Tue Sep 22 21:24:08 2009 From: thomas.wuerthinger at gmx.at (Thomas Wuerthinger) Date: Tue, 22 Sep 2009 21:24:08 -0700 Subject: Hotswap patch? Message-ID: <4AB9A2E8.80100@gmx.at> Patrick Wright wrote: > Thomas--is any special flag required to enable this when launching the > JVM if I build MLVM with your changeset in it? Also, I assume that if > classes are redefined we will eventually run into the standard > problems of PermGen limits on loaded classes? No, there is no special flag required to enable my hotswap code. When you apply the changeset to jdk7-b51, you swap the current hotswapping implementation with my version. Yes, with frequent use of hotswapping the problem of a limited PermGen arises. Especially as currently the old classes are still kept in the system. A fix for this might be to remove old classes from the system if none of their methods are active or reachable from active methods (and this is true for all of their subclasses). - thomas From james_ladd at hotmail.com Wed Sep 23 14:52:41 2009 From: james_ladd at hotmail.com (James Ladd) Date: Thu, 24 Sep 2009 07:52:41 +1000 Subject: Which file is the interpreter? In-Reply-To: References: Message-ID: Re: Which file is the interpreter? Thank you for the responses. Gary Benson's blog is very interesting but also lengthy, and the file templateTable_.cpp in src/cpu//vm/ looks close to what I am after, but not it. Although I could be wrong given my newness to the code. Im looking for the loop that takes the next instruction and dispatches it. Maybe I just dont understand the JVM - yet. Is there such a loop ? Rgs, James. _________________________________________________________________ Looking for a place to rent, share or buy this winter? Find your next place with Ninemsn?property http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090924/1dd65ba0/attachment.html From eller.helmut at gmail.com Wed Sep 23 22:43:56 2009 From: eller.helmut at gmail.com (Helmut Eller) Date: Thu, 24 Sep 2009 07:43:56 +0200 Subject: Which file is the interpreter? References: Message-ID: * James Ladd [2009-09-23 23:52+0200] writes: > Im looking for the loop that takes the next instruction and dispatches > it. Maybe I just dont understand the JVM - yet. Is there such a loop ? As described in Gary Benson blog, there are two interpreters: the c++ interpreter and the template based interpreter. The loop that you are searching is probably the run method in bytecodeInterpreter.cpp. But as far as I understand the c++ interpreter is normally not used (maybe for debugging or new platforms). The template interpreter has no dispatch loop: templates are chained together which removes dispatch overhead almost entirely. Helmut From John.Rose at Sun.COM Thu Sep 24 13:16:00 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 24 Sep 2009 13:16:00 -0700 Subject: EG mailings In-Reply-To: References: <0DBC0577-428B-40B5-A431-9F6A87C7372E@Sun.COM> <532686A5-3D25-470C-A8F7-BA9E258C7A85@sun.com> Message-ID: <016613C8-3A83-48EC-9C8E-B969BAD9DB62@sun.com> On Sep 24, 2009, at 7:50 AM, Daniel Heidinga wrote: > Yes, it is very unfortunate we were unable to attend the JVM > Languages Summit. We missed you greatly! Every major Java vendor except IBM was there. > It's great that significant progress was made during the f2f > sessions, but we think there are still loose ends as there are > implicit details missing. I will shortly post the notes from those sessions (Friday night's very long dinner). > Let's use the EG list to drive those through to a successful > conclusion. Yes. The present EG list distribution, though, is inconveniently closed. As EG chair I'm supposed to redirect selected messages to the observer list, but that's ridiculously hit-or-miss. The mail needs to be automatic, since I personally am not automatic by nature. I understand we can't move to OpenJDK because it's not IP-neutral. Shall we move instead to Doug Lea's email server, which has no licensing at all? That way people can monitor our deliberations. I'll bet Doug would welcome us, and he already hosts some JCP lists. -- John From John.Rose at Sun.COM Thu Sep 24 13:46:48 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 24 Sep 2009 13:46:48 -0700 Subject: more on continuations Message-ID: <873D5064-C1F9-491C-8F5E-24BEF9A091AE@sun.com> I have transcribed my recollections about our continuation discussion at the Summit: http://wiki.jvmlangsummit.com/MotionsToContinue If you were there, and remember more, please improve these notes! -- John From miles at milessabin.com Thu Sep 24 13:54:37 2009 From: miles at milessabin.com (Miles Sabin) Date: Thu, 24 Sep 2009 21:54:37 +0100 Subject: more on continuations In-Reply-To: <873D5064-C1F9-491C-8F5E-24BEF9A091AE@sun.com> References: <873D5064-C1F9-491C-8F5E-24BEF9A091AE@sun.com> Message-ID: <30961e500909241354la0f4e4sa8217eb1ba7babe0@mail.gmail.com> That reminds me ... I promised to post a pointer to Tiark Rompf's paper discussing his work on continuations in Scala, http://lamp.epfl.ch/~rompf/continuations-icfp09.pdf The code for the compiler plugin is in EPFL's Scala SVN repository and builds against Scala trunk. I have some simple examples of code which uses delimited continuations to implement generators and coroutines. Cheers, Miles -- Miles Sabin tel: +44 (0)7813 944 528 skype: milessabin http://www.chuusai.com/ http://twitter.com/milessabin From jbaker at zyasoft.com Thu Sep 24 14:36:24 2009 From: jbaker at zyasoft.com (Jim Baker) Date: Thu, 24 Sep 2009 15:36:24 -0600 Subject: more on continuations In-Reply-To: <873D5064-C1F9-491C-8F5E-24BEF9A091AE@sun.com> References: <873D5064-C1F9-491C-8F5E-24BEF9A091AE@sun.com> Message-ID: John, thanks for writing this summarization. This is one talk I unfortunately could not attend. It's important that any supporting continuation model not be thread-bound, if we are going to be able to use it for generators and coroutines in Python. In Jython, there's the possibility of some threadstate leaking through different environments of PySystemState, but in practice this shouldn't really happen. Scoping of generators, plus our own frame storage, makes all this work just fine in Jython 2.5. This question of being thread bound does arise in the greenlets implementation that is popular for scaled-up deployments (such as Slide.com). Greenlets require that all elements of a given greenlet tree be in the same thread, but that may be a property of the implementation, not necessarily of the model. And of course, having support for full continuations is certainly something that we would like to see become available on the JVM. - Jim On Thu, Sep 24, 2009 at 2:46 PM, John Rose wrote: > I have transcribed my recollections about our continuation discussion > at the Summit: > > http://wiki.jvmlangsummit.com/MotionsToContinue > > If you were there, and remember more, please improve these notes! > > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Jim Baker jbaker at zyasoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090924/be59919c/attachment.html From John.Rose at Sun.COM Thu Sep 24 16:15:24 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 24 Sep 2009 16:15:24 -0700 Subject: more on continuations In-Reply-To: <30961e500909241354la0f4e4sa8217eb1ba7babe0@mail.gmail.com> References: <873D5064-C1F9-491C-8F5E-24BEF9A091AE@sun.com> <30961e500909241354la0f4e4sa8217eb1ba7babe0@mail.gmail.com> Message-ID: <08511B68-8D78-4CAA-9F77-A1C5407717C5@sun.com> Thanks, MIles. That is a nice paper. -- John On Sep 24, 2009, at 1:54 PM, Miles Sabin wrote: > That reminds me ... I promised to post a pointer to Tiark Rompf's > paper discussing his work on continuations in Scala, > > http://lamp.epfl.ch/~rompf/continuations-icfp09.pdf From John.Rose at Sun.COM Thu Sep 24 18:53:03 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 24 Sep 2009 18:53:03 -0700 Subject: after hours at the Summit Message-ID: <94B9A458-F9E0-4C44-99C1-B5AAE2698376@sun.com> I transcribed (with slight amplifications) my notes and recollections from a very long dinner last Friday night: http://wiki.jvmlangsummit.com/DinnerAtPiatti It includes pictures of the napkins. (Actually, since the nice restaurant had cloth napkins, I had to ask for sheets of paper...) It's all about JSR 292 issues. -- John From raffaello.giulietti at gmail.com Thu Sep 24 23:59:43 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 25 Sep 2009 08:59:43 +0200 Subject: NetBeans with mlvm Message-ID: <4ABC6A5F.6020108@gmail.com> Hello, does anybody know how to fool NetBeans' language checker to stick to the JDK 7 extensions? Or at least how to turn it off to avoid those annoying red underlines and the red bullets to the left? I'm on version 6.7.1 Thanks From forax at univ-mlv.fr Sat Sep 26 07:24:36 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 Sep 2009 16:24:36 +0200 Subject: after hours at the Summit In-Reply-To: <94B9A458-F9E0-4C44-99C1-B5AAE2698376@sun.com> References: <94B9A458-F9E0-4C44-99C1-B5AAE2698376@sun.com> Message-ID: <4ABE2424.5010801@univ-mlv.fr> Le 25/09/2009 03:53, John Rose a ?crit : > I transcribed (with slight amplifications) my notes and recollections > from a very long dinner last Friday night: > http://wiki.jvmlangsummit.com/DinnerAtPiatti > > It includes pictures of the napkins. (Actually, since the nice > restaurant had cloth napkins, I had to ask for sheets of paper...) > > It's all about JSR 292 issues. > -- John > I've added more infos about what the two new constant pool constants can be and the fact that at runtime LDC CONSTANT_MethodType is interned but not LDC CONSTANT_MethodHandle even if LDC means load constant. We was agree about that but these infos was not in the notes. R?mi From John.Rose at Sun.COM Sat Sep 26 10:14:51 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 26 Sep 2009 10:14:51 -0700 Subject: after hours at the Summit In-Reply-To: <4ABE2424.5010801@univ-mlv.fr> References: <94B9A458-F9E0-4C44-99C1-B5AAE2698376@sun.com> <4ABE2424.5010801@univ-mlv.fr> Message-ID: <174705A9-9458-43EC-94FF-FCE02A05E919@sun.com> On Sep 26, 2009, at 7:24 AM, R?mi Forax wrote: > We was agree about that but these infos was not in the notes. True; thanks for putting it in. -- John P.S. I'm looking into the JCP.org wiki mechanism as a better home for this information. Stay tuned. From james_ladd at hotmail.com Mon Sep 28 02:07:27 2009 From: james_ladd at hotmail.com (James Ladd) Date: Mon, 28 Sep 2009 19:07:27 +1000 Subject: A possible performance boost? In-Reply-To: References: Message-ID: Hi All, I have a suggestion on a possible performance boost for the JVM which if I had time I would research more and implement, however, I'm rather time poor right now and thought I could at least put the idea in the wild for someone else or myself at a later stage. >From my last use of GCC and the code/assembler it generates I noticed that the performance of switch()/case statements could be improved greatly as code generated by GCC did little more than a sequence of compare and jump to next label. Yes - I need to reverify this is the case, but lets assume for a moment that it still is the case. When I last optimized a bytecode dispatcher I found that using a jump table of addressed indexed by bytecode was a very efficient approach and yet still more efficient was to replace bytecodes with direct jump addresses on loading the code. While I looked briefly at the C++ for the templated interpreter of the VM it appears possible to use on or more of the approaches outlined above. Does anyone see a reason this could not be tried, or has it been tried and what were the results? Rgs, James. _________________________________________________________________ Get the latest news, goss and sport Make ninemsn your homepage! http://windowslive.ninemsn.com.au/article.aspx?id=813730 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090928/b3d25265/attachment.html From yung2.alan at gmail.com Mon Sep 28 13:45:11 2009 From: yung2.alan at gmail.com (alan yung) Date: Mon, 28 Sep 2009 13:45:11 -0700 Subject: applying patches doesn't seem to work Message-ID: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com> Hi, I'm trying to apply the mlvm patches to openjdk7 on windows XP. The openjdk7 build actually works, and I got the jdk image, but the problem is, the patch doesn't seem to be applied. I followed the instruction here: http://wikis.sun.com/display/mlvm/Building, but the problem is, even after applying the patch (and it seems to be successful), the whole patches dont seem to be applied. For instance, jdk/indy.patch doesn't seem to be applied since I don't see insertArguments method in /jdk/src/share/classes/java/dyn/MethodHandles.java Is there any gotchas that I'm missing? Thanks. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090928/4d9aa3f2/attachment.html From John.Rose at Sun.COM Mon Sep 28 23:32:19 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 28 Sep 2009 23:32:19 -0700 Subject: Summit pictures Message-ID: I just posted some Summit pictures at http://wiki.jvmlangsummit.com They were taken by Oleg Pliss, the VM engineer in front with the big camera. Thanks Oleg! -- John From Christian.Thalinger at Sun.COM Tue Sep 29 01:24:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 29 Sep 2009 10:24:38 +0200 Subject: applying patches doesn't seem to work In-Reply-To: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com> References: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com> Message-ID: <4AC1C446.9090906@Sun.COM> alan yung wrote: > Hi, > > I'm trying to apply the mlvm patches to openjdk7 on windows XP. The > openjdk7 build actually works, and I got the jdk image, but the problem > is, the patch doesn't seem to be applied. > > I followed the instruction here: > http://wikis.sun.com/display/mlvm/Building , but the problem is, even > after applying the patch (and it seems to be successful), > the whole patches dont seem to be applied. For instance, jdk/indy.patch > doesn't seem to be applied since I don't see insertArguments method in > /jdk/src/share/classes/java/dyn/MethodHandles.java > > Is there any gotchas that I'm missing? One problem could be that the bsd-port repository got updated to jdk7-b72 and maybe the patches don't apply cleanly anymore. Are you sure that the patches applied successful? Can you post the output? -- Christian From yung2.alan at gmail.com Tue Sep 29 02:31:44 2009 From: yung2.alan at gmail.com (alan yung) Date: Tue, 29 Sep 2009 02:31:44 -0700 Subject: applying patches doesn't seem to work In-Reply-To: <4AC1C446.9090906@Sun.COM> References: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com> <4AC1C446.9090906@Sun.COM> Message-ID: <6b6a329a0909290231s3b00c235rebebfc66896711f0@mail.gmail.com> This is the step I followed, and the output I got. $ bash patches/make/link-patch-dirs.sh sources patches + ln -s ../../../patches/hotspot sources/hotspot/.hg/patches + ln -s ../../../patches/jdk sources/jdk/.hg/patches + ln -s ../../../patches/langtools sources/langtools/.hg/patches $ ls -il patches/hotspot/series sources/hotspot/.hg/patches/series 9570149208790991 -rw-r--r-- 1 alan None 1220 Sep 29 01:51 patches/hotspot/series 9570149208790991 -rw-r--r-- 1 alan None 1220 Sep 29 01:51 sources/hotspot/.hg/patches/series $ export davinci=$(pwd) guards="buildable testable" $ sh patches/make/each-patch-repo.sh hg qselect --reapply $guards \ > '$(sh $davinci/patches/make/current-release.sh)' + (cd sources/hotspot; hg qselect --reapply buildable testable $(sh $davinci/patches/make/current-release.sh)) + (cd sources/jdk; hg qselect --reapply buildable testable $(sh $davinci/patches/make/current-release.sh)) + (cd sources/langtools; hg qselect --reapply buildable testable $(sh $davinci/patches/make/current-release.sh)) I don't see any other output, so I assumed it was successfully applied, but maybe not. If it is version issue (jdk7-b72), what is the right way to apply the patches? should I get older version of openjdk7? Thanks! alan On Tue, Sep 29, 2009 at 1:24 AM, Christian Thalinger < Christian.Thalinger at sun.com> wrote: > alan yung wrote: > > Hi, > > > > I'm trying to apply the mlvm patches to openjdk7 on windows XP. The > > openjdk7 build actually works, and I got the jdk image, but the problem > > is, the patch doesn't seem to be applied. > > > > I followed the instruction here: > > http://wikis.sun.com/display/mlvm/Building , but the problem is, even > > after applying the patch (and it seems to be successful), > > the whole patches dont seem to be applied. For instance, jdk/indy.patch > > doesn't seem to be applied since I don't see insertArguments method in > > /jdk/src/share/classes/java/dyn/MethodHandles.java > > > > Is there any gotchas that I'm missing? > > One problem could be that the bsd-port repository got updated to > jdk7-b72 and maybe the patches don't apply cleanly anymore. Are you > sure that the patches applied successful? Can you post the output? > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090929/7b7bd770/attachment.html From yung2.alan at gmail.com Wed Sep 30 00:55:01 2009 From: yung2.alan at gmail.com (alan yung) Date: Wed, 30 Sep 2009 00:55:01 -0700 Subject: applying patches doesn't seem to work In-Reply-To: <6b6a329a0909290231s3b00c235rebebfc66896711f0@mail.gmail.com> References: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com> <4AC1C446.9090906@Sun.COM> <6b6a329a0909290231s3b00c235rebebfc66896711f0@mail.gmail.com> Message-ID: <6b6a329a0909300055h38c97880n553697f2a77923d@mail.gmail.com> Actually, I didn't apply the patches correctly. Now when I tried to apply the patches, it shows many error messages, but it did apply (at least) some patches successfully. My question is, do the patches apply successfully in current head revision? Thanks, alan On Tue, Sep 29, 2009 at 2:31 AM, alan yung wrote: > This is the step I followed, and the output I got. > > $ bash patches/make/link-patch-dirs.sh sources patches > + ln -s ../../../patches/hotspot sources/hotspot/.hg/patches > + ln -s ../../../patches/jdk sources/jdk/.hg/patches > + ln -s ../../../patches/langtools sources/langtools/.hg/patches > > $ ls -il patches/hotspot/series sources/hotspot/.hg/patches/series > 9570149208790991 -rw-r--r-- 1 alan None 1220 Sep 29 01:51 > patches/hotspot/series > 9570149208790991 -rw-r--r-- 1 alan None 1220 Sep 29 01:51 > sources/hotspot/.hg/patches/series > > $ export davinci=$(pwd) guards="buildable testable" > > $ sh patches/make/each-patch-repo.sh hg qselect --reapply $guards \ > > '$(sh $davinci/patches/make/current-release.sh)' > + (cd sources/hotspot; hg qselect --reapply buildable testable $(sh > $davinci/patches/make/current-release.sh)) > + (cd sources/jdk; hg qselect --reapply buildable testable $(sh > $davinci/patches/make/current-release.sh)) > + (cd sources/langtools; hg qselect --reapply buildable testable $(sh > $davinci/patches/make/current-release.sh)) > > I don't see any other output, so I assumed it was successfully applied, but > maybe not. > If it is version issue (jdk7-b72), what is the right way to apply the > patches? should I get older version of openjdk7? > > Thanks! > > alan > > > On Tue, Sep 29, 2009 at 1:24 AM, Christian Thalinger < > Christian.Thalinger at sun.com> wrote: > >> alan yung wrote: >> > Hi, >> > >> > I'm trying to apply the mlvm patches to openjdk7 on windows XP. The >> > openjdk7 build actually works, and I got the jdk image, but the problem >> > is, the patch doesn't seem to be applied. >> > >> > I followed the instruction here: >> > http://wikis.sun.com/display/mlvm/Building , but the problem is, even >> > after applying the patch (and it seems to be successful), >> > the whole patches dont seem to be applied. For instance, jdk/indy.patch >> > doesn't seem to be applied since I don't see insertArguments method in >> > /jdk/src/share/classes/java/dyn/MethodHandles.java >> > >> > Is there any gotchas that I'm missing? >> >> One problem could be that the bsd-port repository got updated to >> jdk7-b72 and maybe the patches don't apply cleanly anymore. Are you >> sure that the patches applied successful? Can you post the output? >> >> -- Christian >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090930/40929585/attachment.html From raffaello.giulietti at gmail.com Wed Sep 30 05:43:22 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 30 Sep 2009 14:43:22 +0200 Subject: building from the sources In-Reply-To: <9997d5e60907280610t21786adar8a397e1163758873@mail.gmail.com> References: <4A6EE917.5020408@gmail.com> <9997d5e60907280610t21786adar8a397e1163758873@mail.gmail.com> Message-ID: <964462730909300543p395bc835v726af678138ac50a@mail.gmail.com> Hi Ubuntu users, I modified the Ubuntu specific patches to work for the current b72 based port. $davinci is supposed to be the path to your da Vinci root directory that already contains the sources and patches subdirectories. You need to copy the *.patch files found in the attachment to your $davinci/patches/jdk directory and append the series file in the attachment to $davinci/patches/jdk/series file. cp -p *.patch $davinci/patches/jdk cat series >> $davinci/patches/jdk/series The interim-endian.patch mentioned in Tobias' post is not needed for b72. Greetings Raffaello On Tue, Jul 28, 2009 at 15:10, Tobias Ivarsson wrote: > The bsd-port builds on Linux as well. > > You might need a few patches though. > This thread was helpful for me when I rebased the interface injection patch > last week: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-April/000486.html > With those instructions I managed to get the build working on Ubuntu 9.04. > > I think there was some fuzz with the patch application, so I'll attach the > patches as they look on my system at the moment. (applies on bsd-port from > last week). > > Simply add these file to your jdk patch repository and add the following > section to your series file (after the reviewed mlvm patches, before the > unreviewed), and "hg qpush -a" should apply these patches along with the > mlvm patches and enable you to build cleanly on Ubuntu. > > # patches required to build on Ubuntu > interim-endian.patch > jmx.snmp-binaryplugs.patch > sun-tools-jar.patch > ia32.patch > > Happy Hacking > /Tobias > > On Tue, Jul 28, 2009 at 2:03 PM, Raffaello Giulietti > wrote: >> >> I'm getting into troubles with the binary snapshot, so I decided to >> build from the sources. >> >> I once managed to build OpenJDK on Ubuntu 9.04/VirtualBox/Vista. >> >> Now, browsing through the building instructions found at >> http://wikis.sun.com/display/mlvm/Building I'm wondering what the >> dependencies between mlvm and the bsd-port are. According to this page, >> the repo is found at http://hg.openjdk.java.net/bsd-port/bsd-port so it >> seems at first sight that mlvm is currently targeted only at this >> platform. >> >> Am I wrong? >> What about Linux? >> >> Thanks >> Raffaello >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -------------- next part -------------- A non-text attachment was scrubbed... Name: ubuntu-patches.tar.gz Type: application/x-gzip Size: 1383 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090930/fdbd90bc/attachment-0001.bin From headius at headius.com Wed Sep 30 11:38:50 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Sep 2009 08:38:50 -1000 Subject: Summit pictures In-Reply-To: References: Message-ID: Great pictures :) On Mon, Sep 28, 2009 at 8:32 PM, John Rose wrote: > I just posted some Summit pictures at ?http://wiki.jvmlangsummit.com > > They were taken by Oleg Pliss, the VM engineer in front with the big > camera. ?Thanks Oleg! > > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From John.Rose at Sun.COM Wed Sep 30 12:42:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 30 Sep 2009 12:42:16 -0700 Subject: applying patches doesn't seem to work In-Reply-To: <6b6a329a0909300055h38c97880n553697f2a77923d@mail.gmail.com> References: <6b6a329a0909281345o7234b5e1k1b172d8ff0a82d6e@mail.gmail.com> <4AC1C446.9090906@Sun.COM> <6b6a329a0909290231s3b00c235rebebfc66896711f0@mail.gmail.com> <6b6a329a0909300055h38c97880n553697f2a77923d@mail.gmail.com> Message-ID: Maybe some of the build instructions are unclear. Check the README file, in the section on "Patch Guards". Currently, we guard patches by Mercurial revision hashes (look inside the series files). This is intended to prevent the problem you are (probably) running into, of applying patches to the wrong micro-version of the main source code. Inside the series file we keep the exact base revision for the patches, expressed as a guard. To meet the requirements of the version guard, you'll need to do "hg checkout" to that version. Here some relevant description from the README: > Each patch must have one or more positive guards. At last one guard > must be a twelve-digit hexadecimal mercurial revision hash, such as > "7836be3e92d0". If a patch is guarded by such a revision, it is > guaranteed to apply, without rejects, to that particular OpenJDK > build, and to build successfully. > > Other tags may be present, especially tags of OpenJDK builds, such > as "jdk7-b25". As it happens, "7836be3e92d0" and "jdk7-b25" refer > to the same revision in the hotspot repository. These symbolic tags > are informational and approximate, and (being less accurate than > hashes) do not guarantee clean application of patches. "At last" is a typo for "At least". -- John On Sep 30, 2009, at 12:55 AM, alan yung wrote: > Actually, I didn't apply the patches correctly. > > Now when I tried to apply the patches, it shows many error messages, > but it did apply (at least) some patches successfully. > > My question is, do the patches apply successfully in current head > revision? From james_ladd at hotmail.com Wed Sep 30 23:41:51 2009 From: james_ladd at hotmail.com (James Ladd) Date: Thu, 1 Oct 2009 16:41:51 +1000 Subject: A possible performance boost? (James Ladd) In-Reply-To: References: Message-ID: Any comments ? > Hi All, > > I have a suggestion on a possible performance boost for the JVM which if I had time > I would research more and implement, however, I'm rather time poor right now and > thought I could at least put the idea in the wild for someone else or myself at a later > stage. > > >From my last use of GCC and the code/assembler it generates I noticed that the performance > of switch()/case statements could be improved greatly as code generated by GCC did little > more than a sequence of compare and jump to next label. Yes - I need to reverify this is > the case, but lets assume for a moment that it still is the case. > > When I last optimized a bytecode dispatcher I found that using a jump table of addressed indexed > by bytecode was a very efficient approach and yet still more efficient was to replace bytecodes with > direct jump addresses on loading the code. > > While I looked briefly at the C++ for the templated interpreter of the VM it appears possible to > use on or more of the approaches outlined above. > > Does anyone see a reason this could not be tried, or has it been tried and what were the results? > > Rgs, James. _________________________________________________________________ Get the latest news, goss and sport Make ninemsn your homepage! http://windowslive.ninemsn.com.au/article.aspx?id=813730 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091001/af6e229f/attachment.html