From szegedia at gmail.com Sat Aug 1 00:54:21 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 1 Aug 2009 09:54:21 +0200 Subject: Few java.dyn API and JavaDoc observations Message-ID: <202DAB21-E993-403F-A49C-B5E6409BD85A@gmail.com> Hi folks, few minor observations regarding JavaDoc and API for java.dyn: 1. Linkage.registerBootstrapMethod JavaDoc says "Register a bootstrap method to use when linking a given caller class. It must be a method handle of a type equivalent to CallSite.CallSite(java.lang.Object, java.lang.String, java.dyn.MethodType). " In reality, the first argument should be java.lang.Class instead. 2. With regard to that, why is the first arg to CallSite ctor an Object, and not a Class? 3. CallSite.nameComponents() returns Object[] - why not String[]? Attila. -- twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com From forax at univ-mlv.fr Sat Aug 1 04:01:55 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sat, 01 Aug 2009 13:01:55 +0200 Subject: Few java.dyn API and JavaDoc observations In-Reply-To: <202DAB21-E993-403F-A49C-B5E6409BD85A@gmail.com> References: <202DAB21-E993-403F-A49C-B5E6409BD85A@gmail.com> Message-ID: <4A7420A3.5000906@univ-mlv.fr> Le 01/08/2009 09:54, Attila Szegedi a ?crit : > Hi folks, > Hi Attila, > few minor observations regarding JavaDoc and API for java.dyn: > > 1. Linkage.registerBootstrapMethod JavaDoc says "Register a bootstrap > method to use when linking a given caller class. It must be a method > handle of a type equivalent to CallSite.CallSite(java.lang.Object, > java.lang.String, java.dyn.MethodType). " In reality, the first > argument should be java.lang.Class instead. > Yes, this part of the doc is not up to date. The doc of BOOTSTRAP_METHOD_TYPE is more accurate. > 2. With regard to that, why is the first arg to CallSite ctor an > Object, and not a Class? > Object => token to be used for invalidation. see http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-July/000864.html > 3. CallSite.nameComponents() returns Object[] - why not String[]? > Personally, I don't like this method. I think it has nothing to do with a CallSite but It's more something that a MOP should provide. Furthermore, it implied that CallSite have to store the name of an invokedynamic call even if this name was already provided to the user by the bootstrap method. In my opinion, a CallSite should store neither the method name nor the declaring class and if a developer wants this info, it should provide a subclass of CallSite to store these info. > Attila. > R?mi PS: I will try to answer to your mail about MOP this afternoon :) From szegedia at gmail.com Sat Aug 1 13:25:32 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 1 Aug 2009 22:25:32 +0200 Subject: Mangled names for invokedynamic Message-ID: <3E7CFA1D-6542-4244-A6C2-5B669700086D@gmail.com> Folks (well, primarily John I think), I'm trying to write a testcase for an invokedynamic call that specifies "dyn:getprop:helloText" as the method name. So far, I've tried the following (all using ASM to generate bytecode as I don't know what if any is the javac-recognized syntax for these): 1. specify the name verbatim as "dyn:getprop:helloText" in the argument to invokedynamic. Gives me the following exception when I call CallSite.nameComponents(): [junit] java.lang.Character [junit] java.lang.ArrayStoreException: java.lang.Character [junit] at sun.dyn.util.BytecodeName.parseBytecodeName(BytecodeName.java:324) [junit] at java.dyn.CallSite.nameComponents(CallSite.java:224) [junit] at org .dynalang .dynalink.beans.BeansLinker.getGuardedInvocation(BeansLinker.java:29) [junit] at org .dynalang .dynalink .support.DynamicLinkerImpl.relinkAndInvoke(DynamicLinkerImpl.java:68) [junit] at sun.dyn.FilterGeneric$F0.invoke_C0(FilterGeneric.java: 343) [junit] at sun.dyn.ToGeneric$A0.target(ToGeneric.java:625) [junit] at sun.dyn.ToGeneric$A0.targetA0(ToGeneric.java:626) [junit] at sun.dyn.ToGeneric$A0.invoke_L(ToGeneric.java:627) [junit] at org .dynalang .dynalink.GreeterDriverImpl.invokeGetHelloText(GreeterDriverImpl.java: 23) [junit] at org.dynalang.dynalink.TestGreeterDriver.testAll(TestGreeterDriver.java: 10) 2. specify the name mangled as either "\=dyn\!getprop\!helloText" or "dyn\!getprop\!helloText". In neither case will CallSite.name() demangle it, nor will CallSite.nameComponents() either demangle or tokenize it - I get back a single-element array with the full mangled name. Am I doing something wrong? Attila. From szegedia at gmail.com Sun Aug 2 01:57:50 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 2 Aug 2009 10:57:50 +0200 Subject: New binary build of MLVM available Message-ID: <2732132E-1ABA-412A-AA5F-88FF1AB73EE7@gmail.com> Folks, I rebuilt the MLVM for Mac OS X from the current Mercurial sources around August 1, 1 AM Central European Time; you can get it at: Attila. From headius at headius.com Sun Aug 2 13:12:00 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 2 Aug 2009 15:12:00 -0500 Subject: Still crashity crashing Message-ID: Ok, finally circled back around to testing things again. With Attila's build, I'm still getting crashes, but more seems to work. I've attached the dump from the crash. To reproduce: 1. grab and unpack a JRuby nightly from 2. set MLVM into JAVA_HOME 3. run bin/jruby -J-Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 It should blow up pretty quickly. I have not had opportunity to narrow it down any more than this. Because of the crashing, it's difficult for me to move forward on indy work :( I'm standing by to do anything I can do to help figure it out. - Charlie -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid40680.log Type: application/octet-stream Size: 27806 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090802/c800d9b6/attachment.obj From szegedia at gmail.com Sun Aug 2 14:34:27 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 2 Aug 2009 23:34:27 +0200 Subject: Still crashity crashing In-Reply-To: References: Message-ID: <20EC2220-B830-4C0C-B0A5-5539F97B033C@gmail.com> I too managed to crash it yesterday, but it turned out I accidentally emitted invalid bytecode from ASM - I forgot to end the binary name of a class with semicolon in method signature of an invokedynamic instruction. Amazingly, neither ASM nor the verifier caught it. The crash message was something along the lines of "ShouldNotBeHere" or similar :-) All I want to say is, in my case it crashed because I fed it garbage. Not necessarily true in your case, but worth doublechecking what you do (knowing you, you probably did it anyway before posting). Attila. On 2009.08.02., at 22:12, Charles Oliver Nutter wrote: > Ok, finally circled back around to testing things again. With Attila's > build, I'm still getting crashes, but more seems to work. > > I've attached the dump from the crash. To reproduce: > > 1. grab and unpack a JRuby nightly from > 2. set MLVM into JAVA_HOME > 3. run bin/jruby -J-Djruby.compile.invokedynamic=true > -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 > > It should blow up pretty quickly. I have not had opportunity to narrow > it down any more than this. > > Because of the crashing, it's difficult for me to move forward on indy > work :( I'm standing by to do anything I can do to help figure it out. > > - Charlie From szegedia at gmail.com Sun Aug 2 14:42:51 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 2 Aug 2009 23:42:51 +0200 Subject: Still crashity crashing In-Reply-To: <20EC2220-B830-4C0C-B0A5-5539F97B033C@gmail.com> References: <20EC2220-B830-4C0C-B0A5-5539F97B033C@gmail.com> Message-ID: Specifically, in my case emitting a class through ASM that has this in it: mv.visitMethodInsn(INVOKEDYNAMIC, "java/dyn/InvokeDynamic", "dyn:getprop:helloText", "(Ljava/lang/Object;)Ljava/lang/String"); crashes the JVM sometime after it loads the class. Note how there's no semicolon after "Ljava/lang/String" Attila. On 2009.08.02., at 23:34, Attila Szegedi wrote: > I too managed to crash it yesterday, but it turned out I > accidentally emitted invalid bytecode from ASM - I forgot to end the > binary name of a class with semicolon in method signature of an > invokedynamic instruction. Amazingly, neither ASM nor the verifier > caught it. The crash message was something along the lines of > "ShouldNotBeHere" or similar :-) > > All I want to say is, in my case it crashed because I fed it > garbage. Not necessarily true in your case, but worth doublechecking > what you do (knowing you, you probably did it anyway before posting). > > Attila. > > On 2009.08.02., at 22:12, Charles Oliver Nutter wrote: > >> Ok, finally circled back around to testing things again. With >> Attila's >> build, I'm still getting crashes, but more seems to work. >> >> I've attached the dump from the crash. To reproduce: >> >> 1. grab and unpack a JRuby nightly from >> 2. set MLVM into JAVA_HOME >> 3. run bin/jruby -J-Djruby.compile.invokedynamic=true >> -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 >> >> It should blow up pretty quickly. I have not had opportunity to >> narrow >> it down any more than this. >> >> Because of the crashing, it's difficult for me to move forward on >> indy >> work :( I'm standing by to do anything I can do to help figure it >> out. >> >> - Charlie From forax at univ-mlv.fr Sun Aug 2 15:21:23 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 03 Aug 2009 00:21:23 +0200 Subject: Still crashity crashing In-Reply-To: References: <20EC2220-B830-4C0C-B0A5-5539F97B033C@gmail.com> Message-ID: <4A761163.1080700@univ-mlv.fr> This is another error here. GuardWithTest adapter try to report a NPE but fillInStackTrace() crash when walking the stack to gather all frames. The good question is how GuardWithTest can throw a NPE knowing that test, target and fallback are null checked before its creation. By the way, John : in MethodHandleImpl.makeGuardWithTest() the code : MethodHandle gtest = spreadArguments(token, test, gtype.changeReturnType(boolean.class), 0); MethodHandle gtarget = spreadArguments(token, target, gtype, 0); MethodHandle gfallback = spreadArguments(token, fallback, gtype, 0); MethodHandle gguard = new GuardWithTest(GuardWithTest.VARARGS_INVOKE, gtest, gtarget, gfallback); if (gtest == null || gtarget == null || gfallback == null) return null; return collectArguments(token, gguard, type, 0, null); should be : MethodHandle gtest = spreadArguments(token, test, gtype.changeReturnType(boolean.class), 0); MethodHandle gtarget = spreadArguments(token, target, gtype, 0); MethodHandle gfallback = spreadArguments(token, fallback, gtype, 0); if (gtest == null || gtarget == null || gfallback == null) return null; MethodHandle gguard = new GuardWithTest(GuardWithTest.VARARGS_INVOKE, gtest, gtarget, gfallback); return collectArguments(token, gguard, type, 0, null); the null check should before the creation of the guard. Anyway, these doesn't solve the problem. Charles, could you try with -Xint, just to see if the NPE is still thrown or not ? cheers, R?mi Le 02/08/2009 23:42, Attila Szegedi a ?crit : > Specifically, in my case emitting a class through ASM that has this in > it: > > mv.visitMethodInsn(INVOKEDYNAMIC, "java/dyn/InvokeDynamic", > "dyn:getprop:helloText", "(Ljava/lang/Object;)Ljava/lang/String"); > > crashes the JVM sometime after it loads the class. Note how there's no > semicolon after "Ljava/lang/String" > > Attila. > > On 2009.08.02., at 23:34, Attila Szegedi wrote: > > >> I too managed to crash it yesterday, but it turned out I >> accidentally emitted invalid bytecode from ASM - I forgot to end the >> binary name of a class with semicolon in method signature of an >> invokedynamic instruction. Amazingly, neither ASM nor the verifier >> caught it. The crash message was something along the lines of >> "ShouldNotBeHere" or similar :-) >> >> All I want to say is, in my case it crashed because I fed it >> garbage. Not necessarily true in your case, but worth doublechecking >> what you do (knowing you, you probably did it anyway before posting). >> >> Attila. >> >> On 2009.08.02., at 22:12, Charles Oliver Nutter wrote: >> >> >>> Ok, finally circled back around to testing things again. With >>> Attila's >>> build, I'm still getting crashes, but more seems to work. >>> >>> I've attached the dump from the crash. To reproduce: >>> >>> 1. grab and unpack a JRuby nightly from >>> 2. set MLVM into JAVA_HOME >>> 3. run bin/jruby -J-Djruby.compile.invokedynamic=true >>> -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 >>> >>> It should blow up pretty quickly. I have not had opportunity to >>> narrow >>> it down any more than this. >>> >>> Because of the crashing, it's difficult for me to move forward on >>> indy >>> work :( I'm standing by to do anything I can do to help figure it >>> out. >>> >>> - 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/20090803/0226cccd/attachment.html From headius at headius.com Sun Aug 2 16:54:24 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 2 Aug 2009 18:54:24 -0500 Subject: Still crashity crashing In-Reply-To: <4A761163.1080700@univ-mlv.fr> References: <20EC2220-B830-4C0C-B0A5-5539F97B033C@gmail.com> <4A761163.1080700@univ-mlv.fr> Message-ID: On Sun, Aug 2, 2009 at 5:21 PM, R?mi Forax wrote: > Charles, could you try with -Xint, just to see if the NPE is still thrown or > not ? With -Xint it works fine, and runs fib(30) for as long as I choose to let it run. - Charlie From headius at headius.com Sun Aug 2 21:23:17 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 2 Aug 2009 23:23:17 -0500 Subject: Still crashity crashing In-Reply-To: References: Message-ID: On Sun, Aug 2, 2009 at 3:12 PM, Charles Oliver Nutter wrote: > Ok, finally circled back around to testing things again. With Attila's > build, I'm still getting crashes, but more seems to work. > > I've attached the dump from the crash. To reproduce: > > 1. grab and unpack a JRuby nightly from http://jruby.headius.com:8080/hudson/job/jruby-dist/ > 2. set MLVM into JAVA_HOME > 3. run bin/jruby -J-Djruby.compile.invokedynamic=true > -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 > > It should blow up pretty quickly. I have not had opportunity to narrow > it down any more than this. > > Because of the crashing, it's difficult for me to move forward on indy > work :( I'm standing by to do anything I can do to help figure it out. > > - Charlie > From Christian.Thalinger at Sun.COM Mon Aug 3 00:49:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 Aug 2009 09:49:38 +0200 Subject: Still crashity crashing In-Reply-To: References: Message-ID: <4A769692.10601@Sun.COM> Charles Oliver Nutter wrote: > Ok, finally circled back around to testing things again. With Attila's > build, I'm still getting crashes, but more seems to work. > > I've attached the dump from the crash. To reproduce: > > 1. grab and unpack a JRuby nightly from I just updated my GIT repository, rebuilt it and it seems "bench_fib_recursive.rb 100" got slower: 0.902000 0.000000 0.902000 ( 0.854000) 0.776000 0.000000 0.776000 ( 0.776000) 0.779000 0.000000 0.779000 ( 0.779000) vs. 2.326000 0.000000 2.326000 ( 2.299000) 2.233000 0.000000 2.233000 ( 2.233000) 2.216000 0.000000 2.216000 ( 2.216000) Anything changed that could cause this slowdown? -- Christian From Christian.Thalinger at Sun.COM Mon Aug 3 01:13:59 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 Aug 2009 10:13:59 +0200 Subject: Still crashity crashing In-Reply-To: References: Message-ID: <4A769C47.9040802@Sun.COM> Charles Oliver Nutter wrote: > Ok, finally circled back around to testing things again. With Attila's > build, I'm still getting crashes, but more seems to work. > > I've attached the dump from the crash. To reproduce: > > 1. grab and unpack a JRuby nightly from > 2. set MLVM into JAVA_HOME > 3. run bin/jruby -J-Djruby.compile.invokedynamic=true > -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 Yes, it crashes for me too with Attila's build. It's very strange that my builds works but Attila's does not. Attila, could give some information how you built your build? Could you verify you Mercurial tip's? Did you use a different GCC version, libraries, ...? Could you provide a debug build? I will build my version from scratch and try again... -- Christian From szegedia at gmail.com Mon Aug 3 02:04:14 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 3 Aug 2009 11:04:14 +0200 Subject: Still crashity crashing In-Reply-To: <4A769C47.9040802@Sun.COM> References: <4A769C47.9040802@Sun.COM> Message-ID: <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> Okay, I think I got it... my "hg tip" for bsd-port was okay: changeset: 125:428565383a55 tag: tip parent: 123:75d7dc371aec parent: 124:5dc862ec024e user: glewis at misty.eyesbeyond.com date: Sat Jul 25 20:53:34 2009 -0700 summary: . Merge from main OpenJDK repository. But "hg tip" for davinci/patches was definitely not: changeset: 8:e433df0d89ae tag: tip user: jrose date: Fri May 15 13:54:21 2009 -0700 summary: meth: test/development project, for use with netbeans and/ or ant doing an update/pull on it resulted in: added 17 changesets with 45 changes to 19 files after which "hg tip" says: changeset: 25:5745e8f6c36b tag: tip user: jrose date: Tue Jul 21 02:04:58 2009 -0700 summary: meth: negative tests for low-level MH matching errors Much better. So, this is probably my bad. Other than that, my build process is as this (using an existing local Hg repository): 1. back out current patches from bsd-port using "hg qselect --pop" on jdk, hotspot, and langtools -- this is necessary to make sure fpull and fupdate don't skip them 2. hg fpull; hg fupdate in bsd-port 3. hg fpull; hg fupdate in davinci/patches 4. apply patches: cd davinci; (cd patches/make; gnumake setup); (cd patches/make; gnumake patch) 5. build: cd bsd-port; ./clean.sh; ./build.sh my build.sh is this: LC_ALL=C LANG=C unset CLASSPATH unset JAVA_HOME make \ ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3/ \ ALT_BINARY_PLUGS_PATH=/Users/aszegedi/Documents/projects/openjdk/jdk-7- icedtea-plugs \ ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \ ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \ ALT_CUPS_HEADERS_PATH=/usr/include \ ANT_HOME=/usr/share/ant \ NO_DOCS=true \ HOTSPOT_BUILD_JOBS=1 \ ALT_JIBX_LIBS_PATH=/Users/aszegedi/Documents/projects/openjdk/jibx/lib gcc is: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Strangely, trying to build using "gnumake" from davinci/patches/make will fail; that's why I go back manually to bsd-port. Also, not doing a ./clean.sh is a bad idea, as it did cause a build to fail in the past. Anyway, the problem is likely that I failed to update the davince/patches from Mercurial. Sorry about that - it was really lame... I'm rebuilding now, will test with Charlie's nightly JRuby when it's done, and if it works, will republish it. Attila. On 2009.08.03., at 10:13, Christian Thalinger wrote: > Charles Oliver Nutter wrote: >> Ok, finally circled back around to testing things again. With >> Attila's >> build, I'm still getting crashes, but more seems to work. >> >> I've attached the dump from the crash. To reproduce: >> >> 1. grab and unpack a JRuby nightly from >> 2. set MLVM into JAVA_HOME >> 3. run bin/jruby -J-Djruby.compile.invokedynamic=true >> -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 > > Yes, it crashes for me too with Attila's build. It's very strange > that > my builds works but Attila's does not. > > Attila, could give some information how you built your build? Could > you > verify you Mercurial tip's? Did you use a different GCC version, > libraries, ...? Could you provide a debug build? > > I will build my version from scratch and try again... > > -- Christian From Christian.Thalinger at Sun.COM Mon Aug 3 02:34:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 Aug 2009 11:34:05 +0200 Subject: Still crashity crashing In-Reply-To: <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> Message-ID: <4A76AF0D.1000908@Sun.COM> Attila Szegedi wrote: > Strangely, trying to build using "gnumake" from davinci/patches/make > will fail; that's why I go back manually to bsd-port. Also, not doing > a ./clean.sh is a bad idea, as it did cause a build to fail in the > past. Anyway, the problem is likely that I failed to update the > davince/patches from Mercurial. Sorry about that - it was really > lame... I'm rebuilding now, will test with Charlie's nightly JRuby > when it's done, and if it works, will republish it. OK, let's see if that fixes the problem. -- Christian From szegedia at gmail.com Mon Aug 3 03:21:52 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 3 Aug 2009 12:21:52 +0200 Subject: Still crashity crashing In-Reply-To: <4A76AF0D.1000908@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A76AF0D.1000908@Sun.COM> Message-ID: <0E963D08-EE63-4EC8-9096-7A6A701826B2@gmail.com> Ok, fib now runs to completion (see below). I'm uploading a new build; the URL is . It will take 1-2 hours as apparently I only have 64KBit/sec uplink where I am now :-( So, don't start downloading just yet :-) Attila. MacBook-Pro-Ati:jruby-1.4.0 aszegedi$ bin/jruby -J- Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ bench_fib_recursive.rb 100 0.539000 0.000000 0.539000 ( 0.520000) 0.480000 0.000000 0.480000 ( 0.480000) 0.475000 0.000000 0.475000 ( 0.476000) 0.469000 0.000000 0.469000 ( 0.468000) 0.466000 0.000000 0.466000 ( 0.466000) 0.477000 0.000000 0.477000 ( 0.477000) 0.473000 0.000000 0.473000 ( 0.473000) 0.465000 0.000000 0.465000 ( 0.465000) 0.473000 0.000000 0.473000 ( 0.473000) 0.471000 0.000000 0.471000 ( 0.471000) 0.494000 0.000000 0.494000 ( 0.494000) 0.473000 0.000000 0.473000 ( 0.473000) 0.477000 0.000000 0.477000 ( 0.478000) 0.478000 0.000000 0.478000 ( 0.478000) 0.469000 0.000000 0.469000 ( 0.470000) 0.496000 0.000000 0.496000 ( 0.496000) 0.471000 0.000000 0.471000 ( 0.472000) 0.490000 0.000000 0.490000 ( 0.490000) 0.480000 0.000000 0.480000 ( 0.480000) 0.494000 0.000000 0.494000 ( 0.493000) 0.487000 0.000000 0.487000 ( 0.488000) 0.480000 0.000000 0.480000 ( 0.480000) 0.478000 0.000000 0.478000 ( 0.478000) 0.534000 0.000000 0.534000 ( 0.535000) 0.553000 0.000000 0.553000 ( 0.553000) 0.482000 0.000000 0.482000 ( 0.481000) 0.523000 0.000000 0.523000 ( 0.523000) 0.483000 0.000000 0.483000 ( 0.484000) 0.480000 0.000000 0.480000 ( 0.480000) 0.473000 0.000000 0.473000 ( 0.473000) 0.478000 0.000000 0.478000 ( 0.478000) 0.473000 0.000000 0.473000 ( 0.473000) 0.470000 0.000000 0.470000 ( 0.469000) 0.472000 0.000000 0.472000 ( 0.472000) 0.474000 0.000000 0.474000 ( 0.474000) 0.474000 0.000000 0.474000 ( 0.474000) 0.474000 0.000000 0.474000 ( 0.474000) 0.477000 0.000000 0.477000 ( 0.477000) 0.477000 0.000000 0.477000 ( 0.477000) 0.471000 0.000000 0.471000 ( 0.472000) 0.474000 0.000000 0.474000 ( 0.474000) 0.480000 0.000000 0.480000 ( 0.479000) 0.479000 0.000000 0.479000 ( 0.479000) 0.475000 0.000000 0.475000 ( 0.475000) 0.476000 0.000000 0.476000 ( 0.476000) 0.478000 0.000000 0.478000 ( 0.478000) 0.474000 0.000000 0.474000 ( 0.474000) 0.473000 0.000000 0.473000 ( 0.473000) 0.473000 0.000000 0.473000 ( 0.473000) 0.471000 0.000000 0.471000 ( 0.471000) 0.471000 0.000000 0.471000 ( 0.471000) 0.475000 0.000000 0.475000 ( 0.475000) 0.470000 0.000000 0.470000 ( 0.470000) 0.469000 0.000000 0.469000 ( 0.469000) 0.598000 0.000000 0.598000 ( 0.599000) 1.197000 0.000000 1.197000 ( 1.197000) 0.979000 0.000000 0.979000 ( 0.979000) 0.746000 0.000000 0.746000 ( 0.746000) 0.810000 0.000000 0.810000 ( 0.810000) 0.762000 0.000000 0.762000 ( 0.762000) 0.645000 0.000000 0.645000 ( 0.644000) 0.474000 0.000000 0.474000 ( 0.474000) 0.469000 0.000000 0.469000 ( 0.469000) 0.467000 0.000000 0.467000 ( 0.467000) 0.469000 0.000000 0.469000 ( 0.469000) 0.472000 0.000000 0.472000 ( 0.472000) 0.469000 0.000000 0.469000 ( 0.469000) 0.469000 0.000000 0.469000 ( 0.469000) 0.480000 0.000000 0.480000 ( 0.480000) 0.478000 0.000000 0.478000 ( 0.479000) 0.473000 0.000000 0.473000 ( 0.474000) 0.474000 0.000000 0.474000 ( 0.474000) 0.487000 0.000000 0.487000 ( 0.487000) 0.472000 0.000000 0.472000 ( 0.472000) 0.469000 0.000000 0.469000 ( 0.469000) 0.475000 0.000000 0.475000 ( 0.475000) 0.476000 0.000000 0.476000 ( 0.476000) 0.471000 0.000000 0.471000 ( 0.471000) 0.470000 0.000000 0.470000 ( 0.470000) 0.467000 0.000000 0.467000 ( 0.467000) 0.473000 0.000000 0.473000 ( 0.473000) 0.469000 0.000000 0.469000 ( 0.468000) 0.472000 0.000000 0.472000 ( 0.472000) 0.489000 0.000000 0.489000 ( 0.489000) 0.565000 0.000000 0.565000 ( 0.566000) 0.566000 0.000000 0.566000 ( 0.566000) 0.497000 0.000000 0.497000 ( 0.497000) 0.482000 0.000000 0.482000 ( 0.481000) 0.475000 0.000000 0.475000 ( 0.475000) 0.485000 0.000000 0.485000 ( 0.485000) 0.483000 0.000000 0.483000 ( 0.483000) 0.481000 0.000000 0.481000 ( 0.481000) 0.479000 0.000000 0.479000 ( 0.479000) 0.524000 0.000000 0.524000 ( 0.523000) 0.490000 0.000000 0.490000 ( 0.490000) 0.485000 0.000000 0.485000 ( 0.485000) 0.476000 0.000000 0.476000 ( 0.477000) 0.476000 0.000000 0.476000 ( 0.476000) 0.489000 0.000000 0.489000 ( 0.489000) 0.473000 0.000000 0.473000 ( 0.473000) MacBook-Pro-Ati:jruby-1.4.0 aszegedi$ On 2009.08.03., at 11:34, Christian Thalinger wrote: > Attila Szegedi wrote: >> Strangely, trying to build using "gnumake" from davinci/patches/make >> will fail; that's why I go back manually to bsd-port. Also, not doing >> a ./clean.sh is a bad idea, as it did cause a build to fail in the >> past. Anyway, the problem is likely that I failed to update the >> davince/patches from Mercurial. Sorry about that - it was really >> lame... I'm rebuilding now, will test with Charlie's nightly JRuby >> when it's done, and if it works, will republish it. > > OK, let's see if that fixes the problem. > > -- Christian From forax at univ-mlv.fr Mon Aug 3 07:15:20 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 03 Aug 2009 16:15:20 +0200 Subject: Still crashity crashing In-Reply-To: References: Message-ID: <4A76F0F8.2010802@univ-mlv.fr> Hi Charles, I try to compile jruby (1.4.0dev) and I go an error saying that ivy/build.xml doesn't exists. So I chnage the line 49 of the build.xml to optionally to the import file: and It seems to work. R?mi Le 03/08/2009 06:23, Charles Oliver Nutter a ?crit : > On Sun, Aug 2, 2009 at 3:12 PM, Charles Oliver > Nutter wrote: > >> Ok, finally circled back around to testing things again. With Attila's >> build, I'm still getting crashes, but more seems to work. >> >> I've attached the dump from the crash. To reproduce: >> >> 1. grab and unpack a JRuby nightly from >> > > http://jruby.headius.com:8080/hudson/job/jruby-dist/ > > >> 2. set MLVM into JAVA_HOME >> 3. run bin/jruby -J-Djruby.compile.invokedynamic=true >> -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 >> >> It should blow up pretty quickly. I have not had opportunity to narrow >> it down any more than this. >> >> Because of the crashing, it's difficult for me to move forward on indy >> work :( I'm standing by to do anything I can do to help figure it out. >> >> - 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/20090803/20c59ff4/attachment.html From headius at headius.com Mon Aug 3 07:11:51 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 3 Aug 2009 09:11:51 -0500 Subject: Still crashity crashing In-Reply-To: <4A76F0F8.2010802@univ-mlv.fr> References: <4A76F0F8.2010802@univ-mlv.fr> Message-ID: On Mon, Aug 3, 2009 at 9:15 AM, R?mi Forax wrote: > Hi Charles, > > I try to compile jruby (1.4.0dev) > and I go an error saying that ivy/build.xml doesn't exists. > > So I chnage the line 49 of the build.xml to optionally > to the import file: > > > and It seems to work. Odd...ivy/build.xml should be there. Anyway, let me know if you have any other problems. - Charlie From headius at headius.com Mon Aug 3 07:12:55 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 3 Aug 2009 09:12:55 -0500 Subject: Still crashity crashing In-Reply-To: <0E963D08-EE63-4EC8-9096-7A6A701826B2@gmail.com> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A76AF0D.1000908@Sun.COM> <0E963D08-EE63-4EC8-9096-7A6A701826B2@gmail.com> Message-ID: For some reason this is still crashing for me: ~/projects/jruby ? ../j2sdk-image/bin/java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-aszegedi_2009_08_03_11_04-b00) OpenJDK Server VM (build 16.0-b06, mixed mode) ~/projects/jruby ? echo $JAVA_HOME /Users/headius/projects/j2sdk-image/ ~/projects/jruby ? jruby -J-Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x011a5aaa, pid=45880, tid=2953842688 # # JRE version: 7.0 # Java VM: OpenJDK Client VM (16.0-b06 mixed mode bsd-x86 ) # Problematic frame: # V [libjvm.dylib+0x1a5aaa] # # An error report file with more information is saved as: # /Users/headius/projects/jruby/hs_err_pid45880.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Abort trap ~/projects/jruby ? jruby -J-Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic --server bench/bench_fib_recursive.rb 100 Illegal instruction :( On Mon, Aug 3, 2009 at 5:21 AM, Attila Szegedi wrote: > Ok, fib now runs to completion (see below). I'm uploading a new build; > the URL is ?>. It will take 1-2 hours as apparently I only have 64KBit/sec uplink > where I am now :-( So, don't start downloading just yet :-) > > Attila. > > MacBook-Pro-Ati:jruby-1.4.0 aszegedi$ bin/jruby -J- > Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ > bench_fib_recursive.rb 100 > ? 0.539000 ? 0.000000 ? 0.539000 ( ?0.520000) > ? 0.480000 ? 0.000000 ? 0.480000 ( ?0.480000) > ? 0.475000 ? 0.000000 ? 0.475000 ( ?0.476000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.468000) > ? 0.466000 ? 0.000000 ? 0.466000 ( ?0.466000) > ? 0.477000 ? 0.000000 ? 0.477000 ( ?0.477000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.465000 ? 0.000000 ? 0.465000 ( ?0.465000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.471000 ? 0.000000 ? 0.471000 ( ?0.471000) > ? 0.494000 ? 0.000000 ? 0.494000 ( ?0.494000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.477000 ? 0.000000 ? 0.477000 ( ?0.478000) > ? 0.478000 ? 0.000000 ? 0.478000 ( ?0.478000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.470000) > ? 0.496000 ? 0.000000 ? 0.496000 ( ?0.496000) > ? 0.471000 ? 0.000000 ? 0.471000 ( ?0.472000) > ? 0.490000 ? 0.000000 ? 0.490000 ( ?0.490000) > ? 0.480000 ? 0.000000 ? 0.480000 ( ?0.480000) > ? 0.494000 ? 0.000000 ? 0.494000 ( ?0.493000) > ? 0.487000 ? 0.000000 ? 0.487000 ( ?0.488000) > ? 0.480000 ? 0.000000 ? 0.480000 ( ?0.480000) > ? 0.478000 ? 0.000000 ? 0.478000 ( ?0.478000) > ? 0.534000 ? 0.000000 ? 0.534000 ( ?0.535000) > ? 0.553000 ? 0.000000 ? 0.553000 ( ?0.553000) > ? 0.482000 ? 0.000000 ? 0.482000 ( ?0.481000) > ? 0.523000 ? 0.000000 ? 0.523000 ( ?0.523000) > ? 0.483000 ? 0.000000 ? 0.483000 ( ?0.484000) > ? 0.480000 ? 0.000000 ? 0.480000 ( ?0.480000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.478000 ? 0.000000 ? 0.478000 ( ?0.478000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.470000 ? 0.000000 ? 0.470000 ( ?0.469000) > ? 0.472000 ? 0.000000 ? 0.472000 ( ?0.472000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.477000 ? 0.000000 ? 0.477000 ( ?0.477000) > ? 0.477000 ? 0.000000 ? 0.477000 ( ?0.477000) > ? 0.471000 ? 0.000000 ? 0.471000 ( ?0.472000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.480000 ? 0.000000 ? 0.480000 ( ?0.479000) > ? 0.479000 ? 0.000000 ? 0.479000 ( ?0.479000) > ? 0.475000 ? 0.000000 ? 0.475000 ( ?0.475000) > ? 0.476000 ? 0.000000 ? 0.476000 ( ?0.476000) > ? 0.478000 ? 0.000000 ? 0.478000 ( ?0.478000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.471000 ? 0.000000 ? 0.471000 ( ?0.471000) > ? 0.471000 ? 0.000000 ? 0.471000 ( ?0.471000) > ? 0.475000 ? 0.000000 ? 0.475000 ( ?0.475000) > ? 0.470000 ? 0.000000 ? 0.470000 ( ?0.470000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.469000) > ? 0.598000 ? 0.000000 ? 0.598000 ( ?0.599000) > ? 1.197000 ? 0.000000 ? 1.197000 ( ?1.197000) > ? 0.979000 ? 0.000000 ? 0.979000 ( ?0.979000) > ? 0.746000 ? 0.000000 ? 0.746000 ( ?0.746000) > ? 0.810000 ? 0.000000 ? 0.810000 ( ?0.810000) > ? 0.762000 ? 0.000000 ? 0.762000 ( ?0.762000) > ? 0.645000 ? 0.000000 ? 0.645000 ( ?0.644000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.469000) > ? 0.467000 ? 0.000000 ? 0.467000 ( ?0.467000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.469000) > ? 0.472000 ? 0.000000 ? 0.472000 ( ?0.472000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.469000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.469000) > ? 0.480000 ? 0.000000 ? 0.480000 ( ?0.480000) > ? 0.478000 ? 0.000000 ? 0.478000 ( ?0.479000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.474000) > ? 0.474000 ? 0.000000 ? 0.474000 ( ?0.474000) > ? 0.487000 ? 0.000000 ? 0.487000 ( ?0.487000) > ? 0.472000 ? 0.000000 ? 0.472000 ( ?0.472000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.469000) > ? 0.475000 ? 0.000000 ? 0.475000 ( ?0.475000) > ? 0.476000 ? 0.000000 ? 0.476000 ( ?0.476000) > ? 0.471000 ? 0.000000 ? 0.471000 ( ?0.471000) > ? 0.470000 ? 0.000000 ? 0.470000 ( ?0.470000) > ? 0.467000 ? 0.000000 ? 0.467000 ( ?0.467000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > ? 0.469000 ? 0.000000 ? 0.469000 ( ?0.468000) > ? 0.472000 ? 0.000000 ? 0.472000 ( ?0.472000) > ? 0.489000 ? 0.000000 ? 0.489000 ( ?0.489000) > ? 0.565000 ? 0.000000 ? 0.565000 ( ?0.566000) > ? 0.566000 ? 0.000000 ? 0.566000 ( ?0.566000) > ? 0.497000 ? 0.000000 ? 0.497000 ( ?0.497000) > ? 0.482000 ? 0.000000 ? 0.482000 ( ?0.481000) > ? 0.475000 ? 0.000000 ? 0.475000 ( ?0.475000) > ? 0.485000 ? 0.000000 ? 0.485000 ( ?0.485000) > ? 0.483000 ? 0.000000 ? 0.483000 ( ?0.483000) > ? 0.481000 ? 0.000000 ? 0.481000 ( ?0.481000) > ? 0.479000 ? 0.000000 ? 0.479000 ( ?0.479000) > ? 0.524000 ? 0.000000 ? 0.524000 ( ?0.523000) > ? 0.490000 ? 0.000000 ? 0.490000 ( ?0.490000) > ? 0.485000 ? 0.000000 ? 0.485000 ( ?0.485000) > ? 0.476000 ? 0.000000 ? 0.476000 ( ?0.477000) > ? 0.476000 ? 0.000000 ? 0.476000 ( ?0.476000) > ? 0.489000 ? 0.000000 ? 0.489000 ( ?0.489000) > ? 0.473000 ? 0.000000 ? 0.473000 ( ?0.473000) > MacBook-Pro-Ati:jruby-1.4.0 aszegedi$ > > On 2009.08.03., at 11:34, Christian Thalinger wrote: > >> Attila Szegedi wrote: >>> Strangely, trying to build using "gnumake" from davinci/patches/make >>> will fail; that's why I go back manually to bsd-port. Also, not doing >>> a ./clean.sh is a bad idea, as it did cause a build to fail in the >>> past. Anyway, the problem is likely that I failed to update the >>> davince/patches from Mercurial. Sorry about that - it was really >>> lame... I'm rebuilding now, will test with Charlie's nightly JRuby >>> when it's done, and if it works, will republish it. >> >> OK, let's see if that fixes the problem. >> >> -- Christian > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From Christian.Thalinger at Sun.COM Mon Aug 3 08:07:21 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 03 Aug 2009 17:07:21 +0200 Subject: Still crashity crashing In-Reply-To: References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A76AF0D.1000908@Sun.COM> <0E963D08-EE63-4EC8-9096-7A6A701826B2@gmail.com> Message-ID: <4A76FD29.2040903@Sun.COM> Charles Oliver Nutter wrote: > For some reason this is still crashing for me: > > ~/projects/jruby ? ../j2sdk-image/bin/java -version > openjdk version "1.7.0-internal" > OpenJDK Runtime Environment (build 1.7.0-internal-aszegedi_2009_08_03_11_04-b00) > OpenJDK Server VM (build 16.0-b06, mixed mode) > > ~/projects/jruby ? echo $JAVA_HOME > /Users/headius/projects/j2sdk-image/ > > ~/projects/jruby ? jruby -J-Djruby.compile.invokedynamic=true > -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x011a5aaa, pid=45880, tid=2953842688 > # > # JRE version: 7.0 > # Java VM: OpenJDK Client VM (16.0-b06 mixed mode bsd-x86 ) > # Problematic frame: > # V [libjvm.dylib+0x1a5aaa] > # > # An error report file with more information is saved as: > # /Users/headius/projects/jruby/hs_err_pid45880.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Abort trap > > ~/projects/jruby ? jruby -J-Djruby.compile.invokedynamic=true > -J-XX:+EnableInvokeDynamic --server bench/bench_fib_recursive.rb 100 > Illegal instruction Same for me. Yet I don't know where the difference is... -- Christian From forax at univ-mlv.fr Mon Aug 3 08:25:34 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 03 Aug 2009 17:25:34 +0200 Subject: Still crashity crashing In-Reply-To: References: <4A76F0F8.2010802@univ-mlv.fr> Message-ID: <4A77016E.1040406@univ-mlv.fr> Le 03/08/2009 16:11, Charles Oliver Nutter a ?crit : > On Mon, Aug 3, 2009 at 9:15 AM, R?mi Forax wrote: > >> Hi Charles, >> >> I try to compile jruby (1.4.0dev) >> and I go an error saying that ivy/build.xml doesn't exists. >> >> So I chnage the line 49 of the build.xml to optionally >> to the import file: >> sometimes I you read my mail before send it. >> >> >> and It seems to work. >> > > Odd...ivy/build.xml should be there. Anyway, let me know if you have > any other problems. > > Hi Charlie, I manage to be able to use the backport with you're code but you really a rogue, you load your classes with the bootstrap classpath (I suppose you bypass the verifier to start faster) and guess what, by default, the backport doesn't take care about classes loaded by the boot classpath. I think it's time to re-consider the default behaviour of the backport agent :) But there is something more problematic, the backport optimizer doesn't play well with your compiler :( time bin/jruby -J-Djruby.jit.logging.verbose=true bench/bench_fib_recursive.rb 100 real 0m38.457s user 0m38.115s sys 0m0.164s time bin/jruby -J-javaagent:../indy-backport/lib/jsr292-backport.jar -J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar -J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true bench/bench_fib_recursive.rb 100 real 4m51.625s user 4m45.040s sys 0m4.640s Could you explain how the compiler works and what are these classes ? agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_0$RUBY$__block__xx1 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_1$RUBY$__block__xx1 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_2$RUBY$__block__xx1 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_3$RUBY$__block__xx1 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_4$RUBY$__block__xx1 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_5$RUBY$__block__xx1 agent ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_6$RUBY$__block__xx1 > - Charlie > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090803/7c045d69/attachment.html From szegedia at gmail.com Mon Aug 3 15:10:24 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 4 Aug 2009 00:10:24 +0200 Subject: Still crashity crashing In-Reply-To: <4A76FD29.2040903@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A76AF0D.1000908@Sun.COM> <0E963D08-EE63-4EC8-9096-7A6A701826B2@gmail.com> <4A76FD29.2040903@Sun.COM> Message-ID: <260FCE54-093A-4938-82DA-CADF87DA5F86@gmail.com> Well, I'm out of ideas. All I can say is, it works for me? guess you'll have to build it yourself. Attila. Sent from my ${mobile_handset_device} On 2009.08.03., at 17:07, Christian Thalinger wrote: > Charles Oliver Nutter wrote: >> For some reason this is still crashing for me: >> >> ~/projects/jruby ? ../j2sdk-image/bin/java -version >> openjdk version "1.7.0-internal" >> OpenJDK Runtime Environment (build 1.7.0-internal- >> aszegedi_2009_08_03_11_04-b00) >> OpenJDK Server VM (build 16.0-b06, mixed mode) >> >> ~/projects/jruby ? echo $JAVA_HOME >> /Users/headius/projects/j2sdk-image/ >> >> ~/projects/jruby ? jruby -J-Djruby.compile.invokedynamic=true >> -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGBUS (0xa) at pc=0x011a5aaa, pid=45880, tid=2953842688 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Client VM (16.0-b06 mixed mode bsd-x86 ) >> # Problematic frame: >> # V [libjvm.dylib+0x1a5aaa] >> # >> # An error report file with more information is saved as: >> # /Users/headius/projects/jruby/hs_err_pid45880.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> Abort trap >> >> ~/projects/jruby ? jruby -J-Djruby.compile.invokedynamic=true >> -J-XX:+EnableInvokeDynamic --server bench/bench_fib_recursive.rb 100 >> Illegal instruction > > Same for me. Yet I don't know where the difference is... > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From Christian.Thalinger at Sun.COM Tue Aug 4 04:04:23 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 Aug 2009 13:04:23 +0200 Subject: Still crashity crashing In-Reply-To: <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> Message-ID: <4A7815B7.6020209@Sun.COM> Attila Szegedi wrote: > Other than that, my build process is as this (using an existing local > Hg repository): > > 1. back out current patches from bsd-port using "hg qselect --pop" on > jdk, hotspot, and langtools -- this is necessary to make sure fpull > and fupdate don't skip them > 2. hg fpull; hg fupdate in bsd-port > 3. hg fpull; hg fupdate in davinci/patches > 4. apply patches: cd davinci; (cd patches/make; gnumake setup); (cd > patches/make; gnumake patch) > 5. build: cd bsd-port; ./clean.sh; ./build.sh I just tried to build it with a make in patches/make/ but that does not work. Normally I build in sources/ with a simple make (after setting up the patches). Unfortunately the HotSpot Queens test fails with: cd bsd_i486_compiler2/product && ./test_gamma openjdk full version "1.6.0-internal-landonf_17_may_2009_13_58-b00" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object openjdk version "1.6.0-internal" OpenJDK Runtime Environment (build 1.6.0-internal-landonf_17_may_2009_13_58-b00) OpenJDK Server VM (build 16.0-b06, mixed mode) Exception in thread "main" java.lang.NoClassDefFoundError: Queens Caused by: java.lang.ClassNotFoundException: Queens at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) This happens because the bootstrap javac picks up the newly built libjvm.dylib and that does not work. A simple fix for this is to add a "exit 0", before javac is called, into these files: build/bsd-i586/hotspot/outputdir/bsd_i486_compiler2/product/test_gamma build/bsd-i586/hotspot/outputdir/bsd_i486_compiler1/product/test_gamma Then the build succeeds. Still building the newly checked out version... -- Christian From Christian.Thalinger at Sun.COM Tue Aug 4 04:35:44 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 Aug 2009 13:35:44 +0200 Subject: Still crashity crashing In-Reply-To: <4A7815B7.6020209@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> Message-ID: <4A781D10.1080605@Sun.COM> Christian Thalinger wrote: > Still building the newly checked out version... Finally I can reproduce the crashes. Either it's related to debug vs. product build or the additional patches applied. Still investigating... -- Christian From Christian.Thalinger at Sun.COM Tue Aug 4 05:03:49 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 Aug 2009 14:03:49 +0200 Subject: Still crashity crashing In-Reply-To: <4A781D10.1080605@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> Message-ID: <4A7823A5.2080707@Sun.COM> Christian Thalinger wrote: > Christian Thalinger wrote: >> Still building the newly checked out version... > > Finally I can reproduce the crashes. Either it's related to debug vs. > product build or the additional patches applied. Still investigating... Oh no! It's so obvious :-/ indy.compiler.patch is not enabled for default builds and so the VM crashes when the compiler kicks in. I just pushed a changeset[1] that enables the patch. Please update your mlvm repository and build again. [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2c1323e05f9a -- Christian From Christian.Thalinger at Sun.COM Tue Aug 4 05:04:56 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 04 Aug 2009 12:04:56 +0000 Subject: hg: mlvm/mlvm/hotspot: series: Enable indy.compiler.patch for default builds. Message-ID: <20090804120457.4B38DE090@hg.openjdk.java.net> Changeset: 2c1323e05f9a Author: twisti Date: 2009-08-04 14:00 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2c1323e05f9a series: Enable indy.compiler.patch for default builds. ! series From Christian.Thalinger at Sun.COM Tue Aug 4 05:16:17 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 Aug 2009 14:16:17 +0200 Subject: Still crashity crashing In-Reply-To: <4A7823A5.2080707@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> Message-ID: <4A782691.4050605@Sun.COM> Christian Thalinger wrote: > Christian Thalinger wrote: >> Christian Thalinger wrote: >>> Still building the newly checked out version... >> Finally I can reproduce the crashes. Either it's related to debug vs. >> product build or the additional patches applied. Still investigating... > > Oh no! It's so obvious :-/ indy.compiler.patch is not enabled for > default builds and so the VM crashes when the compiler kicks in. > > I just pushed a changeset[1] that enables the patch. Please update your > mlvm repository and build again. With a debug build I get this assert: $ bin/jruby --server -J-Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 VM option '+EnableInvokeDynamic' 5.950000 0.000000 5.950000 ( 5.562000) # Found non oop pointer. Dumping state at failure ------ OopMap{ebp=Oop [80]=Oop [84]=Oop [48]=Oop [52]=Oop off=680}bci: 106 Compiled frame (sp=0xb00fe7e0 unextended sp=0xb00fe810, fp=0xb00fe810, pc=0x0289da08) 116 nmethod (2) bench.bench_fib_recursiveInvokermethod__0$RUBY$fib_rubyFixed1::call (15 bytes) 116 nmethod (2) bench.bench_fib_recursiveInvokermethod__0$RUBY$fib_rubyFixed1::call (15 bytes) Register map ebp [0xb00fe7d8] = 0xb00fe810 ------ ebp=Oop register r ebploc = 0xb00fe7d8 *loc = 0xb00fe810 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/oopMap.cpp:408 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/twisti/mlvm/tmp/hotspot/src/share/vm/compiler/oopMap.cpp:408), pid=6427, tid=2954375168 # Error: assert(Universe::heap()->is_in_or_null(*loc),"found non oop pointer") -- Christian From szegedia at gmail.com Tue Aug 4 10:52:36 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 4 Aug 2009 19:52:36 +0200 Subject: Still crashity crashing In-Reply-To: <4A7823A5.2080707@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> Message-ID: <951E4DA2-5919-4659-9EA4-3DA991926498@gmail.com> Hm... Which doesn't really explain why did the fib benchmark run for me with my last build then, does it? Puzzling... Attila. On 2009.08.04., at 14:03, Christian Thalinger wrote: > Christian Thalinger wrote: >> Christian Thalinger wrote: >>> Still building the newly checked out version... >> >> Finally I can reproduce the crashes. Either it's related to debug >> vs. >> product build or the additional patches applied. Still >> investigating... > > Oh no! It's so obvious :-/ indy.compiler.patch is not enabled for > default builds and so the VM crashes when the compiler kicks in. > > I just pushed a changeset[1] that enables the patch. Please update > your > mlvm repository and build again. > > [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2c1323e05f9a > > -- Christian From headius at headius.com Tue Aug 4 11:01:19 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 13:01:19 -0500 Subject: Still crashity crashing In-Reply-To: <4A77016E.1040406@univ-mlv.fr> References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> Message-ID: On Mon, Aug 3, 2009 at 10:25 AM, R?mi Forax wrote: > Hi Charlie, > I manage to be able to use the backport with you're code > but you really a rogue, you load your classes with the bootstrap classpath > (I suppose you bypass the verifier to start faster) > and guess what, by default, the backport doesn't take care about > classes loaded by the boot classpath. > > I think it's time to re-consider the default behaviour of the backport agent > :) Yeah, perhaps...but it's also perhaps reasonable that when people want the backport indy to work they would take the hit for startup. What other behavior are you considering? Offline bytecode manipulation? > But there is something more problematic, > the backport optimizer doesn't play well with your compiler :( > > time bin/jruby -J-Djruby.jit.logging.verbose=true > bench/bench_fib_recursive.rb 100 > real??? 0m38.457s > user??? 0m38.115s > sys??? 0m0.164s > > time bin/jruby -J-javaagent:../indy-backport/lib/jsr292-backport.jar > -J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar > -J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true > bench/bench_fib_recursive.rb 100 > real??? 4m51.625s > user??? 4m45.040s > sys??? 0m4.640s Yes, that's a pretty poor result :( Did you try moving JRuby to non-bootclasspath? > Could you explain how the compiler works and what are these classes? ? > > agent > ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994 > agent This is a jitted method body. ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_0$RUBY$__block__xx1 > agent These are my generated method handles to closures. I will hopefully have some time soon to experiment with the backport myself... - Charlie From headius at headius.com Tue Aug 4 11:02:23 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 13:02:23 -0500 Subject: Still crashity crashing In-Reply-To: <4A782691.4050605@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> Message-ID: It's great that you got it running...I will try with the updated -testing on the compiler patch and see what I can see here. Attila: Can you show the command line you're using to run fib in JRuby? And can you try running JRuby with --bytecode and see if it's actually emitting INVOKEDYNAMIC? On Tue, Aug 4, 2009 at 7:16 AM, Christian Thalinger wrote: > Christian Thalinger wrote: >> Christian Thalinger wrote: >>> Christian Thalinger wrote: >>>> Still building the newly checked out version... >>> Finally I can reproduce the crashes. ?Either it's related to debug vs. >>> product build or the additional patches applied. ?Still investigating... >> >> Oh no! ?It's so obvious :-/ ?indy.compiler.patch is not enabled for >> default builds and so the VM crashes when the compiler kicks in. >> >> I just pushed a changeset[1] that enables the patch. ?Please update your >> mlvm repository and build again. > > With a debug build I get this assert: > > $ bin/jruby --server -J-Djruby.compile.invokedynamic=true > -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 > VM option '+EnableInvokeDynamic' > ?5.950000 ? 0.000000 ? 5.950000 ( ?5.562000) > # Found non oop pointer. ?Dumping state at failure > ------ > OopMap{ebp=Oop [80]=Oop [84]=Oop [48]=Oop [52]=Oop off=680}bci: 106 > Compiled frame (sp=0xb00fe7e0 unextended sp=0xb00fe810, fp=0xb00fe810, > pc=0x0289da08) > ? ? 116 ? nmethod (2) > bench.bench_fib_recursiveInvokermethod__0$RUBY$fib_rubyFixed1::call (15 > bytes) > ? ? 116 ? nmethod (2) > bench.bench_fib_recursiveInvokermethod__0$RUBY$fib_rubyFixed1::call (15 > bytes) > Register map > ebp [0xb00fe7d8] = 0xb00fe810 > ------ > ebp=Oop register r > ebploc = 0xb00fe7d8 *loc = 0xb00fe810 > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: ?SuppressErrorAt=/oopMap.cpp:408 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?Internal Error > (/Users/twisti/mlvm/tmp/hotspot/src/share/vm/compiler/oopMap.cpp:408), > pid=6427, tid=2954375168 > # ?Error: assert(Universe::heap()->is_in_or_null(*loc),"found non oop > pointer") > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From szegedia at gmail.com Tue Aug 4 11:56:51 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 4 Aug 2009 20:56:51 +0200 Subject: Still crashity crashing In-Reply-To: References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> Message-ID: <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> On 2009.08.04., at 20:02, Charles Oliver Nutter wrote: > It's great that you got it running...I will try with the updated > -testing on the compiler patch and see what I can see here. > > Attila: Can you show the command line you're using to run fib in > JRuby? Wait, I got it - I downloaded the ordinary (not dev) 1.4.0 tarball. Using --bytecode tipped me off, since it wasn't emitting invokedynamic. With the dev 1.4.0 JRuby I too get a crash: # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x011a5aaa, pid=39510, tid=2953842688 # # JRE version: 7.0 # Java VM: OpenJDK Client VM (16.0-b06 mixed mode bsd-x86 ) # Problematic frame: # V [libjvm.dylib+0x1a5aaa] # # An error report file with more information is saved as: # /Users/aszegedi/Downloads/jruby-1.4.0dev/hs_err_pid39510.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Abort trap Okay, so then back to rebuilding the MLVM once more :-) Attila. From szegedia at gmail.com Tue Aug 4 14:17:41 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 4 Aug 2009 23:17:41 +0200 Subject: Still crashity crashing In-Reply-To: <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> Message-ID: <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> Okay, uploading a new build. URL is but as usual give it two hours to actually get uploaded... I can now confirm that it indeed does work with jruby-1.4.0dev that indeed emits invokedynamic. The only catch is, it's very slow with invokedynamic, something that Christian also mentioned. MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ bench_fib_recursive.rb 15 2.993000 0.000000 2.993000 ( 2.915000) 2.720000 0.000000 2.720000 ( 2.720000) 2.773000 0.000000 2.773000 ( 2.773000) 2.712000 0.000000 2.712000 ( 2.712000) 3.057000 0.000000 3.057000 ( 3.057000) 3.183000 0.000000 3.183000 ( 3.184000) 3.167000 0.000000 3.167000 ( 3.167000) 3.145000 0.000000 3.145000 ( 3.145000) 3.249000 0.000000 3.249000 ( 3.249000) 3.160000 0.000000 3.160000 ( 3.160000) 3.104000 0.000000 3.104000 ( 3.104000) 3.152000 0.000000 3.152000 ( 3.153000) 3.172000 0.000000 3.172000 ( 3.171000) 3.111000 0.000000 3.111000 ( 3.111000) 3.201000 0.000000 3.201000 ( 3.201000) MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ bench_fib_recursive.rb 15 0.523000 0.000000 0.523000 ( 0.481000) 0.292000 0.000000 0.292000 ( 0.291000) 0.279000 0.000000 0.279000 ( 0.278000) 0.283000 0.000000 0.283000 ( 0.283000) 0.284000 0.000000 0.284000 ( 0.284000) 0.292000 0.000000 0.292000 ( 0.292000) 0.289000 0.000000 0.289000 ( 0.289000) 0.286000 0.000000 0.286000 ( 0.287000) 0.285000 0.000000 0.285000 ( 0.285000) 0.285000 0.000000 0.285000 ( 0.285000) 0.289000 0.000000 0.289000 ( 0.290000) 0.282000 0.000000 0.282000 ( 0.282000) 0.290000 0.000000 0.290000 ( 0.290000) 0.293000 0.000000 0.293000 ( 0.293000) 0.285000 0.000000 0.285000 ( 0.284000) Attila. On 2009.08.04., at 20:56, Attila Szegedi wrote: > On 2009.08.04., at 20:02, Charles Oliver Nutter wrote: > >> It's great that you got it running...I will try with the updated >> -testing on the compiler patch and see what I can see here. >> >> Attila: Can you show the command line you're using to run fib in >> JRuby? > > Wait, I got it - I downloaded the ordinary (not dev) 1.4.0 tarball. > Using --bytecode tipped me off, since it wasn't emitting > invokedynamic. With the dev 1.4.0 JRuby I too get a crash: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x011a5aaa, pid=39510, tid=2953842688 > # > # JRE version: 7.0 > # Java VM: OpenJDK Client VM (16.0-b06 mixed mode bsd-x86 ) > # Problematic frame: > # V [libjvm.dylib+0x1a5aaa] > # > # An error report file with more information is saved as: > # /Users/aszegedi/Downloads/jruby-1.4.0dev/hs_err_pid39510.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Abort trap > > Okay, so then back to rebuilding the MLVM once more :-) > > Attila. From headius at headius.com Tue Aug 4 17:58:52 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 19:58:52 -0500 Subject: Still crashity crashing In-Reply-To: <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> Message-ID: On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi wrote: > I can now confirm that it indeed does work with jruby-1.4.0dev that > indeed emits invokedynamic. > > The only catch is, it's very slow with invokedynamic, something that > Christian also mentioned. The fact that these numbers are so bad and even degrade shows me that although it's compiling indy, it's not eliminating the handles (which is true, the inlining and handle-walking stuff is not ready yet). So it's got many layers of polymorphic calls, probably some argument boxing and unboxing, and basically a ton more overhead than our heavily tuned non-indy call path. I'm confident in the Hotspot guys :) Just wanted to make sure anyone watching didn't think this was the best it would get... > MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- > Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ > bench_fib_recursive.rb 15 > ? 2.993000 ? 0.000000 ? 2.993000 ( ?2.915000) > ? 2.720000 ? 0.000000 ? 2.720000 ( ?2.720000) > ? 2.773000 ? 0.000000 ? 2.773000 ( ?2.773000) > ? 2.712000 ? 0.000000 ? 2.712000 ( ?2.712000) > ? 3.057000 ? 0.000000 ? 3.057000 ( ?3.057000) > ? 3.183000 ? 0.000000 ? 3.183000 ( ?3.184000) > ? 3.167000 ? 0.000000 ? 3.167000 ( ?3.167000) > ? 3.145000 ? 0.000000 ? 3.145000 ( ?3.145000) > ? 3.249000 ? 0.000000 ? 3.249000 ( ?3.249000) > ? 3.160000 ? 0.000000 ? 3.160000 ( ?3.160000) > ? 3.104000 ? 0.000000 ? 3.104000 ( ?3.104000) > ? 3.152000 ? 0.000000 ? 3.152000 ( ?3.153000) > ? 3.172000 ? 0.000000 ? 3.172000 ( ?3.171000) > ? 3.111000 ? 0.000000 ? 3.111000 ( ?3.111000) > ? 3.201000 ? 0.000000 ? 3.201000 ( ?3.201000) > MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ > bench_fib_recursive.rb 15 > ? 0.523000 ? 0.000000 ? 0.523000 ( ?0.481000) > ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.291000) > ? 0.279000 ? 0.000000 ? 0.279000 ( ?0.278000) > ? 0.283000 ? 0.000000 ? 0.283000 ( ?0.283000) > ? 0.284000 ? 0.000000 ? 0.284000 ( ?0.284000) > ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.292000) > ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.289000) > ? 0.286000 ? 0.000000 ? 0.286000 ( ?0.287000) > ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) > ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) > ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.290000) > ? 0.282000 ? 0.000000 ? 0.282000 ( ?0.282000) > ? 0.290000 ? 0.000000 ? 0.290000 ( ?0.290000) > ? 0.293000 ? 0.000000 ? 0.293000 ( ?0.293000) > ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.284000) From forax at univ-mlv.fr Tue Aug 4 18:16:46 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 05 Aug 2009 03:16:46 +0200 Subject: Still crashity crashing In-Reply-To: References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> Message-ID: <4A78DD7E.4010806@univ-mlv.fr> Le 04/08/2009 20:01, Charles Oliver Nutter a ?crit : > On Mon, Aug 3, 2009 at 10:25 AM, R?mi Forax wrote: > >> Hi Charlie, >> I manage to be able to use the backport with you're code >> but you really a rogue, you load your classes with the bootstrap classpath >> (I suppose you bypass the verifier to start faster) >> and guess what, by default, the backport doesn't take care about >> classes loaded by the boot classpath. >> >> I think it's time to re-consider the default behaviour of the backport agent >> :) >> > > Yeah, perhaps...but it's also perhaps reasonable that when people want > the backport indy to work they would take the hit for startup. What > other behavior are you considering? - remove the assertion that invokedynamic can only appear in class 1.7 compatible (version 51.0) class, currently your classes are not compiled with version 51. BTW, John, It should not work with the JSR 292 RI too ? - optimize concurrently with the running program (hotspot do that, not the backport) - change constant values triggering the optimizer - change the algorithm inserting living objects in the bytecode: the current algorithm is pretty basic. > Offline bytecode manipulation? > Old dream. I don't know how to optimize invokedynamic without having the target method handle which is a runtime value. Nevertheless, the backport offers an ASM adapter that you can append to your generator to avoid bytecode instrumentation (and the agent), I will investigate that. > >> But there is something more problematic, >> the backport optimizer doesn't play well with your compiler :( >> >> time bin/jruby -J-Djruby.jit.logging.verbose=true >> bench/bench_fib_recursive.rb 100 >> real 0m38.457s >> user 0m38.115s >> sys 0m0.164s >> >> time bin/jruby -J-javaagent:../indy-backport/lib/jsr292-backport.jar >> -J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar >> -J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true >> bench/bench_fib_recursive.rb 100 >> real 4m51.625s >> user 4m45.040s >> sys 0m4.640s >> > > Yes, that's a pretty poor result :( Did you try moving JRuby to > non-bootclasspath? > I don't think, it's the real problem, it just take me time to figure out why jruby was not able to find the backport support classes. The main problem is that the backport is not able to optimize the produced method handle tree. One problem is that the method InvokeDynamicsupport.pollAndGetClass is private but exported by PGC. The backport has the same contraint that any Java code, so it is not able to optimize any method adapter tree that contains PGC. I will investigate other problems later, it's 3am now :( > >> Could you explain how the compiler works and what are these classes ? >> >> agent >> ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994 >> agent >> > > This is a jitted method body. > > ruby/jit/ruby/home/forax/java/workspace/jruby_minus_1_dot_4_dot_0dev/lib/ruby/$1_dot_8/benchmark/format7681932_5430994BlockCallback$block_0$RUBY$__block__xx1 > >> agent >> > > These are my generated method handles to closures. > > I will hopefully have some time soon to experiment with the backport myself... > > - Charlie > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090805/4ff18231/attachment.html From headius at headius.com Tue Aug 4 18:07:44 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 20:07:44 -0500 Subject: Still crashity crashing In-Reply-To: References: <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> Message-ID: I can't seem to catch a break. My local build and Attila's build still both crash for me. There's got to be something about my environment that's different, eh? As before, interpreter runs fine. Anything that runs long enough to jit seems to crash. I've attached the latest log. On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver Nutter wrote: > On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi wrote: >> I can now confirm that it indeed does work with jruby-1.4.0dev that >> indeed emits invokedynamic. >> >> The only catch is, it's very slow with invokedynamic, something that >> Christian also mentioned. > > The fact that these numbers are so bad and even degrade shows me that > although it's compiling indy, it's not eliminating the handles (which > is true, the inlining and handle-walking stuff is not ready yet). So > it's got many layers of polymorphic calls, probably some argument > boxing and unboxing, and basically a ton more overhead than our > heavily tuned non-indy call path. I'm confident in the Hotspot guys :) > > Just wanted to make sure anyone watching didn't think this was the > best it would get... > >> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >> bench_fib_recursive.rb 15 >> ? 2.993000 ? 0.000000 ? 2.993000 ( ?2.915000) >> ? 2.720000 ? 0.000000 ? 2.720000 ( ?2.720000) >> ? 2.773000 ? 0.000000 ? 2.773000 ( ?2.773000) >> ? 2.712000 ? 0.000000 ? 2.712000 ( ?2.712000) >> ? 3.057000 ? 0.000000 ? 3.057000 ( ?3.057000) >> ? 3.183000 ? 0.000000 ? 3.183000 ( ?3.184000) >> ? 3.167000 ? 0.000000 ? 3.167000 ( ?3.167000) >> ? 3.145000 ? 0.000000 ? 3.145000 ( ?3.145000) >> ? 3.249000 ? 0.000000 ? 3.249000 ( ?3.249000) >> ? 3.160000 ? 0.000000 ? 3.160000 ( ?3.160000) >> ? 3.104000 ? 0.000000 ? 3.104000 ( ?3.104000) >> ? 3.152000 ? 0.000000 ? 3.152000 ( ?3.153000) >> ? 3.172000 ? 0.000000 ? 3.172000 ( ?3.171000) >> ? 3.111000 ? 0.000000 ? 3.111000 ( ?3.111000) >> ? 3.201000 ? 0.000000 ? 3.201000 ( ?3.201000) >> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >> bench_fib_recursive.rb 15 >> ? 0.523000 ? 0.000000 ? 0.523000 ( ?0.481000) >> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.291000) >> ? 0.279000 ? 0.000000 ? 0.279000 ( ?0.278000) >> ? 0.283000 ? 0.000000 ? 0.283000 ( ?0.283000) >> ? 0.284000 ? 0.000000 ? 0.284000 ( ?0.284000) >> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.292000) >> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.289000) >> ? 0.286000 ? 0.000000 ? 0.286000 ( ?0.287000) >> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.290000) >> ? 0.282000 ? 0.000000 ? 0.282000 ( ?0.282000) >> ? 0.290000 ? 0.000000 ? 0.290000 ( ?0.290000) >> ? 0.293000 ? 0.000000 ? 0.293000 ( ?0.293000) >> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.284000) > -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid42686.log Type: application/octet-stream Size: 7412 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090804/5146577f/attachment.obj From headius at headius.com Tue Aug 4 18:17:15 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 20:17:15 -0500 Subject: Still crashity crashing In-Reply-To: <4A78DD7E.4010806@univ-mlv.fr> References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> Message-ID: On Tue, Aug 4, 2009 at 8:16 PM, R?mi Forax wrote: > - remove the assertion that invokedynamic can only appear > ? in class 1.7 compatible (version 51.0) class, > ? currently your classes are not compiled with version 51. > ? BTW, John, It should not work with the JSR 292 RI too ? Yes, ASM allows us to emit invokedynamic, and we always default our generated bytecode to whatever version of JVM we're running on, so it's possible we'll get a combination of <51 and indy if someone turns that flag on for a lower JVM (as in this case). We could certainly change that on our end too. > - optimize concurrently with the running program > ? (hotspot do that, not the backport) In most cases we run code immediately after generating it, so we're not offloading compilation either. We'd probably want to consider doing that so that we wouldn't now have the additional cost of waiting for the backport to run. > The main problem is that the backport is not able to optimize > the produced method handle tree. > > One problem is that the method InvokeDynamicsupport.pollAndGetClass is > private > but exported by PGC. The backport has the same contraint that > any Java code, so it is not able to optimize any method adapter tree > that contains PGC. Ahh...well I could certainly make it public if it would help the optimization. I understand that this is a natural limitation of the backport. - Charlie From Y.S.Ramakrishna at Sun.COM Tue Aug 4 18:56:32 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 04 Aug 2009 18:56:32 -0700 Subject: Still crashity crashing In-Reply-To: References: <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> Message-ID: <4A78E6D0.9090408@Sun.COM> The crash is in GC. Together with yr conjecture that the crash happens after a while when you expect the method to have been jitted, this might imply that the jit is not correctly conveying to GC where the references in jitted frames are or is not marking cards for the generational collector correctly, or GC isn't looking at all the slots it should be looking at or .... (But that is a long assumption.) The funny part about "running long enough" is that the hs_err log says the crash occurred after 0 seconds, so the VM is probably not correctly printing the time it's been running. I'd suggest running the JVM with the options -XX:+VerifyBeforeGC and -XX:+VerifyAfterGC to perhaps catch the problem sooner or get closer to the root cause. If you run with the additional JVM option -XX:+ShowMessageBoxOnError you might be able to pstack the process and get some info. (Or use the hs_err script to decode the stack trace from the hs_err log.) -- ramki On 08/04/09 18:07, Charles Oliver Nutter wrote: > I can't seem to catch a break. My local build and Attila's build still > both crash for me. There's got to be something about my environment > that's different, eh? > > As before, interpreter runs fine. Anything that runs long enough to > jit seems to crash. I've attached the latest log. > > On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver > Nutter wrote: >> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi wrote: >>> I can now confirm that it indeed does work with jruby-1.4.0dev that >>> indeed emits invokedynamic. >>> >>> The only catch is, it's very slow with invokedynamic, something that >>> Christian also mentioned. >> The fact that these numbers are so bad and even degrade shows me that >> although it's compiling indy, it's not eliminating the handles (which >> is true, the inlining and handle-walking stuff is not ready yet). So >> it's got many layers of polymorphic calls, probably some argument >> boxing and unboxing, and basically a ton more overhead than our >> heavily tuned non-indy call path. I'm confident in the Hotspot guys :) >> >> Just wanted to make sure anyone watching didn't think this was the >> best it would get... >> >>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >>> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >>> bench_fib_recursive.rb 15 >>> 2.993000 0.000000 2.993000 ( 2.915000) >>> 2.720000 0.000000 2.720000 ( 2.720000) >>> 2.773000 0.000000 2.773000 ( 2.773000) >>> 2.712000 0.000000 2.712000 ( 2.712000) >>> 3.057000 0.000000 3.057000 ( 3.057000) >>> 3.183000 0.000000 3.183000 ( 3.184000) >>> 3.167000 0.000000 3.167000 ( 3.167000) >>> 3.145000 0.000000 3.145000 ( 3.145000) >>> 3.249000 0.000000 3.249000 ( 3.249000) >>> 3.160000 0.000000 3.160000 ( 3.160000) >>> 3.104000 0.000000 3.104000 ( 3.104000) >>> 3.152000 0.000000 3.152000 ( 3.153000) >>> 3.172000 0.000000 3.172000 ( 3.171000) >>> 3.111000 0.000000 3.111000 ( 3.111000) >>> 3.201000 0.000000 3.201000 ( 3.201000) >>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >>> bench_fib_recursive.rb 15 >>> 0.523000 0.000000 0.523000 ( 0.481000) >>> 0.292000 0.000000 0.292000 ( 0.291000) >>> 0.279000 0.000000 0.279000 ( 0.278000) >>> 0.283000 0.000000 0.283000 ( 0.283000) >>> 0.284000 0.000000 0.284000 ( 0.284000) >>> 0.292000 0.000000 0.292000 ( 0.292000) >>> 0.289000 0.000000 0.289000 ( 0.289000) >>> 0.286000 0.000000 0.286000 ( 0.287000) >>> 0.285000 0.000000 0.285000 ( 0.285000) >>> 0.285000 0.000000 0.285000 ( 0.285000) >>> 0.289000 0.000000 0.289000 ( 0.290000) >>> 0.282000 0.000000 0.282000 ( 0.282000) >>> 0.290000 0.000000 0.290000 ( 0.290000) >>> 0.293000 0.000000 0.293000 ( 0.293000) >>> 0.285000 0.000000 0.285000 ( 0.284000) >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From headius at headius.com Tue Aug 4 20:24:49 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 22:24:49 -0500 Subject: Still crashity crashing In-Reply-To: <4A78E6D0.9090408@Sun.COM> References: <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> <4A78E6D0.9090408@Sun.COM> Message-ID: Here's the output with the verify flags on: ~/projects/jruby ? jruby -J-XX:+UnlockDiagnosticVMOptions -J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC -J-Djruby.compile.invokedynamic -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 [Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyAfterGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyAfterGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyAfterGC:[Verifying threads permgen tenured generation def new generation remset ref_proc syms strs zone dict hand C-heap ] VerifyBeforeGC:[Verifying threads # The hs_err file is attached. I do not have pstack on OS X...do you know what the equivalent would be? On Tue, Aug 4, 2009 at 8:56 PM, wrote: > The crash is in GC. Together with yr conjecture that the crash happens > after a while when you expect the method to have been jitted, this might > imply that the jit is not correctly conveying to GC where the > references in jitted frames are or is not marking cards for the > generational collector correctly, or GC isn't looking at all the > slots it should be looking at or .... (But that is a long assumption.) > The funny part about "running long enough" is that the hs_err log > says the crash occurred after 0 seconds, so the VM is probably > not correctly printing the time it's been running. > > I'd suggest running the JVM with the options -XX:+VerifyBeforeGC and -XX:+VerifyAfterGC > to perhaps catch the problem sooner or get closer to the root cause. > If you run with the additional JVM option -XX:+ShowMessageBoxOnError > you might be able to pstack the process and get some info. (Or > use the hs_err script to decode the stack trace from the hs_err log.) > > -- ramki > > On 08/04/09 18:07, Charles Oliver Nutter wrote: >> I can't seem to catch a break. My local build and Attila's build still >> both crash for me. There's got to be something about my environment >> that's different, eh? >> >> As before, interpreter runs fine. Anything that runs long enough to >> jit seems to crash. I've attached the latest log. >> >> On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver >> Nutter wrote: >>> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi wrote: >>>> I can now confirm that it indeed does work with jruby-1.4.0dev that >>>> indeed emits invokedynamic. >>>> >>>> The only catch is, it's very slow with invokedynamic, something that >>>> Christian also mentioned. >>> The fact that these numbers are so bad and even degrade shows me that >>> although it's compiling indy, it's not eliminating the handles (which >>> is true, the inlining and handle-walking stuff is not ready yet). So >>> it's got many layers of polymorphic calls, probably some argument >>> boxing and unboxing, and basically a ton more overhead than our >>> heavily tuned non-indy call path. I'm confident in the Hotspot guys :) >>> >>> Just wanted to make sure anyone watching didn't think this was the >>> best it would get... >>> >>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >>>> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >>>> bench_fib_recursive.rb 15 >>>> ? 2.993000 ? 0.000000 ? 2.993000 ( ?2.915000) >>>> ? 2.720000 ? 0.000000 ? 2.720000 ( ?2.720000) >>>> ? 2.773000 ? 0.000000 ? 2.773000 ( ?2.773000) >>>> ? 2.712000 ? 0.000000 ? 2.712000 ( ?2.712000) >>>> ? 3.057000 ? 0.000000 ? 3.057000 ( ?3.057000) >>>> ? 3.183000 ? 0.000000 ? 3.183000 ( ?3.184000) >>>> ? 3.167000 ? 0.000000 ? 3.167000 ( ?3.167000) >>>> ? 3.145000 ? 0.000000 ? 3.145000 ( ?3.145000) >>>> ? 3.249000 ? 0.000000 ? 3.249000 ( ?3.249000) >>>> ? 3.160000 ? 0.000000 ? 3.160000 ( ?3.160000) >>>> ? 3.104000 ? 0.000000 ? 3.104000 ( ?3.104000) >>>> ? 3.152000 ? 0.000000 ? 3.152000 ( ?3.153000) >>>> ? 3.172000 ? 0.000000 ? 3.172000 ( ?3.171000) >>>> ? 3.111000 ? 0.000000 ? 3.111000 ( ?3.111000) >>>> ? 3.201000 ? 0.000000 ? 3.201000 ( ?3.201000) >>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >>>> bench_fib_recursive.rb 15 >>>> ? 0.523000 ? 0.000000 ? 0.523000 ( ?0.481000) >>>> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.291000) >>>> ? 0.279000 ? 0.000000 ? 0.279000 ( ?0.278000) >>>> ? 0.283000 ? 0.000000 ? 0.283000 ( ?0.283000) >>>> ? 0.284000 ? 0.000000 ? 0.284000 ( ?0.284000) >>>> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.292000) >>>> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.289000) >>>> ? 0.286000 ? 0.000000 ? 0.286000 ( ?0.287000) >>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >>>> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.290000) >>>> ? 0.282000 ? 0.000000 ? 0.282000 ( ?0.282000) >>>> ? 0.290000 ? 0.000000 ? 0.290000 ( ?0.290000) >>>> ? 0.293000 ? 0.000000 ? 0.293000 ( ?0.293000) >>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.284000) >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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: hs_err_pid43068.log Type: application/octet-stream Size: 7514 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090804/b28b9fd0/attachment.obj From headius at headius.com Tue Aug 4 20:28:32 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 22:28:32 -0500 Subject: Still crashity crashing In-Reply-To: References: <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> <4A78E6D0.9090408@Sun.COM> Message-ID: The ShowMessageBox option also gave me the option of launching gdb. I'm not a gdb expert, but "bt" produced this: (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96f04398 in pthread_join$UNIX2003 () #2 0x0000668b in ContinueInNewThread0 () #3 0x0000440e in JLI_Launch () #4 0x0000d388 in main () Trying now to see if I can view stacks for other threads or something. On Tue, Aug 4, 2009 at 10:24 PM, Charles Oliver Nutter wrote: > Here's the output with the verify flags on: > > ~/projects/jruby ? jruby -J-XX:+UnlockDiagnosticVMOptions > -J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC > -J-Djruby.compile.invokedynamic -J-XX:+EnableInvokeDynamic > bench/bench_fib_recursive.rb 100 > [Verifying threads permgen tenured generation def new generation > remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyBeforeGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyAfterGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyBeforeGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyAfterGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyBeforeGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyAfterGC:[Verifying threads permgen tenured generation def new > generation remset ref_proc syms strs zone dict hand C-heap ] > ?VerifyBeforeGC:[Verifying threads # > > The hs_err file is attached. I do not have pstack on OS X...do you > know what the equivalent would be? > > On Tue, Aug 4, 2009 at 8:56 PM, wrote: >> The crash is in GC. Together with yr conjecture that the crash happens >> after a while when you expect the method to have been jitted, this might >> imply that the jit is not correctly conveying to GC where the >> references in jitted frames are or is not marking cards for the >> generational collector correctly, or GC isn't looking at all the >> slots it should be looking at or .... (But that is a long assumption.) >> The funny part about "running long enough" is that the hs_err log >> says the crash occurred after 0 seconds, so the VM is probably >> not correctly printing the time it's been running. >> >> I'd suggest running the JVM with the options -XX:+VerifyBeforeGC and -XX:+VerifyAfterGC >> to perhaps catch the problem sooner or get closer to the root cause. >> If you run with the additional JVM option -XX:+ShowMessageBoxOnError >> you might be able to pstack the process and get some info. (Or >> use the hs_err script to decode the stack trace from the hs_err log.) >> >> -- ramki >> >> On 08/04/09 18:07, Charles Oliver Nutter wrote: >>> I can't seem to catch a break. My local build and Attila's build still >>> both crash for me. There's got to be something about my environment >>> that's different, eh? >>> >>> As before, interpreter runs fine. Anything that runs long enough to >>> jit seems to crash. I've attached the latest log. >>> >>> On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver >>> Nutter wrote: >>>> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi wrote: >>>>> I can now confirm that it indeed does work with jruby-1.4.0dev that >>>>> indeed emits invokedynamic. >>>>> >>>>> The only catch is, it's very slow with invokedynamic, something that >>>>> Christian also mentioned. >>>> The fact that these numbers are so bad and even degrade shows me that >>>> although it's compiling indy, it's not eliminating the handles (which >>>> is true, the inlining and handle-walking stuff is not ready yet). So >>>> it's got many layers of polymorphic calls, probably some argument >>>> boxing and unboxing, and basically a ton more overhead than our >>>> heavily tuned non-indy call path. I'm confident in the Hotspot guys :) >>>> >>>> Just wanted to make sure anyone watching didn't think this was the >>>> best it would get... >>>> >>>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >>>>> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >>>>> bench_fib_recursive.rb 15 >>>>> ? 2.993000 ? 0.000000 ? 2.993000 ( ?2.915000) >>>>> ? 2.720000 ? 0.000000 ? 2.720000 ( ?2.720000) >>>>> ? 2.773000 ? 0.000000 ? 2.773000 ( ?2.773000) >>>>> ? 2.712000 ? 0.000000 ? 2.712000 ( ?2.712000) >>>>> ? 3.057000 ? 0.000000 ? 3.057000 ( ?3.057000) >>>>> ? 3.183000 ? 0.000000 ? 3.183000 ( ?3.184000) >>>>> ? 3.167000 ? 0.000000 ? 3.167000 ( ?3.167000) >>>>> ? 3.145000 ? 0.000000 ? 3.145000 ( ?3.145000) >>>>> ? 3.249000 ? 0.000000 ? 3.249000 ( ?3.249000) >>>>> ? 3.160000 ? 0.000000 ? 3.160000 ( ?3.160000) >>>>> ? 3.104000 ? 0.000000 ? 3.104000 ( ?3.104000) >>>>> ? 3.152000 ? 0.000000 ? 3.152000 ( ?3.153000) >>>>> ? 3.172000 ? 0.000000 ? 3.172000 ( ?3.171000) >>>>> ? 3.111000 ? 0.000000 ? 3.111000 ( ?3.111000) >>>>> ? 3.201000 ? 0.000000 ? 3.201000 ( ?3.201000) >>>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >>>>> bench_fib_recursive.rb 15 >>>>> ? 0.523000 ? 0.000000 ? 0.523000 ( ?0.481000) >>>>> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.291000) >>>>> ? 0.279000 ? 0.000000 ? 0.279000 ( ?0.278000) >>>>> ? 0.283000 ? 0.000000 ? 0.283000 ( ?0.283000) >>>>> ? 0.284000 ? 0.000000 ? 0.284000 ( ?0.284000) >>>>> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.292000) >>>>> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.289000) >>>>> ? 0.286000 ? 0.000000 ? 0.286000 ( ?0.287000) >>>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >>>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >>>>> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.290000) >>>>> ? 0.282000 ? 0.000000 ? 0.282000 ( ?0.282000) >>>>> ? 0.290000 ? 0.000000 ? 0.290000 ( ?0.290000) >>>>> ? 0.293000 ? 0.000000 ? 0.293000 ( ?0.293000) >>>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.284000) >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >> > From headius at headius.com Tue Aug 4 20:34:55 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 4 Aug 2009 22:34:55 -0500 Subject: Still crashity crashing In-Reply-To: References: <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> <4A78E6D0.9090408@Sun.COM> Message-ID: Ok, found it...there are 9 threads active: (gdb) info threads 9 process 43094 thread 0x2903 0x96ebf3ae in __semwait_signal () 8 process 43094 thread 0x2803 0x96ebf3ae in __semwait_signal () 7 process 43094 thread 0x2703 0x96ebf3ae in __semwait_signal () 6 process 43094 thread 0x2603 0x96eb8202 in semaphore_wait_trap () 5 process 43094 thread 0x2303 0x96ebf3ae in __semwait_signal () 4 process 43094 thread 0x2203 0x96ebf3ae in __semwait_signal () 3 process 43094 thread 0x2103 0x96efc796 in __wait4 () * 2 process 43094 thread 0x213 0x96ebf3ae in __semwait_signal () 1 process 43094 thread 0x717 0x96ebf3ae in __semwait_signal () Their backtraces are as follows: (gdb) thread 1 [Switching to thread 1 (process 43094 thread 0x717)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96f04398 in pthread_join$UNIX2003 () #2 0x0000668b in ContinueInNewThread0 () #3 0x0000440e in JLI_Launch () #4 0x0000d388 in main () (gdb) thread 2 [Switching to thread 2 (process 43094 thread 0x213)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96eea326 in _pthread_cond_wait () #2 0x96ee9d0d in pthread_cond_wait$UNIX2003 () #3 0x0136aea9 in os::PlatformEvent::park () #4 0x0134f32f in Monitor::IWait () #5 0x0134f5c4 in Monitor::wait () #6 0x01463070 in VMThread::execute () #7 0x0113e3a0 in GenCollectorPolicy::mem_allocate_work () #8 0x011cec88 in GenCollectedHeap::mem_allocate () #9 0x0142c27e in typeArrayKlass::allocate () #10 0x01362222 in oopFactory::new_typeArray () #11 0x010ef68f in Runtime1::new_type_array () #12 0x01ab508a in ?? () #13 0x01ae41f3 in ?? () #14 0x01ae3aa4 in ?? () #15 0x01aede5c in ?? () #16 0x01aef690 in ?? () #17 0x01af1684 in ?? () #18 0x01af1244 in ?? () #19 0x01af0cb0 in ?? () #20 0x01a4282f in ?? () #21 0x01a422cf in ?? () #22 0x01a421c7 in ?? () #23 0x01a421c7 in ?? () #24 0x01a421c7 in ?? () #25 0x01a421c7 in ?? () #26 0x01a421c7 in ?? () #27 0x01a421c7 in ?? () #28 0x01a421c7 in ?? () #29 0x01a421c7 in ?? () #30 0x01a421c7 in ?? () #31 0x01a41ff3 in ?? () #32 0x01a41ff3 in ?? () #33 0x01a3f2cc in ?? () #34 0x01222eb2 in JavaCalls::call_helper () #35 0x0136a241 in os::os_exception_wrapper () #36 0x01221a83 in JavaCalls::call () #37 0x011f67ac in instanceKlass::call_class_initializer_impl () #38 0x011f6a6e in instanceKlass::initialize_impl () #39 0x011f70c8 in instanceKlass::initialize () #40 0x013181f5 in LinkResolver::resolve_static_call () #41 0x01319e2b in LinkResolver::resolve_invokestatic () #42 0x01319f15 in LinkResolver::resolve_invoke () #43 0x0121b66b in InterpreterRuntime::resolve_invoke () #44 0x01a4f8cf in ?? () #45 0x01a421c7 in ?? () #46 0x01a421c7 in ?? () #47 0x01a421c7 in ?? () #48 0x01a41ff3 in ?? () #49 0x01a421c7 in ?? () #50 0x01a4216f in ?? () #51 0x01a4216f in ?? () #52 0x01a3f2cc in ?? () #53 0x01222eb2 in JavaCalls::call_helper () #54 0x0136a241 in os::os_exception_wrapper () #55 0x01221a83 in JavaCalls::call () #56 0x0122e6d8 in jni_invoke_static () #57 0x0124253d in jni_CallStaticVoidMethod () #58 0x00001f31 in JavaMain () #59 0x96ee9095 in _pthread_start () #60 0x96ee8f52 in thread_start () (gdb) thread 3 [Switching to thread 3 (process 43094 thread 0x2103)] 0x96efc796 in __wait4 () (gdb) bt #0 0x96efc796 in __wait4 () #1 0x96efc787 in waitpid$UNIX2003 () #2 0x0136a856 in os::fork_and_exec () #3 0x0145eae4 in VMError::show_message_box () #4 0x0145e87d in VMError::report_and_die () #5 0x01370b5e in JVM_handle_bsd_signal () #6 0x0136a031 in signalHandler () #7 #8 0x011a43aa in frame::oops_interpreted_do () #9 0x011a4aa6 in frame::oops_do_internal () #10 0x0141f175 in JavaThread::oops_do () #11 0x0141f5ff in Threads::verify () #12 0x0142db1c in Universe::verify () #13 0x011d1506 in GenCollectedHeap::do_collection () #14 0x0113e5e3 in GenCollectorPolicy::satisfy_failed_allocation () #15 0x011cecc5 in GenCollectedHeap::satisfy_failed_allocation () #16 0x0145f23b in VM_GenCollectForAllocation::doit () #17 0x01464125 in VM_Operation::evaluate () #18 0x014627fd in VMThread::evaluate_operation () #19 0x0146346c in VMThread::loop () #20 0x0146375c in VMThread::run () #21 0x0136dab5 in java_start () #22 0x96ee9095 in _pthread_start () #23 0x96ee8f52 in thread_start () (gdb) thread 4 [Switching to thread 4 (process 43094 thread 0x2203)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96eea326 in _pthread_cond_wait () #2 0x96ee9d0d in pthread_cond_wait$UNIX2003 () #3 0x0136aea9 in os::PlatformEvent::park () #4 0x013ed57a in ObjectMonitor::wait () #5 0x013ed711 in ObjectSynchronizer::wait () #6 0x01293a5d in JVM_MonitorWait () #7 0x01a4971d in ?? () #8 0x01a41ff3 in ?? () #9 0x01a41ff3 in ?? () #10 0x01a3f2cc in ?? () #11 0x01222eb2 in JavaCalls::call_helper () #12 0x0136a241 in os::os_exception_wrapper () #13 0x012222d2 in JavaCalls::call_virtual () #14 0x0122250d in JavaCalls::call_virtual () #15 0x0128fefe in thread_entry () #16 0x01422671 in JavaThread::thread_main_inner () #17 0x0142275e in JavaThread::run () #18 0x0136dab5 in java_start () #19 0x96ee9095 in _pthread_start () #20 0x96ee8f52 in thread_start () (gdb) thread 5 [Switching to thread 5 (process 43094 thread 0x2303)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96eea326 in _pthread_cond_wait () #2 0x96ee9d0d in pthread_cond_wait$UNIX2003 () #3 0x0136aea9 in os::PlatformEvent::park () #4 0x013ed57a in ObjectMonitor::wait () #5 0x013ed711 in ObjectSynchronizer::wait () #6 0x01293a5d in JVM_MonitorWait () #7 0x01a4971d in ?? () #8 0x01a41ff3 in ?? () #9 0x01a421c7 in ?? () #10 0x01a421c7 in ?? () #11 0x01a3f2cc in ?? () #12 0x01222eb2 in JavaCalls::call_helper () #13 0x0136a241 in os::os_exception_wrapper () #14 0x012222d2 in JavaCalls::call_virtual () #15 0x0122250d in JavaCalls::call_virtual () #16 0x0128fefe in thread_entry () #17 0x01422671 in JavaThread::thread_main_inner () #18 0x0142275e in JavaThread::run () #19 0x0136dab5 in java_start () #20 0x96ee9095 in _pthread_start () #21 0x96ee8f52 in thread_start () (gdb) thread 6 [Switching to thread 6 (process 43094 thread 0x2603)] 0x96eb8202 in semaphore_wait_trap () (gdb) bt #0 0x96eb8202 in semaphore_wait_trap () #1 0x0136d8a0 in check_pending_signals () #2 0x0136d9c9 in os::signal_wait () #3 0x01367c85 in signal_thread_entry () #4 0x01422671 in JavaThread::thread_main_inner () #5 0x0142275e in JavaThread::run () #6 0x0136dab5 in java_start () #7 0x96ee9095 in _pthread_start () #8 0x96ee8f52 in thread_start () (gdb) thread 7 [Switching to thread 7 (process 43094 thread 0x2703)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96eea326 in _pthread_cond_wait () #2 0x96ee9d0d in pthread_cond_wait$UNIX2003 () #3 0x0136aea9 in os::PlatformEvent::park () #4 0x0134f32f in Monitor::IWait () #5 0x0134f5c4 in Monitor::wait () #6 0x01148fff in CompileQueue::get () #7 0x0114c91c in CompileBroker::compiler_thread_loop () #8 0x0141b154 in compiler_thread_entry () #9 0x01422671 in JavaThread::thread_main_inner () #10 0x0142275e in JavaThread::run () #11 0x0136dab5 in java_start () #12 0x96ee9095 in _pthread_start () #13 0x96ee8f52 in thread_start () (gdb) thread 8 [Switching to thread 8 (process 43094 thread 0x2803)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96eea326 in _pthread_cond_wait () #2 0x96ee9d0d in pthread_cond_wait$UNIX2003 () #3 0x0136aea9 in os::PlatformEvent::park () #4 0x0134f32f in Monitor::IWait () #5 0x0134f701 in Monitor::wait () #6 0x0131cfa4 in LowMemoryDetector::low_memory_detector_thread_entry () #7 0x01422671 in JavaThread::thread_main_inner () #8 0x0142275e in JavaThread::run () #9 0x0136dab5 in java_start () #10 0x96ee9095 in _pthread_start () #11 0x96ee8f52 in thread_start () (gdb) thread 9 [Switching to thread 9 (process 43094 thread 0x2903)] 0x96ebf3ae in __semwait_signal () (gdb) bt #0 0x96ebf3ae in __semwait_signal () #1 0x96eea326 in _pthread_cond_wait () #2 0x96f0f9f0 in pthread_cond_timedwait$UNIX2003 () #3 0x0136c019 in os::PlatformEvent::park () #4 0x0136f164 in os::sleep () #5 0x0142086f in WatcherThread::run () #6 0x0136dab5 in java_start () #7 0x96ee9095 in _pthread_start () #8 0x96ee8f52 in thread_start () On Tue, Aug 4, 2009 at 10:28 PM, Charles Oliver Nutter wrote: > The ShowMessageBox option also gave me the option of launching gdb. > I'm not a gdb expert, but "bt" produced this: > > (gdb) bt > #0 ?0x96ebf3ae in __semwait_signal () > #1 ?0x96f04398 in pthread_join$UNIX2003 () > #2 ?0x0000668b in ContinueInNewThread0 () > #3 ?0x0000440e in JLI_Launch () > #4 ?0x0000d388 in main () > > Trying now to see if I can view stacks for other threads or something. > > On Tue, Aug 4, 2009 at 10:24 PM, Charles Oliver > Nutter wrote: >> Here's the output with the verify flags on: >> >> ~/projects/jruby ? jruby -J-XX:+UnlockDiagnosticVMOptions >> -J-XX:+VerifyBeforeGC -J-XX:+VerifyAfterGC >> -J-Djruby.compile.invokedynamic -J-XX:+EnableInvokeDynamic >> bench/bench_fib_recursive.rb 100 >> [Verifying threads permgen tenured generation def new generation >> remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyBeforeGC:[Verifying threads permgen tenured generation def new >> generation remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyAfterGC:[Verifying threads permgen tenured generation def new >> generation remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyBeforeGC:[Verifying threads permgen tenured generation def new >> generation remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyAfterGC:[Verifying threads permgen tenured generation def new >> generation remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyBeforeGC:[Verifying threads permgen tenured generation def new >> generation remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyAfterGC:[Verifying threads permgen tenured generation def new >> generation remset ref_proc syms strs zone dict hand C-heap ] >> ?VerifyBeforeGC:[Verifying threads # >> >> The hs_err file is attached. I do not have pstack on OS X...do you >> know what the equivalent would be? >> >> On Tue, Aug 4, 2009 at 8:56 PM, wrote: >>> The crash is in GC. Together with yr conjecture that the crash happens >>> after a while when you expect the method to have been jitted, this might >>> imply that the jit is not correctly conveying to GC where the >>> references in jitted frames are or is not marking cards for the >>> generational collector correctly, or GC isn't looking at all the >>> slots it should be looking at or .... (But that is a long assumption.) >>> The funny part about "running long enough" is that the hs_err log >>> says the crash occurred after 0 seconds, so the VM is probably >>> not correctly printing the time it's been running. >>> >>> I'd suggest running the JVM with the options -XX:+VerifyBeforeGC and -XX:+VerifyAfterGC >>> to perhaps catch the problem sooner or get closer to the root cause. >>> If you run with the additional JVM option -XX:+ShowMessageBoxOnError >>> you might be able to pstack the process and get some info. (Or >>> use the hs_err script to decode the stack trace from the hs_err log.) >>> >>> -- ramki >>> >>> On 08/04/09 18:07, Charles Oliver Nutter wrote: >>>> I can't seem to catch a break. My local build and Attila's build still >>>> both crash for me. There's got to be something about my environment >>>> that's different, eh? >>>> >>>> As before, interpreter runs fine. Anything that runs long enough to >>>> jit seems to crash. I've attached the latest log. >>>> >>>> On Tue, Aug 4, 2009 at 7:58 PM, Charles Oliver >>>> Nutter wrote: >>>>> On Tue, Aug 4, 2009 at 4:17 PM, Attila Szegedi wrote: >>>>>> I can now confirm that it indeed does work with jruby-1.4.0dev that >>>>>> indeed emits invokedynamic. >>>>>> >>>>>> The only catch is, it's very slow with invokedynamic, something that >>>>>> Christian also mentioned. >>>>> The fact that these numbers are so bad and even degrade shows me that >>>>> although it's compiling indy, it's not eliminating the handles (which >>>>> is true, the inlining and handle-walking stuff is not ready yet). So >>>>> it's got many layers of polymorphic calls, probably some argument >>>>> boxing and unboxing, and basically a ton more overhead than our >>>>> heavily tuned non-indy call path. I'm confident in the Hotspot guys :) >>>>> >>>>> Just wanted to make sure anyone watching didn't think this was the >>>>> best it would get... >>>>> >>>>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server -J- >>>>>> Djruby.compile.invokedynamic=true -J-XX:+EnableInvokeDynamic bench/ >>>>>> bench_fib_recursive.rb 15 >>>>>> ? 2.993000 ? 0.000000 ? 2.993000 ( ?2.915000) >>>>>> ? 2.720000 ? 0.000000 ? 2.720000 ( ?2.720000) >>>>>> ? 2.773000 ? 0.000000 ? 2.773000 ( ?2.773000) >>>>>> ? 2.712000 ? 0.000000 ? 2.712000 ( ?2.712000) >>>>>> ? 3.057000 ? 0.000000 ? 3.057000 ( ?3.057000) >>>>>> ? 3.183000 ? 0.000000 ? 3.183000 ( ?3.184000) >>>>>> ? 3.167000 ? 0.000000 ? 3.167000 ( ?3.167000) >>>>>> ? 3.145000 ? 0.000000 ? 3.145000 ( ?3.145000) >>>>>> ? 3.249000 ? 0.000000 ? 3.249000 ( ?3.249000) >>>>>> ? 3.160000 ? 0.000000 ? 3.160000 ( ?3.160000) >>>>>> ? 3.104000 ? 0.000000 ? 3.104000 ( ?3.104000) >>>>>> ? 3.152000 ? 0.000000 ? 3.152000 ( ?3.153000) >>>>>> ? 3.172000 ? 0.000000 ? 3.172000 ( ?3.171000) >>>>>> ? 3.111000 ? 0.000000 ? 3.111000 ( ?3.111000) >>>>>> ? 3.201000 ? 0.000000 ? 3.201000 ( ?3.201000) >>>>>> MacBook-Pro-Ati:jruby-1.4.0dev aszegedi$ bin/jruby --server bench/ >>>>>> bench_fib_recursive.rb 15 >>>>>> ? 0.523000 ? 0.000000 ? 0.523000 ( ?0.481000) >>>>>> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.291000) >>>>>> ? 0.279000 ? 0.000000 ? 0.279000 ( ?0.278000) >>>>>> ? 0.283000 ? 0.000000 ? 0.283000 ( ?0.283000) >>>>>> ? 0.284000 ? 0.000000 ? 0.284000 ( ?0.284000) >>>>>> ? 0.292000 ? 0.000000 ? 0.292000 ( ?0.292000) >>>>>> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.289000) >>>>>> ? 0.286000 ? 0.000000 ? 0.286000 ( ?0.287000) >>>>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >>>>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.285000) >>>>>> ? 0.289000 ? 0.000000 ? 0.289000 ( ?0.290000) >>>>>> ? 0.282000 ? 0.000000 ? 0.282000 ( ?0.282000) >>>>>> ? 0.290000 ? 0.000000 ? 0.290000 ( ?0.290000) >>>>>> ? 0.293000 ? 0.000000 ? 0.293000 ( ?0.293000) >>>>>> ? 0.285000 ? 0.000000 ? 0.285000 ( ?0.284000) >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > From Y.S.Ramakrishna at Sun.COM Tue Aug 4 23:20:43 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Tue, 04 Aug 2009 23:20:43 -0700 Subject: Still crashity crashing In-Reply-To: References: <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> <4A78E6D0.9090408@Sun.COM> Message-ID: <4A7924BB.9090700@sun.com> So it looks like something is causing the iteration over the oops in an interpreter frame on a Java thread stack to fail, and this happens prior to a GC (so GC is likely not screwing up here, but rather perhaps the interpreter). With those very general remarks, it's over to the MLVM cognoscenti :-) -- ramki Charles Oliver Nutter wrote: ... > (gdb) thread 3 > [Switching to thread 3 (process 43094 thread 0x2103)] > 0x96efc796 in __wait4 () > (gdb) bt > #0 0x96efc796 in __wait4 () > #1 0x96efc787 in waitpid$UNIX2003 () > #2 0x0136a856 in os::fork_and_exec () > #3 0x0145eae4 in VMError::show_message_box () > #4 0x0145e87d in VMError::report_and_die () > #5 0x01370b5e in JVM_handle_bsd_signal () > #6 0x0136a031 in signalHandler () > #7 > #8 0x011a43aa in frame::oops_interpreted_do () > #9 0x011a4aa6 in frame::oops_do_internal () > #10 0x0141f175 in JavaThread::oops_do () > #11 0x0141f5ff in Threads::verify () > #12 0x0142db1c in Universe::verify () > #13 0x011d1506 in GenCollectedHeap::do_collection () > #14 0x0113e5e3 in GenCollectorPolicy::satisfy_failed_allocation () > #15 0x011cecc5 in GenCollectedHeap::satisfy_failed_allocation () > #16 0x0145f23b in VM_GenCollectForAllocation::doit () > #17 0x01464125 in VM_Operation::evaluate () > #18 0x014627fd in VMThread::evaluate_operation () > #19 0x0146346c in VMThread::loop () > #20 0x0146375c in VMThread::run () > #21 0x0136dab5 in java_start () > #22 0x96ee9095 in _pthread_start () > #23 0x96ee8f52 in thread_start () > From headius at headius.com Wed Aug 5 00:39:33 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 5 Aug 2009 02:39:33 -0500 Subject: Still crashity crashing In-Reply-To: <4A7924BB.9090700@sun.com> References: <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> <4A78E6D0.9090408@Sun.COM> <4A7924BB.9090700@sun.com> Message-ID: And I am standing by to push any other gdb buttons necessary to help investigate :) Given a couple months I might be able to dig into Hotspot internals myself, but alas... On Wed, Aug 5, 2009 at 1:20 AM, Y. Srinivas Ramakrishna < Y.S.Ramakrishna at sun.com> wrote: > So it looks like something is causing the iteration over the oops in > an interpreter frame on a Java thread stack to fail, and this > happens prior to a GC (so GC is likely not screwing up here, > but rather perhaps the interpreter). > > With those very general remarks, it's over to the MLVM cognoscenti :-) > -- ramki > > Charles Oliver Nutter wrote: > ... > > (gdb) thread 3 > > [Switching to thread 3 (process 43094 thread 0x2103)] > > 0x96efc796 in __wait4 () > > (gdb) bt > > #0 0x96efc796 in __wait4 () > > #1 0x96efc787 in waitpid$UNIX2003 () > > #2 0x0136a856 in os::fork_and_exec () > > #3 0x0145eae4 in VMError::show_message_box () > > #4 0x0145e87d in VMError::report_and_die () > > #5 0x01370b5e in JVM_handle_bsd_signal () > > #6 0x0136a031 in signalHandler () > > #7 > > #8 0x011a43aa in frame::oops_interpreted_do () > > #9 0x011a4aa6 in frame::oops_do_internal () > > #10 0x0141f175 in JavaThread::oops_do () > > #11 0x0141f5ff in Threads::verify () > > #12 0x0142db1c in Universe::verify () > > #13 0x011d1506 in GenCollectedHeap::do_collection () > > #14 0x0113e5e3 in GenCollectorPolicy::satisfy_failed_allocation () > > #15 0x011cecc5 in GenCollectedHeap::satisfy_failed_allocation () > > #16 0x0145f23b in VM_GenCollectForAllocation::doit () > > #17 0x01464125 in VM_Operation::evaluate () > > #18 0x014627fd in VMThread::evaluate_operation () > > #19 0x0146346c in VMThread::loop () > > #20 0x0146375c in VMThread::run () > > #21 0x0136dab5 in java_start () > > #22 0x96ee9095 in _pthread_start () > > #23 0x96ee8f52 in thread_start () > > > _______________________________________________ > 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/20090805/2e60e1d1/attachment.html From forax at univ-mlv.fr Wed Aug 5 08:43:35 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 05 Aug 2009 17:43:35 +0200 Subject: Still crashity crashing In-Reply-To: References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> Message-ID: <4A79A8A7.2030706@univ-mlv.fr> Le 05/08/2009 03:17, Charles Oliver Nutter a ?crit : > On Tue, Aug 4, 2009 at 8:16 PM, R?mi Forax wrote: > >> - remove the assertion that invokedynamic can only appear >> in class 1.7 compatible (version 51.0) class, >> currently your classes are not compiled with version 51. >> BTW, John, It should not work with the JSR 292 RI too ? >> > > Yes, ASM allows us to emit invokedynamic, and we always default our > generated bytecode to whatever version of JVM we're running on, so > it's possible we'll get a combination of<51 and indy if someone turns > that flag on for a lower JVM (as in this case). > > We could certainly change that on our end too. > Yes, It will avoid to crawle all classes but only the ones with invokedynamic. So it will reduce the startup time. > >> - optimize concurrently with the running program >> (hotspot do that, not the backport) >> > > In most cases we run code immediately after generating it, so we're > not offloading compilation either. We'd probably want to consider > doing that so that we wouldn't now have the additional cost of waiting > for the backport to run. > Yes. > >> The main problem is that the backport is not able to optimize >> the produced method handle tree. >> >> One problem is that the method InvokeDynamicsupport.pollAndGetClass is >> private >> but exported by PGC. The backport has the same contraint that >> any Java code, so it is not able to optimize any method adapter tree >> that contains PGC. >> > > Ahh...well I could certainly make it public if it would help the > optimization. I understand that this is a natural limitation of the > backport. > Ok, the backport is now able to correctly optimize your code (a stupid && instead of ||) and i'm happy to say that the backport now performs better. time bin/jruby --client -J-javaagent:../indy-backport/lib/jsr292-backport.jar -J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar -J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true bench/bench_fib_recursive.rb 100 real 0m45.438s user 0m45.102s sys 0m0.252s time bin/jruby --client bench/bench_fib_recursive.rb 100 real 0m38.535s user 0m38.239s sys 0m0.168s time bin/jruby --server -J-javaagent:../indy-backport/lib/jsr292-backport.jar -J-Xbootclasspath/p:../indy-backport/lib/jsr292-backport.jar -J-Djruby.compile.invokedynamic=true -J-Djruby.jit.logging.verbose=true bench/bench_fib_recursive.rb 100 real 0m38.887s user 0m44.930s sys 0m0.497s time bin/jruby --server bench/bench_fib_recursive.rb 100 real 0m27.885s user 0m27.645s sys 0m0.197s The next room of improvement is to directly put the bytecode weaver of the backport at the end of the JRuby ASM compiler. I hope this will reduce the startup time. > - Charlie > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090805/60c50e38/attachment.html From headius at headius.com Wed Aug 5 08:36:36 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 5 Aug 2009 10:36:36 -0500 Subject: Still crashity crashing In-Reply-To: <4A79A8A7.2030706@univ-mlv.fr> References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> <4A79A8A7.2030706@univ-mlv.fr> Message-ID: On Wed, Aug 5, 2009 at 10:43 AM, R?mi Forax wrote: > Ok, the backport is now able to correctly optimize your code > (a stupid && instead of ||) > and i'm happy to say that the backport now performs better. Oh yes, these numbers are much better! This renews my resolve to have a look at the backport and see if I can add some optimization improvements. We may be able to get it as fast as the non-indy logic, which would be excellent for everyone. - Charlie From John.Rose at Sun.COM Wed Aug 5 15:38:52 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 05 Aug 2009 15:38:52 -0700 Subject: Still crashity crashing In-Reply-To: References: <20EC2220-B830-4C0C-B0A5-5539F97B033C@gmail.com> Message-ID: <1DBC2165-445B-43B4-BB15-D035565215DF@sun.com> Thanks! That's a variant of this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6844449 On Aug 2, 2009, at 2:42 PM, Attila Szegedi wrote: > Note how there's no > semicolon after "Ljava/lang/String" From John.Rose at Sun.COM Wed Aug 5 15:42:57 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 05 Aug 2009 15:42:57 -0700 Subject: Still crashity crashing In-Reply-To: <4A79A8A7.2030706@univ-mlv.fr> References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> <4A79A8A7.2030706@univ-mlv.fr> Message-ID: <7F314BC6-37D5-4446-8C00-97CEDB83559C@sun.com> On Aug 5, 2009, at 8:43 AM, R?mi Forax wrote: > The next room of improvement is to directly put the bytecode weaver > of the backport at the end of the JRuby ASM compiler. > I hope this will reduce the startup time. (Jumping into the middle...) Sounds like an ASM compatibility mode. Does ASM have an option to automagically rewrite ldc of CONSTANT_Class into the old idiom (synthetic static class$ field, etc.)? If so, can that pattern stretch another order of magnitude to support some or all of the backport logic? -- John From John.Rose at Sun.COM Wed Aug 5 15:49:26 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 05 Aug 2009 15:49:26 -0700 Subject: Still crashity crashing In-Reply-To: References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <94ECE05B-687E-438C-8EC2-C6E837A7EF00@gmail.com> <97B22D0A-38CC-4F77-AFC8-CE3EBF7CA917@gmail.com> Message-ID: <90E15B93-F099-4839-B1E4-C4A34409F0FA@sun.com> On Aug 4, 2009, at 5:58 PM, Charles Oliver Nutter wrote: > I'm confident in the Hotspot guys :) Thanks; we are working hard to justify that confidence. Christian has begun inlining more complex chains such as lambda (long x) => { x + x } : http://pylonshq.com/irclogs/%23mlvm/%23mlvm.2009-07-29.log.html -- John From John.Rose at Sun.COM Wed Aug 5 15:58:04 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 05 Aug 2009 15:58:04 -0700 Subject: Still crashity crashing In-Reply-To: <4A782691.4050605@Sun.COM> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> Message-ID: <17099E83-7641-4056-BC3F-7FDB5CADB71E@sun.com> I think Christian is asleep right now, so I'll steal his thunder and give a mini-update: He's almost certainly found the key crasher. It was a bit of known-kludgey code (mine) we put into the stack walker. It's the logic the recognizes return-points after MH.invoke calls. Now we have to fix it the right way; he got it partially working; stay tuned for a full fix. As Han Solo said walking out of the Mos Eisley cantina, "Sorry about the mess." -- John On Aug 4, 2009, at 5:16 AM, Christian Thalinger wrote: > Christian Thalinger wrote: >> Christian Thalinger wrote: >>> Christian Thalinger wrote: >>>> Still building the newly checked out version... >>> Finally I can reproduce the crashes. Either it's related to debug >>> vs. >>> product build or the additional patches applied. Still >>> investigating... >> >> Oh no! It's so obvious :-/ indy.compiler.patch is not enabled for >> default builds and so the VM crashes when the compiler kicks in. >> >> I just pushed a changeset[1] that enables the patch. Please update >> your >> mlvm repository and build again. > > With a debug build I get this assert: From headius at headius.com Wed Aug 5 17:08:15 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 5 Aug 2009 19:08:15 -0500 Subject: Still crashity crashing In-Reply-To: <17099E83-7641-4056-BC3F-7FDB5CADB71E@sun.com> References: <4A769C47.9040802@Sun.COM> <8E19761C-FE59-469E-86F1-7FBC12F82186@gmail.com> <4A7815B7.6020209@Sun.COM> <4A781D10.1080605@Sun.COM> <4A7823A5.2080707@Sun.COM> <4A782691.4050605@Sun.COM> <17099E83-7641-4056-BC3F-7FDB5CADB71E@sun.com> Message-ID: On Wed, Aug 5, 2009 at 5:58 PM, John Rose wrote: > I think Christian is asleep right now, so I'll steal his thunder and > give a mini-update: ? He's almost certainly found the key crasher. ?It > was a bit of known-kludgey code (mine) we put into the stack walker. > It's the logic the recognizes return-points after MH.invoke calls. > Now we have to fix it the right way; he got it partially working; stay > tuned for a full fix. > > As Han Solo said walking out of the Mos Eisley cantina, "Sorry about > the mess." Hey, that's great news, as is the ever-improving inlining! We've actually got people on the JRuby user list interested in using indy for experimental purposes with JRuby as it starts to stabilize, and possibly running applications on it if the benefits are great enough. I'm also keen to see how well escape analysis couples with indy...if it helps a lot, there's many places we can restructure JRuby's code to make escape analysis more effective. As always, I'm standing by to try things out and report results. - Charlie From forax at univ-mlv.fr Wed Aug 5 17:30:19 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 06 Aug 2009 02:30:19 +0200 Subject: Still crashity crashing In-Reply-To: <7F314BC6-37D5-4446-8C00-97CEDB83559C@sun.com> References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> <4A79A8A7.2030706@univ-mlv.fr> <7F314BC6-37D5-4446-8C00-97CEDB83559C@sun.com> Message-ID: <4A7A241B.20406@univ-mlv.fr> Le 06/08/2009 00:42, John Rose a ?crit : > On Aug 5, 2009, at 8:43 AM, R?mi Forax wrote: > > >> The next room of improvement is to directly put the bytecode weaver >> of the backport at the end of the JRuby ASM compiler. >> I hope this will reduce the startup time. >> > > (Jumping into the middle...) > > Sounds like an ASM compatibility mode. Does ASM have an option to > automagically rewrite ldc of CONSTANT_Class into the old idiom > (synthetic static class$ field, etc.)? As far as I know, No ! > If so, can that pattern > stretch another order of magnitude to support some or all of the > backport logic? > Ok, hacking JRuby, I was able to use the backport without the agent, but that means also without the optimizer. Basically, the code run 5 times slower with -server and 7 times slower with -client i.e not that far from the numbers of my first report :( John, as you see the backport needs the agent to be able to recompile at runtime callsite target to have decent perf so providing only a bytecode transformer is not that useful. I have seen some small rooms of improvement in the JRuby code (apart from replacing DynamicMethod by MethodHandle which is what must be done but which is also in my opinion a more than one week job :) I will send a separate email tomorrow, It's too late now. > -- John > cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090806/27ea6bba/attachment.html From headius at headius.com Wed Aug 5 17:40:48 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 5 Aug 2009 19:40:48 -0500 Subject: Still crashity crashing In-Reply-To: <4A7A241B.20406@univ-mlv.fr> References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> <4A79A8A7.2030706@univ-mlv.fr> <7F314BC6-37D5-4446-8C00-97CEDB83559C@sun.com> <4A7A241B.20406@univ-mlv.fr> Message-ID: On Wed, Aug 5, 2009 at 7:30 PM, R?mi Forax wrote: > I have seen some small rooms of improvement in the JRuby code > (apart from replacing? DynamicMethod by MethodHandle which is > ?what must be done but which is also in my opinion a more than one week job > :) Nah, it's a day at most. Here's the process: 1. When generating DynamicMethods that point at real Java code, also attach target class, method name, and signature info. 2. Use this info at runtime when preparing the call sites. And even if we went with a stupid-simple solution, I could switch on JRuby's reflection-based mode and simply unreflect the Method object each ReflectedMethod (extends DynamicMethod) would contain. The fact that we can juggle handle information immediately before installing it in the call site makes everything pretty easy. And here's a couple questions for you and John: 1. If we desired to expand JRuby's monomorphic inline caching in indy mode, could we simply chain together a series of GWTs that perform type comparisons? So we'd have something like at call site:GWT1 test: is receiver a String target: call cached String method fallback: GWT2 test: is receiver an Array target: call cached Array method fallback: GWT3 ... fallback: slow lookup and perhaps add to or edit the GWT chain based on some heuristic Since the entire sequence would still inline (ideally) it would be similar to the regenerated call site logic that the DLR does...except way better, because it wouldn't interfere with the eventual targets inlining into the caller. 2. Have you (or anyone else) thought much about how indy might eventually play with the tiered compiler? I could see the two working extremely well together. In my head, the first tier compilation would happen quickly and know about method handle chains, but also install appropriate profiling hooks that can gather information about those chains. For example, in the GWT case above, it would include branch profiling to see which of the types in the PIC were getting hit most often. Then the second tier compiler could do a better job of optimizing those paths. I know the tiered compiler work has slowed over the past few months, but I've also heard plans are still to make it a reality. Tiered compilation combined with indy would certainly be worth more than the sum of its parts, since dynamic, multi-stage optimization is the name of the game for fast dynamic languages. - Charlie From forax at univ-mlv.fr Thu Aug 6 07:35:23 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 06 Aug 2009 16:35:23 +0200 Subject: Still crashity crashing In-Reply-To: References: <4A76F0F8.2010802@univ-mlv.fr> <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> <4A79A8A7.2030706@univ-mlv.fr> <7F314BC6-37D5-4446-8C00-97CEDB83559C@sun.com> <4A7A241B.20406@univ-mlv.fr> Message-ID: <4A7AEA2B.2090906@univ-mlv.fr> Le 06/08/2009 02:40, Charles Oliver Nutter a ?crit : > On Wed, Aug 5, 2009 at 7:30 PM, R?mi Forax wrote: > >> I have seen some small rooms of improvement in the JRuby code >> (apart from replacing DynamicMethod by MethodHandle which is >> what must be done but which is also in my opinion a more than one week job >> :) >> > > Nah, it's a day at most. => Cool :) > Here's the process: > > 1. When generating DynamicMethods that point at real Java code, also > attach target class, method name, and signature info. > 2. Use this info at runtime when preparing the call sites. > You should try to cache the method handle in the DynamicMethod to reuse the same MH for several call sites. > And even if we went with a stupid-simple solution, I could switch on > JRuby's reflection-based mode and simply unreflect the Method object > each ReflectedMethod (extends DynamicMethod) would contain. The fact > that we can juggle handle information immediately before installing it > in the call site makes everything pretty easy. > > And here's a couple questions for you and John: > > 1. If we desired to expand JRuby's monomorphic inline caching in indy > mode, could we simply chain together a series of GWTs that perform > type comparisons? So we'd have something like > > at call site:GWT1 > test: is receiver a String > target: call cached String method > fallback: GWT2 > test: is receiver an Array > target: call cached Array method > fallback: GWT3 > ... > fallback: slow lookup and perhaps add to or edit the GWT > chain based on some heuristic > > Since the entire sequence would still inline (ideally) it would be > similar to the regenerated call site logic that the DLR does...except > way better, because it wouldn't interfere with the eventual targets > inlining into the caller. > Speaking for what I am knowing, i.e without a special wildcard rule for inlining, It's working for bi-morphic call but after that local vtable (or selector table) implemented using table or lookup switch are more efficient. Something like: let receiverClass = receiver.getClass(); switch(receiverClass.hashCode()) { case 0x1345678: return ... case 0x678456: // here there is a collision, very rare in practice, fallback to if..else if (receiverClass == String.class) { } else { } ... } > 2. Have you (or anyone else) thought much about how indy might > eventually play with the tiered compiler? I could see the two working > extremely well together. In my head, the first tier compilation would > happen quickly and know about method handle chains, but also install > appropriate profiling hooks that can gather information about those > chains. For example, in the GWT case above, it would include branch > profiling to see which of the types in the PIC were getting hit most > often. Then the second tier compiler could do a better job of > optimizing those paths. > > I know the tiered compiler work has slowed over the past few months, > but I've also heard plans are still to make it a reality. Tiered > compilation combined with indy would certainly be worth more than the > sum of its parts, since dynamic, multi-stage optimization is the name > of the game for fast dynamic languages. > I wonder if tiered compilation is still an active project since Steve Goldman passed away. I know that someone new (I don't remember who) was in charge to this project but I haven't seen any news since. > - Charlie > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090806/c121ec94/attachment.html From headius at headius.com Thu Aug 6 10:09:23 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 6 Aug 2009 12:09:23 -0500 Subject: Still crashity crashing In-Reply-To: <4A7AEA2B.2090906@univ-mlv.fr> References: <4A77016E.1040406@univ-mlv.fr> <4A78DD7E.4010806@univ-mlv.fr> <4A79A8A7.2030706@univ-mlv.fr> <7F314BC6-37D5-4446-8C00-97CEDB83559C@sun.com> <4A7A241B.20406@univ-mlv.fr> <4A7AEA2B.2090906@univ-mlv.fr> Message-ID: On Thu, Aug 6, 2009 at 9:35 AM, R?mi Forax wrote: > You should try to cache the method handle in the DynamicMethod > to reuse the same MH for several call sites. Yeah, good call. I'll have to store it at Object, though, since we want a single codebase to work for Java 5+. But caching it shouldn't be hard. > Speaking for what I am knowing, i.e > without a special wildcard rule for inlining, > It's working for bi-morphic call but after that > local vtable (or selector table) implemented using table or > lookup switch are more efficient. > > Something like: > let receiverClass = receiver.getClass(); > switch(receiverClass.hashCode()) { > ?? case 0x1345678: > ?????? return ... > ?? case 0x678456: > ????? // here there is a collision, very rare in practice, fallback to > if..else > ????? if (receiverClass == String.class) { > > ?????? } else { > > ?????? } > ??? ... > } Yes, I'm sure there would be a failover point. I wonder how one could do a switch using only method handles...perhaps there's a need for another handle type that takes a table of values => target handles and another handle to retrieve the switch argument? > I wonder if tiered compilation is still an active project > since Steve Goldman passed away. > I know that someone new (I don't remember who) > was in charge to this project but I haven't seen > any news since. I had heard it was still progressing, but very slowly. I hope new resources appear soon to help move it along :( - Charlie From John.Rose at Sun.COM Thu Aug 6 15:32:29 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 06 Aug 2009 15:32:29 -0700 Subject: Mangled names for invokedynamic In-Reply-To: <3E7CFA1D-6542-4244-A6C2-5B669700086D@gmail.com> References: <3E7CFA1D-6542-4244-A6C2-5B669700086D@gmail.com> Message-ID: <26E11703-B80C-45B2-A3A2-12E9E862E839@Sun.COM> That looks like a bug in BytecodeName.parseBytecodeName. The 'new String' shortly after the error point should have been 'new Object'. Time for more unit testing! -- John From John.Rose at Sun.COM Thu Aug 6 18:06:32 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 06 Aug 2009 18:06:32 -0700 Subject: Mangled names for invokedynamic In-Reply-To: <3E7CFA1D-6542-4244-A6C2-5B669700086D@gmail.com> References: <3E7CFA1D-6542-4244-A6C2-5B669700086D@gmail.com> Message-ID: I just pushed some fixes and unit tests for mangling. Thanks for the report! -- John On Aug 1, 2009, at 1:25 PM, Attila Szegedi wrote: > Folks (well, primarily John I think), > > I'm trying to write a testcase for an invokedynamic call that > specifies "dyn:getprop:helloText" as the method name. So far, I've > tried the following (all using ASM to generate bytecode as I don't > know what if any is the javac-recognized syntax for these): From john.rose at sun.com Thu Aug 6 18:08:09 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 07 Aug 2009 01:08:09 +0000 Subject: hg: mlvm/mlvm: meth: sun.dyn.util.BytecodeName passes unit tests Message-ID: <20090807010809.AF21AE58F@hg.openjdk.java.net> Changeset: f0e76a3fe55d Author: jrose Date: 2009-08-06 18:04 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/f0e76a3fe55d meth: sun.dyn.util.BytecodeName passes unit tests + netbeans/meth/test/sun/dyn/util/BytecodeNameTest.java From john.rose at sun.com Thu Aug 6 18:08:50 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 07 Aug 2009 01:08:50 +0000 Subject: hg: mlvm/mlvm/jdk: meth: sun.dyn.util.BytecodeName passes unit tests Message-ID: <20090807010851.2504EE591@hg.openjdk.java.net> Changeset: a734350b0b96 Author: jrose Date: 2009-08-06 18:05 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a734350b0b96 meth: sun.dyn.util.BytecodeName passes unit tests ! indy.patch From yamauchi at google.com Fri Aug 7 15:03:25 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Fri, 7 Aug 2009 15:03:25 -0700 Subject: Continuations, here I come In-Reply-To: <4A72F132.508@Sun.COM> References: <4A72E643.9010407@jku.at> <4A72F132.508@Sun.COM> Message-ID: Hi all, I'm also curious to see/try the latest update/patch as I'd like to experiment with the continuation feature in the JVM. I have looked at this file (which I think is an old file) so far: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/2c1323e05f9a/callcc.patch I patched it to openjdk6 (Hotspot 11) and the test appears to work, though the monitor support seemed unfinished. BTW, here are two comments that I personally had about the API from the perspective of using continuations from the Java language (referring to the old patch): 1. I think that we don't want to run the finally clauses twice (once when the exception is thrown on 'copyStack' and again after the stack is resumed). 2. I think we want to unlock all the monitors on a stack save and relock them on a stack resume. (though I'm not sure what the intention of the unfinished code was.) Just my 2 cents. I understand that there has been quite bit of progress and a new patch since then. Thanks, Hiroshi On Fri, Jul 31, 2009 at 6:27 AM, Christian Thalinger wrote: > Lukas Stadler wrote: >> The current status: I could push the patch into the patch-repository, >> but I'm kind of a mercurial-newbie... Do you perhaps have any pointers >> to a description of how that works? :-) > > Sure. ?Well, you could read the Mercurial book[1], but I think that's > overkill for just one push. ?As far as I understand, you want to commit > a patch file without putting it into the series file. ?That's easy (e.g. > for a HotSpot patch): > > $ cd patches/hotspot/ > $ cp ~/cont.patch . > $ hg add cont.patch > $ hg commit -m "cont: New file." > $ hg push > > Hmm, and here we may have a problem: commit rights. ?Do you have an > OpenJDK username? ?Yes, you have: > > lstadler ? ? ? ?Lukas Stadler ? Johannes Kepler University Linz, Austria > > For a successful push you need three things: > > 1. an OpenJDK username > 2. commit rights (Mark can help you here) > 3. a valid default or default-push URL > > You can check the latter with: > > $ hg paths > default = http://hg.openjdk.java.net/mlvm/mlvm/hotspot > default-push = ssh://twisti at hg.openjdk.java.net/mlvm/mlvm/hotspot > > Hope that helps. > > [1] http://hgbook.red-bean.com/ > > -- Christian > _______________________________________________ > 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 Fri Aug 7 17:15:04 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 08 Aug 2009 00:15:04 +0000 Subject: hg: mlvm/mlvm: meth: more sun.dyn.util.BytecodeName test cases Message-ID: <20090808001504.D27E8E91F@hg.openjdk.java.net> Changeset: 7b03cdfd6265 Author: jrose Date: 2009-08-07 17:10 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/7b03cdfd6265 meth: more sun.dyn.util.BytecodeName test cases ! netbeans/meth/test/sun/dyn/util/BytecodeNameTest.java From mental at rydia.net Fri Aug 7 17:46:58 2009 From: mental at rydia.net (MenTaLguY) Date: Fri, 07 Aug 2009 20:46:58 -0400 Subject: Continuations, here I come In-Reply-To: <4A72E643.9010407@jku.at> References: <4A72E643.9010407@jku.at> Message-ID: <1249692418.4361.117.camel@bede> Hmm. I can't say I'm really a fan of the proposed API for delimited continuations. I'd really like to see something like this (pseudocode): public DelimitedContinuation makeAdder(final Integer value) { final StackMarker m = new StackMarker(); return (DelimitedContinuation)m.shift(new Callable { public Object call() { // if reset is called, a return/exception here // propagates to the continuation's caller, or else // to the m.shift() call site if prior to m.reset() return value + (Integer)m.reset( new DelimitedCapture() { public Object call(DelimitedContinuation dc) { // return/exception here unwinds back to // call site of m.shift() return dc; } } }); } }) } ... DelimitedContinuation adder; Integer result; adder = makeAdder(3); result = (Integer)adder.call(4); assert result == 7; result = (Integer)adder.call(6); assert result == 9 One of the *really* important properties of delimited continuations is that they are simple functions: they take an argument, they return a value. Additionally, ideally it should be possible to use 'adder' from many threads at once safely -- that is hard to do if you are forced to use holder objects to get around a lack of arguments or return values. I think in addition to delimited continuations (which need to be multi-shot and threadsafe insofar as they don't mutate shared objects), there is also a need for separate explicit support for coroutines, where the internal continuation is one-shot (as distinct from escape-only), thereby avoiding the security implications of full continuations. (Each coroutine would also need to support its own set of threadlocal values, since threadlocals in Java are heavily used for dynamic scoping, and switching between coroutines introduces a different dynamic scope.) -mental -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090807/03fa4f8b/attachment.bin From headius at headius.com Fri Aug 7 18:03:31 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 7 Aug 2009 21:03:31 -0400 Subject: Continuations, here I come In-Reply-To: <1249692418.4361.117.camel@bede> References: <4A72E643.9010407@jku.at> <1249692418.4361.117.camel@bede> Message-ID: On Fri, Aug 7, 2009 at 8:46 PM, MenTaLguY wrote: > I think in addition to delimited continuations (which need to be > multi-shot and threadsafe insofar as they don't mutate shared objects), > there is also a need for separate explicit support for coroutines, where > the internal continuation is one-shot (as distinct from escape-only), > thereby avoiding the security implications of full continuations. This also figures into making the continuation work applicable to real applications, since ideally the subset needed for coroutines would not have to violate Java security model and would therefore be more likely to make it into a real JDK at some point. I'm pretty stoked to try out the patches now that I've heard all the updates. Maybe I or someone else needs to do a build with indy, tailcall, and callcc all in the same build, just for experimentation purposes... - Charlie From john.rose at sun.com Fri Aug 7 18:17:13 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 08 Aug 2009 01:17:13 +0000 Subject: hg: mlvm/mlvm/jdk: meth: more sun.dyn.util.BytecodeName test cases Message-ID: <20090808011713.7FCD8E92B@hg.openjdk.java.net> Changeset: 7c01acbb1be2 Author: jrose Date: 2009-08-07 18:13 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7c01acbb1be2 meth: more sun.dyn.util.BytecodeName test cases ! indy.patch From john.rose at sun.com Fri Aug 7 18:17:12 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 08 Aug 2009 01:17:12 +0000 Subject: hg: mlvm/mlvm: meth: more sun.dyn.util.BytecodeName test cases Message-ID: <20090808011713.7EF20E92A@hg.openjdk.java.net> Changeset: 5958143570a7 Author: jrose Date: 2009-08-07 18:13 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/5958143570a7 meth: more sun.dyn.util.BytecodeName test cases ! netbeans/meth/test/sun/dyn/util/BytecodeNameTest.java From szegedia at gmail.com Sat Aug 8 00:56:42 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 8 Aug 2009 09:56:42 +0200 Subject: Continuations, here I come In-Reply-To: References: <4A72E643.9010407@jku.at> <4A72F132.508@Sun.COM> Message-ID: <229AB0C0-4EA4-46B0-9A7C-15FC5F22B566@gmail.com> On 2009.08.08., at 0:03, Hiroshi Yamauchi wrote: > Hi all, > > I'm also curious to see/try the latest update/patch as I'd like to > experiment with the continuation feature in the JVM. > > I have looked at this file (which I think is an old file) so far: > > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/2c1323e05f9a/callcc.patch > > I patched it to openjdk6 (Hotspot 11) and the test appears to work, > though the monitor support seemed unfinished. > > BTW, here are two comments that I personally had about the API from > the perspective of using continuations from the Java language > (referring to the old patch): > > 1. I think that we don't want to run the finally clauses twice (once > when the exception is thrown on 'copyStack' and again after the stack > is resumed). The thing is, the semantics of the finally block become application- specific when you throw in continuations in the mix. Some finally blocks are meant to clean up high-level application state (and thus need to only be executed on the very last time). Some finally blocks are meant to clean up transient state (i.e. a database connection) and should execute every time, plus need some mechanism for reestablishment of their state on resume; you yourself mention one typical example, which is locking of monitors. A good continuations mechanism should support both, and add language construct for distinguishing between the two. Now, this is not as daunting as it might sound. Since - as I said - the nature of the finally block becomes application-specific, you can just have an application-specific mechanism for checking whether it is a capture or the real exit, so you can do: try { ... } finally { if(isCapturingContinuation()) { ... capturing cleanup (usually unused) ... } else { ... final cleanup ... } ... transient cleanup ... } Those finally blocks that don't have this will be considered to have purely transient cleanup, of course. However, a support for reinitialization of transient state is naturally required. > 2. I think we want to unlock all the monitors on a stack save and > relock them on a stack resume. (though I'm not sure what the intention > of the unfinished code was.) Sure, that makes sense. Locks are typical transient state. You get unlocking for free if you decide to run the finally clauses on both continuation capture and final exit. Attila. -- twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com From emmanuel.castro at laposte.net Sat Aug 8 14:49:45 2009 From: emmanuel.castro at laposte.net (Emmanuel Castro) Date: Sat, 8 Aug 2009 23:49:45 +0200 Subject: Continuations, here I come In-Reply-To: <4A72E643.9010407@jku.at> References: <4A72E643.9010407@jku.at> Message-ID: <736021ac0908081449h66b66c46sfda0be05f87ea340@mail.gmail.com> I am currently working on an interpreter for a functional toy language. When the evaluation of an argument is suspended (using a continuation), the execution is resumed to the next argument, and so on. (A toy prototype will be available before Autumn) In my case, it is not realistic to create a DelimitedRunnable for each function application because most of the time it the continuation is not needed. I note the following. It might be a good idea to have two methods to make delimited continuations: - One when the capturing of the delimited continuation is most likely, using something like DelimitedRunnable; - One when the capturing of the delimited continuation is exceptional, with something like diff-ing two continuations. 2009/7/31 Lukas Stadler > For performance reasons there is one restriction: The delimited > continuation should not be cut within a stackframe. This might not seem > like a problem but remember that inline can collapse multiple java > stackframes into a single native one. > Isn't it possible to deoptimize the inlined stackframes? I've often heard about Deoptimization, especially in work about Tail Call Optimization by Arnold Schwaighofer. I understand that deoptimization can be expensive, but in the second case - when capturing is exceptional - I think it's worth it. - Emmanuel Castro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090808/37518764/attachment.html From raffaello.giulietti at gmail.com Mon Aug 10 09:54:46 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 10 Aug 2009 18:54:46 +0200 Subject: Internal Error (frame.cpp:1209) Message-ID: <4A8050D6.70407@gmail.com> Hi, I could finally build mlvm on Ubuntu 9.04 by following instructions from various sources. Unfortunately, upon first use of the javac I immediately got Internal Error (frame.cpp:1209), pid=xxxx, tid=yyyyyy Error: ShouldNotReachHere() This same error was already mentioned in http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-June/000762.html by Christian Thalinger. Some suggestion or workaround? Thanks Raffaello From Christian.Thalinger at Sun.COM Mon Aug 10 10:16:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 10 Aug 2009 19:16:18 +0200 Subject: Internal Error (frame.cpp:1209) In-Reply-To: <4A8050D6.70407@gmail.com> References: <4A8050D6.70407@gmail.com> Message-ID: <4A8055E2.8010200@Sun.COM> Raffaello Giulietti wrote: > Hi, > > I could finally build mlvm on Ubuntu 9.04 by following instructions from > various sources. > > Unfortunately, upon first use of the javac I immediately got > > Internal Error (frame.cpp:1209), pid=xxxx, tid=yyyyyy > Error: ShouldNotReachHere() > > This same error was already mentioned in > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-June/000762.html > by Christian Thalinger. > > Some suggestion or workaround? I'm currently working on a fix for that, I just need John to review it. You can workaround that problem with -J-Xint. -- Christian From weiyinteo at gmail.com Mon Aug 10 12:56:21 2009 From: weiyinteo at gmail.com (Wei Yin Teo) Date: Mon, 10 Aug 2009 20:56:21 +0100 Subject: Can't instantiate anonymous class more than 16 times Message-ID: Hi, After loading an anonymous class through the AnonymousClassLoader, I could construct the object by calling the newInstance on the class. But the 16th time failed. Here is the code and stack trace class LoadingTest { public void testLoading() { AnonymousClassLoader acl = new AnonymousClassLoader(); Class testClass = acl.loadClass(getClassBytes()); for (int i = 0; i < 100; i++) { try { testClass.newInstance(); } catch(Throwable e) { System.out.println("failed at " + i); e.printStackTrace(); throw e; } } } private byte[] getClassBytes() { ClassWriter cw = new ClassWriter(0); MethodVisitor mv; cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, "java/lang/Object", null); mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); mv.visitCode(); Label l0 = new Label(); mv.visitLabel(l0); mv.visitVarInsn(ALOAD, 0); mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "", "()V"); mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;"); mv.visitLdcInsn("constructed"); mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V"); mv.visitInsn(RETURN); Label l1 = new Label(); mv.visitLabel(l1); mv .visitLocalVariable("this", "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, l0, l1, 0); mv.visitMaxs(2, 1); mv.visitEnd(); cw.visitEnd(); return cw.toByteArray(): } } It appears at the 16th time, the JVM generate a ConstructorAccessor and it does not know how to handle anonymous class. Thanks, Wei Here is the output from the code. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = ======================================================================== constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed constructed failed at 16 java.lang.NoClassDefFoundError: InstanceTest/7572081 at sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown Source) at sun .reflect .DelegatingConstructorAccessorImpl .newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:539) at java.lang.Class.newInstance0(Class.java:372) at java.lang.Class.newInstance(Class.java:325) at test .com .gs .s4j.misc.AnonymousClassLoading.testLoading(AnonymousClassLoading.java: 47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 43) at java.lang.reflect.Method.invoke(Method.java:623) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at org .eclipse .jdt .internal .junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java: 130) at org .eclipse .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org .eclipse .jdt .internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java: 467) at org .eclipse .jdt .internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java: 683) at org .eclipse .jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java: 390) at org .eclipse .pde .internal .junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java: 62) at org .eclipse .pde .internal .junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 43) at java.lang.reflect.Method.invoke(Method.java:623) at org .eclipse .equinox .internal .app .EclipseAppContainer.callMethodWithException(EclipseAppContainer.java: 574) at org .eclipse .equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org .eclipse .core .runtime .internal .adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org .eclipse .core .runtime .internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org .eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 368) at org .eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 43) at java.lang.reflect.Method.invoke(Method.java:623) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287) Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 at org .eclipse .osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java: 494) at org .eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java: 410) at org .eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java: 398) at org .eclipse .osgi .internal .baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:331) ... 41 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090810/99d8a5d4/attachment.html From forax at univ-mlv.fr Mon Aug 10 14:54:50 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 10 Aug 2009 23:54:50 +0200 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: References: Message-ID: <4A80972A.2040402@univ-mlv.fr> Le 10/08/2009 21:56, Wei Yin Teo a ?crit : > Hi, > > After loading an anonymous class through the AnonymousClassLoader, I > could construct the object by calling the newInstance on the class. > But the 16th time failed. Here is the code and stack trace hum, perhaps a bug, could you try with : AnonymousClassLoader acl = new AnonymousClassLoader(LoadingTest.class); cheers, R?mi > > class LoadingTest { > > public void testLoading() { > AnonymousClassLoader acl = new AnonymousClassLoader(); > > Class testClass = acl.loadClass(getClassBytes()); > > for (int i = 0; i < 100; i++) { > try { > testClass.newInstance(); > } > catch(Throwable e) { > System.out.println("failed at " + i); > e.printStackTrace(); > throw e; > } > } > } > > private byte[] getClassBytes() { > ClassWriter cw = new ClassWriter(0); > MethodVisitor mv; > > cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, > "java/lang/Object", null); > mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); > mv.visitCode(); > Label l0 = new Label(); > mv.visitLabel(l0); > mv.visitVarInsn(ALOAD, 0); > mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "", "()V"); > mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", > "Ljava/io/PrintStream;"); > mv.visitLdcInsn("constructed"); > mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", > "(Ljava/lang/String;)V"); > mv.visitInsn(RETURN); > Label l1 = new Label(); > mv.visitLabel(l1); > mv > .visitLocalVariable("this", > "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, > l0, l1, 0); > mv.visitMaxs(2, 1); > mv.visitEnd(); > cw.visitEnd(); > return cw.toByteArray(): > } > } > > It appears at the 16th time, the JVM generate a ConstructorAccessor > and it does not know how to handle anonymous class. > > Thanks, > Wei > > Here is the output from the code. > ==================================================================================================================== > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > constructed > failed at 16 > java.lang.NoClassDefFoundError: InstanceTest/7572081 > at sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:539) > at java.lang.Class.newInstance0(Class.java:372) > at java.lang.Class.newInstance(Class.java:325) > at > test.com.gs.s4j.misc.AnonymousClassLoading.testLoading(AnonymousClassLoading.java:47) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:623) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at > org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) > at > org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:623) > at > org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:623) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) > at org.eclipse.equinox.launcher.Main.run(Main.java:1311) > at org.eclipse.equinox.launcher.Main.main(Main.java:1287) > Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 > at > org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494) > at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) > at > org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) > at > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) > at java.lang.ClassLoader.loadClass(ClassLoader.java:331) > ... 41 more > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20090810/0f467a2d/attachment.html From forax at univ-mlv.fr Mon Aug 10 15:19:45 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 11 Aug 2009 00:19:45 +0200 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <4A80972A.2040402@univ-mlv.fr> References: <4A80972A.2040402@univ-mlv.fr> Message-ID: <4A809D01.8070509@univ-mlv.fr> Le 10/08/2009 23:54, R?mi Forax a ?crit : > Le 10/08/2009 21:56, Wei Yin Teo a ?crit : >> Hi, >> >> After loading an anonymous class through the AnonymousClassLoader, I >> could construct the object by calling the newInstance on the class. >> But the 16th time failed. Here is the code and stack trace > > hum, perhaps a bug, > could you try with : > > AnonymousClassLoader acl = new AnonymousClassLoader(LoadingTest.class); > > cheers, > R?mi Forget what I've written. I am able to reproduce the bug. It seems you can't create more than 16 instances of an anonymous class, a really weird bug, isn't it. The known workaround is to create one class by instance :( ... byte[] classBytes = getClassBytes(); for (int i = 0; i < 100; i++) { Class testClass = acl.loadClass(classBytes); try { testClass.newInstance(); } ... R?mi > >> >> class LoadingTest { >> >> public void testLoading() { >> AnonymousClassLoader acl = new AnonymousClassLoader(); >> >> Class testClass = acl.loadClass(getClassBytes()); >> >> for (int i = 0; i < 100; i++) { >> try { >> testClass.newInstance(); >> } >> catch(Throwable e) { >> System.out.println("failed at " + i); >> e.printStackTrace(); >> throw e; >> } >> } >> } >> >> private byte[] getClassBytes() { >> ClassWriter cw = new ClassWriter(0); >> MethodVisitor mv; >> >> cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, >> "java/lang/Object", null); >> mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); >> mv.visitCode(); >> Label l0 = new Label(); >> mv.visitLabel(l0); >> mv.visitVarInsn(ALOAD, 0); >> mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "", "()V"); >> mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", >> "Ljava/io/PrintStream;"); >> mv.visitLdcInsn("constructed"); >> mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", >> "(Ljava/lang/String;)V"); >> mv.visitInsn(RETURN); >> Label l1 = new Label(); >> mv.visitLabel(l1); >> mv >> .visitLocalVariable("this", >> "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, >> l0, l1, 0); >> mv.visitMaxs(2, 1); >> mv.visitEnd(); >> cw.visitEnd(); >> return cw.toByteArray(): >> } >> } >> >> It appears at the 16th time, the JVM generate a ConstructorAccessor >> and it does not know how to handle anonymous class. >> >> Thanks, >> Wei >> >> Here is the output from the code. >> ==================================================================================================================== >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> constructed >> failed at 16 >> java.lang.NoClassDefFoundError: InstanceTest/7572081 >> at sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown Source) >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:539) >> at java.lang.Class.newInstance0(Class.java:372) >> at java.lang.Class.newInstance(Class.java:325) >> at >> test.com.gs.s4j.misc.AnonymousClassLoading.testLoading(AnonymousClassLoading.java:47) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:623) >> at junit.framework.TestCase.runTest(TestCase.java:164) >> at junit.framework.TestCase.runBare(TestCase.java:130) >> at junit.framework.TestResult$1.protect(TestResult.java:106) >> at junit.framework.TestResult.runProtected(TestResult.java:124) >> at junit.framework.TestResult.run(TestResult.java:109) >> at junit.framework.TestCase.run(TestCase.java:120) >> at >> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) >> at >> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) >> at >> org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) >> at >> org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:623) >> at >> org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) >> at >> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) >> at >> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) >> at >> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) >> at >> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) >> at >> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:623) >> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) >> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) >> at org.eclipse.equinox.launcher.Main.run(Main.java:1311) >> at org.eclipse.equinox.launcher.Main.main(Main.java:1287) >> Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 >> at >> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494) >> at >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) >> at >> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) >> at >> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:331) >> ... 41 more >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090811/d269ae43/attachment.html From weiyinteo at gmail.com Mon Aug 10 15:49:40 2009 From: weiyinteo at gmail.com (Wei Yin Teo) Date: Mon, 10 Aug 2009 23:49:40 +0100 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <4A809D01.8070509@univ-mlv.fr> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> Message-ID: <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> Right, I think the work around is working because we are getting a new class and we don't hit the threshold. The magic number 15 is the ReflectionFactory.inflationThreshold() as we can see in the class NativeConstructorAccessorImpl public Object newInstance(Object[] args) ... { if (++numInvocations > ReflectionFactory.inflationThreshold()) { ConstructorAccessorImpl acc = (ConstructorAccessorImpl) new MethodAccessorGenerator(). generateConstructor(...) ... I think the AnonymousClassLoader mangles the class name from InstanceTest to InstanceTest/123456. However the generated ConstructorAccessor would interpret that as a class InstanceTest. 123456 instead of InstanceTest and the JVM would then try to load InstanceTest/123456.class. Of course it can't be found anywhere. I suppose Class.forName() should not be able to locate it in the system(permGen?) name space, either. On further note, I can't load an anonymous class which subclass another anonymous class too; because the class loader can't find the super class. I am not too sure about how the class loading mechanism plays with anonymous classes, especially how do we maintain an anonymous class hierarchy. Thanks, Wei On 10 Aug 2009, at 23:19, R?mi Forax wrote: > Le 10/08/2009 23:54, R?mi Forax a ?crit : >> >> Le 10/08/2009 21:56, Wei Yin Teo a ?crit : >>> >>> Hi, >>> >>> After loading an anonymous class through the AnonymousClassLoader, >>> I could construct the object by calling the newInstance on the >>> class. But the 16th time failed. Here is the code and stack trace >> >> hum, perhaps a bug, >> could you try with : >> >> AnonymousClassLoader acl = new >> AnonymousClassLoader(LoadingTest.class); >> >> cheers, >> R?mi > > Forget what I've written. > I am able to reproduce the bug. > It seems you can't create more than 16 instances of an anonymous > class, > a really weird bug, isn't it. > > The known workaround is to create one class by instance :( > > ... > byte[] classBytes = getClassBytes(); > for (int i = 0; i < 100; i++) { > Class testClass = acl.loadClass(classBytes); > try { > testClass.newInstance(); > } > ... > > R?mi > >> >>> >>> class LoadingTest { >>> >>> public void testLoading() { >>> AnonymousClassLoader acl = new AnonymousClassLoader(); >>> >>> Class testClass = acl.loadClass(getClassBytes()); >>> >>> for (int i = 0; i < 100; i++) { >>> try { >>> testClass.newInstance(); >>> } >>> catch(Throwable e) { >>> System.out.println("failed at " + i); >>> e.printStackTrace(); >>> throw e; >>> } >>> } >>> } >>> >>> private byte[] getClassBytes() { >>> ClassWriter cw = new ClassWriter(0); >>> MethodVisitor mv; >>> >>> cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, >>> "java/lang/Object", null); >>> mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); >>> mv.visitCode(); >>> Label l0 = new Label(); >>> mv.visitLabel(l0); >>> mv.visitVarInsn(ALOAD, 0); >>> mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "", >>> "()V"); >>> mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", >>> "Ljava/io/PrintStream;"); >>> mv.visitLdcInsn("constructed"); >>> mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", >>> "(Ljava/lang/String;)V"); >>> mv.visitInsn(RETURN); >>> Label l1 = new Label(); >>> mv.visitLabel(l1); >>> mv >>> .visitLocalVariable("this", >>> "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, >>> l0, l1, 0); >>> mv.visitMaxs(2, 1); >>> mv.visitEnd(); >>> cw.visitEnd(); >>> return cw.toByteArray(): >>> } >>> } >>> >>> It appears at the 16th time, the JVM generate a >>> ConstructorAccessor and it does not know how to handle anonymous >>> class. >>> >>> Thanks, >>> Wei >>> >>> Here is the output from the code. >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> ==================================================================== >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> constructed >>> failed at 16 >>> java.lang.NoClassDefFoundError: InstanceTest/7572081 >>> at sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown >>> Source) >>> at >>> sun >>> .reflect >>> .DelegatingConstructorAccessorImpl >>> .newInstance(DelegatingConstructorAccessorImpl.java:45) >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:539) >>> at java.lang.Class.newInstance0(Class.java:372) >>> at java.lang.Class.newInstance(Class.java:325) >>> at >>> test >>> .com >>> .gs >>> .s4j >>> .misc.AnonymousClassLoading.testLoading(AnonymousClassLoading.java: >>> 47) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun >>> .reflect >>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun >>> .reflect >>> .DelegatingMethodAccessorImpl >>> .invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:623) >>> at junit.framework.TestCase.runTest(TestCase.java:164) >>> at junit.framework.TestCase.runBare(TestCase.java:130) >>> at junit.framework.TestResult$1.protect(TestResult.java:106) >>> at junit.framework.TestResult.runProtected(TestResult.java:124) >>> at junit.framework.TestResult.run(TestResult.java:109) >>> at junit.framework.TestCase.run(TestCase.java:120) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal >>> .junit >>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) >>> at >>> org >>> .eclipse >>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal >>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal >>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) >>> at >>> org >>> .eclipse >>> .jdt >>> .internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java: >>> 390) >>> at >>> org >>> .eclipse >>> .pde >>> .internal >>> .junit >>> .runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) >>> at >>> org >>> .eclipse >>> .pde >>> .internal >>> .junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun >>> .reflect >>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun >>> .reflect >>> .DelegatingMethodAccessorImpl >>> .invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:623) >>> at >>> org >>> .eclipse >>> .equinox >>> .internal >>> .app >>> .EclipseAppContainer >>> .callMethodWithException(EclipseAppContainer.java:574) >>> at >>> org >>> .eclipse >>> .equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java: >>> 196) >>> at >>> org >>> .eclipse >>> .core >>> .runtime >>> .internal >>> .adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java: >>> 110) >>> at >>> org >>> .eclipse >>> .core >>> .runtime >>> .internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java: >>> 79) >>> at >>> org >>> .eclipse >>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) >>> at >>> org >>> .eclipse >>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun >>> .reflect >>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun >>> .reflect >>> .DelegatingMethodAccessorImpl >>> .invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:623) >>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) >>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) >>> at org.eclipse.equinox.launcher.Main.run(Main.java:1311) >>> at org.eclipse.equinox.launcher.Main.main(Main.java:1287) >>> Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 >>> at >>> org >>> .eclipse >>> .osgi >>> .internal.loader.BundleLoader.findClassInternal(BundleLoader.java: >>> 494) >>> at >>> org >>> .eclipse >>> .osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) >>> at >>> org >>> .eclipse >>> .osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) >>> at >>> org >>> .eclipse >>> .osgi >>> .internal >>> .baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java: >>> 105) >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:331) >>> ... 41 more >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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/20090810/1cc52ab9/attachment.html From forax at univ-mlv.fr Mon Aug 10 18:09:07 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 11 Aug 2009 03:09:07 +0200 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> Message-ID: <4A80C4B3.9090508@univ-mlv.fr> Le 11/08/2009 00:49, Wei Yin Teo a ?crit : > Right, I think the work around is working because we are getting a new > class and we don't hit the threshold. > > The magic number 15 is the ReflectionFactory.inflationThreshold() as > we can see in the class NativeConstructorAccessorImpl > > > public Object newInstance(Object[] args) ... { > if (++numInvocations > ReflectionFactory.inflationThreshold()) { > ConstructorAccessorImpl acc = (ConstructorAccessorImpl) > new MethodAccessorGenerator(). > generateConstructor(...) > ... > > I think the AnonymousClassLoader mangles the class name from > InstanceTest to InstanceTest/123456. However the generated > ConstructorAccessor would interpret that as a class > InstanceTest.123456 instead of InstanceTest and the JVM would then try > to load InstanceTest/123456.class. Of course it can't be found > anywhere. I suppose Class.forName() should not be able to locate it in > the system(permGen?) name space, either. You're right the problem is in package sun.reflect but the problem is not a dot transformed to a slash or vice-versa. Class.forName() uses class loader mechanism, and anonymous class aren't registered in any classloader cache. The reflection factory (here MethodAccessorGenerator) generates a bytecode with the name of the anonymous class in the constant pool to be able to call the constructor of the anonymous class. When this bytecode is loaded, the VM tries to resolve it with a classloader mechanism, so it fails throwing a NoClassDefFound. So, short time workaround: use -Dsun.reflect.noInflation=false Another workaround, use method handle instead of reflection: // creation Constructor c = testClass.getConstructor((Class[])null); MethodHandle mh = MethodHandles.lookup().unreflectConstrcutor(c); // call mh.invoke(); John, I wonder if the interface of AnonymousClassLoader should not be changed to provide a method handle instead of a Class ? Else, it remember sending a patch to add a method getHostClass() to java.lang.Class or sun.misc.Unsafe to be able to know if a Class is an anonymous class or not. > > On further note, I can't load an anonymous class which subclass > another anonymous class too; because the class loader can't find the > super class. Yes, for the same reason. > I am not too sure about how the class loading mechanism plays with > anonymous classes, especially how do we maintain an anonymous class > hierarchy. As explain above, you can't. (technically, you can create a fake ClassLoader which contains all your anonymous classes) Anonymous classes like their Java counter-part are designed for loading small final classes like closures not for creating a whole hierarchy of anonymous classes. > > Thanks, > Wei Cheers, R?mi > > > On 10 Aug 2009, at 23:19, R?mi Forax wrote: > >> Le 10/08/2009 23:54, R?mi Forax a ?crit : >>> Le 10/08/2009 21:56, Wei Yin Teo a ?crit : >>>> Hi, >>>> >>>> After loading an anonymous class through the AnonymousClassLoader, >>>> I could construct the object by calling the newInstance on the >>>> class. But the 16th time failed. Here is the code and stack trace >>> >>> hum, perhaps a bug, >>> could you try with : >>> >>> AnonymousClassLoader acl = new AnonymousClassLoader(LoadingTest.class); >>> >>> cheers, >>> R?mi >> >> Forget what I've written. >> I am able to reproduce the bug. >> It seems you can't create more than 16 instances of an anonymous class, >> a really weird bug, isn't it. >> >> The known workaround is to create one class by instance :( >> >> ... >> byte[] classBytes = getClassBytes(); >> for (int i = 0; i < 100; i++) { >> Class testClass = acl.loadClass(classBytes); >> try { >> testClass.newInstance(); >> } >> ... >> >> R?mi >> >>> >>>> >>>> class LoadingTest { >>>> >>>> public void testLoading() { >>>> AnonymousClassLoader acl = new AnonymousClassLoader(); >>>> >>>> Class testClass = acl.loadClass(getClassBytes()); >>>> >>>> for (int i = 0; i < 100; i++) { >>>> try { >>>> testClass.newInstance(); >>>> } >>>> catch(Throwable e) { >>>> System.out.println("failed at " + i); >>>> e.printStackTrace(); >>>> throw e; >>>> } >>>> } >>>> } >>>> >>>> private byte[] getClassBytes() { >>>> ClassWriter cw = new ClassWriter(0); >>>> MethodVisitor mv; >>>> >>>> cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, >>>> "java/lang/Object", null); >>>> mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); >>>> mv.visitCode(); >>>> Label l0 = new Label(); >>>> mv.visitLabel(l0); >>>> mv.visitVarInsn(ALOAD, 0); >>>> mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "", "()V"); >>>> mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", >>>> "Ljava/io/PrintStream;"); >>>> mv.visitLdcInsn("constructed"); >>>> mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", >>>> "(Ljava/lang/String;)V"); >>>> mv.visitInsn(RETURN); >>>> Label l1 = new Label(); >>>> mv.visitLabel(l1); >>>> mv >>>> .visitLocalVariable("this", >>>> "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, >>>> l0, l1, 0); >>>> mv.visitMaxs(2, 1); >>>> mv.visitEnd(); >>>> cw.visitEnd(); >>>> return cw.toByteArray(): >>>> } >>>> } >>>> >>>> It appears at the 16th time, the JVM generate a ConstructorAccessor >>>> and it does not know how to handle anonymous class. >>>> >>>> Thanks, >>>> Wei >>>> >>>> Here is the output from the code. >>>> ==================================================================================================================== >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> constructed >>>> failed at 16 >>>> java.lang.NoClassDefFoundError: InstanceTest/7572081 >>>> at sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown >>>> Source) >>>> at >>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:539) >>>> at java.lang.Class.newInstance0(Class.java:372) >>>> at java.lang.Class.newInstance(Class.java:325) >>>> at >>>> test.com.gs.s4j.misc.AnonymousClassLoading.testLoading(AnonymousClassLoading.java:47) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>> at junit.framework.TestCase.runTest(TestCase.java:164) >>>> at junit.framework.TestCase.runBare(TestCase.java:130) >>>> at junit.framework.TestResult$1.protect(TestResult.java:106) >>>> at junit.framework.TestResult.runProtected(TestResult.java:124) >>>> at junit.framework.TestResult.run(TestResult.java:109) >>>> at junit.framework.TestCase.run(TestCase.java:120) >>>> at >>>> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) >>>> at >>>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>>> at >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) >>>> at >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) >>>> at >>>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) >>>> at >>>> org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) >>>> at >>>> org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>> at >>>> org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) >>>> at >>>> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) >>>> at >>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) >>>> at >>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) >>>> at >>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) >>>> at >>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) >>>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) >>>> at org.eclipse.equinox.launcher.Main.run(Main.java:1311) >>>> at org.eclipse.equinox.launcher.Main.main(Main.java:1287) >>>> Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 >>>> at >>>> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494) >>>> at >>>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) >>>> at >>>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398) >>>> at >>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:331) >>>> ... 41 more >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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 -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090811/b35d4fea/attachment.html From weiyinteo at gmail.com Tue Aug 11 12:03:58 2009 From: weiyinteo at gmail.com (Wei Yin Teo) Date: Tue, 11 Aug 2009 20:03:58 +0100 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <4A80C4B3.9090508@univ-mlv.fr> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> Message-ID: <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> On 11 Aug 2009, at 02:09, R?mi Forax wrote: > Le 11/08/2009 00:49, Wei Yin Teo a ?crit : >> >> Right, I think the work around is working because we are getting a >> new class and we don't hit the threshold. >> >> The magic number 15 is the ReflectionFactory.inflationThreshold() >> as we can see in the class NativeConstructorAccessorImpl >> >> >> public Object newInstance(Object[] args) ... { >> if (++numInvocations > >> ReflectionFactory.inflationThreshold()) { >> ConstructorAccessorImpl acc = (ConstructorAccessorImpl) >> new MethodAccessorGenerator(). >> generateConstructor(...) >> ... >> >> I think the AnonymousClassLoader mangles the class name from >> InstanceTest to InstanceTest/123456. However the generated >> ConstructorAccessor would interpret that as a class InstanceTest. >> 123456 instead of InstanceTest and the JVM would then try to load >> InstanceTest/123456.class. Of course it can't be found anywhere. I >> suppose Class.forName() should not be able to locate it in the >> system(permGen?) name space, either. > > You're right the problem is in package sun.reflect but the problem > is not > a dot transformed to a slash or vice-versa. > > Class.forName() uses class loader mechanism, and anonymous class > aren't registered > in any classloader cache. The reflection factory (here > MethodAccessorGenerator) > generates a bytecode with the name of the anonymous class in the > constant pool > to be able to call the constructor of the anonymous class. > When this bytecode is loaded, the VM tries to resolve it with a > classloader mechanism, > so it fails throwing a NoClassDefFound. > > So, short time workaround: > use -Dsun.reflect.noInflation=false Apparently, this doesn't work as you can see the above newInstance(..) calls MethodAccessorGenerator().generateConstructor(...) when the threshold is exceeded. Shouldn't it call ReflectionFactory.newConstructorAccessor(), which is guarded by the system property, instead? > > Another workaround, use method handle instead of reflection: > // creation > Constructor c = testClass.getConstructor((Class[])null); > MethodHandle mh = MethodHandles.lookup().unreflectConstrcutor(c); > // call > mh.invoke(); > I'll try this. > > > > John, I wonder if the interface of AnonymousClassLoader should not > be changed to provide a method handle instead of a Class ? > > Else, it remember sending a patch to add a method getHostClass() to > java.lang.Class or sun.misc.Unsafe to be able to know if a Class > is an anonymous class or not. > > >> >> On further note, I can't load an anonymous class which subclass >> another anonymous class too; because the class loader can't find >> the super class. > > Yes, for the same reason. > >> I am not too sure about how the class loading mechanism plays with >> anonymous classes, especially how do we maintain an anonymous class >> hierarchy. > > As explain above, you can't. > (technically, you can create a fake ClassLoader which contains all > your anonymous classes) > Anonymous classes like their Java counter-part are designed for > loading small final classes > like closures not for creating a whole hierarchy of anonymous classes. > > >> >> Thanks, >> Wei > > > Cheers, > R?mi > > >> >> >> On 10 Aug 2009, at 23:19, R?mi Forax wrote: >> >>> Le 10/08/2009 23:54, R?mi Forax a ?crit : >>>> >>>> Le 10/08/2009 21:56, Wei Yin Teo a ?crit : >>>>> >>>>> Hi, >>>>> >>>>> After loading an anonymous class through the >>>>> AnonymousClassLoader, I could construct the object by calling >>>>> the newInstance on the class. But the 16th time failed. Here is >>>>> the code and stack trace >>>> >>>> hum, perhaps a bug, >>>> could you try with : >>>> >>>> AnonymousClassLoader acl = new >>>> AnonymousClassLoader(LoadingTest.class); >>>> >>>> cheers, >>>> R?mi >>> >>> Forget what I've written. >>> I am able to reproduce the bug. >>> It seems you can't create more than 16 instances of an anonymous >>> class, >>> a really weird bug, isn't it. >>> >>> The known workaround is to create one class by instance :( >>> >>> ... >>> byte[] classBytes = getClassBytes(); >>> for (int i = 0; i < 100; i++) { >>> Class testClass = acl.loadClass(classBytes); >>> try { >>> testClass.newInstance(); >>> } >>> ... >>> >>> R?mi >>> >>>> >>>>> >>>>> class LoadingTest { >>>>> >>>>> public void testLoading() { >>>>> AnonymousClassLoader acl = new AnonymousClassLoader(); >>>>> >>>>> Class testClass = acl.loadClass(getClassBytes()); >>>>> >>>>> for (int i = 0; i < 100; i++) { >>>>> try { >>>>> testClass.newInstance(); >>>>> } >>>>> catch(Throwable e) { >>>>> System.out.println("failed at " + i); >>>>> e.printStackTrace(); >>>>> throw e; >>>>> } >>>>> } >>>>> } >>>>> >>>>> private byte[] getClassBytes() { >>>>> ClassWriter cw = new ClassWriter(0); >>>>> MethodVisitor mv; >>>>> >>>>> cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, >>>>> "java/lang/Object", null); >>>>> mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); >>>>> mv.visitCode(); >>>>> Label l0 = new Label(); >>>>> mv.visitLabel(l0); >>>>> mv.visitVarInsn(ALOAD, 0); >>>>> mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "", >>>>> "()V"); >>>>> mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", >>>>> "Ljava/io/PrintStream;"); >>>>> mv.visitLdcInsn("constructed"); >>>>> mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", >>>>> "println", >>>>> "(Ljava/lang/String;)V"); >>>>> mv.visitInsn(RETURN); >>>>> Label l1 = new Label(); >>>>> mv.visitLabel(l1); >>>>> mv >>>>> .visitLocalVariable("this", >>>>> "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, >>>>> l0, l1, 0); >>>>> mv.visitMaxs(2, 1); >>>>> mv.visitEnd(); >>>>> cw.visitEnd(); >>>>> return cw.toByteArray(): >>>>> } >>>>> } >>>>> >>>>> It appears at the 16th time, the JVM generate a >>>>> ConstructorAccessor and it does not know how to handle anonymous >>>>> class. >>>>> >>>>> Thanks, >>>>> Wei >>>>> >>>>> Here is the output from the code. >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> ================================================================== >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> constructed >>>>> failed at 16 >>>>> java.lang.NoClassDefFoundError: InstanceTest/7572081 >>>>> at >>>>> sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown >>>>> Source) >>>>> at >>>>> sun >>>>> .reflect >>>>> .DelegatingConstructorAccessorImpl >>>>> .newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java: >>>>> 539) >>>>> at java.lang.Class.newInstance0(Class.java:372) >>>>> at java.lang.Class.newInstance(Class.java:325) >>>>> at >>>>> test >>>>> .com >>>>> .gs >>>>> .s4j >>>>> .misc >>>>> .AnonymousClassLoading.testLoading(AnonymousClassLoading.java:47) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> sun >>>>> .reflect >>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>>> at >>>>> sun >>>>> .reflect >>>>> .DelegatingMethodAccessorImpl >>>>> .invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>>> at junit.framework.TestCase.runTest(TestCase.java:164) >>>>> at junit.framework.TestCase.runBare(TestCase.java:130) >>>>> at junit.framework.TestResult$1.protect(TestResult.java:106) >>>>> at junit.framework.TestResult.runProtected(TestResult.java:124) >>>>> at junit.framework.TestResult.run(TestResult.java:109) >>>>> at junit.framework.TestCase.run(TestCase.java:120) >>>>> at >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit >>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java: >>>>> 130) >>>>> at >>>>> org >>>>> .eclipse >>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java: >>>>> 38) >>>>> at >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) >>>>> at >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) >>>>> at >>>>> org >>>>> .eclipse >>>>> .jdt >>>>> .internal >>>>> .junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) >>>>> at >>>>> org >>>>> .eclipse >>>>> .pde >>>>> .internal >>>>> .junit >>>>> .runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java: >>>>> 62) >>>>> at >>>>> org >>>>> .eclipse >>>>> .pde >>>>> .internal >>>>> .junit.runtime.CoreTestApplication.run(CoreTestApplication.java: >>>>> 23) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> sun >>>>> .reflect >>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>>> at >>>>> sun >>>>> .reflect >>>>> .DelegatingMethodAccessorImpl >>>>> .invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>>> at >>>>> org >>>>> .eclipse >>>>> .equinox >>>>> .internal >>>>> .app >>>>> .EclipseAppContainer >>>>> .callMethodWithException(EclipseAppContainer.java:574) >>>>> at >>>>> org >>>>> .eclipse >>>>> .equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java: >>>>> 196) >>>>> at >>>>> org >>>>> .eclipse >>>>> .core >>>>> .runtime >>>>> .internal >>>>> .adaptor >>>>> .EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) >>>>> at >>>>> org >>>>> .eclipse >>>>> .core >>>>> .runtime >>>>> .internal >>>>> .adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) >>>>> at >>>>> org >>>>> .eclipse >>>>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) >>>>> at >>>>> org >>>>> .eclipse >>>>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> sun >>>>> .reflect >>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>>> at >>>>> sun >>>>> .reflect >>>>> .DelegatingMethodAccessorImpl >>>>> .invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: >>>>> 559) >>>>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) >>>>> at org.eclipse.equinox.launcher.Main.run(Main.java:1311) >>>>> at org.eclipse.equinox.launcher.Main.main(Main.java:1287) >>>>> Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 >>>>> at >>>>> org >>>>> .eclipse >>>>> .osgi >>>>> .internal >>>>> .loader.BundleLoader.findClassInternal(BundleLoader.java:494) >>>>> at >>>>> org >>>>> .eclipse >>>>> .osgi.internal.loader.BundleLoader.findClass(BundleLoader.java: >>>>> 410) >>>>> at >>>>> org >>>>> .eclipse >>>>> .osgi.internal.loader.BundleLoader.findClass(BundleLoader.java: >>>>> 398) >>>>> at >>>>> org >>>>> .eclipse >>>>> .osgi >>>>> .internal >>>>> .baseadaptor >>>>> .DefaultClassLoader.loadClass(DefaultClassLoader.java:105) >>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:331) >>>>> ... 41 more >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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/20090811/f8ae7a5d/attachment.html From weiyinteo at gmail.com Tue Aug 11 12:15:26 2009 From: weiyinteo at gmail.com (Wei Yin Teo) Date: Tue, 11 Aug 2009 20:15:26 +0100 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> Message-ID: <3CFE0616-F6C7-42E3-92F5-0EF22338EE95@gmail.com> It doesn't work. :( java.dyn.NoAccessException: receiver must be in caller class: InstanceTest/27271057.()void, from test.AnonymousClassLoading at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) at java.dyn.MethodHandles.unreflectImpl(MethodHandles.java:496) at java.dyn.MethodHandles $Lookup.unreflectConstructor(MethodHandles.java:408) at test.AnonymousClassLoading.testLoading(AnonymousClassLoading.java: 50) On 11 Aug 2009, at 20:03, Wei Yin Teo wrote: > > > On 11 Aug 2009, at 02:09, R?mi Forax wrote: > >> Le 11/08/2009 00:49, Wei Yin Teo a ?crit : >>> >>> Right, I think the work around is working because we are getting a >>> new class and we don't hit the threshold. >>> >>> The magic number 15 is the ReflectionFactory.inflationThreshold() >>> as we can see in the class NativeConstructorAccessorImpl >>> >>> >>> public Object newInstance(Object[] args) ... { >>> if (++numInvocations > >>> ReflectionFactory.inflationThreshold()) { >>> ConstructorAccessorImpl acc = (ConstructorAccessorImpl) >>> new MethodAccessorGenerator(). >>> generateConstructor(...) >>> ... >>> >>> I think the AnonymousClassLoader mangles the class name from >>> InstanceTest to InstanceTest/123456. However the generated >>> ConstructorAccessor would interpret that as a class InstanceTest. >>> 123456 instead of InstanceTest and the JVM would then try to load >>> InstanceTest/123456.class. Of course it can't be found anywhere. I >>> suppose Class.forName() should not be able to locate it in the >>> system(permGen?) name space, either. >> >> You're right the problem is in package sun.reflect but the problem >> is not >> a dot transformed to a slash or vice-versa. >> >> Class.forName() uses class loader mechanism, and anonymous class >> aren't registered >> in any classloader cache. The reflection factory (here >> MethodAccessorGenerator) >> generates a bytecode with the name of the anonymous class in the >> constant pool >> to be able to call the constructor of the anonymous class. >> When this bytecode is loaded, the VM tries to resolve it with a >> classloader mechanism, >> so it fails throwing a NoClassDefFound. >> >> So, short time workaround: >> use -Dsun.reflect.noInflation=false > > Apparently, this doesn't work as you can see the above > newInstance(..) calls > MethodAccessorGenerator().generateConstructor(...) when the > threshold is exceeded. Shouldn't it call > ReflectionFactory.newConstructorAccessor(), which is guarded by the > system property, instead? > >> >> Another workaround, use method handle instead of reflection: >> // creation >> Constructor c = testClass.getConstructor((Class[])null); >> MethodHandle mh = MethodHandles.lookup().unreflectConstrcutor(c); >> // call >> mh.invoke(); >> > I'll try this. >> >> >> >> John, I wonder if the interface of AnonymousClassLoader should not >> be changed to provide a method handle instead of a Class ? >> >> Else, it remember sending a patch to add a method getHostClass() to >> java.lang.Class or sun.misc.Unsafe to be able to know if a Class >> is an anonymous class or not. >> >> >>> >>> On further note, I can't load an anonymous class which subclass >>> another anonymous class too; because the class loader can't find >>> the super class. >> >> Yes, for the same reason. >> >>> I am not too sure about how the class loading mechanism plays with >>> anonymous classes, especially how do we maintain an anonymous >>> class hierarchy. >> >> As explain above, you can't. >> (technically, you can create a fake ClassLoader which contains all >> your anonymous classes) >> Anonymous classes like their Java counter-part are designed for >> loading small final classes >> like closures not for creating a whole hierarchy of anonymous >> classes. >> >> >>> >>> Thanks, >>> Wei >> >> >> Cheers, >> R?mi >> >> >>> >>> >>> On 10 Aug 2009, at 23:19, R?mi Forax wrote: >>> >>>> Le 10/08/2009 23:54, R?mi Forax a ?crit : >>>>> >>>>> Le 10/08/2009 21:56, Wei Yin Teo a ?crit : >>>>>> >>>>>> Hi, >>>>>> >>>>>> After loading an anonymous class through the >>>>>> AnonymousClassLoader, I could construct the object by calling >>>>>> the newInstance on the class. But the 16th time failed. Here is >>>>>> the code and stack trace >>>>> >>>>> hum, perhaps a bug, >>>>> could you try with : >>>>> >>>>> AnonymousClassLoader acl = new >>>>> AnonymousClassLoader(LoadingTest.class); >>>>> >>>>> cheers, >>>>> R?mi >>>> >>>> Forget what I've written. >>>> I am able to reproduce the bug. >>>> It seems you can't create more than 16 instances of an anonymous >>>> class, >>>> a really weird bug, isn't it. >>>> >>>> The known workaround is to create one class by instance :( >>>> >>>> ... >>>> byte[] classBytes = getClassBytes(); >>>> for (int i = 0; i < 100; i++) { >>>> Class testClass = acl.loadClass(classBytes); >>>> try { >>>> testClass.newInstance(); >>>> } >>>> ... >>>> >>>> R?mi >>>> >>>>> >>>>>> >>>>>> class LoadingTest { >>>>>> >>>>>> public void testLoading() { >>>>>> AnonymousClassLoader acl = new AnonymousClassLoader(); >>>>>> >>>>>> Class testClass = acl.loadClass(getClassBytes()); >>>>>> >>>>>> for (int i = 0; i < 100; i++) { >>>>>> try { >>>>>> testClass.newInstance(); >>>>>> } >>>>>> catch(Throwable e) { >>>>>> System.out.println("failed at " + i); >>>>>> e.printStackTrace(); >>>>>> throw e; >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> private byte[] getClassBytes() { >>>>>> ClassWriter cw = new ClassWriter(0); >>>>>> MethodVisitor mv; >>>>>> >>>>>> cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "InstanceTest", null, >>>>>> "java/lang/Object", null); >>>>>> mv = cw.visitMethod(ACC_PUBLIC, "", "()V", null, null); >>>>>> mv.visitCode(); >>>>>> Label l0 = new Label(); >>>>>> mv.visitLabel(l0); >>>>>> mv.visitVarInsn(ALOAD, 0); >>>>>> mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", >>>>>> "", "()V"); >>>>>> mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", >>>>>> "Ljava/io/PrintStream;"); >>>>>> mv.visitLdcInsn("constructed"); >>>>>> mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", >>>>>> "println", >>>>>> "(Ljava/lang/String;)V"); >>>>>> mv.visitInsn(RETURN); >>>>>> Label l1 = new Label(); >>>>>> mv.visitLabel(l1); >>>>>> mv >>>>>> .visitLocalVariable("this", >>>>>> "Ltest/com/gs/s4j/misc/AnonymousClassLoading;", null, >>>>>> l0, l1, 0); >>>>>> mv.visitMaxs(2, 1); >>>>>> mv.visitEnd(); >>>>>> cw.visitEnd(); >>>>>> return cw.toByteArray(): >>>>>> } >>>>>> } >>>>>> >>>>>> It appears at the 16th time, the JVM generate a >>>>>> ConstructorAccessor and it does not know how to handle >>>>>> anonymous class. >>>>>> >>>>>> Thanks, >>>>>> Wei >>>>>> >>>>>> Here is the output from the code. >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> = >>>>>> ================================================================= >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> constructed >>>>>> failed at 16 >>>>>> java.lang.NoClassDefFoundError: InstanceTest/7572081 >>>>>> at >>>>>> sun.reflect.GeneratedConstructorAccessor3.newInstance(Unknown >>>>>> Source) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .DelegatingConstructorAccessorImpl >>>>>> .newInstance(DelegatingConstructorAccessorImpl.java:45) >>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java: >>>>>> 539) >>>>>> at java.lang.Class.newInstance0(Class.java:372) >>>>>> at java.lang.Class.newInstance(Class.java:325) >>>>>> at >>>>>> test >>>>>> .com >>>>>> .gs >>>>>> .s4j >>>>>> .misc >>>>>> .AnonymousClassLoading.testLoading(AnonymousClassLoading.java:47) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: >>>>>> 57) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .DelegatingMethodAccessorImpl >>>>>> .invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>>>> at junit.framework.TestCase.runTest(TestCase.java:164) >>>>>> at junit.framework.TestCase.runBare(TestCase.java:130) >>>>>> at junit.framework.TestResult$1.protect(TestResult.java:106) >>>>>> at junit.framework.TestResult.runProtected(TestResult.java:124) >>>>>> at junit.framework.TestResult.run(TestResult.java:109) >>>>>> at junit.framework.TestCase.run(TestCase.java:120) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .jdt >>>>>> .internal >>>>>> .junit >>>>>> .runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java: >>>>>> 130) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .jdt.internal.junit.runner.TestExecution.run(TestExecution.java: >>>>>> 38) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .jdt >>>>>> .internal >>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java: >>>>>> 467) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .jdt >>>>>> .internal >>>>>> .junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java: >>>>>> 683) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .jdt >>>>>> .internal >>>>>> .junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .pde >>>>>> .internal >>>>>> .junit >>>>>> .runtime >>>>>> .RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .pde >>>>>> .internal >>>>>> .junit.runtime.CoreTestApplication.run(CoreTestApplication.java: >>>>>> 23) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: >>>>>> 57) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .DelegatingMethodAccessorImpl >>>>>> .invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .equinox >>>>>> .internal >>>>>> .app >>>>>> .EclipseAppContainer >>>>>> .callMethodWithException(EclipseAppContainer.java:574) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .equinox >>>>>> .internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .core >>>>>> .runtime >>>>>> .internal >>>>>> .adaptor >>>>>> .EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .core >>>>>> .runtime >>>>>> .internal >>>>>> .adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: >>>>>> 57) >>>>>> at >>>>>> sun >>>>>> .reflect >>>>>> .DelegatingMethodAccessorImpl >>>>>> .invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:623) >>>>>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: >>>>>> 559) >>>>>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) >>>>>> at org.eclipse.equinox.launcher.Main.run(Main.java:1311) >>>>>> at org.eclipse.equinox.launcher.Main.main(Main.java:1287) >>>>>> Caused by: java.lang.ClassNotFoundException: InstanceTest.7572081 >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .osgi >>>>>> .internal >>>>>> .loader.BundleLoader.findClassInternal(BundleLoader.java:494) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .osgi.internal.loader.BundleLoader.findClass(BundleLoader.java: >>>>>> 410) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .osgi.internal.loader.BundleLoader.findClass(BundleLoader.java: >>>>>> 398) >>>>>> at >>>>>> org >>>>>> .eclipse >>>>>> .osgi >>>>>> .internal >>>>>> .baseadaptor >>>>>> .DefaultClassLoader.loadClass(DefaultClassLoader.java:105) >>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:331) >>>>>> ... 41 more >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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/20090811/cc4d55db/attachment.html From forax at univ-mlv.fr Tue Aug 11 13:47:40 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 11 Aug 2009 22:47:40 +0200 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> Message-ID: <4A81D8EC.3030906@univ-mlv.fr> Le 11/08/2009 21:03, Wei Yin Teo a ?crit : > > > On 11 Aug 2009, at 02:09, R?mi Forax wrote: > >> Le 11/08/2009 00:49, Wei Yin Teo a ?crit : >>> Right, I think the work around is working because we are getting a >>> new class and we don't hit the threshold. >>> >>> The magic number 15 is the ReflectionFactory.inflationThreshold() as >>> we can see in the class NativeConstructorAccessorImpl >>> >>> >>> public Object newInstance(Object[] args) ... { >>> if (++numInvocations > ReflectionFactory.inflationThreshold()) { >>> ConstructorAccessorImpl acc = (ConstructorAccessorImpl) >>> new MethodAccessorGenerator(). >>> generateConstructor(...) >>> ... >>> >>> I think the AnonymousClassLoader mangles the class name from >>> InstanceTest to InstanceTest/123456. However the generated >>> ConstructorAccessor would interpret that as a class >>> InstanceTest.123456 instead of InstanceTest and the JVM would then >>> try to load InstanceTest/123456.class. Of course it can't be found >>> anywhere. I suppose Class.forName() should not be able to locate it >>> in the system(permGen?) name space, either. >> >> You're right the problem is in package sun.reflect but the problem is not >> a dot transformed to a slash or vice-versa. >> >> Class.forName() uses class loader mechanism, and anonymous class >> aren't registered >> in any classloader cache. The reflection factory (here >> MethodAccessorGenerator) >> generates a bytecode with the name of the anonymous class in the >> constant pool >> to be able to call the constructor of the anonymous class. >> When this bytecode is loaded, the VM tries to resolve it with a >> classloader mechanism, >> so it fails throwing a NoClassDefFound. >> >> So, short time workaround: >> use -Dsun.reflect.noInflation=false > > Apparently, this doesn't work as you can see the above newInstance(..) > calls MethodAccessorGenerator().generateConstructor(...) when the > threshold is exceeded. Shouldn't it call > ReflectionFactory.newConstructorAccessor(), which is guarded by the > system property, instead? oup, sorry -Dsun.reflect.noInflation=true R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090811/4971c1d1/attachment.html From weiyinteo at gmail.com Tue Aug 11 14:14:25 2009 From: weiyinteo at gmail.com (Wei Yin Teo) Date: Tue, 11 Aug 2009 22:14:25 +0100 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <4A81D8EC.3030906@univ-mlv.fr> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> <4A81D8EC.3030906@univ-mlv.fr> Message-ID: <64ADD406-06E3-4F81-A800-D43CC8CD2DD3@gmail.com> I tried both: true and false. :) In fact, setting it to true would fail the first time. In ReflectionFactory.newConstructorAccessor, we have if (noInflation) { return new MethodAccessorGenerator(). generateConstructor(c.getDeclaringClass(), c.getParameterTypes(), c.getExceptionTypes(), c.getModifiers()); } else { NativeConstructorAccessorImpl acc = new NativeConstructorAccessorImpl(c); DelegatingConstructorAccessorImpl res = new DelegatingConstructorAccessorImpl(acc); acc.setParent(res); return res; } We get the generated bytecode constructor the first time instead when the threshold is exceeded. On 11 Aug 2009, at 21:47, R?mi Forax wrote: > Le 11/08/2009 21:03, Wei Yin Teo a ?crit : >> >> >> >> On 11 Aug 2009, at 02:09, R?mi Forax wrote: >> >>> Le 11/08/2009 00:49, Wei Yin Teo a ?crit : >>>> >>>> Right, I think the work around is working because we are getting >>>> a new class and we don't hit the threshold. >>>> >>>> The magic number 15 is the ReflectionFactory.inflationThreshold() >>>> as we can see in the class NativeConstructorAccessorImpl >>>> >>>> >>>> public Object newInstance(Object[] args) ... { >>>> if (++numInvocations > >>>> ReflectionFactory.inflationThreshold()) { >>>> ConstructorAccessorImpl acc = (ConstructorAccessorImpl) >>>> new MethodAccessorGenerator(). >>>> generateConstructor(...) >>>> ... >>>> >>>> I think the AnonymousClassLoader mangles the class name from >>>> InstanceTest to InstanceTest/123456. However the generated >>>> ConstructorAccessor would interpret that as a class InstanceTest. >>>> 123456 instead of InstanceTest and the JVM would then try to load >>>> InstanceTest/123456.class. Of course it can't be found anywhere. >>>> I suppose Class.forName() should not be able to locate it in the >>>> system(permGen?) name space, either. >>> >>> You're right the problem is in package sun.reflect but the problem >>> is not >>> a dot transformed to a slash or vice-versa. >>> >>> Class.forName() uses class loader mechanism, and anonymous class >>> aren't registered >>> in any classloader cache. The reflection factory (here >>> MethodAccessorGenerator) >>> generates a bytecode with the name of the anonymous class in the >>> constant pool >>> to be able to call the constructor of the anonymous class. >>> When this bytecode is loaded, the VM tries to resolve it with a >>> classloader mechanism, >>> so it fails throwing a NoClassDefFound. >>> >>> So, short time workaround: >>> use -Dsun.reflect.noInflation=false >> >> Apparently, this doesn't work as you can see the above >> newInstance(..) calls >> MethodAccessorGenerator().generateConstructor(...) when the >> threshold is exceeded. Shouldn't it call >> ReflectionFactory.newConstructorAccessor(), which is guarded by the >> system property, instead? > > oup, sorry > -Dsun.reflect.noInflation=true > > R?mi > _______________________________________________ > 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/20090811/ae733a31/attachment.html From forax at univ-mlv.fr Tue Aug 11 14:28:27 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 11 Aug 2009 23:28:27 +0200 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <3CFE0616-F6C7-42E3-92F5-0EF22338EE95@gmail.com> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> <3CFE0616-F6C7-42E3-92F5-0EF22338EE95@gmail.com> Message-ID: <4A81E27B.4000408@univ-mlv.fr> Le 11/08/2009 21:15, Wei Yin Teo a ?crit : > It doesn't work. :( > > > java.dyn.NoAccessException: receiver must be in caller class: > InstanceTest/27271057.()void, from test.AnonymousClassLoading > at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) > at java.dyn.MethodHandles.unreflectImpl(MethodHandles.java:496) > at > java.dyn.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:408) > at test.AnonymousClassLoading.testLoading(AnonymousClassLoading.java:50) This is another bug :( Not your lucky day :) This one is funny because this is a bug totally in the mind of the programmer. There is a mismatch, the reflection API says "constructor dot invoke" which for the VM means "call ()" but it means create a new instance. So here, the code tries to just called the method and failed because you are not in caller class. To summarize, unreflectConstructor() is currently broken :( R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090811/abb298ba/attachment.html From forax at univ-mlv.fr Tue Aug 11 15:05:21 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 12 Aug 2009 00:05:21 +0200 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <64ADD406-06E3-4F81-A800-D43CC8CD2DD3@gmail.com> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> <4A81D8EC.3030906@univ-mlv.fr> <64ADD406-06E3-4F81-A800-D43CC8CD2DD3@gmail.com> Message-ID: <4A81EB21.3000408@univ-mlv.fr> Le 11/08/2009 23:14, Wei Yin Teo a ?crit : > I tried both: true and false. :) > > In fact, setting it to true would fail the first time. In > ReflectionFactory.newConstructorAccessor, we have > > if (noInflation) { > return new MethodAccessorGenerator(). > generateConstructor(c.getDeclaringClass(), > c.getParameterTypes(), > c.getExceptionTypes(), > c.getModifiers()); > } else { > NativeConstructorAccessorImpl acc = > new NativeConstructorAccessorImpl(c); > DelegatingConstructorAccessorImpl res = > new DelegatingConstructorAccessorImpl(acc); > acc.setParent(res); > return res; > } > > We get the generated bytecode constructor the first time instead when > the threshold is exceeded. I see two other solution, you can bump the threshold to Integer.MAX_VALUE or use this gory hack :) Constructor constructor = testClass.getConstructor((Class[])null); constructor.newInstance(); // Initialize accessor which is lazily created Field constructorPrimaryAccessorField = Constructor.class.getDeclaredField("constructorAccessor"); constructorPrimaryAccessorField.setAccessible(true); Object constructorPrimaryAccessor = constructorPrimaryAccessorField.get(constructor); // traverse delegate Field delegateField = constructorPrimaryAccessor.getClass().getDeclaredField("delegate"); delegateField.setAccessible(true); Object nativeAccessor = delegateField.get(constructorPrimaryAccessor); Field counterField = nativeAccessor.getClass().getDeclaredField("numInvocations"); counterField.setAccessible(true); for (int i = 0; i < 100; i++) { try { constructor.newInstance(); // reset counter counterField.setInt(nativeAccessor, 0); } catch(Throwable e) { ... R?mi > > > On 11 Aug 2009, at 21:47, R?mi Forax wrote: > >> Le 11/08/2009 21:03, Wei Yin Teo a ?crit : >>> >>> >>> On 11 Aug 2009, at 02:09, R?mi Forax wrote: >>> >>>> Le 11/08/2009 00:49, Wei Yin Teo a ?crit : >>>>> Right, I think the work around is working because we are getting a >>>>> new class and we don't hit the threshold. >>>>> >>>>> The magic number 15 is the ReflectionFactory.inflationThreshold() >>>>> as we can see in the class NativeConstructorAccessorImpl >>>>> >>>>> >>>>> public Object newInstance(Object[] args) ... { >>>>> if (++numInvocations > ReflectionFactory.inflationThreshold()) { >>>>> ConstructorAccessorImpl acc = (ConstructorAccessorImpl) >>>>> new MethodAccessorGenerator(). >>>>> generateConstructor(...) >>>>> ... >>>>> >>>>> I think the AnonymousClassLoader mangles the class name from >>>>> InstanceTest to InstanceTest/123456. However the generated >>>>> ConstructorAccessor would interpret that as a class >>>>> InstanceTest.123456 instead of InstanceTest and the JVM would then >>>>> try to load InstanceTest/123456.class. Of course it can't be found >>>>> anywhere. I suppose Class.forName() should not be able to locate >>>>> it in the system(permGen?) name space, either. >>>> >>>> You're right the problem is in package sun.reflect but the problem >>>> is not >>>> a dot transformed to a slash or vice-versa. >>>> >>>> Class.forName() uses class loader mechanism, and anonymous class >>>> aren't registered >>>> in any classloader cache. The reflection factory (here >>>> MethodAccessorGenerator) >>>> generates a bytecode with the name of the anonymous class in the >>>> constant pool >>>> to be able to call the constructor of the anonymous class. >>>> When this bytecode is loaded, the VM tries to resolve it with a >>>> classloader mechanism, >>>> so it fails throwing a NoClassDefFound. >>>> >>>> So, short time workaround: >>>> use -Dsun.reflect.noInflation=false >>> >>> Apparently, this doesn't work as you can see the above >>> newInstance(..) calls >>> MethodAccessorGenerator().generateConstructor(...) when the >>> threshold is exceeded. Shouldn't it call >>> ReflectionFactory.newConstructorAccessor(), which is guarded by the >>> system property, instead? >> >> oup, sorry >> -Dsun.reflect.noInflation=true >> >> R?mi >> _______________________________________________ >> 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 -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090812/6e6f62fc/attachment.html From weiyinteo at gmail.com Tue Aug 11 14:59:34 2009 From: weiyinteo at gmail.com (Wei Yin Teo) Date: Tue, 11 Aug 2009 22:59:34 +0100 Subject: Can't instantiate anonymous class more than 16 times In-Reply-To: <4A81E27B.4000408@univ-mlv.fr> References: <4A80972A.2040402@univ-mlv.fr> <4A809D01.8070509@univ-mlv.fr> <9D73ABC3-9878-4F6E-B64B-D3C0CAE1AD47@gmail.com> <4A80C4B3.9090508@univ-mlv.fr> <1D0F070E-9684-4BFB-8BCB-68CEEBE058A4@gmail.com> <3CFE0616-F6C7-42E3-92F5-0EF22338EE95@gmail.com> <4A81E27B.4000408@univ-mlv.fr> Message-ID: <9D987E24-8288-4A92-B498-D7601BE41DFE@gmail.com> No worry. Once a bug is identified, it can be fixed. :) Anyway, I've found the work around i.e. by increasing the threshold using -Dsun.reflect.inflationThreshold=100000000. On 11 Aug 2009, at 22:28, R?mi Forax wrote: > Le 11/08/2009 21:15, Wei Yin Teo a ?crit : >> >> It doesn't work. :( >> >> >> java.dyn.NoAccessException: receiver must be in caller class: >> InstanceTest/27271057.()void, from test.AnonymousClassLoading >> at sun.dyn.MemberName.newNoAccessException(MemberName.java:421) >> at java.dyn.MethodHandles.unreflectImpl(MethodHandles.java:496) >> at java.dyn.MethodHandles >> $Lookup.unreflectConstructor(MethodHandles.java:408) >> at >> test.AnonymousClassLoading.testLoading(AnonymousClassLoading.java:50) > > This is another bug :( > Not your lucky day :) > > This one is funny because this is a bug totally in the mind of the > programmer. > There is a mismatch, the reflection API says "constructor dot invoke" > which for the VM means "call ()" but it means create a new > instance. > So here, the code tries to just called the method > and failed because you are not in caller class. > > To summarize, unreflectConstructor() is currently broken :( > > R?mi > > > > _______________________________________________ > 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/20090811/9f2bcca7/attachment.html From yamauchi at google.com Wed Aug 12 12:43:04 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 12 Aug 2009 12:43:04 -0700 Subject: Continuations, here I come In-Reply-To: <229AB0C0-4EA4-46B0-9A7C-15FC5F22B566@gmail.com> References: <4A72E643.9010407@jku.at> <4A72F132.508@Sun.COM> <229AB0C0-4EA4-46B0-9A7C-15FC5F22B566@gmail.com> Message-ID: Hi Attila, On Sat, Aug 8, 2009 at 12:56 AM, Attila Szegedi wrote: > The thing is, the semantics of the finally block become application- > specific when you throw in continuations in the mix. Some finally > blocks are meant to clean up high-level application state (and thus > need to only be executed on the very last time). Some finally blocks > are meant to clean up transient state (i.e. a database connection) and > should execute every time, plus need some mechanism for > reestablishment of their state on resume; you yourself mention one > typical example, which is locking of monitors. > > A good continuations mechanism should support both, and add language > construct for distinguishing between the two. Now, this is not as > daunting as it might sound. Since - as I said - the nature of the > finally block becomes application-specific, you can just have an > application-specific mechanism for checking whether it is a capture or > the real exit, so you can do: > > try { > ... > } > finally { > ? ?if(isCapturingContinuation()) { > ? ? ? ?... capturing cleanup (usually unused) ... > ? ?} > ? ?else { > ? ? ? ?... final cleanup ... > ? ?} > ? ?... transient cleanup ... > } > > Those finally blocks that don't have this will be considered to have > purely transient cleanup, of course. However, a support for > reinitialization of transient state is naturally required. You are probably right about that. It appears that there is currently no obvious support for reinitialization on resume (aside from monitors, which I argued, should be handled like transient state above.) So, my thinking was that finalizers are meant for final cleanup only. Also, it's not impossible to do the cleanup/reinitialization of transient state without language support if the app code is written continuation aware, though it'd be awkward. But if not all the app code isn't written continuation aware (eg existing legacy code), finalizers would be written for final cleanup, in which case, running them more than once would not be a good idea. Anyhow, it sounds like an interesting question :) BTW, will the continuation feature be in the planned JDK7? Thanks, Hiroshi From forax at univ-mlv.fr Thu Aug 13 01:42:18 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 13 Aug 2009 10:42:18 +0200 Subject: Bug in sun.dyn.util.Wrapper.forWrapperType Message-ID: <4A83D1EA.3030609@univ-mlv.fr> I was playing with findbugs on jdk7 and it find a bug in sun.dyn.util.Wrapper /** Return the wrapper that wraps values into the given wrapper type. * If it is {@code Object} or an interface, return {@code OBJECT}. * Otherwise, it must be a wrapper type. * The type must not be a primitive type. * @throws IllegalArgumentException for unexpected types */ public static Wrapper forWrapperType(Class type) { Wrapper w = findWrapperType(type); if (w != null) return w; for (Wrapper x : values()) if (w.wrapperType == type) throw new InternalError(); // redo hash function throw newIllegalArgumentException("not wrapper: "+type); } here if (w.wrapperType == type) should be if (x.wrapperType == type) R?mi From fredrik.ohrstrom at oracle.com Mon Aug 17 05:53:52 2009 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 17 Aug 2009 14:53:52 +0200 Subject: I would like to discuss the MethodHandles factory In-Reply-To: References: <4A0834AB.70503@oracle.com> <4A1E1000.3080203@sun.com> Message-ID: <4A8952E0.1010609@oracle.com> John Rose skrev: > On May 27, 2009, at 9:16 PM, Charles Oliver Nutter wrote: > > >> we *must* give the keys to the castle to language >> developers, by opening up the very guts of the JVM's optimizing >> pipeline >> > > I agree that static type checking for method handles would be very > useful, but the language design work is difficult and subtle. > > As method handles become useful, they may tip the scales in favor of > adopting more (or all) of Neal Gafter's closures proposals. > > If Neal's design is adapted so that that various function-type > interfaces are not guaranteed to reify a closure's type at runtime, I > think we could fit method handles under closures. I'm not sure how > much of a distortion that would be; there will be some. > > So this: > x instanceof {int => String} > would translate to something like > x instanceof MethodHandle > && ((MethodHandle)x).type() > .isAssignableTo(MethodType.make(String.class, int.class)) > > And {int => String}.class would either be illegal or produce an > interface with lots of special magic treatment. > > Or maybe {int => String}.class would be a MethodType. As I said, some > distortion is likely. > Yes, some distortion is likely. But MethodHandles are so close to closures (no pun intended) that it would be a waste, not to use them. I have been thinking about the relationship between MethodHandles, closures and stored messages, here: http://blogs.oracle.com/ohrstrom/2009/08/using_methodhandles_to_reconci.html Closures can even be useful for the dynamic language runtime developer! :-) //Fredrik From John.Rose at Sun.COM Mon Aug 17 12:26:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 17 Aug 2009 12:26:16 -0700 Subject: Bug in sun.dyn.util.Wrapper.forWrapperType In-Reply-To: <4A83D1EA.3030609@univ-mlv.fr> References: <4A83D1EA.3030609@univ-mlv.fr> Message-ID: <483A1564-6469-48C7-B0C6-F23ED015A34B@sun.com> Thanks! -- John On Aug 13, 2009, at 1:42 AM, R?mi Forax wrote: > I was playing with findbugs on jdk7 > and it find a bug in sun.dyn.util.Wrapper From szegedia at gmail.com Mon Aug 17 13:06:25 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 17 Aug 2009 22:06:25 +0200 Subject: Problem with collectArguments on primitive array type Message-ID: <814AC154-0520-4019-9CF5-C1EE745008C7@gmail.com> Hi folks, I have this program that doesn't work with mlvm build from August 4: --------------------- import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; public class TestCollectArguments { public static void main(String[] args) throws Throwable { MethodHandle xv = MethodHandles.publicLookup().findVirtual( TestCollectArguments.class, "xv", MethodType.make(int.class, int.class, int[].class)); // This works - exact invocation System.out.println(MethodHandles.invoke(xv, new TestCollectArguments(), 1, new int[] { 2, 3 })); MethodHandle collecting = MethodHandles.collectArguments(xv, MethodType.make(int.class, Object.class, int.class, int.class, int.class)); // This fails - collecting arguments System.out.println(MethodHandles.invoke(collecting, new TestCollectArguments(), 1, 2, 3)); } public int xv(int y, int... z) { for (int zz : z) { y += zz; } return y; } } --------------------- It throws: Exception in thread "main" java.dyn.WrongMethodTypeException: [Ljava.lang.Object; cannot be cast to [I at sun.dyn.FromGeneric$A3.invoke_I3(FromGeneric.java:543) at sun.dyn.FilterGeneric$F4.invoke_C2(FilterGeneric.java:631) at sun.dyn.ToGeneric$A4.target(ToGeneric.java:746) at sun.dyn.ToGeneric$A4.targetA4(ToGeneric.java:750) at sun.dyn.ToGeneric$A4.invoke_I(ToGeneric.java:766) at sun.dyn.FromGeneric$A5.invoke_I5(FromGeneric.java:567) at java.dyn.MethodHandles.invoke(MethodHandles.java:638) at TestCollectArguments.main(TestCollectArguments.java:21) Seems it has troubles collecting arguments for an int[] vararg. Attila. From szegedia at gmail.com Mon Aug 17 14:02:43 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 17 Aug 2009 23:02:43 +0200 Subject: Problem with collectArguments on primitive array type In-Reply-To: <814AC154-0520-4019-9CF5-C1EE745008C7@gmail.com> References: <814AC154-0520-4019-9CF5-C1EE745008C7@gmail.com> Message-ID: <498409F2-8C38-4552-AAC9-51422060067F@gmail.com> Actually, this also fails for non-primitive arrays. Changing every "int" to "String" will give java.dyn.WrongMethodTypeException: [Ljava.lang.Object; cannot be cast to [Ljava.lang.String; So, it seems like the problem is even more generic... (Alternatively, I'm doing something wrong...) Attila. On 2009.08.17., at 22:06, Attila Szegedi wrote: > Hi folks, > > I have this program that doesn't work with mlvm build from August 4: > > --------------------- > import java.dyn.MethodHandle; > import java.dyn.MethodHandles; > import java.dyn.MethodType; > > public class TestCollectArguments > { > public static void main(String[] args) throws Throwable > { > MethodHandle xv = MethodHandles.publicLookup().findVirtual( > TestCollectArguments.class, "xv", > MethodType.make(int.class, > int.class, int[].class)); > // This works - exact invocation > System.out.println(MethodHandles.invoke(xv, new > TestCollectArguments(), > 1, new int[] { 2, 3 })); > MethodHandle collecting = MethodHandles.collectArguments(xv, > MethodType.make(int.class, Object.class, int.class, > int.class, > int.class)); > // This fails - collecting arguments > System.out.println(MethodHandles.invoke(collecting, > new TestCollectArguments(), 1, 2, 3)); > } > > public int xv(int y, int... z) > { > for (int zz : z) > { > y += zz; > } > return y; > } > } > --------------------- > > It throws: > > Exception in thread "main" java.dyn.WrongMethodTypeException: > [Ljava.lang.Object; cannot be cast to [I > at sun.dyn.FromGeneric$A3.invoke_I3(FromGeneric.java:543) > at sun.dyn.FilterGeneric$F4.invoke_C2(FilterGeneric.java:631) > at sun.dyn.ToGeneric$A4.target(ToGeneric.java:746) > at sun.dyn.ToGeneric$A4.targetA4(ToGeneric.java:750) > at sun.dyn.ToGeneric$A4.invoke_I(ToGeneric.java:766) > at sun.dyn.FromGeneric$A5.invoke_I5(FromGeneric.java:567) > at java.dyn.MethodHandles.invoke(MethodHandles.java:638) > at TestCollectArguments.main(TestCollectArguments.java:21) > > Seems it has troubles collecting arguments for an int[] vararg. > > Attila. From John.Rose at Sun.COM Mon Aug 17 15:43:08 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 17 Aug 2009 15:43:08 -0700 Subject: Problem with collectArguments on primitive array type In-Reply-To: <814AC154-0520-4019-9CF5-C1EE745008C7@gmail.com> References: <814AC154-0520-4019-9CF5-C1EE745008C7@gmail.com> Message-ID: Hi Atilla. It's a bug. The collector created in sun.dyn.MHI.collectArguments (from ValueConversions.varargsArray) creates an Object[] unconditionally; it needs to be generalized to other element types. In the backtrace you are seeing, F4.invoke_C2 has applied 'filter' to the two incoming boxed ints and gotten an Object[] instead of the int[] required by the 'target', which is a wrapper (via A3.invoke_I3) for your strongly-typed xv function. -- John > > It throws: > > Exception in thread "main" java.dyn.WrongMethodTypeException: > [Ljava.lang.Object; cannot be cast to [I > at sun.dyn.FromGeneric$A3.invoke_I3(FromGeneric.java:543) > at sun.dyn.FilterGeneric$F4.invoke_C2(FilterGeneric.java:631) > at sun.dyn.ToGeneric$A4.target(ToGeneric.java:746) > at sun.dyn.ToGeneric$A4.targetA4(ToGeneric.java:750) > at sun.dyn.ToGeneric$A4.invoke_I(ToGeneric.java:766) > at sun.dyn.FromGeneric$A5.invoke_I5(FromGeneric.java:567) > at java.dyn.MethodHandles.invoke(MethodHandles.java:638) > at TestCollectArguments.main(TestCollectArguments.java:21) > > Seems it has troubles collecting arguments for an int[] vararg. > > Attila. > > _______________________________________________ > 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/20090817/0f517bfa/attachment.html From Christian.Thalinger at Sun.COM Tue Aug 18 01:55:55 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 Aug 2009 10:55:55 +0200 Subject: findVirtual problem Message-ID: <4A8A6C9B.70101@Sun.COM> Hi! Looks like there is a problem with findVirtual. Since I don't know very much about the MethodHandle Java level, I want to be sure it's not my fault. Doing: MethodHandle mh = MethodHandles.lookup().findVirtual(Object.class, "toString", MethodType.make(String.class)); String result = mh.invoke("foo"); results in: Exception in thread "main" java.dyn.WrongMethodTypeException: ()Ljava/lang/String; cannot be called as (Ljava/lang/String;)Ljava/lang/String; which looks very odd to me. This also happens with other virtuals that take e.g. ints. Is it my fault or is there a bug in MethodType? -- Christian From szegedia at gmail.com Tue Aug 18 01:59:49 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 18 Aug 2009 10:59:49 +0200 Subject: findVirtual problem In-Reply-To: <4A8A6C9B.70101@Sun.COM> References: <4A8A6C9B.70101@Sun.COM> Message-ID: <620EACAA-EA90-4B9E-BEB0-284F4CAB4ECF@gmail.com> Shouldn't that be mh.invoke("foo") ? It returns a String and takes an Object. Attila. On 2009.08.18., at 10:55, Christian Thalinger wrote: > MethodHandle mh = MethodHandles.lookup().findVirtual(Object.class, > "toString", MethodType.make(String.class)); > String result = mh.invoke("foo"); From Christian.Thalinger at Sun.COM Tue Aug 18 02:25:35 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 Aug 2009 11:25:35 +0200 Subject: findVirtual problem In-Reply-To: <620EACAA-EA90-4B9E-BEB0-284F4CAB4ECF@gmail.com> References: <4A8A6C9B.70101@Sun.COM> <620EACAA-EA90-4B9E-BEB0-284F4CAB4ECF@gmail.com> Message-ID: <4A8A738F.60504@Sun.COM> Attila Szegedi wrote: > Shouldn't that be > > mh.invoke("foo") > > ? It returns a String and takes an Object. No, the syntax is correct. A MethodHandle invoke only specifies the return type. -- Christian From raffaello.giulietti at gmail.com Tue Aug 18 06:07:59 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 18 Aug 2009 15:07:59 +0200 Subject: findVirtual problem In-Reply-To: <4A8A738F.60504@Sun.COM> References: <4A8A6C9B.70101@Sun.COM> <620EACAA-EA90-4B9E-BEB0-284F4CAB4ECF@gmail.com> <4A8A738F.60504@Sun.COM> Message-ID: <4A8AA7AF.10701@gmail.com> Christian Thalinger wrote: > Attila Szegedi wrote: >> Shouldn't that be >> >> mh.invoke("foo") >> >> ? It returns a String and takes an Object. > > No, the syntax is correct. A MethodHandle invoke only specifies the > return type. > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev Hi Christian, do an upcast String result = mh.invoke((Object) "foo"); From raffaello.giulietti at gmail.com Tue Aug 18 06:29:29 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 18 Aug 2009 15:29:29 +0200 Subject: Throwable Message-ID: <4A8AACB9.5060106@gmail.com> The language compiler complains about an unreported exception Throwable; must be caught or declared to be thrown in using both InvokeDynamic and the (invisible) MethodHandle.invoke() Why is this so? What about an (unchecked) RuntimeException instead? From raffaello.giulietti at gmail.com Tue Aug 18 07:45:40 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 18 Aug 2009 16:45:40 +0200 Subject: Inlining Message-ID: <4A8ABE94.8030602@gmail.com> * Is there a special -XX: flag to turn on inlining of methods invoked via method handles? * Or must something be enabled during the build of mlvm? Thanks Raffaello From Christian.Thalinger at Sun.COM Tue Aug 18 11:02:48 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 Aug 2009 20:02:48 +0200 Subject: Inlining In-Reply-To: <4A8ABE94.8030602@gmail.com> References: <4A8ABE94.8030602@gmail.com> Message-ID: <4A8AECC8.1080400@Sun.COM> Raffaello Giulietti wrote: > * Is there a special -XX: flag to turn on inlining of methods invoked > via method handles? > * Or must something be enabled during the build of mlvm? No, inlining is enabled by default. Currently only DMH invokes are inlined, but I'm working on inlining the rest. Are you missing specific calls? I wanted to write a status update anyway... Yesterday I could inline for the first time a whole GuardWithTest calling sequence (with adjusting some switches). The inlined sequence looks like this (methods take one int argument and return an int): 1% b gwt::foo @ 6 (29 bytes) @ 14 java.dyn.MethodHandle::invoke inline (hot) @ 14 sun.dyn.ToGeneric$A1::invoke inline (hot) @ 4 sun.dyn.ToGeneric$A1::invoke_I inline (hot) @ 3 sun.dyn.ToGeneric$A1::targetA1 inline (hot) @ 2 java.lang.Integer::valueOf inline (hot) @ 50 java.lang.Integer:: inline (hot) @ 1 java.lang.Number:: inline (hot) @ 1 java.lang.Object:: inline (hot) @ 5 sun.dyn.ToGeneric$A1::target inline (hot) @ 9 java.dyn.MethodHandle::invoke inline (hot) @ 9 java.dyn.MethodHandle::invoke inline (hot) @ 4 java.dyn.MethodHandle::invoke inline (hot) @ 4 sun.dyn.MethodHandleImpl$GuardWithTest::invoke inline (hot) @ 4 sun.dyn.MethodHandleImpl$GuardWithTest::invoke_L1 inline (hot) @ 5 java.dyn.MethodHandle::invoke inline (hot) @ 5 gwt::invoke inline (hot) @ 16 java.lang.Integer::intValue inline (hot) @ 23 gwt::test inline (hot) @ 16 java.dyn.MethodHandle::invoke inline (hot) @ 16 sun.dyn.FromGeneric$A1::invoke call site not reached @ 25 java.dyn.MethodHandle::invoke inline (hot) @ 25 sun.dyn.FromGeneric$A1::invoke inline (hot) @ 4 sun.dyn.FromGeneric$A1::invoke_I1 inline (hot) @ 10 java.dyn.MethodHandle::invoke inline (hot) @ 10 java.dyn.MethodHandle::invoke inline (hot) @ 16 java.lang.Integer::intValue inline (hot) @ 25 java.dyn.MethodHandle::invoke inline (hot) @ 25 gwt::invoke inline (hot) @ 2 gwt::fallback inline (hot) @ 13 sun.dyn.FromGeneric$Adapter::convert_I inline (hot) @ 5 java.dyn.MethodHandle::invoke inline (hot) @ 5 sun.dyn.util.ValueConversions::invoke inline (hot) @ 2 sun.dyn.util.ValueConversions::boxInteger inline (hot) @ 1 java.lang.Integer::valueOf inline (hot) @ 50 java.lang.Integer:: inline (hot) @ 1 java.lang.Number:: inline (hot) @ 1 java.lang.Object:: inline (hot) @ 6 sun.dyn.ToGeneric$Adapter::return_I inline (hot) @ 5 java.dyn.MethodHandle::invoke inline (hot) @ 5 sun.dyn.util.ValueConversions::invoke inline (hot) @ 2 sun.dyn.util.ValueConversions::unboxInteger inline (hot) @ 10 java.lang.Integer::intValue inline (hot) Currently hunting various bugs... -- Christian From headius at headius.com Tue Aug 18 12:38:45 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 18 Aug 2009 12:38:45 -0700 Subject: Throwable In-Reply-To: <4A8AACB9.5060106@gmail.com> References: <4A8AACB9.5060106@gmail.com> Message-ID: On Tue, Aug 18, 2009 at 6:29 AM, Raffaello Giulietti wrote: > The language compiler complains about an > unreported exception Throwable; must be caught or declared to be thrown > in using both InvokeDynamic and the (invisible) MethodHandle.invoke() > > Why is this so? > What about an (unchecked) RuntimeException instead? I believe this was added because in theory the target of invokedynamic or a Method handle could produce any Throwable in the system, and so in order for you to be able to propagate or handle those throwables, it must throw Throwable. - Charlie From John.Rose at Sun.COM Tue Aug 18 12:45:20 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 18 Aug 2009 12:45:20 -0700 Subject: findVirtual problem In-Reply-To: <4A8AA7AF.10701@gmail.com> References: <4A8A6C9B.70101@Sun.COM> <620EACAA-EA90-4B9E-BEB0-284F4CAB4ECF@gmail.com> <4A8A738F.60504@Sun.COM> <4A8AA7AF.10701@gmail.com> Message-ID: <85083E75-2FB8-4307-8433-4F7694839A21@sun.com> On Aug 18, 2009, at 6:07 AM, Raffaello Giulietti wrote: > Hi Christian, > > do an upcast > > String result = mh.invoke((Object) "foo"); Yes. The difference between the two call sites is: (Ljava/lang/String;)Ljava/lang/String; vs. (Ljava/lang/Object;)Ljava/lang/String; The actual (erased) types of the arguments determine the descriptor, and hence the required MethodType. To avoid all such issues, with a possible performance hit, use the more lenient calling sequence supplied (as a non-primitive) by MethodHandles.invoke: String result = (String) MethodHandles.invoke(mh, "foo"); MHs.invoke (which has fixed-arity and varargs versions) supplies all- you-can-eat boxing and casting. This is an issue being discussed by the EG, whether the lenient semantics of MHs.invoke should be supported at all times by the primitive MH.invoke. The cost of doing so would be increased complexity at every MH invocation site, in many JVMs. The benefit would be ease of programming. -- John From Christian.Thalinger at Sun.COM Wed Aug 19 01:28:32 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 19 Aug 2009 10:28:32 +0200 Subject: findVirtual problem In-Reply-To: <85083E75-2FB8-4307-8433-4F7694839A21@sun.com> References: <4A8A6C9B.70101@Sun.COM> <620EACAA-EA90-4B9E-BEB0-284F4CAB4ECF@gmail.com> <4A8A738F.60504@Sun.COM> <4A8AA7AF.10701@gmail.com> <85083E75-2FB8-4307-8433-4F7694839A21@sun.com> Message-ID: <4A8BB7B0.10900@Sun.COM> John Rose wrote: > On Aug 18, 2009, at 6:07 AM, Raffaello Giulietti wrote: > >> Hi Christian, >> >> do an upcast >> >> String result = mh.invoke((Object) "foo"); > > Yes. The difference between the two call sites is: > (Ljava/lang/String;)Ljava/lang/String; > vs. > (Ljava/lang/Object;)Ljava/lang/String; > > The actual (erased) types of the arguments determine the descriptor, > and hence the required MethodType. > > To avoid all such issues, with a possible performance hit, use the > more lenient calling sequence supplied (as a non-primitive) by > MethodHandles.invoke: > String result = (String) MethodHandles.invoke(mh, "foo"); > > MHs.invoke (which has fixed-arity and varargs versions) supplies all- > you-can-eat boxing and casting. > > This is an issue being discussed by the EG, whether the lenient > semantics of MHs.invoke should be supported at all times by the > primitive MH.invoke. The cost of doing so would be increased > complexity at every MH invocation site, in many JVMs. The benefit > would be ease of programming. I see. Thank you for the explanation. -- Christian From raffaello.giulietti at gmail.com Wed Aug 19 02:15:29 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 19 Aug 2009 11:15:29 +0200 Subject: Inlining In-Reply-To: <4A8AECC8.1080400@Sun.COM> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> Message-ID: <4A8BC2B1.9040307@gmail.com> Christian Thalinger wrote: > Raffaello Giulietti wrote: >> * Is there a special -XX: flag to turn on inlining of methods invoked >> via method handles? >> * Or must something be enabled during the build of mlvm? > > No, inlining is enabled by default. Currently only DMH invokes are > inlined, but I'm working on inlining the rest. Are you missing specific > calls? > I'm experimenting with the implementation of a Smalltalk-like language. I'm using invokedynamic that targets a trivial stub that dispatches over the receiver's type which finally invokes a DMH. A simple test shows a factor of 150-200 with respect to an ordinary invokevirtual. That is, my Smalltalkish method invocation implementation, although seemingly trivial, is about 2 orders of magnitudes slower than Java's :-( That's why I'm wondering if inlining is at work. From raffaello.giulietti at gmail.com Wed Aug 19 02:36:26 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 19 Aug 2009 11:36:26 +0200 Subject: Throwable In-Reply-To: References: <4A8AACB9.5060106@gmail.com> Message-ID: <4A8BC79A.402@gmail.com> Charles Oliver Nutter wrote: > On Tue, Aug 18, 2009 at 6:29 AM, Raffaello > Giulietti wrote: >> The language compiler complains about an >> unreported exception Throwable; must be caught or declared to be thrown >> in using both InvokeDynamic and the (invisible) MethodHandle.invoke() >> >> Why is this so? >> What about an (unchecked) RuntimeException instead? > > I believe this was added because in theory the target of invokedynamic > or a Method handle could produce any Throwable in the system, and so > in order for you to be able to propagate or handle those throwables, > it must throw Throwable. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev Yes, this is the first reason that comes to mind. But it is not technically necessary. The JVM spec doesn't mandate that methods declare the exceptions they throw. And since InvokeDynamic and MethodHandle are quite special Java classes known to the language compiler, the throws declaration could be avoided even in the language for these cases. As you might guess, I'm not a close friend of checked exceptions ;-) From pdoubleya at gmail.com Wed Aug 19 03:07:08 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Wed, 19 Aug 2009 12:07:08 +0200 Subject: Throwable In-Reply-To: <4A8BC79A.402@gmail.com> References: <4A8AACB9.5060106@gmail.com> <4A8BC79A.402@gmail.com> Message-ID: <64efa1ba0908190307w77409453haf4ef4ffe41f936b@mail.gmail.com> The issue of InvokeDynamic calls from Java as regards checked exceptions was discussed on the Project Coin mailing list: http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/thread.html#1650 see the mails related to "JSR 292" and others with "292" in the title. See for example this partial thread: http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001647.html There's more there across several threads, sorry I don't have time to filter it out, but basically, InvokeDynamic calls from Java will be required to declare the Throwable. This also comes up in this thread (doesn't have 292 in the title) http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001868.html HTH Patrick From raffaello.giulietti at gmail.com Wed Aug 19 03:54:24 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 19 Aug 2009 12:54:24 +0200 Subject: Throwable In-Reply-To: <64efa1ba0908190307w77409453haf4ef4ffe41f936b@mail.gmail.com> References: <4A8AACB9.5060106@gmail.com> <4A8BC79A.402@gmail.com> <64efa1ba0908190307w77409453haf4ef4ffe41f936b@mail.gmail.com> Message-ID: <4A8BD9E0.30207@gmail.com> Patrick Wright wrote: > The issue of InvokeDynamic calls from Java as regards checked > exceptions was discussed on the Project Coin mailing list: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/thread.html#1650 > > see the mails related to "JSR 292" and others with "292" in the title. > See for example this partial thread: > http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001647.html > > There's more there across several threads, sorry I don't have time to > filter it out, but basically, InvokeDynamic calls from Java will be > required to declare the Throwable. This also comes up in this thread > (doesn't have 292 in the title) > http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001868.html > > > HTH > Patrick > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev Patrick, thanks for the references. Unfortunately, they tend to exacerbate the eternal debate between checked and unchecked exceptions and remind me the likely eternal debate between statically and dynamically typed languages. Fortunately, the JVM doesn't know about checked exceptions. Let's hope this will remain so even in the future. From Christian.Thalinger at Sun.COM Wed Aug 19 06:36:42 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 19 Aug 2009 15:36:42 +0200 Subject: Inlining In-Reply-To: <4A8BC2B1.9040307@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> Message-ID: <4A8BFFEA.5070202@Sun.COM> Raffaello Giulietti wrote: > Christian Thalinger wrote: >> Raffaello Giulietti wrote: >>> * Is there a special -XX: flag to turn on inlining of methods invoked >>> via method handles? >>> * Or must something be enabled during the build of mlvm? >> No, inlining is enabled by default. Currently only DMH invokes are >> inlined, but I'm working on inlining the rest. Are you missing specific >> calls? >> > > I'm experimenting with the implementation of a Smalltalk-like language. > I'm using invokedynamic that targets a trivial stub that dispatches over > the receiver's type which finally invokes a DMH. > > A simple test shows a factor of 150-200 with respect to an ordinary > invokevirtual. That is, my Smalltalkish method invocation > implementation, although seemingly trivial, is about 2 orders of > magnitudes slower than Java's :-( That's why I'm wondering if inlining > is at work. Is it publicly available and easy to set up so I can give it a shot? -- Christian From raffaello.giulietti at gmail.com Wed Aug 19 06:41:26 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 19 Aug 2009 15:41:26 +0200 Subject: Inlining In-Reply-To: <4A8BC2B1.9040307@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> Message-ID: <4A8C0106.4000904@gmail.com> Raffaello Giulietti wrote: > Christian Thalinger wrote: >> Raffaello Giulietti wrote: >>> * Is there a special -XX: flag to turn on inlining of methods invoked >>> via method handles? >>> * Or must something be enabled during the build of mlvm? >> No, inlining is enabled by default. Currently only DMH invokes are >> inlined, but I'm working on inlining the rest. Are you missing specific >> calls? >> > > I'm experimenting with the implementation of a Smalltalk-like language. > I'm using invokedynamic that targets a trivial stub that dispatches over > the receiver's type which finally invokes a DMH. > > A simple test shows a factor of 150-200 with respect to an ordinary > invokevirtual. That is, my Smalltalkish method invocation > implementation, although seemingly trivial, is about 2 orders of > magnitudes slower than Java's :-( That's why I'm wondering if inlining > is at work. > > Christian, your worries were well founded. In fact, the target handler of the invokedynamic was not a direct MH but a bound MH, instead. I forgot about my own implementation :-( I have know refactored the code to make use of DMHs by storing the bound argument in an accessible location and passing it explicitly as an argument to invokedynamic. Unfortunately, I get: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (sharedRuntime.cpp:590), pid=3632, tid=3072932752 # Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)") # # JRE version: 7.0 # Java VM: OpenJDK Server VM (16.0-b06 mixed mode linux-x86 ) A similar crash happens with -Xint enabled. Is this issue known? Thanks Raffaello From Christian.Thalinger at Sun.COM Wed Aug 19 08:51:40 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 19 Aug 2009 17:51:40 +0200 Subject: Inlining In-Reply-To: <4A8C0106.4000904@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> Message-ID: <4A8C1F8C.2060205@Sun.COM> Raffaello Giulietti wrote: > Christian, your worries were well founded. > > In fact, the target handler of the invokedynamic was not a direct MH but > a bound MH, instead. I forgot about my own implementation :-( > > I have know refactored the code to make use of DMHs by storing the bound > argument in an accessible location and passing it explicitly as an > argument to invokedynamic. Unfortunately, I get: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (sharedRuntime.cpp:590), pid=3632, tid=3072932752 > # Error: guarantee(cb->is_adapter_blob(),"exception happened outside > interpreter, nmethods and vtable stubs (1)") > # > # JRE version: 7.0 > # Java VM: OpenJDK Server VM (16.0-b06 mixed mode linux-x86 ) > > > A similar crash happens with -Xint enabled. > > Is this issue known? Ugh. I never saw that assert. Maybe John Rose knows more about that one. -- Christian From raffaello.giulietti at gmail.com Wed Aug 19 09:27:41 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 19 Aug 2009 18:27:41 +0200 Subject: Inlining In-Reply-To: <4A8C1F8C.2060205@Sun.COM> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> Message-ID: <4A8C27FD.8050606@gmail.com> > > Ugh. I never saw that assert. Maybe John Rose knows more about that one. > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev I extensively cleaned up and refactored my code, so the error doesn't happen anymore. This shows that the cause was certainly some bug in my previous code, which was rather contrived. The code now depends on direct method handles. The performance factor with respect to similar Java code dropped from 150-200 with the bound MHs solution to about 20-30 with direct MHs. invokedynamic's target is a handle that points to a method in a stub class. The method dispatches over the receiver's type. The dispatcher method invokes the ultimate method via a method handle kept in the stub. This scheme thus implements a simple inline caching solution. A test program iterates a few million times, invoking the same method on the same instance, so the method handle kept in the stub is looked up via the slow path only once. Is there any other implementor that has implemented a similar scheme for his/her preferred dynamic language? Do you observe similar costs of about 1 order of magnitude with respect to Java? Thanks you all Raffaello From eller.helmut at gmail.com Wed Aug 19 13:27:10 2009 From: eller.helmut at gmail.com (Helmut Eller) Date: Wed, 19 Aug 2009 22:27:10 +0200 Subject: Error handling without exceptions (was: Throwable) References: <4A8AACB9.5060106@gmail.com> Message-ID: Hello, I've been wondering if the java.dyn stuff will enable error handling which is not based on exceptions. For instance if a MethodHandle is called with the wrong number of arguments the current design seems to assume that throwing an exception is a sensible action to take. Throwing an exception is a sensible thing to do in many languages but some languages, Common Lisp comes to mind, handle errors by calling the current error handler. Is it possible to efficiently check the argument count and in case of a mismatch to call an error handler without unwinding the stack? Helmut From John.Rose at Sun.COM Wed Aug 19 17:49:37 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 19 Aug 2009 17:49:37 -0700 Subject: Throwable In-Reply-To: <4A8BD9E0.30207@gmail.com> References: <4A8AACB9.5060106@gmail.com> <4A8BC79A.402@gmail.com> <64efa1ba0908190307w77409453haf4ef4ffe41f936b@mail.gmail.com> <4A8BD9E0.30207@gmail.com> Message-ID: <1AF53013-B915-4CF4-AB18-FF09324972CB@sun.com> On Aug 19, 2009, at 3:54 AM, Raffaello Giulietti wrote: > Fortunately, the JVM doesn't know about checked exceptions. Let's hope > this will remain so even in the future. The Java language checks exceptions statically. The JVM doesn't. Neither of these facts will change in the foreseeable future. The design choices you see in JSR 292 language support are simply preserving that aspect of the status quo. -- John From John.Rose at Sun.COM Wed Aug 19 17:54:44 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 19 Aug 2009 17:54:44 -0700 Subject: Error handling without exceptions (was: Throwable) In-Reply-To: References: <4A8AACB9.5060106@gmail.com> Message-ID: <5A96CA11-7F63-45A6-98CB-C4763A9BE344@sun.com> On Aug 19, 2009, at 1:27 PM, Helmut Eller wrote: > Is it possible to efficiently check the argument count and in case > of a > mismatch to call an error handler without unwinding the stack? You can build this sort of thing on top of the primitives supplied by JSR 292, but it doesn't need to be wired into the JVM. And, no, such a feature would not be free; it would add significant overheads to every method handle call. Using exceptions the way the JVM does keeps hot paths clean. Any kind of "back up, coerce, and try again" logic would require fast path code to preserve state for slow paths, which translates to register pressure even if the feature is never used. It's always easier on the optimizer if there is only one way forward. -- John From Christian.Thalinger at Sun.COM Fri Aug 21 05:21:38 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 21 Aug 2009 12:21:38 +0000 Subject: hg: mlvm/mlvm/hotspot: 6833129, 6873116: Changeset from upstream that gets removed when promoted. Message-ID: <20090821122139.64E49122D9@hg.openjdk.java.net> Changeset: 7af5b91defe7 Author: twisti Date: 2009-08-21 14:07 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/7af5b91defe7 6833129, 6873116: Changeset from upstream that gets removed when promoted. series: Added above changesets. indy.compiler: Fixed client compiler crashes. + 6833129.patch + 6873116.patch ! indy.compiler.patch ! series From Christian.Thalinger at Sun.COM Fri Aug 21 05:52:41 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 Aug 2009 14:52:41 +0200 Subject: javac/client compiler crashes fixed In-Reply-To: <20090821122139.64E49122D9@hg.openjdk.java.net> References: <20090821122139.64E49122D9@hg.openjdk.java.net> Message-ID: <4A8E9899.6040508@Sun.COM> Hi! Sorry for the long delay on this one, but we had to sort out some stuff about this patch upstream. Finally, this change fixes the crashes you have seen in javac (no need for -J-Xint anymore). Please let me know if something still fails. -- Christian From Christian.Thalinger at Sun.COM Fri Aug 21 07:11:33 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 21 Aug 2009 14:11:33 +0000 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters. Message-ID: <20090821141134.0467B122EB@hg.openjdk.java.net> Changeset: a5c35afafeaf Author: twisti Date: 2009-08-21 15:58 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a5c35afafeaf indy.compiler.inline: Added generated bytecode adapters. ! indy.compiler.inline.patch From Christian.Thalinger at Sun.COM Fri Aug 21 07:39:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 Aug 2009 16:39:52 +0200 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters. In-Reply-To: <20090821141134.0467B122EB@hg.openjdk.java.net> References: <20090821141134.0467B122EB@hg.openjdk.java.net> Message-ID: <4A8EB1B8.6@Sun.COM> Hi! This commit adds generated bytecode adapters for MethodHandles. With these adapters it's possible to inline the whole path of a MethodHandleChain, plus the ultimate target, into the caller. But keep in mind: THIS IS WORK IN PROGRESS and is not enabled by default! A lot of stuff already works, like a number of JRuby benchmarks, but there are also various crashes (that I actually know about). To get your whole call path inlined you may need to tweak the inlining thresholds a little. To inline the call path of a simple GuardWithTest testcase I need to use: -XX:InlineSmallCode=1500 -XX:MaxInlineSize=50 -XX:MaxInlineLevel=15 To find out what thresholds are best for you, build a debug JVM and use: -XX:+PrintCompilation -XX:+PrintInlining If you see something like: @ 4 sun.dyn.ToGeneric$A1::invoke_I already compiled into a medium method you need to increase InlineSmallCode, and for: @ 16 java.lang.Integer::intValue inlining too deep you, obviously, have to increase MaxInlineLevel (note: this switch is only available in debug builds). The need for this tweaking will go away in the future, but for now, if you want to get the whole call path inlined (which may not have the best performance), you have to use some switches. Of course I want feedback about crashes! Preferably with small testcases... :-) -- Christian From John.Rose at Sun.COM Fri Aug 21 11:37:36 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 21 Aug 2009 11:37:36 -0700 Subject: javac/client compiler crashes fixed In-Reply-To: <4A8E9899.6040508@Sun.COM> References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> Message-ID: Yes! Thanks for slogging through this one, Christian. -- John (on my iPhone) On Aug 21, 2009, at 5:52 AM, Christian Thalinger wrote: > Hi! > > Sorry for the long delay on this one, but we had to sort out some > stuff > about this patch upstream. > > Finally, this change fixes the crashes you have seen in javac (no need > for -J-Xint anymore). Please let me know if something still fails. > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From headius at headius.com Sun Aug 23 01:47:09 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 23 Aug 2009 03:47:09 -0500 Subject: javac/client compiler crashes fixed In-Reply-To: References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> Message-ID: Ok...I did an updated build, and things are definitely better in the crash department. But I wonder if I'm not getting all the appropriate patches applied... client still crashes for me with bench_fib_recursive, but server runs successfully, albeit very slowly, about 10x slower than non-indy execution. Other simple scripts don't seem to crash at all now, which is also good. I've attached the crash output...let me know if there's anything else I can provide (like confirmation of head revisions, etc). On Fri, Aug 21, 2009 at 1:37 PM, John Rose wrote: > Yes! ?Thanks for slogging through this one, Christian. > > -- John ?(on my iPhone) > > On Aug 21, 2009, at 5:52 AM, Christian Thalinger ?> wrote: > >> Hi! >> >> Sorry for the long delay on this one, but we had to sort out some >> stuff >> about this patch upstream. >> >> Finally, this change fixes the crashes you have seen in javac (no need >> for -J-Xint anymore). ?Please let me know if something still fails. >> >> -- Christian >> _______________________________________________ >> 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: hs_err_pid42833.log Type: application/octet-stream Size: 28419 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090823/b0cecafb/attachment-0001.obj From headius at headius.com Sun Aug 23 02:08:29 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 23 Aug 2009 04:08:29 -0500 Subject: javac/client compiler crashes fixed In-Reply-To: References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> Message-ID: FYI, here's the results of qpush -a...I notice the compiler.inline patch isn't applying because it's -testable: ~/projects/davinci ? sh patches/make/each-patch-repo.sh 'hg qpush -a' + (cd sources/hotspot; hg qpush -a) applying 6833129.patch applying 6873116.patch applying meth-6862576.patch applying meth.patch applying nonperm.patch applying meth.walker.patch applying indy.patch applying indy.compiler.patch skipping indy.compiler.inline.patch - guarded by '-testable' skipping indy-amd64.patch - guarded by '-buildable' skipping indy-sparc.patch - guarded by '-buildable' skipping meth.proj.patch - guarded by ['+projects'] skipping anonk.proj.patch - guarded by ['+projects'] skipping annot.patch - guarded by '-testable' skipping inti.patch - guarded by '-buildable' skipping callcc.patch - guarded by '-testable' skipping tailc.patch - guarded by ['+tailc-lazy'] skipping tailc-eager.patch - guarded by ['+tailc-lazy'] now at: indy.compiler.patch + (cd sources/jdk; hg qpush -a) applying indy.tests.patch applying indy.pack.patch applying indy.patch skipping dyncast.patch - guarded by ['+dyncast'] skipping inti.patch - guarded by '-buildable' skipping callcc.patch - guarded by '-testable' skipping tailc.patch - guarded by ['+tailc'] now at: indy.patch + (cd sources/langtools; hg qpush -a) applying meth.patch skipping dyncast.patch - guarded by ['+dyncast'] skipping tailc.patch - guarded by ['+tailc'] now at: meth.patch On Sun, Aug 23, 2009 at 3:47 AM, Charles Oliver Nutter wrote: > Ok...I did an updated build, and things are definitely better in the > crash department. But I wonder if I'm not getting all the appropriate > patches applied... > > client still crashes for me with bench_fib_recursive, but server runs > successfully, albeit very slowly, about 10x slower than non-indy > execution. > > Other simple scripts don't seem to crash at all now, which is also good. > > I've attached the crash output...let me know if there's anything else > I can provide (like confirmation of head revisions, etc). > > On Fri, Aug 21, 2009 at 1:37 PM, John Rose wrote: >> Yes! ?Thanks for slogging through this one, Christian. >> >> -- John ?(on my iPhone) >> >> On Aug 21, 2009, at 5:52 AM, Christian Thalinger > ?> wrote: >> >>> Hi! >>> >>> Sorry for the long delay on this one, but we had to sort out some >>> stuff >>> about this patch upstream. >>> >>> Finally, this change fixes the crashes you have seen in javac (no need >>> for -J-Xint anymore). ?Please let me know if something still fails. >>> >>> -- Christian >>> _______________________________________________ >>> 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 >> > From Christian.Thalinger at Sun.COM Sun Aug 23 02:22:02 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 23 Aug 2009 11:22:02 +0200 Subject: javac/client compiler crashes fixed In-Reply-To: References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> Message-ID: <4A910A3A.90509@Sun.COM> Charles Oliver Nutter wrote: > FYI, here's the results of qpush -a...I notice the compiler.inline > patch isn't applying because it's -testable: > > ~/projects/davinci ? sh patches/make/each-patch-repo.sh 'hg qpush -a' > + (cd sources/hotspot; hg qpush -a) > applying 6833129.patch > applying 6873116.patch > applying meth-6862576.patch > applying meth.patch > applying nonperm.patch > applying meth.walker.patch > applying indy.patch > applying indy.compiler.patch > skipping indy.compiler.inline.patch - guarded by '-testable' You have to remove the testable guard to get the inline patch applied. qselect should print something like: $ hg qselect 4256b1662add buildable -- Christian From John.Rose at Sun.COM Sun Aug 23 04:02:59 2009 From: John.Rose at Sun.COM (John Rose) Date: Sun, 23 Aug 2009 04:02:59 -0700 Subject: javac/client compiler crashes fixed In-Reply-To: References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> Message-ID: <429AA5EE-65AA-4E74-8C35-DEB9D02FCB48@sun.com> On Aug 23, 2009, at 1:47 AM, Charles Oliver Nutter wrote: > client still crashes for me While this shouldn't happen at all, note that our focus is presently on server. The crashes we want to see (if that makes sense!) are with the server compiler and inlining turned on. Thanks for jumping on the new changes! (There are more to come...) -- John From headius at headius.com Sun Aug 23 11:39:52 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 23 Aug 2009 13:39:52 -0500 Subject: Inlining In-Reply-To: <4A8C27FD.8050606@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> <4A8C27FD.8050606@gmail.com> Message-ID: On Wed, Aug 19, 2009 at 11:27 AM, Raffaello Giulietti wrote: > invokedynamic's target is a handle that points to a method in a stub > class. The method dispatches over the receiver's type. The dispatcher > method invokes the ultimate method via a method handle kept in the stub. > This scheme thus implements a simple inline caching solution. It sounds like you're still dispatching through a generic piece of code, yes? If you have a piece of code in the call path that all calls pass through, you essentially defeat inlining entirely. JRuby runs like this in normal mode on Java 6 and lower, and it defeats inlining pretty handily. A better design, which can be turned on in JRuby, is to pull the target method "object" all the way back to the place it's being called, and invoke it there. Then it can be inlined. You also need some serious caching in place to avoid re-looking-up the method repeatedly. Do you have anything like that? > A test program iterates a few million times, invoking the same method on > the same instance, so the method handle kept in the stub is looked up > via the slow path only once. What does that method handle point at? What does the target method do? - Charlie From headius at headius.com Sun Aug 23 11:56:47 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 23 Aug 2009 13:56:47 -0500 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters. In-Reply-To: <4A8EB1B8.6@Sun.COM> References: <20090821141134.0467B122EB@hg.openjdk.java.net> <4A8EB1B8.6@Sun.COM> Message-ID: On Fri, Aug 21, 2009 at 9:39 AM, Christian Thalinger wrote: > This commit adds generated bytecode adapters for MethodHandles. ?With > these adapters it's possible to inline the whole path of a > MethodHandleChain, plus the ultimate target, into the caller. Very cool :) > But keep in mind: THIS IS WORK IN PROGRESS and is not enabled by default! How do we enable it? It this just turning off the +testable guard? > A lot of stuff already works, like a number of JRuby benchmarks, but > there are also various crashes (that I actually know about). > > To get your whole call path inlined you may need to tweak the inlining > thresholds a little. ?To inline the call path of a simple GuardWithTest > testcase I need to use: > > -XX:InlineSmallCode=1500 -XX:MaxInlineSize=50 -XX:MaxInlineLevel=15 > > To find out what thresholds are best for you, build a debug JVM and use: > > -XX:+PrintCompilation -XX:+PrintInlining > > If you see something like: > > ?@ 4 ? sun.dyn.ToGeneric$A1::invoke_I ?already compiled into a medium > method > > you need to increase InlineSmallCode, and for: > > ?@ 16 ? java.lang.Integer::intValue ?inlining too deep > > you, obviously, have to increase MaxInlineLevel (note: this switch is > only available in debug builds). Very good tips...I am now able to reproduce your perf results. I'll post in a separate email. > The need for this tweaking will go away in the future, but for now, if > you want to get the whole call path inlined (which may not have the best > performance), you have to use some switches. Excellent...now it's starting to get really exciting :) - Charlie From headius at headius.com Sun Aug 23 12:11:15 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 23 Aug 2009 14:11:15 -0500 Subject: Early JRuby indy results on recursive "fib" Message-ID: Ok, so I've got Christian's inlining stuff enabled and working, and I can report that things are definitely looking up. I made one modification to JRuby: removing the logic to do an unboxed 'long' call, since it goes around normal dynamic dispatch and always uses an inline caching mechanism. The appropriate change in the future would be to have unboxed paths through indy as well. For now, I just commented that logic out. The bench_recursive_fib.rb script in JRuby's repo is the slow dual-recursing fib impl, running to fib(30). Here's running bench_recursive_fib without indy: ~/projects/jruby ? jruby --server bench/bench_fib_recursive.rb 100 0.432000 0.000000 0.432000 ( 0.385000) 0.234000 0.000000 0.234000 ( 0.234000) 0.228000 0.000000 0.228000 ( 0.228000) 0.227000 0.000000 0.227000 ( 0.227000) 0.229000 0.000000 0.229000 ( 0.229000) 0.230000 0.000000 0.230000 ( 0.230000) 0.231000 0.000000 0.231000 ( 0.231000) 0.231000 0.000000 0.231000 ( 0.231000) 0.226000 0.000000 0.226000 ( 0.226000) 0.226000 0.000000 0.226000 ( 0.226000) 0.226000 0.000000 0.226000 ( 0.225000) 0.226000 0.000000 0.226000 ( 0.226000) It also deoptimizes down to around 0.40 later when another piece of code compiles and causes a number of call paths to go polymorphic. Now here's the same thing with indy: ~/projects/jruby ? jruby --server -J-Djruby.compile.invokedynamic=true -J-XX:InlineSmallCode=1500 -J-XX:MaxInlineSize=50 -J-XX:+EnableInvokeDynamic bench/bench_fib_recursive.rb 100 0.437000 0.000000 0.437000 ( 0.402000) 0.206000 0.000000 0.206000 ( 0.206000) 0.208000 0.000000 0.208000 ( 0.208000) 0.211000 0.000000 0.211000 ( 0.211000) 0.205000 0.000000 0.205000 ( 0.205000) 0.206000 0.000000 0.206000 ( 0.206000) 0.207000 0.000000 0.207000 ( 0.207000) 0.207000 0.000000 0.207000 ( 0.207000) 0.207000 0.000000 0.207000 ( 0.207000) The best time I saw was 0.202, and more importantly it never deoptimized as additional Ruby code jitted! I tested a few other things and did not see performance gains, but only saw moderate degradation in most cases. I'll need to look at each in turn and see what might be causing the slowdown. The truth is that fib is a much simpler microbench than most of the others, so it's easy to ensure it's optimizing correctly. But make no mistake...this is the first time we've had JRuby performing better with indy than with our built-in logic. And even more exciting: I don't think this is actually inlining the dynamic calls, eventually still doing a slow virtual call to the target body of code. My next phase of indy work will bind the last handle in the chain to a DMH that goes to the actual code body, which should allow it to inline all the way through. Excellent work, Christian! And thank you for the flag suggestions...I'm very excited to be able to reproduce your JRuby fib results locally! FYI, here's the indy and non-indy bytecode I'm outputting for fib: http://gist.github.com/173403 - Charlie From Christian.Thalinger at Sun.COM Mon Aug 24 00:30:38 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 24 Aug 2009 09:30:38 +0200 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters. In-Reply-To: References: <20090821141134.0467B122EB@hg.openjdk.java.net> <4A8EB1B8.6@Sun.COM> Message-ID: <4A92419E.20205@Sun.COM> Charles Oliver Nutter wrote: >> But keep in mind: THIS IS WORK IN PROGRESS and is not enabled by default! > > How do we enable it? It this just turning off the +testable guard? Sorry, yes, I should have mentioned that. >> The need for this tweaking will go away in the future, but for now, if >> you want to get the whole call path inlined (which may not have the best >> performance), you have to use some switches. > > Excellent...now it's starting to get really exciting :) Indeed :-) -- Christian From raffaello.giulietti at gmail.com Mon Aug 24 03:08:31 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 24 Aug 2009 12:08:31 +0200 Subject: Inlining In-Reply-To: References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> <4A8C27FD.8050606@gmail.com> Message-ID: <4A92669F.9060006@gmail.com> Hi Charles, let's pretend to have only parameterless messages. Then a message send gets translated into something like InvokeDynamic.#"rich name for call_site_i"(stub_i, receiver); The "rich name" identifies the call_site_i. For each call site there is a specific stub_i which carries information about the most recent method lookups in the form of (receiver class, method handle) pairs. How many pairs are maintained in the stub depends on how polymorphic the inline cache shall be. The target of the call site is a method handle to a method similar to static Obj invoke_0(Stub stub, Obj self) { if (self.klass == stub.klass_0) return stub.mh_0.invoke(self); // some other similar lines, depending on how polymorphic the inline cache shall be // otherwise do a slow lookup, cache the results in the stub according to some strategy and invoke the final method return lookupCacheInvoke(stub, self); } It is true that each call site's target refers to the same method handle, hence to the same dispatching method, i.e., invoke_0 above. However, every call site has its own Stub instance, so every call site caches its own information. But you state > It sounds like you're still dispatching through a generic piece of > code, yes? If you have a piece of code in the call path that all calls > pass through, you essentially defeat inlining entirely. Why is this so? I cannot see why invoke_0 couldn't be inlined at the invokedynamic call site. Is there a fundamental reason? Thanks Raffaello From headius at headius.com Mon Aug 24 08:29:50 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 24 Aug 2009 10:29:50 -0500 Subject: Inlining In-Reply-To: <4A92669F.9060006@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> <4A8C27FD.8050606@gmail.com> <4A92669F.9060006@gmail.com> Message-ID: On Mon, Aug 24, 2009 at 5:08 AM, Raffaello Giulietti wrote: > The target of the call site is a method handle to a method similar to > > static Obj invoke_0(Stub stub, Obj self) { > ? ?if (self.klass == stub.klass_0) > ? ? ? ?return stub.mh_0.invoke(self); > ? ?// some other similar lines, depending on how polymorphic the inline > cache shall be > > ? ?// otherwise do a slow lookup, cache the results in the stub > according to some strategy and invoke the final method > ? ?return lookupCacheInvoke(stub, self); > } > > It is true that each call site's target refers to the same method > handle, hence to the same dispatching method, i.e., invoke_0 above. > However, every call site has its own Stub instance, so every call site > caches its own information. > > But you state > >> It sounds like you're still dispatching through a generic piece of >> code, yes? If you have a piece of code in the call path that all calls >> pass through, you essentially defeat inlining entirely. > > Why is this so? I cannot see why invoke_0 couldn't be inlined at the > invokedynamic call site. Is there a fundamental reason? invoke_0 will be inlined, but the further call to the method handles may not be. If this same method is being called through for many different paths, then you actually have a polymorphic (even megamorphic) call site at the invoke(self) calls. It will be, to the JVM, a single call site with a large number of possible targets, and at least Hotspot can't inline across such a boundary. What you actually want to do is install a MH into the indy call site that points either directly at the eventual method to be called or at a guardWithTest handle that performs your polymorphic check and then decides on a slow or fast path call. Here's what that looks like in JRuby: private static MethodHandle createGWT(MethodHandle test, MethodHandle target, MethodHandle fallback, CacheEntry entry, CallSite site) { MethodHandle myTest = MethodHandles.insertArguments(test, 0, entry); MethodHandle myTarget = MethodHandles.insertArguments(target, 0, entry); MethodHandle myFallback = MethodHandles.insertArguments(fallback, 0, site); MethodHandle guardWithTest = MethodHandles.guardWithTest(myTest, myTarget, myFallback); return MethodHandles.convertArguments(guardWithTest, site.type()); } The result of this call is installed directly into the indy call site. The "test" boils down to this: public static boolean test(CacheEntry entry, IRubyObject self) { return entry.typeOk(self.getMetaClass()); } This just confirms that the CacheEntry (a tuple of class token and method) is valid for the incoming self. The fallback patch ends up like this, a megamorphic slow-path bit of logic: public static IRubyObject fallback(JRubyCallSite site, ThreadContext context, IRubyObject caller, IRubyObject self, String name) { RubyClass selfClass = pollAndGetClass(context, self); CacheEntry entry = selfClass.searchWithCache(name); if (methodMissing(entry, site.callType(), name, caller)) { return callMethodMissing(entry, site.callType(), context, self, name); } site.setTarget(createGWT(TEST_0, TARGET_0, FALLBACK_0, entry, site)); return entry.method.call(context, self, selfClass, name); } Notice that it reinstalls a *new* GWT with the new fast-path target, and then calls the method directly. The targets don't have any generic piece of code; they all bind eventually to a virtual call to DynamicMethod.call, where DynamicMethod is JRuby's method object abstraction. In each case, the eventual implementation of "call" invoked should be monomorphic for a given GWT fast path, but I will also be removing that last phase in favor of a DirectMethodHandle that goes straight to the actual target code (DynamicMethod impls are frequently generated code, since we don't have method handles pre-JDK7). But the basic idea is that your fast path should not call through any generalized Java code; it needs to be handles all the way to a unique target, or inlining is defeated. With indy now showing some perf improvement over my basic code, I'm going to fix that last phase and prepare a blog post on all this. - Charlie From raffaello.giulietti at gmail.com Mon Aug 24 10:14:30 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 24 Aug 2009 19:14:30 +0200 Subject: Inlining In-Reply-To: References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> <4A8C27FD.8050606@gmail.com> <4A92669F.9060006@gmail.com> Message-ID: <4A92CA76.6040008@gmail.com> Charles Oliver Nutter wrote: > On Mon, Aug 24, 2009 at 5:08 AM, Raffaello > Giulietti wrote: >> The target of the call site is a method handle to a method similar to >> >> static Obj invoke_0(Stub stub, Obj self) { >> if (self.klass == stub.klass_0) >> return stub.mh_0.invoke(self); >> // some other similar lines, depending on how polymorphic the inline >> cache shall be >> >> // otherwise do a slow lookup, cache the results in the stub >> according to some strategy and invoke the final method >> return lookupCacheInvoke(stub, self); >> } >> >> It is true that each call site's target refers to the same method >> handle, hence to the same dispatching method, i.e., invoke_0 above. >> However, every call site has its own Stub instance, so every call site >> caches its own information. >> >> But you state >> >>> It sounds like you're still dispatching through a generic piece of >>> code, yes? If you have a piece of code in the call path that all calls >>> pass through, you essentially defeat inlining entirely. >> Why is this so? I cannot see why invoke_0 couldn't be inlined at the >> invokedynamic call site. Is there a fundamental reason? > > invoke_0 will be inlined, but the further call to the method handles > may not be. If this same method is being called through for many > different paths, then you actually have a polymorphic (even > megamorphic) call site at the invoke(self) calls. It will be, to > the JVM, a single call site with a large number of possible targets, > and at least Hotspot can't inline across such a boundary. > > What you actually want to do is install a MH into the indy call site > that points either directly at the eventual method to be called or at > a guardWithTest handle that performs your polymorphic check and then > decides on a slow or fast path call. > > Here's what that looks like in JRuby: > > private static MethodHandle createGWT(MethodHandle test, > MethodHandle target, MethodHandle fallback, CacheEntry entry, CallSite > site) { > MethodHandle myTest = MethodHandles.insertArguments(test, 0, entry); > MethodHandle myTarget = MethodHandles.insertArguments(target, 0, entry); > MethodHandle myFallback = > MethodHandles.insertArguments(fallback, 0, site); > MethodHandle guardWithTest = > MethodHandles.guardWithTest(myTest, myTarget, myFallback); > > return MethodHandles.convertArguments(guardWithTest, site.type()); > } > > The result of this call is installed directly into the indy call site. > The "test" boils down to this: > > public static boolean test(CacheEntry entry, IRubyObject self) { > return entry.typeOk(self.getMetaClass()); > } > > This just confirms that the CacheEntry (a tuple of class token and > method) is valid for the incoming self. > > The fallback patch ends up like this, a megamorphic slow-path bit of logic: > > public static IRubyObject fallback(JRubyCallSite site, > ThreadContext context, IRubyObject caller, IRubyObject self, String > name) { > RubyClass selfClass = pollAndGetClass(context, self); > CacheEntry entry = selfClass.searchWithCache(name); > if (methodMissing(entry, site.callType(), name, caller)) { > return callMethodMissing(entry, site.callType(), context, > self, name); > } > site.setTarget(createGWT(TEST_0, TARGET_0, FALLBACK_0, entry, site)); > > return entry.method.call(context, self, selfClass, name); > } > > Notice that it reinstalls a *new* GWT with the new fast-path target, > and then calls the method directly. > > The targets don't have any generic piece of code; they all bind > eventually to a virtual call to DynamicMethod.call, where > DynamicMethod is JRuby's method object abstraction. In each case, the > eventual implementation of "call" invoked should be monomorphic for a > given GWT fast path, but I will also be removing that last phase in > favor of a DirectMethodHandle that goes straight to the actual target > code (DynamicMethod impls are frequently generated code, since we > don't have method handles pre-JDK7). But the basic idea is that your > fast path should not call through any generalized Java code; it needs > to be handles all the way to a unique target, or inlining is defeated. > > With indy now showing some perf improvement over my basic code, I'm > going to fix that last phase and prepare a blog post on all this. > > - Charlie Charlie, thanks for the clear explanation. Tomorrow I'll try to refactor my code according to your suggestions. From john.rose at sun.com Tue Aug 25 01:16:36 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 25 Aug 2009 08:16:36 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rename and adjust {nonperm, meth, indy}.patch for pre-integration review Message-ID: <20090825081637.3281E124FC@hg.openjdk.java.net> Changeset: d5753d32b610 Author: jrose Date: 2009-08-24 19:59 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d5753d32b610 meth, indy: rename and adjust {nonperm,meth,indy}.patch for pre-integration review + indy-6858164.patch ! indy.compiler.inline.patch - indy.patch + meth-6815692.patch - meth.patch ! meth.walker.patch + nonperm-6863023.patch - nonperm.patch ! series From john.rose at sun.com Tue Aug 25 01:28:45 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 25 Aug 2009 08:28:45 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rename and adjust {nonperm, meth, indy}.patch for pre-integration review (2) Message-ID: <20090825082845.83E9612501@hg.openjdk.java.net> Changeset: 68a143b1a444 Author: jrose Date: 2009-08-25 01:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/68a143b1a444 meth, indy: rename and adjust {nonperm,meth,indy}.patch for pre-integration review (2) ! indy.compiler.inline.patch ! indy.compiler.patch ! nonperm-6863023.patch From Christian.Thalinger at Sun.COM Tue Aug 25 02:36:56 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 Aug 2009 11:36:56 +0200 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rename and adjust {nonperm, meth, indy}.patch for pre-integration review In-Reply-To: <20090825081637.3281E124FC@hg.openjdk.java.net> References: <20090825081637.3281E124FC@hg.openjdk.java.net> Message-ID: <4A93B0B8.3070600@Sun.COM> John.Rose at Sun.COM wrote: > Changeset: d5753d32b610 > Author: jrose > Date: 2009-08-24 19:59 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d5753d32b610 > > meth, indy: rename and adjust {nonperm,meth,indy}.patch for pre-integration review > > + indy-6858164.patch > ! indy.compiler.inline.patch > - indy.patch > + meth-6815692.patch > - meth.patch > ! meth.walker.patch > + nonperm-6863023.patch > - nonperm.patch > ! series This changeset contains some changes that are related to JDK changes, which were not commited. Did these changes slip in by accident? There is now a confusing warning message, since JSR 292 support is still available: $ gamma -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic simpleVM option '+UnlockExperimentalVMOptions' VM option '+EnableMethodHandles' VM option '+EnableInvokeDynamic' OpenJDK Server VM warning: JSR 292 method handle code is mismatched to this JVM. Disabling support. 891396832 -- Christian From raffaello.giulietti at gmail.com Tue Aug 25 06:31:41 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 25 Aug 2009 15:31:41 +0200 Subject: Inlining In-Reply-To: <4A92CA76.6040008@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> <4A8C27FD.8050606@gmail.com> <4A92669F.9060006@gmail.com> <4A92CA76.6040008@gmail.com> Message-ID: <4A93E7BD.4070105@gmail.com> Raffaello Giulietti wrote: > Charles Oliver Nutter wrote: >> On Mon, Aug 24, 2009 at 5:08 AM, Raffaello >> Giulietti wrote: >>> The target of the call site is a method handle to a method similar to >>> >>> static Obj invoke_0(Stub stub, Obj self) { >>> if (self.klass == stub.klass_0) >>> return stub.mh_0.invoke(self); >>> // some other similar lines, depending on how polymorphic the inline >>> cache shall be >>> >>> // otherwise do a slow lookup, cache the results in the stub >>> according to some strategy and invoke the final method >>> return lookupCacheInvoke(stub, self); >>> } >>> >>> It is true that each call site's target refers to the same method >>> handle, hence to the same dispatching method, i.e., invoke_0 above. >>> However, every call site has its own Stub instance, so every call site >>> caches its own information. >>> >>> But you state >>> >>>> It sounds like you're still dispatching through a generic piece of >>>> code, yes? If you have a piece of code in the call path that all calls >>>> pass through, you essentially defeat inlining entirely. >>> Why is this so? I cannot see why invoke_0 couldn't be inlined at the >>> invokedynamic call site. Is there a fundamental reason? >> invoke_0 will be inlined, but the further call to the method handles >> may not be. If this same method is being called through for many >> different paths, then you actually have a polymorphic (even >> megamorphic) call site at the invoke(self) calls. It will be, to >> the JVM, a single call site with a large number of possible targets, >> and at least Hotspot can't inline across such a boundary. >> >> What you actually want to do is install a MH into the indy call site >> that points either directly at the eventual method to be called or at >> a guardWithTest handle that performs your polymorphic check and then >> decides on a slow or fast path call. >> >> Here's what that looks like in JRuby: >> >> private static MethodHandle createGWT(MethodHandle test, >> MethodHandle target, MethodHandle fallback, CacheEntry entry, CallSite >> site) { >> MethodHandle myTest = MethodHandles.insertArguments(test, 0, entry); >> MethodHandle myTarget = MethodHandles.insertArguments(target, 0, entry); >> MethodHandle myFallback = >> MethodHandles.insertArguments(fallback, 0, site); >> MethodHandle guardWithTest = >> MethodHandles.guardWithTest(myTest, myTarget, myFallback); >> >> return MethodHandles.convertArguments(guardWithTest, site.type()); >> } >> >> The result of this call is installed directly into the indy call site. >> The "test" boils down to this: >> >> public static boolean test(CacheEntry entry, IRubyObject self) { >> return entry.typeOk(self.getMetaClass()); >> } >> >> This just confirms that the CacheEntry (a tuple of class token and >> method) is valid for the incoming self. >> >> The fallback patch ends up like this, a megamorphic slow-path bit of logic: >> >> public static IRubyObject fallback(JRubyCallSite site, >> ThreadContext context, IRubyObject caller, IRubyObject self, String >> name) { >> RubyClass selfClass = pollAndGetClass(context, self); >> CacheEntry entry = selfClass.searchWithCache(name); >> if (methodMissing(entry, site.callType(), name, caller)) { >> return callMethodMissing(entry, site.callType(), context, >> self, name); >> } >> site.setTarget(createGWT(TEST_0, TARGET_0, FALLBACK_0, entry, site)); >> >> return entry.method.call(context, self, selfClass, name); >> } >> >> Notice that it reinstalls a *new* GWT with the new fast-path target, >> and then calls the method directly. >> >> The targets don't have any generic piece of code; they all bind >> eventually to a virtual call to DynamicMethod.call, where >> DynamicMethod is JRuby's method object abstraction. In each case, the >> eventual implementation of "call" invoked should be monomorphic for a >> given GWT fast path, but I will also be removing that last phase in >> favor of a DirectMethodHandle that goes straight to the actual target >> code (DynamicMethod impls are frequently generated code, since we >> don't have method handles pre-JDK7). But the basic idea is that your >> fast path should not call through any generalized Java code; it needs >> to be handles all the way to a unique target, or inlining is defeated. >> >> With indy now showing some perf improvement over my basic code, I'm >> going to fix that last phase and prepare a blog post on all this. >> >> - Charlie > > > Charlie, thanks for the clear explanation. > Tomorrow I'll try to refactor my code according to your suggestions. > OK, I tried with the GWT solution. It is 4 times slower than my own schema. But I'm using a mlvm build from a couple of weeks ago. According to Christian (http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001049.html), only direct mh are inlined with older builds, which could explain the slower behavior of GWTs with respect to my DMHs-only solution. I'll try with a new mlvm build with the latest patches partly announced in http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001067.html as soon as I hear that the issues mentioned in http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001082.html are fixed. Raffaello From Christian.Thalinger at Sun.COM Tue Aug 25 06:46:55 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 Aug 2009 15:46:55 +0200 Subject: Inlining In-Reply-To: <4A93E7BD.4070105@gmail.com> References: <4A8ABE94.8030602@gmail.com> <4A8AECC8.1080400@Sun.COM> <4A8BC2B1.9040307@gmail.com> <4A8C0106.4000904@gmail.com> <4A8C1F8C.2060205@Sun.COM> <4A8C27FD.8050606@gmail.com> <4A92669F.9060006@gmail.com> <4A92CA76.6040008@gmail.com> <4A93E7BD.4070105@gmail.com> Message-ID: <4A93EB4F.3000200@Sun.COM> Raffaello Giulietti wrote: > OK, I tried with the GWT solution. It is 4 times slower than my own > schema. But I'm using a mlvm build from a couple of weeks ago. According > to Christian > (http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001049.html), > only direct mh are inlined with older builds, which could explain the > slower behavior of GWTs with respect to my DMHs-only solution. > > I'll try with a new mlvm build with the latest patches partly announced > in > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001067.html > as soon as I hear that the issues mentioned in > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-August/001082.html > are fixed. But it works for me as before, even with the warning message. So you can give it a try. -- Christian From raffaello.giulietti at gmail.com Tue Aug 25 11:23:52 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 25 Aug 2009 20:23:52 +0200 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters. In-Reply-To: <4A8EB1B8.6@Sun.COM> References: <20090821141134.0467B122EB@hg.openjdk.java.net> <4A8EB1B8.6@Sun.COM> Message-ID: <4A942C38.3010505@gmail.com> > To get your whole call path inlined you may need to tweak the inlining > thresholds a little. To inline the call path of a simple GuardWithTest > testcase I need to use: > > -XX:InlineSmallCode=1500 -XX:MaxInlineSize=50 -XX:MaxInlineLevel=15 > > To find out what thresholds are best for you, build a debug JVM and use: > > -XX:+PrintCompilation -XX:+PrintInlining > What is needed to build a debug JVM? "hg qselect"ing some guards? Which ones? Or some "make" option? Or something else? Thanks Raffaello From Christian.Thalinger at Sun.COM Tue Aug 25 11:44:37 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 Aug 2009 20:44:37 +0200 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters. In-Reply-To: <4A942C38.3010505@gmail.com> References: <20090821141134.0467B122EB@hg.openjdk.java.net> <4A8EB1B8.6@Sun.COM> <4A942C38.3010505@gmail.com> Message-ID: <4A943115.3030606@Sun.COM> Raffaello Giulietti wrote: >> To get your whole call path inlined you may need to tweak the inlining >> thresholds a little. To inline the call path of a simple GuardWithTest >> testcase I need to use: >> >> -XX:InlineSmallCode=1500 -XX:MaxInlineSize=50 -XX:MaxInlineLevel=15 >> >> To find out what thresholds are best for you, build a debug JVM and use: >> >> -XX:+PrintCompilation -XX:+PrintInlining >> > > > What is needed to build a debug JVM? You only want to build a JVM or the whole JDK? To build a debug VM do: $ make jvmg or $ make fastdebug For a full debug JDK build do: $ make debug_build > "hg qselect"ing some guards? Which ones? $ hg qselect 4256b1662add buildable > Or some "make" option? > Or something else? -- Christian From John.Rose at Sun.COM Tue Aug 25 12:02:48 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 25 Aug 2009 12:02:48 -0700 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rename and adjust {nonperm, meth, indy}.patch for pre-integration review In-Reply-To: <4A93B0B8.3070600@Sun.COM> References: <20090825081637.3281E124FC@hg.openjdk.java.net> <4A93B0B8.3070600@Sun.COM> Message-ID: <5991E7ED-105B-45F1-9E5B-5DBFFC443A6E@sun.com> indy.patch in jdk changeset 57 has raiseException. Did you pull it into jdk? -- John On Aug 25, 2009, at 2:36 AM, Christian Thalinger wrote: > John.Rose at Sun.COM wrote: >> Changeset: d5753d32b610 >> Author: jrose >> Date: 2009-08-24 19:59 -0700 >> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d5753d32b610 >> >> meth, indy: rename and adjust {nonperm,meth,indy}.patch for pre- >> integration review >> >> + indy-6858164.patch >> ! indy.compiler.inline.patch >> - indy.patch >> + meth-6815692.patch >> - meth.patch >> ! meth.walker.patch >> + nonperm-6863023.patch >> - nonperm.patch >> ! series > > This changeset contains some changes that are related to JDK changes, > which were not commited. Did these changes slip in by accident? From Christian.Thalinger at Sun.COM Tue Aug 25 12:14:24 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 Aug 2009 21:14:24 +0200 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rename and adjust {nonperm, meth, indy}.patch for pre-integration review In-Reply-To: <5991E7ED-105B-45F1-9E5B-5DBFFC443A6E@sun.com> References: <20090825081637.3281E124FC@hg.openjdk.java.net> <4A93B0B8.3070600@Sun.COM> <5991E7ED-105B-45F1-9E5B-5DBFFC443A6E@sun.com> Message-ID: <4A943810.9020208@Sun.COM> John Rose wrote: > indy.patch in jdk changeset 57 has raiseException. Did you pull it > into jdk? -- John Hmm, I had the changeset but it seems not the newest patch version was applied?!?!? Obviously my fault, sorry. -- Christian From Christian.Thalinger at Sun.COM Thu Aug 27 09:17:07 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 27 Aug 2009 16:17:07 +0000 Subject: hg: mlvm/mlvm/hotspot: indy.compiler.inline: Some fixes, but still a couple of problems. Message-ID: <20090827161708.30059126C6@hg.openjdk.java.net> Changeset: 58929243564d Author: twisti Date: 2009-08-27 18:11 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/58929243564d indy.compiler.inline: Some fixes, but still a couple of problems. ! indy.compiler.inline.patch From Christian.Thalinger at Sun.COM Mon Aug 31 07:15:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 31 Aug 2009 16:15:53 +0200 Subject: javac/client compiler crashes fixed In-Reply-To: References: <20090821122139.64E49122D9@hg.openjdk.java.net> <4A8E9899.6040508@Sun.COM> Message-ID: <4A9BDB19.1060206@Sun.COM> 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. -- Christian