From john.r.rose at oracle.com Fri Sep 2 00:52:45 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 02 Sep 2011 07:52:45 +0000 Subject: hg: mlvm/mlvm: rebase mlvm to hsx/hotspot-comp Message-ID: <20110902075245.4214C472DE@hg.openjdk.java.net> Changeset: da760b9a2310 Author: jrose Date: 2011-09-02 00:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/da760b9a2310 rebase mlvm to hsx/hotspot-comp ! README.txt ! make/Makefile From john.r.rose at oracle.com Fri Sep 2 00:52:50 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 02 Sep 2011 07:52:50 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase mlvm to hsx/hotspot-comp Message-ID: <20110902075250.E77A4472DF@hg.openjdk.java.net> Changeset: b06696a8c93a Author: jrose Date: 2011-09-02 00:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b06696a8c93a rebase mlvm to hsx/hotspot-comp ! bsd.patch ! series ! snowleopard.patch From john.r.rose at oracle.com Fri Sep 2 00:52:58 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 02 Sep 2011 07:52:58 +0000 Subject: hg: mlvm/mlvm/jdk: rebase mlvm to hsx/hotspot-comp Message-ID: <20110902075258.A64C8472E0@hg.openjdk.java.net> Changeset: a84556b2ac1b Author: jrose Date: 2011-09-02 00:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a84556b2ac1b rebase mlvm to hsx/hotspot-comp ! cval-tune-7030453.patch + jdk7-b147-to-bsd-port.patch + meth-acc-7077803.patch ! meth.patch ! series From john.r.rose at oracle.com Fri Sep 2 00:53:03 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 02 Sep 2011 07:53:03 +0000 Subject: hg: mlvm/mlvm/langtools: rebase mlvm to hsx/hotspot-comp Message-ID: <20110902075303.9BA6A472E1@hg.openjdk.java.net> Changeset: c427d2032b13 Author: jrose Date: 2011-09-02 00:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/c427d2032b13 rebase mlvm to hsx/hotspot-comp + jdk7-b147-to-bsd-port.patch ! series From john.r.rose at oracle.com Fri Sep 2 00:58:12 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 2 Sep 2011 00:58:12 -0700 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> Message-ID: <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> OK, I have rebased the mlvm patch repository to hsx/hotspot-comp. If you have been reusing your upstream source repositories (based on bsd-port), you will have to discard them and pull instead from hotspot-comp. As a temporary solution for building on Mac OS, I have included a set of new patches called patches/*/jdk7-b147-to-bsd-port.patch which capture the relevant differences from bsd-port, and are applicable to the contents of hsx/hotspot-comp/*/. When we get the bsd-port changes folded into hsx, these ugly patches will go away. BTW, if you build on Mac OS, you need to enable the guard "bsd-port" in the patch queue guard files, or else the ugly patches won't get rolled in. The makefile (in patches/make/) attempts to do this automagically for you. Please give it a whirl and let me know what breaks. End-of-summer regards, -- John On Aug 19, 2011, at 11:47 AM, Christian Thalinger wrote: > On Aug 19, 2011, at 7:33 PM, Tom Rodriguez wrote: > >>>>> >>>> >>>> I'm open to suggestions on this one. >>>> >>>> It seems to me that the bsd-port repo. is slowing down prior to absorption into the mainline. >>>> >>>> In this case, maybe the rational thing is to reparent to a faster-moving repo. >>>> >>>> In particular, I think we should reparent to from bsd-port/bsd-port to hsx/hotspot-comp . That's (approximately) where our future is anyway. >>>> >>>> Current diffs only in bsd-port (which are necessary for mac builds!) can be posted as a suitably conditional part of the mlvm patch queue. >>>> >>>> Comments? >>> >>> I concur! Moving to hsx/hotspot-comp would be a very good idea. That would make publishing patches to mlvm a lot easier. >> >> I think we're not very far from having the bsd-port diffs in hotspot which will alleviate this. I kind of volunteered myself to shepherd them in and I want to get it done early next week. Hopefully this will allow the mac builds to start directly from hsx, modulo any build breakages since neither BSD nor Mac are in JPRT yet. > > I volunteer to review (and try) them too. From stephen.bannasch at deanbrook.org Fri Sep 2 05:07:38 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 2 Sep 2011 08:07:38 -0400 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: At 12:58 AM -0700 9/2/11, John Rose wrote: >OK, I have rebased the mlvm patch repository to hsx/hotspot-comp. > >If you have been reusing your upstream source repositories (based on bsd-port), you will have to discard them and pull instead from hotspot-comp. > >As a temporary solution for building on Mac OS, I have included a set of new patches called patches/*/jdk7-b147-to-bsd-port.patch which capture the relevant differences from bsd-port, and are applicable to the contents of hsx/hotspot-comp/*/. When we get the bsd-port changes folded into hsx, these ugly patches will go away. > >BTW, if you build on Mac OS, you need to enable the guard "bsd-port" in the patch queue guard files, or else the ugly patches won't get rolled in. The makefile (in patches/make/) attempts to do this automagically for you. > >Please give it a whirl and let me know what breaks. Thanks John, is gcc 4.0 still required. When I setup my build system for mlvm and bsd-port I did the following to use gcc 4.0: # Create the ALT_COMPILER_PATH directory and compiler links: # In the sources/ dir create the ALT_COMPILER_PATH dir and # the following symbolic links to the gcc 4.0 compilers: # # cd sources # mkdir ALT_COMPILER_PATH # cd ALT_COMPILER_PATH # ln -s /usr/bin .SOURCE # ln -s .SOURCE/g++-4.0 g++ # ln -s .SOURCE/gcc-4.0 gcc From stephen.bannasch at deanbrook.org Fri Sep 2 06:11:20 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 2 Sep 2011 09:11:20 -0400 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: >OK, I have rebased the mlvm patch repository to hsx/hotspot-comp. > >If you have been reusing your upstream source repositories (based on bsd-port), you will have to discard them and pull instead from hotspot-comp. > >As a temporary solution for building on Mac OS, I have included a set of new patches called patches/*/jdk7-b147-to-bsd-port.patch which capture the relevant differences from bsd-port, and are applicable to the contents of hsx/hotspot-comp/*/. When we get the bsd-port changes folded into hsx, these ugly patches will go away. > >BTW, if you build on Mac OS, you need to enable the guard "bsd-port" in the patch queue guard files, or else the uglypatches won't get rolled in. The makefile (in patches/make/) attempts to do this automagically for you. > >Please give it a whirl and let me know what breaks. I removed the bsd-port forest in sources and ran: hg fclone http://hg.openjdk.java.net/hsx/hotspot-comp sources Re-created the ALT_COMPILER_PATH dir and symlinks to gcc 4.0 compilers Updated my build scripts (https://gist.github.com/243072) to use the latest steps in: patches/README.txt but am getting these errors now: *** running make ... jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of ARCH cannot be empty, will use ''" jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of PLATFORM cannot be empty, will use ''" jdk/make/common/shared/Defs.gmk:380: jdk/make/common/shared/Defs-.gmk: No such file or directory jdk/make/common/shared/Defs.gmk:546: *** "ERROR: Trouble with the absolute path for OUTPUTDIR './build/-'". Stop. From john.r.rose at oracle.com Fri Sep 2 13:16:45 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 2 Sep 2011 13:16:45 -0700 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: <8AF92F99-2D7D-49EB-B9D2-687299F68009@oracle.com> On Sep 2, 2011, at 5:07 AM, Stephen Bannasch wrote: > is gcc 4.0 still required. That requirement hasn't changed. I don't think anyone has retried 4.2 recently. > I removed the bsd-port forest in sources and ran: > > hg fclone http://hg.openjdk.java.net/hsx/hotspot-comp sources > > Re-created the ALT_COMPILER_PATH dir and symlinks to gcc 4.0 compilers > > Updated my build scripts (https://gist.github.com/243072) to use the latest steps in: > > patches/README.txt > > but am getting these errors now: > > *** running make ... > > jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of ARCH cannot be empty, will use ''" > jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of PLATFORM cannot be empty, will use ''" > jdk/make/common/shared/Defs.gmk:380: jdk/make/common/shared/Defs-.gmk: No such file or directory > jdk/make/common/shared/Defs.gmk:546: *** "ERROR: Trouble with the absolute path for OUTPUTDIR './build/-'". Stop. That's a really basic square-one error. It looks as if the bsd-port patches failed to apply to your new sources. See brief experiment below. You might try this for a manual fixup of the guards files: -------- for d in jdk hotspot langtools; do (cd $d; hg qselect | grep bsd-port || echo bsd-port >> .hg/patches/guards); done -------- -- John P.S. Here's my local experiment... -------- pwd /Users/jrose/Projects/davinci/sources -------- hg qapp -R jdk jdk7-b147-to-bsd-port.patch -------- hg qpop -R jdk popping jdk7-b147-to-bsd-port.patch patch queue now empty -------- rm -rf build -------- sh build.sh jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of ARCH cannot be empty, will use ''" jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of ARCH_DATA_MODEL cannot be empty, will use ''" jdk/make/common/shared/Defs.gmk:181: "WARNING: Value of PLATFORM cannot be empty, will use ''" jdk/make/common/shared/Defs.gmk:380: jdk/make/common/shared/Defs-.gmk: No such file or directory jdk/make/common/shared/Defs.gmk:546: *** "ERROR: Trouble with the absolute path for OUTPUTDIR './build/-'". Stop. -------- hg qpush -R jdk applying jdk7-b147-to-bsd-port.patch now at: jdk7-b147-to-bsd-port.patch -------- sh build.sh Control bsd i586 1.8.0-internal all build started: 11-09-02 13:06 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110902/6fcfeeb5/attachment.html From forax at univ-mlv.fr Sun Sep 4 16:11:56 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 05 Sep 2011 01:11:56 +0200 Subject: Hotspot loves PHP.reboot Message-ID: <4E6405BC.1090108@univ-mlv.fr> I've just compiled the hotspot (64bits server) using the hotspot-comp workspace of hotspot express (hsx) http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/ Here are the result when running PHP.reboot on fibonacci (-server is the server VM of jdk1.7.0): Java: java -server bigfibo 4.45 s java -hsx bigfibo 4.44 s PHP.reboot (no type annotation) phpr.sh -server bigfibo 22.72 s phpr.sh -hsx bigfibo 13.61 s PHP.reboot (type specialization) phpr.sh -server bigfibo 11.09 s phpr.sh -hsx bigfibo 8.06 s PHP.reboot (user defined type annotation) phpr.sh -server bigfibo2 6.96 s phpr.sh -hsx bigfibo2 4.21 s PHP.reboot is an hybrid runtime, it starts with an interpreter that walks the AST (really slow) and then compile to bytecode. The first test is with no type information provided by the user, so all variables are object and invokedynamic is used for the operations, the comparison and for function calls. As you see, there is a huge speedup. The second test enables a flag that ask the runtime to try to specialize the function at runtime. Because the algorithm used is a fast-forward typechecker, the parameter of fibo is san pecialized as int but the return type is still an object (because fibo is recursive). So basically here, invokedynamic is used for the function calls and the + between the results of the function calls. This '+' is a nasty one because the two parameters are objects, so it requires a double guards. You can see the speedup is nice too. The third test uses a file that declare the parameter type and return type of fibo as int, so only the function calls are done using invokedynamic. You can also see the speedup and weirdly it's now faster than Java (not a lot if compare the value but don't forget that PHP.reboot starts in interpreter mode) so it's clearly faster. I will take a look to the inlining tree to try to understand why, it's maybe because fibo is a recursive call or because using an invokedynamic which is resolved as an invokestatic enables more inlining than just an invokestatic. John, Christian, Tom and all the others of the hotspot-comp team, you make my day :) cheers, R?mi From christian.thalinger at oracle.com Mon Sep 5 03:22:17 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 5 Sep 2011 12:22:17 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E6405BC.1090108@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> Message-ID: <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> On Sep 5, 2011, at 1:11 AM, R?mi Forax wrote: > I've just compiled the hotspot (64bits server) using the hotspot-comp > workspace of hotspot express (hsx) > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/ > > Here are the result when running PHP.reboot on fibonacci > (-server is the server VM of jdk1.7.0): > > Java: > java -server bigfibo 4.45 s > java -hsx bigfibo 4.44 s > > PHP.reboot (no type annotation) > phpr.sh -server bigfibo 22.72 s > phpr.sh -hsx bigfibo 13.61 s > > PHP.reboot (type specialization) > phpr.sh -server bigfibo 11.09 s > phpr.sh -hsx bigfibo 8.06 s > > PHP.reboot (user defined type annotation) > phpr.sh -server bigfibo2 6.96 s > phpr.sh -hsx bigfibo2 4.21 s > > PHP.reboot is an hybrid runtime, it starts with an interpreter > that walks the AST (really slow) and then compile to bytecode. > > The first test is with no type information provided by the user, > so all variables are object and invokedynamic is used for the > operations, the comparison and for function calls. > As you see, there is a huge speedup. > > The second test enables a flag that ask the runtime to try to > specialize the function at runtime. Because the algorithm > used is a fast-forward typechecker, the parameter of fibo > is san pecialized as int but the return type is still an object > (because fibo is recursive). > So basically here, invokedynamic is used for the function calls > and the + between the results of the function calls. > This '+' is a nasty one because the two parameters are objects, > so it requires a double guards. > You can see the speedup is nice too. > > The third test uses a file that declare the parameter type and > return type of fibo as int, so only the function calls are done > using invokedynamic. > You can also see the speedup and weirdly it's now faster than Java > (not a lot if compare the value but don't forget that > PHP.reboot starts in interpreter mode) so it's clearly faster. > I will take a look to the inlining tree to try to understand why, > it's maybe because fibo is a recursive call or because using > an invokedynamic which is resolved as an invokestatic > enables more inlining than just an invokestatic. > > John, Christian, Tom and all the others of the hotspot-comp team, > you make my day :) These numbers make mine too :-) Thanks for trying the current version. -- Christian > > cheers, > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Mon Sep 5 06:09:07 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 05 Sep 2011 15:09:07 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> Message-ID: <4E64C9F3.9040408@univ-mlv.fr> On 09/05/2011 12:22 PM, Christian Thalinger wrote: > On Sep 5, 2011, at 1:11 AM, R?mi Forax wrote: > >> I've just compiled the hotspot (64bits server) using the hotspot-comp >> workspace of hotspot express (hsx) >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/ >> >> Here are the result when running PHP.reboot on fibonacci >> (-server is the server VM of jdk1.7.0): >> >> Java: >> java -server bigfibo 4.45 s >> java -hsx bigfibo 4.44 s >> >> PHP.reboot (no type annotation) >> phpr.sh -server bigfibo 22.72 s >> phpr.sh -hsx bigfibo 13.61 s >> >> PHP.reboot (type specialization) >> phpr.sh -server bigfibo 11.09 s >> phpr.sh -hsx bigfibo 8.06 s >> >> PHP.reboot (user defined type annotation) >> phpr.sh -server bigfibo2 6.96 s >> phpr.sh -hsx bigfibo2 4.21 s >> >> PHP.reboot is an hybrid runtime, it starts with an interpreter >> that walks the AST (really slow) and then compile to bytecode. >> >> The first test is with no type information provided by the user, >> so all variables are object and invokedynamic is used for the >> operations, the comparison and for function calls. >> As you see, there is a huge speedup. >> >> The second test enables a flag that ask the runtime to try to >> specialize the function at runtime. Because the algorithm >> used is a fast-forward typechecker, the parameter of fibo >> is san pecialized as int but the return type is still an object >> (because fibo is recursive). >> So basically here, invokedynamic is used for the function calls >> and the + between the results of the function calls. >> This '+' is a nasty one because the two parameters are objects, >> so it requires a double guards. >> You can see the speedup is nice too. >> >> The third test uses a file that declare the parameter type and >> return type of fibo as int, so only the function calls are done >> using invokedynamic. >> You can also see the speedup and weirdly it's now faster than Java >> (not a lot if compare the value but don't forget that >> PHP.reboot starts in interpreter mode) so it's clearly faster. >> I will take a look to the inlining tree to try to understand why, >> it's maybe because fibo is a recursive call or because using >> an invokedynamic which is resolved as an invokestatic >> enables more inlining than just an invokestatic. >> >> John, Christian, Tom and all the others of the hotspot-comp team, >> you make my day :) > These numbers make mine too :-) Thanks for trying the current version. No, Thank you. Frankly, it's amazing to see how something that was at a point only in the collective mind of the JSR 292 EG is now real and fast thanks to your ability to massage hotspot. > -- Christian R?mi From headius at headius.com Tue Sep 6 07:59:43 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 09:59:43 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E64C9F3.9040408@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> Message-ID: Awesome numbers, especially promising for impls like JRuby that will never have type annotations and for which type inference will be very limited. Getting within 3x Java while still fully boxed is amazing. Perhaps the next big thing for InDy will be getting EA working across invokedynamic boundaries? Perhaps someone can explain why that's difficult (or impossible) now, since it seems to me that generating a bytecoded form for MH trees should allow EA to work as with any other code. No? - Charlie On Mon, Sep 5, 2011 at 8:09 AM, R?mi Forax wrote: > On 09/05/2011 12:22 PM, Christian Thalinger wrote: >> On Sep 5, 2011, at 1:11 AM, R?mi Forax wrote: >> >>> I've just compiled the hotspot (64bits server) using the hotspot-comp >>> workspace of hotspot express (hsx) >>> ? http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/ >>> >>> Here are the result when running PHP.reboot on fibonacci >>> (-server is the server VM of jdk1.7.0): >>> >>> Java: >>> java -server bigfibo ? ? ? ?4.45 s >>> java -hsx bigfibo ? ? ? ? ? 4.44 s >>> >>> PHP.reboot (no type annotation) >>> phpr.sh -server bigfibo ? ?22.72 s >>> phpr.sh -hsx bigfibo ? ? ? 13.61 s >>> >>> PHP.reboot (type specialization) >>> phpr.sh -server bigfibo ? ?11.09 s >>> phpr.sh -hsx bigfibo ? ? ? ?8.06 s >>> >>> PHP.reboot (user defined type annotation) >>> phpr.sh -server bigfibo2 ? ?6.96 s >>> phpr.sh -hsx bigfibo2 ? ? ? 4.21 s >>> >>> PHP.reboot is an hybrid runtime, it starts with an interpreter >>> that walks the AST (really slow) and then compile to bytecode. >>> >>> The first test is with no type information provided by the user, >>> so all variables are object and invokedynamic is used for the >>> operations, the comparison and for function calls. >>> As you see, there is a huge speedup. >>> >>> The second test enables a flag that ask the runtime to try to >>> specialize the function at runtime. Because the algorithm >>> used is a fast-forward typechecker, the parameter of fibo >>> is san pecialized as int but the return type is still an object >>> (because fibo is recursive). >>> So basically here, invokedynamic is used for the function calls >>> and the + between the results of the function calls. >>> This '+' is a nasty one because the two parameters are objects, >>> so it requires a double guards. >>> You can see the speedup is nice too. >>> >>> The third test uses a file that declare the parameter type and >>> return type of fibo as int, so only the function calls are done >>> using invokedynamic. >>> You can also see the speedup and weirdly it's now faster than Java >>> (not a lot if compare the value but don't forget that >>> PHP.reboot starts in interpreter mode) so it's clearly faster. >>> I will take a look to the inlining tree to try to understand why, >>> it's maybe because fibo is a recursive call or because using >>> an invokedynamic which is resolved as an invokestatic >>> enables more inlining than just an invokestatic. >>> >>> John, Christian, Tom and all the others of the hotspot-comp team, >>> you make my day :) >> These numbers make mine too :-) ?Thanks for trying the current version. > > No, Thank you. > Frankly, it's amazing to see how something that was at a point only > in the collective mind of the JSR 292 EG is now real and fast > thanks to your ability to massage hotspot. > >> -- Christian > > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From forax at univ-mlv.fr Tue Sep 6 08:39:58 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 06 Sep 2011 17:39:58 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> Message-ID: <4E663ECE.4080309@univ-mlv.fr> On 09/06/2011 04:59 PM, Charles Oliver Nutter wrote: > Awesome numbers, especially promising for impls like JRuby that will > never have type annotations and for which type inference will be very > limited. Getting within 3x Java while still fully boxed is amazing. Yes, but don't forget that PHP.reboot has no overflow check. > Perhaps the next big thing for InDy will be getting EA working across > invokedynamic boundaries? Perhaps someone can explain why that's > difficult (or impossible) now, since it seems to me that generating a > bytecoded form for MH trees should allow EA to work as with any other > code. No? Good question :) > - Charlie R?mi From headius at headius.com Tue Sep 6 08:51:12 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 10:51:12 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E663ECE.4080309@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> Message-ID: On Tue, Sep 6, 2011 at 10:39 AM, R?mi Forax wrote: > Yes, but don't forget that PHP.reboot has no overflow check. Did we ever figure out if it's possible to trick Hotspot into doing a JO instead of the raw bit-level operations? John/Christian/Tom: what would it take to get HS to "know" that we're doing an integer overflow-after-maths check and do the (faster?) JO? R?mi: For what it's worth, I did specialize +/- for 1 and 2 in the indy-based call protocols to avoid a full overflow check. - Charlie From christian.thalinger at oracle.com Tue Sep 6 10:33:39 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Sep 2011 19:33:39 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> Message-ID: <31300F8B-7777-4E7C-BA98-51B87DC906C8@oracle.com> On Sep 6, 2011, at 5:51 PM, Charles Oliver Nutter wrote: > On Tue, Sep 6, 2011 at 10:39 AM, R?mi Forax wrote: >> Yes, but don't forget that PHP.reboot has no overflow check. > > Did we ever figure out if it's possible to trick Hotspot into doing a > JO instead of the raw bit-level operations? John/Christian/Tom: what > would it take to get HS to "know" that we're doing an integer > overflow-after-maths check and do the (faster?) JO? We already talked a bit about that some while ago. I think matching that double-xor-trick (or whatever it's called) is too risky. A JDK method that does the check (and the math?) would be nice so we can intrinsify it. GWT would fit here. Btw. what means JO? -- Christian > > R?mi: For what it's worth, I did specialize +/- for 1 and 2 in the > indy-based call protocols to avoid a full overflow check. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Tue Sep 6 10:36:36 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 06 Sep 2011 19:36:36 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <31300F8B-7777-4E7C-BA98-51B87DC906C8@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <31300F8B-7777-4E7C-BA98-51B87DC906C8@oracle.com> Message-ID: <4E665A24.1040205@univ-mlv.fr> On 09/06/2011 07:33 PM, Christian Thalinger wrote: > On Sep 6, 2011, at 5:51 PM, Charles Oliver Nutter wrote: > >> On Tue, Sep 6, 2011 at 10:39 AM, R?mi Forax wrote: >>> Yes, but don't forget that PHP.reboot has no overflow check. >> Did we ever figure out if it's possible to trick Hotspot into doing a >> JO instead of the raw bit-level operations? John/Christian/Tom: what >> would it take to get HS to "know" that we're doing an integer >> overflow-after-maths check and do the (faster?) JO? > We already talked a bit about that some while ago. I think matching that double-xor-trick (or whatever it's called) is too risky. A JDK method that does the check (and the math?) would be nice so we can intrinsify it. GWT would fit here. > > Btw. what means JO? jump on overflow, i guess. > > -- Christian R?mi From forax at univ-mlv.fr Tue Sep 6 10:36:56 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 06 Sep 2011 19:36:56 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> Message-ID: <4E665A38.9030600@univ-mlv.fr> On 09/06/2011 05:51 PM, Charles Oliver Nutter wrote: > On Tue, Sep 6, 2011 at 10:39 AM, R?mi Forax wrote: >> Yes, but don't forget that PHP.reboot has no overflow check. > Did we ever figure out if it's possible to trick Hotspot into doing a > JO instead of the raw bit-level operations? John/Christian/Tom: what > would it take to get HS to "know" that we're doing an integer > overflow-after-maths check and do the (faster?) JO? > > R?mi: For what it's worth, I did specialize +/- for 1 and 2 in the > indy-based call protocols to avoid a full overflow check. If you have specialize for -2/+2, you should reuse exactly the same code for +n/-n. see https://code.google.com/p/jsr292-cookbook/source/browse/trunk/binary-operation/src/jsr292/cookbook/binop/RT.java#11 > > - Charlie R?mi From headius at headius.com Tue Sep 6 11:26:22 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 13:26:22 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <31300F8B-7777-4E7C-BA98-51B87DC906C8@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <31300F8B-7777-4E7C-BA98-51B87DC906C8@oracle.com> Message-ID: On Tue, Sep 6, 2011 at 12:33 PM, Christian Thalinger wrote: > We already talked a bit about that some while ago. ?I think matching that double-xor-trick (or whatever it's called) is too risky. ?A JDK method that does the check (and the math?) would be nice so we can intrinsify it. ?GWT would fit here. Yeah, talking with Kris Mok over Twitter we both agreed that an intrinsic would be preferable. Prescribing a specific code shape is fragile and dangerous if someone actually wants the xors in place (a JO instruction would not be 100% equivalent, obviously). > Btw. what means JO? Jump if Overflow. - Charlie From headius at headius.com Tue Sep 6 11:28:08 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 13:28:08 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E665A38.9030600@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <4E665A38.9030600@univ-mlv.fr> Message-ID: On Tue, Sep 6, 2011 at 12:36 PM, R?mi Forax wrote: > If you have specialize for -2/+2, you should reuse exactly the same code > for +n/-n. > see > https://code.google.com/p/jsr292-cookbook/source/browse/trunk/binary-operation/src/jsr292/cookbook/binop/RT.java#11 You're right. I'll make that change. Thanks! - Charlie From john.r.rose at oracle.com Tue Sep 6 12:58:56 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2011 12:58:56 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <4E665A38.9030600@univ-mlv.fr> Message-ID: On Sep 6, 2011, at 11:28 AM, Charles Oliver Nutter wrote: > On Tue, Sep 6, 2011 at 12:36 PM, R?mi Forax wrote: >> If you have specialize for -2/+2, you should reuse exactly the same code >> for +n/-n. >> see >> https://code.google.com/p/jsr292-cookbook/source/browse/trunk/binary-operation/src/jsr292/cookbook/binop/RT.java#11 > > You're right. I'll make that change. Thanks! Also (from an early attempt at a cookbook): http://hg.openjdk.java.net/mlvm/mlvm/file/tip/netbeans/indy-demo/src/recipes/FastAndSlow.java This uses the same logic as Remi's safeAdd. What's needed here is a way to get 33 bits out of a 32-bit add intrinsic. There's no fully natural way to do this, and about 4 kludgey ways. Because there are so many poor ways to shape the API, it's hard to pick the best one to invest in. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110906/c29b9c73/attachment.html From john.r.rose at oracle.com Tue Sep 6 13:04:34 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2011 13:04:34 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> Message-ID: <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote: > Did we ever figure out if it's possible to trick Hotspot into doing a > JO instead of the raw bit-level operations? John/Christian/Tom: what > would it take to get HS to "know" that we're doing an integer > overflow-after-maths check and do the (faster?) JO? (1) Write a compelling API for something like Integer.addDetectingOverflow. (2) Roll it into JDK 8+epsilon. (3) Do the JIT work. People have thought on and off about (1) for many years, but with no clear winner. Exceptions or boxed objects have unpleasant interactions and are hard to use, while smuggling out the 33rd bit some other way (TLS, a long or double, a return-by-reference, a sentinel value) is painful. (This is a case where tuples would make things simple, but it is not enough to motivate introducing tuples.) -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110906/333a878a/attachment.html From headius at headius.com Tue Sep 6 13:18:39 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 15:18:39 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: On Tue, Sep 6, 2011 at 3:04 PM, John Rose wrote: > (1) Write a compelling API for something like Integer.addDetectingOverflow. > (2) Roll it into JDK 8+epsilon. > (3) Do the JIT work. > People have thought on and off about (1) for many years, but with no clear > winner. ?Exceptions or boxed objects have unpleasant interactions and are > hard to use, while smuggling out the 33rd bit some other way (TLS, a long or > double, a return-by-reference, a sentinel value) is painful. > (This is a case where tuples would make things simple, but it is not enough > to motivate introducing tuples.) Not that it matters, but JRuby's integer math is all 64-bit...so we want a 65th bit of data out of maths :) A couple observations: * I think I speak for the entire JVM dynlang community when I say that we'd be happy to smuggle features into Java 6 via unsupported packages. In other words, if there were a sun.misc intrinsic we could link against, we'd happily do it when running on Hotspot and move to the formal way in JDK 8. * I was about to suggest a closure-based approach to handling the overflow (a callback, basically) but then realized constructing the closure instance has a nontrivial cost too. Yep, that's a fun little API design problem to solve. Hmm. - Charlie From john.r.rose at oracle.com Tue Sep 6 13:19:38 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2011 13:19:38 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <4E665A38.9030600@univ-mlv.fr> Message-ID: <7E0B9D76-1C00-47CF-9DA8-02FBC990A008@oracle.com> On Sep 6, 2011, at 12:58 PM, John Rose wrote: > What's needed here is a way to get 33 bits out of a 32-bit add intrinsic. There's no fully natural way to do this, and about 4 kludgey ways. Because there are so many poor ways to shape the API, it's hard to pick the best one to invest in. But, assuming the user wants to force a JO, here's one fairly clean way to do it: /** * Detect 32-bit overflow if the parameters are summed. * @return true if the inputs have the same sign, but their 32-bit sum would have a different sign */ public static boolean addWouldOverflow(int x, int y) { //int res = x + y; //boolean overflowDetected = (SGN(x) == SGN(y) && SGN(x) != SGN(res)); //boolean overflowDetected = ((x ^ y) >= 0 & (x ^ res) < 0); //boolean overflowDetected = ((x ^ y ^ -1) & (x ^ res)) < 0; return (((x ^ y ^ -1) & (x ^ (x+y))) < 0); } That would provide a fairly stable and clear target for the JIT to aim at. No points for ease-of-use. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110906/2644ab55/attachment.html From forax at univ-mlv.fr Tue Sep 6 13:36:12 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 06 Sep 2011 22:36:12 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <7E0B9D76-1C00-47CF-9DA8-02FBC990A008@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <4E665A38.9030600@univ-mlv.fr> <7E0B9D76-1C00-47CF-9DA8-02FBC990A008@oracle.com> Message-ID: <4E66843C.1000402@univ-mlv.fr> On 09/06/2011 10:19 PM, John Rose wrote: > On Sep 6, 2011, at 12:58 PM, John Rose wrote: > >> What's needed here is a way to get 33 bits out of a 32-bit add >> intrinsic. There's no fully natural way to do this, and about 4 >> kludgey ways. Because there are so many poor ways to shape the API, >> it's hard to pick the best one to invest in. > > But, assuming the user wants to force a JO, here's one fairly clean > way to do it: > > /** > * Detect 32-bit overflow if the parameters are summed. > * @return true if the inputs have the same sign, but their 32-bit > sum would have a different sign > */ > public static boolean addWouldOverflow(int x, int y) { > //int res = x + y; > //boolean overflowDetected = (SGN(x) == SGN(y) && SGN(x) != > SGN(res)); > //boolean overflowDetected = ((x ^ y) >= 0 & (x ^ res) < 0); > //boolean overflowDetected = ((x ^ y ^ -1) & (x ^ res)) < 0; > return (((x ^ y ^ -1) & (x ^ (x+y))) < 0); > } > > That would provide a fairly stable and clear target for the JIT to aim > at. No points for ease-of-use. An exception is perhaps more easier to use, because if it overflow you may have to deoptimize, for that you need the stack and local values, it's easier to jump to a exception handler that will push all these values and call the interpreter. > > -- John R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110906/abb14493/attachment.html From headius at headius.com Tue Sep 6 14:32:51 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 16:32:51 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E66843C.1000402@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <4E665A38.9030600@univ-mlv.fr> <7E0B9D76-1C00-47CF-9DA8-02FBC990A008@oracle.com> <4E66843C.1000402@univ-mlv.fr> Message-ID: On Tue, Sep 6, 2011 at 3:36 PM, R?mi Forax wrote: > An exception is perhaps more easier to use, > because if it overflow you may have to deoptimize, for that you need the > stack and local values, > it's easier to jump to a exception handler that will push all these values > and call the interpreter. I tend to agree. An exception would be cleanest. However, an exception must be caught...so you have the additional try/catch logic affecting optimization, no? Of course perf nuts would also want to pre-allocate that exception, since it's really flow control. Dunno if there's any precedent for that in the JVM other than OutOfMemoryError. - Charlie From john.r.rose at oracle.com Tue Sep 6 16:10:56 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Sep 2011 16:10:56 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: On Sep 6, 2011, at 1:18 PM, Charles Oliver Nutter wrote: > On Tue, Sep 6, 2011 at 3:04 PM, John Rose wrote: >> (1) Write a compelling API for something like Integer.addDetectingOverflow. >> (2) Roll it into JDK 8+epsilon. >> (3) Do the JIT work. >> People have thought on and off about (1) for many years, but with no clear >> winner. Exceptions or boxed objects have unpleasant interactions and are >> hard to use, while smuggling out the 33rd bit some other way (TLS, a long or >> double, a return-by-reference, a sentinel value) is painful. >> (This is a case where tuples would make things simple, but it is not enough >> to motivate introducing tuples.) > > Not that it matters, but JRuby's integer math is all 64-bit...so we > want a 65th bit of data out of maths :) Most of the tricks apply to both 32- and 64-bit ints. > ...that's a fun little > API design problem to solve. Hmm. Yes. Your request for "JO" makes me think some users would be happy with a boolean test, a la addWouldOverflow. It's what happens after the test that differs widely among applications, so why not just standardize the test. if (addWouldOverflow(p, q)) { throw or return BigInt or ... } return new Integer(p + q); The p+q, if it occurs within addWouldOverflow(p, q), will value-number to the explicit p+q, allowing the expected assembly code which computes p+q and then checks the overflow bit. (Actually, it's likely that the "addl p',q" instruction would occur twice, because hotspot not very good at tracking condition codes.) On Sep 6, 2011, at 1:36 PM, R?mi Forax wrote: > An exception is perhaps more easier to use, > because if it overflow you may have to deoptimize, for that you need the stack and local values, > it's easier to jump to a exception handler that will push all these values and call the interpreter. That's true, except that exceptions tend to be imprecise: It's hard to tell which sub-expression cause the exception, out of a complex statement. Addressing both the precision and pre-allocation problems, you could ask the application to create the exception: public static int addDetectingOverflow(int x, int y, X onOverflow) throws X -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110906/63e2769a/attachment.html From headius at headius.com Tue Sep 6 20:07:44 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Sep 2011 22:07:44 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: On Tue, Sep 6, 2011 at 6:10 PM, John Rose wrote: > Yes. ?Your request for "JO" makes me think some users would be happy with a > boolean test, a la addWouldOverflow. > It's what happens after the test that differs widely among applications, so > why not just standardize the test. > ? if (addWouldOverflow(p, q)) { throw or return BigInt or ... } > ? return new Integer(p + q); > The p+q, if it occurs within?addWouldOverflow(p, q), will value-number to > the explicit p+q, allowing the expected assembly code which computes p+q and > then checks the overflow bit. > (Actually, it's likely that the "addl p',q" instruction would occur twice, > because hotspot not very good at tracking condition codes.) That was my immediate concern. JO will act based on the last operation, so we wouldn't duplicate any work. Of course, at the level of multiple addl's it may be a small price to pay for a less code-order-sensitive option like addWouldOverflow. Thinking about how you'd JIT with such intrinsics made me realize the best case is still the full-on "addDetectingOverflow" since it could emit the add and jo operations all together in the proper order. Anything that depends on the bytecode ordering (iadd followed by this intrinsic call) would be tweaky, and then there's the simple fact that in the *absence* of JIT there's no real way to do "didAddOverflow" without passing everything in again like we do in JRuby now. Perhaps no gain in that case. Only the full "addDetectingOverflow" could reliable do the add and jo in precisely the correct order, figuring in any other register effects. > That's true, except that exceptions tend to be imprecise: ?It's hard to tell > which sub-expression cause the exception, out of a complex statement. > Addressing both the precision and pre-allocation problems, you could ask the > application to create the exception: > ??public static > ? int addDetectingOverflow(int x, int y, X onOverflow) throws X This is pretty good, though it's another unusual precedent for JDK (or at least I know of no APIs that have this form). Still, it might be the lightest-weight option, since it allows you to opt completely out of all allocation. I also thought of an existing API that would benefit from this, and perhaps there's a path to getting something in JDK 7 (unofficially) and JDK 8 (officially): BigInteger. Ideally BigInteger should only use a primitive long (or int?) up to its limits, and not allocate an array until it exceeds those limits. Such an implementation would need to do the same overflow checks JRuby does, and could benefit from addDetectingOverflow. And we know there's constant cries for BigInteger and BigDecimal perf to be improved...so I'd say every bit helps. - Charlie From per at bothner.com Wed Sep 7 00:00:01 2011 From: per at bothner.com (Per Bothner) Date: Wed, 07 Sep 2011 00:00:01 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: <4E671671.6060907@bothner.com> On 09/06/2011 08:07 PM, Charles Oliver Nutter wrote: > I also thought of an existing API that would benefit from this, and > perhaps there's a path to getting something in JDK 7 (unofficially) > and JDK 8 (officially): BigInteger. Ideally BigInteger should only use > a primitive long (or int?) up to its limits, and not allocate an array > until it exceeds those limits. Such an implementation would need to do > the same overflow checks JRuby does, and could benefit from > addDetectingOverflow. And we know there's constant cries for > BigInteger and BigDecimal perf to be improved...so I'd say every bit > helps. Kawa's gnu.math.IntNum already does this. It has only two fields: /** All integers are stored in 2's-complement form. * If words == null, the ival is the value of this IntNum. * Otherwise, the first ival elements of words make the value * of this IntNum, stored in little-endian order, 2's-complement form. */ public int ival; public int[] words; I assume this is one reason why Kawa's IntNum is (mostly) faster than BigInteger. -- --Per Bothner per at bothner.com http://per.bothner.com/ From john.r.rose at oracle.com Wed Sep 7 00:08:28 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Sep 2011 00:08:28 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E671671.6060907@bothner.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> Message-ID: On Sep 7, 2011, at 12:00 AM, Per Bothner wrote: > I assume this is one reason why Kawa's IntNum is (mostly) faster than > BigInteger. Yes, that's probably true. Here's a dirty secret: As you can see from the OpenJDK sources, BigDecimal, but not BigInteger, has this optimization (see private field BigDecimal.intCompact). Why BigDecimal but not BigInteger? Because specjbb2000 uses BigDecimal. (OTOH, an imperfect metric like specjbb2000 is far better than no metric at all, for driving competition.) -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/4eef7835/attachment.html From forax at univ-mlv.fr Wed Sep 7 02:15:13 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 07 Sep 2011 11:15:13 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> Message-ID: <4E673621.40407@univ-mlv.fr> On 09/07/2011 09:08 AM, John Rose wrote: > On Sep 7, 2011, at 12:00 AM, Per Bothner wrote: > >> I assume this is one reason why Kawa's IntNum is (mostly) faster than >> BigInteger. > > Yes, that's probably true. > > Here's a dirty secret: As you can see from the OpenJDK sources, > BigDecimal, but not BigInteger, has this optimization (see private > field BigDecimal.intCompact). Why BigDecimal but not BigInteger? > Because specjbb2000 uses BigDecimal. > > (OTOH, an imperfect metric like specjbb2000 is far better than no > metric at all, for driving competition.) This remember me that we don't have any benchmarks using dynamic languages which is, as you explain, not good on the long term. What about having 10 to 12 benchs, one by language, provided by each language runtime developer as a good bench for their runtime ? > > -- John R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/8e79ba5a/attachment-0001.html From duncan.macgregor at ge.com Wed Sep 7 04:00:37 2011 From: duncan.macgregor at ge.com (MacGregor, Duncan (GE Energy)) Date: Wed, 7 Sep 2011 13:00:37 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr><2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com><4E64C9F3.9040408@univ-mlv.fr><4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: <1DCC266105BEF8478FFB15F4BE468EC70601D2E4@BUDMLVEM09.e2k.ad.ge.com> Could we do pass a method handle into this hypothetical to this hypothetical addDetectingOverflow and allow thus allow the caller to specify what should happen in the overflow case? Or does that still leave too much of a problem regarding actually returning the values? From: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-bounces at openjdk.java.net] On Behalf Of John Rose Sent: 06 September 2011 21:05 To: Da Vinci Machine Project Subject: Re: Hotspot loves PHP.reboot On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote: Did we ever figure out if it's possible to trick Hotspot into doing a JO instead of the raw bit-level operations? John/Christian/Tom: what would it take to get HS to "know" that we're doing an integer overflow-after-maths check and do the (faster?) JO? (1) Write a compelling API for something like Integer.addDetectingOverflow. (2) Roll it into JDK 8+epsilon. (3) Do the JIT work. People have thought on and off about (1) for many years, but with no clear winner. Exceptions or boxed objects have unpleasant interactions and are hard to use, while smuggling out the 33rd bit some other way (TLS, a long or double, a return-by-reference, a sentinel value) is painful. (This is a case where tuples would make things simple, but it is not enough to motivate introducing tuples.) -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/6bc0d3ad/attachment.html From christian.thalinger at oracle.com Wed Sep 7 04:22:32 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Sep 2011 13:22:32 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E673621.40407@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> <4E673621.40407@univ-mlv.fr> Message-ID: <6DEF5421-AD4D-4CFC-94AF-5F5CBA67F772@oracle.com> On Sep 7, 2011, at 11:15 AM, R?mi Forax wrote: > On 09/07/2011 09:08 AM, John Rose wrote: >> >> On Sep 7, 2011, at 12:00 AM, Per Bothner wrote: >> >>> I assume this is one reason why Kawa's IntNum is (mostly) faster than >>> BigInteger. >> >> Yes, that's probably true. >> >> Here's a dirty secret: As you can see from the OpenJDK sources, BigDecimal, but not BigInteger, has this optimization (see private field BigDecimal.intCompact). Why BigDecimal but not BigInteger? Because specjbb2000 uses BigDecimal. >> >> (OTOH, an imperfect metric like specjbb2000 is far better than no metric at all, for driving competition.) > > This remember me that we don't have any benchmarks using dynamic languages > which is, as you explain, not good on the long term. > > What about having 10 to 12 benchs, one by language, provided by each language runtime developer > as a good bench for their runtime ? That is a VERY good idea! How about if PHP.reboot contributes the first one? ;-) -- Christian > >> >> -- John > > 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/20110907/b4eb1452/attachment.html From forax at univ-mlv.fr Wed Sep 7 07:08:21 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 07 Sep 2011 16:08:21 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <1DCC266105BEF8478FFB15F4BE468EC70601D2E4@BUDMLVEM09.e2k.ad.ge.com> References: <4E6405BC.1090108@univ-mlv.fr><2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com><4E64C9F3.9040408@univ-mlv.fr><4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <1DCC266105BEF8478FFB15F4BE468EC70601D2E4@BUDMLVEM09.e2k.ad.ge.com> Message-ID: <4E677AD5.3040106@univ-mlv.fr> On 09/07/2011 01:00 PM, MacGregor, Duncan (GE Energy) wrote: > > Could we do pass a method handle into this hypothetical to this > hypothetical addDetectingOverflow and allow thus allow the caller to > specify what should happen in the overflow case? Or does that still > leave too much of a problem regarding actually returning the values? > The return value is one problem because what you need to provide is not the return value of addDetectingOverflow but to the method that inlines (perhaps not directly) addDetectingOverflow. The other problem is that the VM will have to gather all locals to pass them as argument of the method handle. It's simpler to jump to a code that will call the interpreter (or another compiled code as PyPy does) hence the use of an exception. R?mi > *From:*mlvm-dev-bounces at openjdk.java.net > [mailto:mlvm-dev-bounces at openjdk.java.net] *On Behalf Of *John Rose > *Sent:* 06 September 2011 21:05 > *To:* Da Vinci Machine Project > *Subject:* Re: Hotspot loves PHP.reboot > > On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote: > > > > Did we ever figure out if it's possible to trick Hotspot into doing a > JO instead of the raw bit-level operations? John/Christian/Tom: what > would it take to get HS to "know" that we're doing an integer > overflow-after-maths check and do the (faster?) JO? > > (1) Write a compelling API for something like > Integer.addDetectingOverflow. > > (2) Roll it into JDK 8+epsilon. > > (3) Do the JIT work. > > People have thought on and off about (1) for many years, but with no > clear winner. Exceptions or boxed objects have unpleasant > interactions and are hard to use, while smuggling out the 33rd bit > some other way (TLS, a long or double, a return-by-reference, a > sentinel value) is painful. > > (This is a case where tuples would make things simple, but it is not > enough to motivate introducing tuples.) > > -- John > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/a92fc125/attachment.html From forax at univ-mlv.fr Wed Sep 7 07:13:54 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 07 Sep 2011 16:13:54 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <6DEF5421-AD4D-4CFC-94AF-5F5CBA67F772@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> <4E673621.40407@univ-mlv.fr> <6DEF5421-AD4D-4CFC-94AF-5F5CBA67F772@oracle.com> Message-ID: <4E677C22.60600@univ-mlv.fr> On 09/07/2011 01:22 PM, Christian Thalinger wrote: > > On Sep 7, 2011, at 11:15 AM, R?mi Forax wrote: > >> On 09/07/2011 09:08 AM, John Rose wrote: >>> On Sep 7, 2011, at 12:00 AM, Per Bothner wrote: >>> >>>> I assume this is one reason why Kawa's IntNum is (mostly) faster than >>>> BigInteger. >>> >>> Yes, that's probably true. >>> >>> Here's a dirty secret: As you can see from the OpenJDK sources, >>> BigDecimal, but not BigInteger, has this optimization (see private >>> field BigDecimal.intCompact). Why BigDecimal but not BigInteger? >>> Because specjbb2000 uses BigDecimal. >>> >>> (OTOH, an imperfect metric like specjbb2000 is far better than no >>> metric at all, for driving competition.) >> >> This remember me that we don't have any benchmarks using dynamic >> languages >> which is, as you explain, not good on the long term. >> >> What about having 10 to 12 benchs, one by language, provided by each >> language runtime developer >> as a good bench for their runtime ? > > That is a VERY good idea! How about if PHP.reboot contributes the > first one? ;-) I've to think a bit about what is the best program for a bench of PHP.reboot. I also think that we should provide only one jar with a special entrypoint. What is the best location for that benchmark ? > > -- Christian R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/46a92cbd/attachment-0001.html From christian.thalinger at oracle.com Wed Sep 7 07:21:01 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 7 Sep 2011 16:21:01 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E677C22.60600@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> <4E673621.40407@univ-mlv.fr> <6DEF5421-AD4D-4CFC-94AF-5F5CBA67F772@oracle.com> <4E677C22.60600@univ-mlv.fr> Message-ID: <7E664766-E779-4756-8C04-2F827C10DC88@oracle.com> On Sep 7, 2011, at 4:13 PM, R?mi Forax wrote: > On 09/07/2011 01:22 PM, Christian Thalinger wrote: >> >> >> On Sep 7, 2011, at 11:15 AM, R?mi Forax wrote: >> >>> On 09/07/2011 09:08 AM, John Rose wrote: >>>> >>>> On Sep 7, 2011, at 12:00 AM, Per Bothner wrote: >>>> >>>>> I assume this is one reason why Kawa's IntNum is (mostly) faster than >>>>> BigInteger. >>>> >>>> Yes, that's probably true. >>>> >>>> Here's a dirty secret: As you can see from the OpenJDK sources, BigDecimal, but not BigInteger, has this optimization (see private field BigDecimal.intCompact). Why BigDecimal but not BigInteger? Because specjbb2000 uses BigDecimal. >>>> >>>> (OTOH, an imperfect metric like specjbb2000 is far better than no metric at all, for driving competition.) >>> >>> This remember me that we don't have any benchmarks using dynamic languages >>> which is, as you explain, not good on the long term. >>> >>> What about having 10 to 12 benchs, one by language, provided by each language runtime developer >>> as a good bench for their runtime ? >> >> That is a VERY good idea! How about if PHP.reboot contributes the first one? ;-) > > I've to think a bit about what is the best program for a bench of PHP.reboot. > I also think that we should provide only one jar with a special entrypoint. Right, that would be good. Maybe something like DaCapo where you have one jar file but you can also choose to run single benchmarks (e.g. java -jar jsr292bench.jar [phpreboot|jruby|seph|...]). > > What is the best location for that benchmark ? Not sure. What about Kenai? -- Christian > >> >> -- Christian > > 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/20110907/d87635e3/attachment.html From forax at univ-mlv.fr Wed Sep 7 07:24:22 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 07 Sep 2011 16:24:22 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: <4E677E96.80601@univ-mlv.fr> On 09/07/2011 05:07 AM, Charles Oliver Nutter wrote: > On Tue, Sep 6, 2011 at 6:10 PM, John Rose wrote: >> > Yes. Your request for "JO" makes me think some users would be happy with a >> > boolean test, a la addWouldOverflow. >> > It's what happens after the test that differs widely among applications, so >> > why not just standardize the test. >> > if (addWouldOverflow(p, q)) { throw or return BigInt or ... } >> > return new Integer(p + q); >> > The p+q, if it occurs within addWouldOverflow(p, q), will value-number to >> > the explicit p+q, allowing the expected assembly code which computes p+q and >> > then checks the overflow bit. >> > (Actually, it's likely that the "addl p',q" instruction would occur twice, >> > because hotspot not very good at tracking condition codes.) > That was my immediate concern. JO will act based on the last > operation, so we wouldn't duplicate any work. Of course, at the level > of multiple addl's it may be a small price to pay for a less > code-order-sensitive option like addWouldOverflow. > > Thinking about how you'd JIT with such intrinsics made me realize the > best case is still the full-on "addDetectingOverflow" since it could > emit the add and jo operations all together in the proper order. > Anything that depends on the bytecode ordering (iadd followed by this > intrinsic call) would be tweaky, and then there's the simple fact that > in the*absence* of JIT there's no real way to do "didAddOverflow" > without passing everything in again like we do in JRuby now. Perhaps > no gain in that case. Only the full "addDetectingOverflow" could > reliable do the add and jo in precisely the correct order, figuring in > any other register effects. > >> > That's true, except that exceptions tend to be imprecise: It's hard to tell >> > which sub-expression cause the exception, out of a complex statement. >> > Addressing both the precision and pre-allocation problems, you could ask the >> > application to create the exception: >> > public static >> > int addDetectingOverflow(int x, int y, X onOverflow) throws X > This is pretty good, though it's another unusual precedent for JDK (or > at least I know of no APIs that have this form). Still, it might be > the lightest-weight option, since it allows you to opt completely out > of all allocation. The other solution is to do the strict opposite, to use an exception that have a private constructor so it can't be created by a user code and have no stacktrace, etc (see http://download.oracle.com/javase/7/docs/api/java/lang/Throwable.html#Throwable%28java.lang.String,%20java.lang.Throwable,%20boolean,%20boolean%29) so the VM knows that only methods *DetectingOverflow are able to throw that specific exception. int addDetectingOverflow(int x, int y) throws IntegerOverflowException This also have the advantage that the inlining heuristic can be tweaked to not count exception handlers that receive that specific exception. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/86d7af2f/attachment.html From john.r.rose at oracle.com Wed Sep 7 12:02:33 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Sep 2011 12:02:33 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E677E96.80601@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E677E96.80601@univ-mlv.fr> Message-ID: <53930D38-8FA1-4ACA-9856-12BCEF3522AA@oracle.com> On Sep 7, 2011, at 7:24 AM, R?mi Forax wrote: > so the VM knows that only methods *DetectingOverflow are able to throw that specific exception. > int addDetectingOverflow(int x, int y) throws IntegerOverflowException > This also have the advantage that the inlining heuristic can be tweaked > to not count exception handlers that receive that specific exception. Generalize this to "UnexpectedTypeStateException" and build that into a set of patterns that accomplish user-defined deoptimization. That would be worth special-casing in the JVM. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/f3c472e5/attachment.html From thomas.wuerthinger at oracle.com Wed Sep 7 12:33:24 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 07 Sep 2011 21:33:24 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: <4E67C704.60909@oracle.com> On 9/7/11 1:10 AM, John Rose wrote: > > That's true, except that exceptions tend to be imprecise: It's hard > to tell which sub-expression cause the exception, out of a complex > statement. > > Addressing both the precision and pre-allocation problems, you could > ask the application to create the exception: > > public static > int addDetectingOverflow(int x, int y, X onOverflow) throws X This would probably also mean that the exception object created for capturing the slow-case program state needs to be escape-analyzed and removed in the optimized code that deoptimizes on overflow? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/8f48ddf6/attachment.html From per at bothner.com Wed Sep 7 12:32:02 2011 From: per at bothner.com (Per Bothner) Date: Wed, 07 Sep 2011 12:32:02 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E673621.40407@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> <4E673621.40407@univ-mlv.fr> Message-ID: <4E67C6B2.4020604@bothner.com> On 09/07/2011 02:15 AM, R?mi Forax wrote: > This remember me that we don't have any benchmarks using dynamic languages > which is, as you explain, not good on the long term. > > What about having 10 to 12 benchs, one by language, provided by each > language runtime developer > as a good bench for their runtime ? Well, there are the Computer Language Benchmark Game problems at http://shootout.alioth.debian.org/ . Isaac Gouy doesn't want to support more languages officially, but we can certainly use these as a starting point on some alternative server. (There are fast Kawa versions of all the current benchmarks: http://per.bothner.com/blog/2010/Kawa-in-shootout/ ) -- --Per Bothner per at bothner.com http://per.bothner.com/ From mikeb01 at gmail.com Wed Sep 7 13:20:34 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Wed, 7 Sep 2011 21:20:34 +0100 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <8AF92F99-2D7D-49EB-B9D2-687299F68009@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> <8AF92F99-2D7D-49EB-B9D2-687299F68009@oracle.com> Message-ID: > is gcc 4.0 still required. > > That requirement hasn't changed. ?I don't think anyone has retried 4.2 > recently. Does anyone know where to get binaries for gcc-4.0 on Lion? My shiny new laptop stubbornly refuses to build 4.0 from macports. Mike. From mroos at roos.com Wed Sep 7 13:22:38 2011 From: mroos at roos.com (Mark Roos) Date: Wed, 7 Sep 2011 13:22:38 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <53930D38-8FA1-4ACA-9856-12BCEF3522AA@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E677E96.80601@univ-mlv.fr> <53930D38-8FA1-4ACA-9856-12BCEF3522AA@oracle.com> Message-ID: R?mi Forax wrote: > > so the VM knows that only methods *DetectingOverflow are able to > throw that specific exception. > int addDetectingOverflow(int x, int y) throws IntegerOverflowException > This also have the advantage that the inlining heuristic can be tweaked > to not count exception handlers that receive that specific exception. > > Generalize this to "UnexpectedTypeStateException" and build that > into a set of patterns that accomplish user-defined deoptimization. > That would be worth special-casing in the JVM. > > -- John_______________________________________________ Would not s specialized GWT be a nice way to handle this? Especially one where the developer could provide a test in an inline assembly like style for slot access, unboxing and compares Seems to me John mentioned an idea for a methodHandle to inline code as in interesting concept mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/9d9a917f/attachment.html From john.r.rose at oracle.com Wed Sep 7 13:38:07 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Sep 2011 13:38:07 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E67C704.60909@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> Message-ID: On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote: > This would probably also mean that the exception object created for capturing the slow-case program state needs to be escape-analyzed and removed in the optimized code that deoptimizes on overflow? Yes. And in the case of user-defined deoptimization, the exception object would encode the continuation required by the source language. (A continuation would be something like a source location or an AST node, plus a map from local values to source variables. The local exception handler would package up the live local values into a display that could be loaded into the backup interpreter.) This exception object would be live only on the exception path, and so (as you say) could be built lazily from the JVM's debug info for EA. As we discussed at the JVM Language Summit, building user-level deoptimization on top of JVM-level deoptimization should allow non-Java languages to benefit from the same partial-compilation tactics that Java enjoys. The nicest part is that the basic components are in place; we just need to settle on effective patterns and tune up the associated JVM optimizations. For example, at the Summit Remi pointed out an optimization problem associated with this pattern: Object l0, l1, l2, ...; l0 = l1 = l2 = ... null; // these are required only for definite assignment in the catch body try { ...do fast path... if (...constraint violated...) throw new DeoptExc(...); return ...fast result... } catch (DeoptExc ex) { Object[] display = { l0, l1, l2, ... }; return backupInterpreter(ex, display); // N.B. could throw DeoptExc to caller also } This problem is that the eager initializations of the various locals slow down the fast path. (Did I get it right Remi?) The register allocator should push them down into the catch body, and maybe even into the static debug info of the JVM. If we had a benchmark that demonstrated the problems with such an approach, we could file a bug to tune the optimizer for it. The ideal benchmark would not actually run the deoptimization path (except to demonstrate correctness) but would measure the speed of the fast path, and the impact of the deopt support on the fast path. Integer overflow is an obvious candidate for a rare deopt condition, and so would a quasi-constant function binding (via a MutableCallsite). A tak or fib benchmark could demonstrate both. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110907/918bc601/attachment-0001.html From headius at headius.com Wed Sep 7 14:25:30 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 7 Sep 2011 16:25:30 -0500 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E671671.6060907@bothner.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> Message-ID: On Wed, Sep 7, 2011 at 2:00 AM, Per Bothner wrote: > Kawa's gnu.math.IntNum already does this. ?It has only two fields: Yeah, I think I remember you mentioning this in one of the arbitrary-precision math threads on JVM-L. I assume you could use an intrinsic optimization for overflow checks too, yes? - Charlie From forax at univ-mlv.fr Wed Sep 7 15:02:56 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Sep 2011 00:02:56 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E67C6B2.4020604@bothner.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> <4E673621.40407@univ-mlv.fr> <4E67C6B2.4020604@bothner.com> Message-ID: <4E67EA10.8050900@univ-mlv.fr> On 09/07/2011 09:32 PM, Per Bothner wrote: > On 09/07/2011 02:15 AM, R?mi Forax wrote: >> This remember me that we don't have any benchmarks using dynamic languages >> which is, as you explain, not good on the long term. >> >> What about having 10 to 12 benchs, one by language, provided by each >> language runtime developer >> as a good bench for their runtime ? > Well, there are the Computer Language Benchmark Game problems at > http://shootout.alioth.debian.org/ . Isaac Gouy doesn't want to support > more languages officially, but we can certainly use these as a starting > point on some alternative server. > > (There are fast Kawa versions of all the current benchmarks: > http://per.bothner.com/blog/2010/Kawa-in-shootout/ ) The shootout benchmark compares languages/runtimes, I want to compare JVMs or versions of JVMs running idiomatic code of each dynamic languages. R?mi From forax at univ-mlv.fr Wed Sep 7 15:28:19 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Sep 2011 00:28:19 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> Message-ID: <4E67F003.1060702@univ-mlv.fr> On 09/07/2011 10:38 PM, John Rose wrote: > On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote: > >> This would probably also mean that the exception object created for >> capturing the slow-case program state needs to be escape-analyzed and >> removed in the optimized code that deoptimizes on overflow? > > Yes. And in the case of user-defined deoptimization, the exception > object would encode the continuation required by the source language. > > (A continuation would be something like a source location or an AST > node, plus a map from local values to source variables. The local > exception handler would package up the live local values into a > display that could be loaded into the backup interpreter.) > > This exception object would be live only on the exception path, and so > (as you say) could be built lazily from the JVM's debug info for EA. > > As we discussed at the JVM Language Summit, building user-level > deoptimization on top of JVM-level deoptimization should allow > non-Java languages to benefit from the same partial-compilation > tactics that Java enjoys. > > The nicest part is that the basic components are in place; we just > need to settle on effective patterns and tune up the associated JVM > optimizations. > > For example, at the Summit Remi pointed out an optimization problem > associated with this pattern: > > Object l0, l1, l2, ...; > l0 = l1 = l2 = ... null; // these are required only for definite > assignment in the catch body > try { > ...do fast path... > if (...constraint violated...) throw new DeoptExc(...); > return ...fast result... > } catch (DeoptExc ex) { > Object[] display = { l0, l1, l2, ... }; > return backupInterpreter(ex, display); // N.B. could throw > DeoptExc to caller also > } > > This problem is that the eager initializations of the various locals > slow down the fast path. (Did I get it right Remi?) The register > allocator should push them down into the catch body, and maybe even > into the static debug info of the JVM. Locals is not the only problem, you have to track stack values too. It's the combination of locals initialization, local variable creation for storing stack values and supplementary exception handlers (that's the main problem, or you have multiple handlers, or you have one handler and a constant) that slow down the fast path. Also, in the catch block you can use invokedynamic to avoid the object array creation at call site. > > If we had a benchmark that demonstrated the problems with such an > approach, we could file a bug to tune the optimizer for it. The ideal > benchmark would not actually run the deoptimization path (except to > demonstrate correctness) but would measure the speed of the fast path, > and the impact of the deopt support on the fast path. Integer > overflow is an obvious candidate for a rare deopt condition, and so > would a quasi-constant function binding (via a MutableCallsite). A > tak or fib benchmark could demonstrate both. Ok, let's try with fib. > > -- John R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/3a322352/attachment.html From per at bothner.com Wed Sep 7 15:40:30 2011 From: per at bothner.com (Per Bothner) Date: Wed, 07 Sep 2011 15:40:30 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> Message-ID: <4E67F2DE.6090704@bothner.com> On 09/07/2011 02:25 PM, Charles Oliver Nutter wrote: > On Wed, Sep 7, 2011 at 2:00 AM, Per Bothner wrote: >> Kawa's gnu.math.IntNum already does this. It has only two fields: > > Yeah, I think I remember you mentioning this in one of the > arbitrary-precision math threads on JVM-L. I assume you could use an > intrinsic optimization for overflow checks too, yes? That seem likely. Right now the code path is a bit complex, but in the case of adding two array-less IntNum we convert to long, and do a long addition. Then we check if the result is in the range [minFixNum..maxFixNum] of pre-allocated IntNums. Then we check if result==(int)result - i.e. if we got an actual overflow. So in addition to a fast overflow check it would be helpful to have a fast test that the result is in range of the preallocated "fixnums". If we had a cheap overflow test then I'd presumably change the code patch to use int arithmetic (instead of long), but it might still be too much to inline. I think a fast overflow check is most helpful when you want to detect overflow and throw an exception; it's less of a win when you also need to allocate a BigInteger/IntNum. -- --Per Bothner per at bothner.com http://per.bothner.com/ From per at bothner.com Wed Sep 7 15:43:35 2011 From: per at bothner.com (Per Bothner) Date: Wed, 07 Sep 2011 15:43:35 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E67EA10.8050900@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> <4E673621.40407@univ-mlv.fr> <4E67C6B2.4020604@bothner.com> <4E67EA10.8050900@univ-mlv.fr> Message-ID: <4E67F397.4040900@bothner.com> On 09/07/2011 03:02 PM, R?mi Forax wrote: > On 09/07/2011 09:32 PM, Per Bothner wrote: >> On 09/07/2011 02:15 AM, R?mi Forax wrote: >>> What about having 10 to 12 benchs, one by language, provided by each >>> language runtime developer >>> as a good bench for their runtime ? >> Well, there are the Computer Language Benchmark Game problems at >> http://shootout.alioth.debian.org/ . > ... > The shootout benchmark compares languages/runtimes, > I want to compare JVMs or versions of JVMs running > idiomatic code of each dynamic languages. But why can't the shootout benchmark programs also be useful for testing and comparing JVMs? -- --Per Bothner per at bothner.com http://per.bothner.com/ From john.r.rose at oracle.com Wed Sep 7 16:12:35 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Sep 2011 16:12:35 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E67F003.1060702@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E67F003.1060702@univ-mlv.fr> Message-ID: On Sep 7, 2011, at 3:28 PM, R?mi Forax wrote: > On 09/07/2011 10:38 PM, John Rose wrote: >> >> Object l0, l1, l2, ...; >> l0 = l1 = l2 = ... null; // these are required only for definite assignment in the catch body >> try { >> ...do fast path... >> if (...constraint violated...) throw new DeoptExc(...); >> return ...fast result... >> } catch (DeoptExc ex) { >> Object[] display = { l0, l1, l2, ... }; >> return backupInterpreter(ex, display); // N.B. could throw DeoptExc to caller also >> } >> >> This problem is that the eager initializations of the various locals slow down the fast path. (Did I get it right Remi?) The register allocator should push them down into the catch body, and maybe even into the static debug info of the JVM. > > Locals is not the only problem, you have to track stack values too. To clarify, I meant only JVM locals, which serve as virtual registers for the application language locals, stacks, whatever. JVM stack elements are guaranteed to be thrown away when a JVM exception is thrown, so they function like virtual registers that are blown by deopt. events. > It's the combination of locals initialization, local variable creation > for storing stack values Yes, if there are logically stacked values that need tracking into slow paths, they need to be spilled to JVM locals. The cost of this will be reduced by good register allocations in the JIT. Ensuring this is part of the tuning job. > and supplementary exception handlers > (that's the main problem, or you have multiple handlers, > or you have one handler and a constant) > that slow down the fast path. I think a single handler is going to be simpler all the way around. Thus, the deopt. source location and value display map have to be stored somewhere so they can be made a parameter to the handler. I think the exception object is the most likely place to store it; TLS is also a candidate. To extend on your cute idea below, have the source location and value display map be static parameters to the invokedynamic instruction which initiates transfer to the slow path. That way everything is in the class file, but lazily unpacked only if needed. There's little or no need to use executable bytecode instructions (other than an indy at the throw point and an indy in the local handler) to manage the deopt. transition. The actual bytecodes can be devoted to executing the fast path code, and testing for type-state faults. BTW, although one might think that the repertoire for static BSM arguments is limited (string, class, int, long, MH, MT), note that the MH gives a hook to open-ended constant formation. Just treat the MH as a thunk to be executed to materialize a desired constant. > Also, in the catch block you can use invokedynamic to avoid > the object array creation at call site. Yes, cute idea. Simplifying code on the slow path should make for faster loading and startup. Or (putting on my Pack200 hat), invokedynamic is the ultimate code-stream compressor. -- John From howard.lovatt at gmail.com Wed Sep 7 21:06:29 2011 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Thu, 8 Sep 2011 14:06:29 +1000 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E671671.6060907@bothner.com> Message-ID: It would be really nice if you could have a class that was something like Double with overflow check initially and then when you detect an overflow substitute in something like BigDecimal instead, i.e. hot swapping of the object's class. This saves having to have a class with two fields and checking one field for null in each method. I believe hot-swapping of classes has been considered as a standard JVM addition and that there are some JVMs, particularly in debug mode, that can do this. Even a very limited form of hot swapping would be useful, you could say that the class must have exactly the same number of instance fields and these must have the same length or be padded and that it must have exactly the same number of virtual methods. Note that double, long, and pointer on many JVMs are 64 bits and therefore even with the limitation of same length you could do something useful (transitioning a number from int through double to arbitrary precision). -- Howard. On 8 September 2011 07:25, Charles Oliver Nutter wrote: > On Wed, Sep 7, 2011 at 2:00 AM, Per Bothner wrote: > > Kawa's gnu.math.IntNum already does this. It has only two fields: > > Yeah, I think I remember you mentioning this in one of the > arbitrary-precision math threads on JVM-L. I assume you could use an > intrinsic optimization for overflow checks too, yes? > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- -- Howard. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/807b471d/attachment-0001.html From eller.helmut at gmail.com Wed Sep 7 23:04:45 2011 From: eller.helmut at gmail.com (Helmut Eller) Date: Thu, 08 Sep 2011 08:04:45 +0200 Subject: Hotspot loves PHP.reboot References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> Message-ID: * John Rose [2011-09-06 20:04] writes: > On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote: > > Did we ever figure out if it's possible to trick Hotspot into doing a > JO instead of the raw bit-level operations? John/Christian/Tom: what > would it take to get HS to "know" that we're doing an integer > overflow-after-maths check and do the (faster?) JO? > > (1) Write a compelling API for something like Integer.addDetectingOverflow. > (2) Roll it into JDK 8+epsilon. > (3) Do the JIT work. > > People have thought on and off about (1) for many years, but with no clear > winner. Exceptions or boxed objects have unpleasant interactions and are > hard to use, while smuggling out the 33rd bit some other way (TLS, a long or > double, a return-by-reference, a sentinel value) is painful. > > (This is a case where tuples would make things simple, but it is not enough > to motivate introducing tuples.) Your comment seems to imply that tuples or multiple return values will not be available anytime soon. Have you some information on what will and will not be in JDK8? Helmut From thomas.wuerthinger at oracle.com Thu Sep 8 04:57:57 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 08 Sep 2011 13:57:57 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> Message-ID: <4E68ADC5.4020105@oracle.com> On 07.09.2011 22:38, John Rose wrote: > For example, at the Summit Remi pointed out an optimization problem > associated with this pattern: > > Object l0, l1, l2, ...; > l0 = l1 = l2 = ... null; // these are required only for definite > assignment in the catch body > try { > ...do fast path... > if (...constraint violated...) throw new DeoptExc(...); > return ...fast result... > } catch (DeoptExc ex) { > Object[] display = { l0, l1, l2, ... }; > return backupInterpreter(ex, display); // N.B. could throw > DeoptExc to caller also > } > > This problem is that the eager initializations of the various locals > slow down the fast path. (Did I get it right Remi?) The register > allocator should push them down into the catch body, and maybe even > into the static debug info of the JVM. Why not the following code pattern? Does it generate too many bytecodes? What about an exception that contains a *detailed* stack trace that includes expression stack and local variables? That might solve the issue of capturing the local variables altogether and provide a natural way of expressing customized deoptimization. Object l0, l1, l2, ...; try { ...do fast path... if (...constraint violated...) { Object[] display = { l0, l1, l2, null, ... }; throw new DeoptExc(display); } return ...fast result... } catch (DeoptExc ex) { return backupInterpreter(ex, ex.display); // N.B. could throw DeoptExc to caller also } So with the *detailed* stack trace it would read: Object l0, l1, l2, ...; try { ...do fast path... if (...constraint violated...) throw new DeoptExc(); return ...fast result... } catch (DeoptExc ex) { return backupInterpreter(ex, ex.getLocalsAndStack()); // N.B. could throw DeoptExc to caller also } That could also work nicely with "addWithoutOverflow(a, b) throws DeoptExc". In the optimized code the catch block and the throw-statement are both not present (based on the branch prediction analysis). So in case of overflow the VM would first do a Java-level deoptimization. Then the interpreter would throw the DeoptExc, which will then lead to the scripting-level deoptimization. - thomas From mikeb01 at gmail.com Thu Sep 8 11:45:34 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Thu, 8 Sep 2011 19:45:34 +0100 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: Hi, Should there be a relevant jdk7-b147-to-bsd-port.patch patch for the hotspot tree? stub:hotspot mikeb01$ hg qselect bsd-port stub:hotspot mikeb01$ head -4 .hg/patches/series # base = a32de5085326 in http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot [2011-09-01] jdk7-b147-to-bsd-port.patch #+bsd-port snowleopard.patch #+bsd-port #-/snowleopard #+gcc42 stub:hotspot mikeb01$ hg qpush applying jdk7-b147-to-bsd-port.patch unable to read jdk7-b147-to-bsd-port.patch stub:patches mikeb01$ ls */jdk7-b147-to-bsd-port.patch jdk/jdk7-b147-to-bsd-port.patch langtools/jdk7-b147-to-bsd-port.patch Mike. On Fri, Sep 2, 2011 at 8:58 AM, John Rose wrote: > OK, I have rebased the mlvm patch repository to hsx/hotspot-comp. > > If you have been reusing your upstream source repositories (based on bsd-port), you will have to discard them and pull instead from hotspot-comp. > > As a temporary solution for building on Mac OS, I have included a set of new patches called patches/*/jdk7-b147-to-bsd-port.patch which capture the relevant differences from bsd-port, and are applicable to the contents of hsx/hotspot-comp/*/. ?When we get the bsd-port changes folded into hsx, these ugly patches will go away. > > BTW, if you build on Mac OS, you need to enable the guard "bsd-port" in the patch queue guard files, or else the ugly patches won't get rolled in. ?The makefile (in patches/make/) attempts to do this automagically for you. > > Please give it a whirl and let me know what breaks. > > End-of-summer regards, > -- John > > On Aug 19, 2011, at 11:47 AM, Christian Thalinger wrote: > >> On Aug 19, 2011, at 7:33 PM, Tom Rodriguez wrote: >> >>>>>> >>>>> >>>>> I'm open to suggestions on this one. >>>>> >>>>> It seems to me that the bsd-port repo. is slowing down prior to absorption into the mainline. >>>>> >>>>> In this case, maybe the rational thing is to reparent to a faster-moving repo. >>>>> >>>>> In particular, I think we should reparent to from bsd-port/bsd-port to hsx/hotspot-comp . ?That's (approximately) where our future is anyway. >>>>> >>>>> Current diffs only in bsd-port (which are necessary for mac builds!) can be posted as a suitably conditional part of the mlvm patch queue. >>>>> >>>>> Comments? >>>> >>>> I concur! ?Moving to hsx/hotspot-comp would be a very good idea. ?That would make publishing patches to mlvm a lot easier. >>> >>> I think we're not very far from having the bsd-port diffs in hotspot which will alleviate this. ?I kind of volunteered myself to shepherd them in and I want to get it done early next week. ?Hopefully this will allow the mac builds to start directly from hsx, modulo any build breakages since neither BSD nor Mac are in JPRT yet. >> >> I volunteer to review (and try) them too. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Thu Sep 8 12:06:50 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 08 Sep 2011 19:06:50 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase mlvm to hsx/hotspot-comp (add jdk7-b147-to-bsd-port) Message-ID: <20110908190650.60E6C47492@hg.openjdk.java.net> Changeset: 6d10c6db8300 Author: jrose Date: 2011-09-08 12:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/6d10c6db8300 rebase mlvm to hsx/hotspot-comp (add jdk7-b147-to-bsd-port) + jdk7-b147-to-bsd-port.patch From john.r.rose at oracle.com Thu Sep 8 12:07:17 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 12:07:17 -0700 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: <620994DF-8522-4548-B2C3-7C8E859E1970@oracle.com> On Sep 8, 2011, at 11:45 AM, Michael Barker wrote: > Should there be a relevant jdk7-b147-to-bsd-port.patch patch for the > hotspot tree? (blush) Now there is. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/b7e3ea35/attachment.html From mikeb01 at gmail.com Thu Sep 8 12:26:28 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Thu, 8 Sep 2011 20:26:28 +0100 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <620994DF-8522-4548-B2C3-7C8E859E1970@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> <620994DF-8522-4548-B2C3-7C8E859E1970@oracle.com> Message-ID: > Should there be a relevant jdk7-b147-to-bsd-port.patch patch for the > hotspot tree? > > (blush) ?Now there is. ?-- John Cheers! From john.r.rose at oracle.com Thu Sep 8 12:47:47 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 12:47:47 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E68ADC5.4020105@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> Message-ID: On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote: > Why not the following code pattern? Does it generate too many bytecodes? That's a reasonable alternative. It generates data movement bytecodes O(L * M), where L is the average number of live values at deopt points and M is the number of deopt points. The quadratic exponent on bytecode size bothers me, at least a little. The other pattern pins the live values into a common set of locals, reducing data movement bytecodes (and probably compiled code data movement). Using Remi's trick of an invokedynamic instead of a varargs array, the number of data movement bytecodes can be cut down about 3x (no iconst/aastore). But it's still quadratic. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/2ea1781d/attachment.html From forax at univ-mlv.fr Thu Sep 8 15:06:55 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 09 Sep 2011 00:06:55 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E67F003.1060702@univ-mlv.fr> Message-ID: <4E693C7F.9050405@univ-mlv.fr> On 09/08/2011 01:12 AM, John Rose wrote: > On Sep 7, 2011, at 3:28 PM, R?mi Forax wrote: > >> On 09/07/2011 10:38 PM, John Rose wrote: >>> Object l0, l1, l2, ...; >>> l0 = l1 = l2 = ... null; // these are required only for definite assignment in the catch body >>> try { >>> ...do fast path... >>> if (...constraint violated...) throw new DeoptExc(...); >>> return ...fast result... >>> } catch (DeoptExc ex) { >>> Object[] display = { l0, l1, l2, ... }; >>> return backupInterpreter(ex, display); // N.B. could throw DeoptExc to caller also >>> } >>> >>> This problem is that the eager initializations of the various locals slow down the fast path. (Did I get it right Remi?) The register allocator should push them down into the catch body, and maybe even into the static debug info of the JVM. >> Locals is not the only problem, you have to track stack values too. > To clarify, I meant only JVM locals, which serve as virtual registers for the application language locals, stacks, whatever. JVM stack elements are guaranteed to be thrown away when a JVM exception is thrown, so they function like virtual registers that are blown by deopt. events. > >> It's the combination of locals initialization, local variable creation >> for storing stack values > Yes, if there are logically stacked values that need tracking into slow paths, they need to be spilled to JVM locals. The cost of this will be reduced by good register allocations in the JIT. Ensuring this is part of the tuning job. > >> and supplementary exception handlers >> (that's the main problem, or you have multiple handlers, >> or you have one handler and a constant) >> that slow down the fast path. > I think a single handler is going to be simpler all the way around. Thus, the deopt. source location and value display map have to be stored somewhere so they can be made a parameter to the handler. I think the exception object is the most likely place to store it; TLS is also a candidate. currently I'm thinking to use multiple exception handler entry points but only one common code. handler1: iconst_0 goto common_handler handler2: iconst_1 goto common_handler ... common_handler: swap pop // remove exception object aload spill1 aload spill2 ... invokedynamic foo (ILObject;LObject ...) > > To extend on your cute idea below, have the source location and value display map be static parameters to the invokedynamic instruction which initiates transfer to the slow path. That way everything is in the class file, but lazily unpacked only if needed. There's little or no need to use executable bytecode instructions (other than an indy at the throw point and an indy in the local handler) to manage the deopt. transition. The actual bytecodes can be devoted to executing the fast path code, and testing for type-state faults. for PHP.reboot I need the AST node corresponding to the operation that overflow, so I need a live value. But I can use one parameter of the method to transfer all AST nodes wrapped in one object bound to the current method. > > BTW, although one might think that the repertoire for static BSM arguments is limited (string, class, int, long, MH, MT), note that the MH gives a hook to open-ended constant formation. Just treat the MH as a thunk to be executed to materialize a desired constant. but you can get live value unless you allow to insert live values to the constant pool when linking the class (another old dream). > >> Also, in the catch block you can use invokedynamic to avoid >> the object array creation at call site. > Yes, cute idea. Simplifying code on the slow path should make for faster loading and startup. > > Or (putting on my Pack200 hat), invokedynamic is the ultimate code-stream compressor. > > -- John R?mi From thomas.wuerthinger at oracle.com Thu Sep 8 16:06:09 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 09 Sep 2011 01:06:09 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> Message-ID: <4E694A61.8040901@oracle.com> On 08.09.2011 21:47, John Rose wrote: > On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote: > >> Why not the following code pattern? Does it generate too many bytecodes? > > That's a reasonable alternative. > > It generates data movement bytecodes O(L * M), where L is the average > number of live values at deopt points and M is the number of deopt > points. The quadratic exponent on bytecode size bothers me, at least > a little. But with a specialized DeoptimizeException that automatically captures the values of the local variables and operand stack at the JVM-level (in fillInStackTrace), there would not be any data movement bytecodes at all. It would require a 1-1 correspondance between scripting language local variables and Java bytecode local variables, but would both be efficient to generate and performant at run time. The information could be captured for all stack frames between the throwing method and the catching method. Here an example for a scripting method that performs a+b and is guessed to not overflow. Object add(int a, int b) { try { return fastPathAdd(a, b); } catch(DeoptimizationException e) { Integer local1 = e.getTopFrame().getLocalAt(0); Integer local2 = e.getTopFrame().getLocalAt(1); return slowPathAdd(local1, local2); } } int fastPathAdd(int a, int b) { if (canOverflow(a, b)) throw new DeoptimizationException(); return a + b; } Object slowPathAdd(Object a, Object b) { // ... generic add implementation ... } - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110909/a18c8b38/attachment.html From john.r.rose at oracle.com Thu Sep 8 16:21:26 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 16:21:26 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E694A61.8040901@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> Message-ID: <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote: > Here an example for a scripting method that performs a+b and is guessed to not overflow. Your example is simplified by the fact that, in the handler, there is only one possible deopt point. What if there are two? E.g., what if your code is: add(a,b,c) := a+b+c . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/166904bf/attachment-0001.html From john.r.rose at oracle.com Thu Sep 8 16:39:27 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 16:39:27 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E693C7F.9050405@univ-mlv.fr> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E67F003.1060702@univ-mlv.fr> <4E693C7F.9050405@univ-mlv.fr> Message-ID: <51770239-3072-4F98-B22C-95081CADB626@oracle.com> On Sep 8, 2011, at 3:06 PM, R?mi Forax wrote: > but you can get live value unless you allow to insert live values to the > constant pool > when linking the class (another old dream). Can we make a solution from ClassValue? -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/0da4242b/attachment.html From forax at univ-mlv.fr Thu Sep 8 16:51:29 2011 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 09 Sep 2011 01:51:29 +0200 Subject: Hotspot loves PHP.reboot Message-ID: If we have coroutine, yes! Remi John Rose wrote: >On Sep 8, 2011, at 3:06 PM, R?mi Forax wrote: > >> but you can get live value unless you allow to insert live values to the >> constant pool >> when linking the class (another old dream). > >Can we make a solution from ClassValue? -- John > > >_______________________________________________ >mlvm-dev mailing list >mlvm-dev at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From thomas.wuerthinger at oracle.com Thu Sep 8 17:35:31 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 09 Sep 2011 02:35:31 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> Message-ID: <4E695F53.2040103@oracle.com> On 09.09.2011 01:21, John Rose wrote: > On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote: > >> Here an example for a scripting method that performs a+b and is >> guessed to not overflow. > > Your example is simplified by the fact that, in the handler, there is > only one possible deopt point. What if there are two? > > E.g., what if your code is: add(a,b,c) := a+b+c . > The example could be any complex scripting function. So let's consider the following method: function sumUp(n) { var sum=0; for (var i=0; islowpath-entry-point. Such a slowpath-entry-point could either be an interpreter loop method (started with the current locals and scripting code position) or a lazily generated generic OSR version of the scripting function. So the code could look like: Object sumUpGeneric(int n) { try { return sumUpFastPath(n); } catch(DeoptimizationException e) { StackFrame f = e.getStackFrame("sumUpFastPath"); ScriptingPosition p = map.get(f.bci()); return invokeInterpreter(sumUpMethod, p, f.getLocals(), f.getExpressionStack()); } } The operand stack and locals manipulation in the generated bytecodes must exactly match the manipulations done by the scripting interpreter, but I think that it is possible to align those (although there might be some complexity due to the fact that certain value types require more than 1 stack slot). The safeAdd method could be intrinsified to deoptimize to the Java interpreter. So, in case an overflow occurs, there would be a two-level deoptimization: Java optimized code => Java interpreter (which now actually throws the DeoptimizationException) => Scripting language interpreter. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110909/3ac3d463/attachment.html From john.r.rose at oracle.com Thu Sep 8 18:00:29 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Sep 2011 18:00:29 -0700 Subject: Hotspot loves PHP.reboot In-Reply-To: <4E695F53.2040103@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> Message-ID: On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote: > The operand stack and locals manipulation in the generated bytecodes must exactly match the manipulations done by the scripting interpreter, but I think that it is possible to align those (although there might be some complexity due to the fact that certain value types require more than 1 stack slot). The safeAdd method could be intrinsified to deoptimize to the Java interpreter. So, in case an overflow occurs, there would be a two-level deoptimization: Java optimized code => Java interpreter (which now actually throws the DeoptimizationException) => Scripting language interpreter. Got it. I had missed the meaning of your phrase "at the JVM-level (in fillInStackTrace)". So the exception has an extra-heavy backtrace. The backtrace amounts to a JVM continuation. Is there a way to do data hiding so that the language runtime can only see locals that it has a right to observe? That IMO is the problem with rich backtraces: They provide a very deep punch into the JVM, which can be exploited (like reflection) to break across trust boundaries. I guess one answer is that we could trust language runtimes. I'd rather find a more compartmentalized solution, hence my interest in patterns expressible in current bytecodes. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110908/03295cf6/attachment.html From john.r.rose at oracle.com Fri Sep 9 00:16:50 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 09 Sep 2011 07:16:50 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp Message-ID: <20110909071651.292C8474C8@hg.openjdk.java.net> Changeset: 55905659f0da Author: jrose Date: 2011-09-09 00:16 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/55905659f0da rebase to current hsx/hotspot-comp ! bsd.patch ! jdk7-b147-to-bsd-port.patch ! series From john.r.rose at oracle.com Fri Sep 9 00:16:56 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 09 Sep 2011 07:16:56 +0000 Subject: hg: mlvm/mlvm/jdk: rebase to current hsx/hotspot-comp Message-ID: <20110909071656.D7877474C9@hg.openjdk.java.net> Changeset: e365d4c876fc Author: jrose Date: 2011-09-09 00:16 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e365d4c876fc rebase to current hsx/hotspot-comp ! jdk7-b147-to-bsd-port.patch ! series From john.r.rose at oracle.com Fri Sep 9 00:17:02 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 09 Sep 2011 07:17:02 +0000 Subject: hg: mlvm/mlvm/langtools: rebase to current hsx/hotspot-comp Message-ID: <20110909071702.70F1C474CA@hg.openjdk.java.net> Changeset: 67de663d4ecb Author: jrose Date: 2011-09-09 00:16 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/67de663d4ecb rebase to current hsx/hotspot-comp ! series From forax at univ-mlv.fr Fri Sep 9 12:01:34 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 09 Sep 2011 21:01:34 +0200 Subject: Hotspot loves PHP.reboot In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> Message-ID: <4E6A628E.6030208@univ-mlv.fr> I've taken the time to write a small prototype (by hand :( ) see http://www-igm.univ-mlv.fr/~forax/tmp/jsr292-deopt.zip using Fibonacci as John suggest. The idea is to transfer the control from fibo written using ints to fibo written using Object (BigInteger at runtime). If an operation overflow, an exception is thrown and the stack is reconstructed to restart the operation on objects. Moreover, a call can now fail because the result value is not an int anymore, in that case, the new return value is thrown inside an exception (one by thread), again the exception is catched and the control flow is transfered to the version that use objects just after the call. To summarize, you can transfer the control flow, either because an operation fail or because the return value of a call is not an int anymore. public static int fibo(int n) { if (n < 2) return 1; return fibo(n - 1) + fibo(n - 2); } In fibo, we have 5 deoptimization pointcuts, n -1 can overflow, n - 2 can overflow, + can overflow, the first call to fibo can return a big integer, the second call to fibo can return a big integer. Each pointcut is encapsulated in a try catch that jump to a specific exception handler. All exception handlers first push a constant (corresponding to the pointcut number) and then jump to the same code that load all variables that potentially store the stack and do an invokedynamic invokedynamic calls a specific function (I have called it an exit function) which constructed from the fibonacci function but using objects. Depending on the pointcut number, a preamble code jump before an operation to restart it or after a function call to replace the return value stored in the exception. Because fibo is recursive, it can also call a plain old fibonacci function using objects without preamble jump code. You can note that the exit function (and the plain function if the function is recursive) can be generated lazily, only if needed i.e. if an overflow occurs. Now the bench on my laptop for fibo(45), i.e when there is no overflow: $ time java -cp .:classes JavaFibo // classical Java, fibo(45) using ints real 0m7.393s user 0m7.238s sys 0m0.014s $ time java -cp .:classes JavaLongFibo // classical Java, fibo (45) using longs real 0m6.021s user 0m6.000s sys 0m0.017s $ time java -cp .:classes Fibo // ints + overflow detecttion real 0m8.263s user 0m8.112s sys 0m0.015s Not that bad but it's only with 5 pointcuts. For the record, here is the time for fibo(47): $ time java -cp .:classes Fibo real 3m21.727s user 3m22.882s sys 0m0.513s I know that the deoptimization bootstrap method can install a transfer method that is a little faster but I think that either BigInteger are slow or I have made a mistake in the deoptimization code. Anyway, the result value is Ok. R?mi On 09/08/2011 09:47 PM, John Rose wrote: > On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote: > >> Why not the following code pattern? Does it generate too many bytecodes? > > That's a reasonable alternative. > > It generates data movement bytecodes O(L * M), where L is the average > number of live values at deopt points and M is the number of deopt > points. The quadratic exponent on bytecode size bothers me, at least > a little. > > The other pattern pins the live values into a common set of locals, > reducing data movement bytecodes (and probably compiled code data > movement). > > Using Remi's trick of an invokedynamic instead of a varargs array, the > number of data movement bytecodes can be cut down about 3x (no > iconst/aastore). But it's still quadratic. > > -- John > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110909/2f2635ee/attachment.html From john.r.rose at oracle.com Fri Sep 9 16:44:22 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 09 Sep 2011 23:44:22 +0000 Subject: hg: mlvm/mlvm/hotspot: after rebase, tweak patch metadata Message-ID: <20110909234423.1048747503@hg.openjdk.java.net> Changeset: 77152ce2c746 Author: jrose Date: 2011-09-09 16:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/77152ce2c746 after rebase, tweak patch metadata - meth-zero-7066143.patch ! series ! tuple-tsig.patch From john.r.rose at oracle.com Fri Sep 9 16:44:30 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 09 Sep 2011 23:44:30 +0000 Subject: hg: mlvm/mlvm/jdk: after rebase, tweak patch metadata Message-ID: <20110909234430.E639147504@hg.openjdk.java.net> Changeset: e7cbff158bbc Author: jrose Date: 2011-09-09 16:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e7cbff158bbc after rebase, tweak patch metadata ! series From john.r.rose at oracle.com Fri Sep 9 16:44:38 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 09 Sep 2011 23:44:38 +0000 Subject: hg: mlvm/mlvm/langtools: after rebase, tweak patch metadata Message-ID: <20110909234438.60D6B47505@hg.openjdk.java.net> Changeset: 55b0cb070030 Author: jrose Date: 2011-09-09 16:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/55b0cb070030 after rebase, tweak patch metadata ! series From john.r.rose at oracle.com Sat Sep 10 19:32:28 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 11 Sep 2011 02:32:28 +0000 Subject: hg: mlvm/mlvm/jdk: indy: first cut of support for new classfile features in JDK7 Message-ID: <20110911023228.CBEEE47543@hg.openjdk.java.net> Changeset: 768833b01a9a Author: jrose Date: 2011-09-10 19:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/768833b01a9a indy: first cut of support for new classfile features in JDK7 ! indy.pack.patch + indy.pack.patch.html ! series From mikeb01 at gmail.com Sun Sep 11 01:10:25 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Sun, 11 Sep 2011 09:10:25 +0100 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: > Please give it a whirl and let me know what breaks. I have a working build on Mac OS X Lion with gcc-4.2. I started with stephenb's MLVM build scripts. I have a couple of small issues to crack as I went: - Bootstrapped with 64bit bsd-port openjdk 1.7 binaries from: http://code.google.com/p/openjdk-osx-build/. - Disabled warning as errors as per: http://wikis.sun.com/display/OpenJDK/Darwin10Build - For some reason the /usr/bin/printf binary didn't like one of the printf statements in the top-level make folder, so the made the following change: --- a/make/Defs-internal.gmk Thu Sep 01 13:54:18 2011 -0700 +++ b/make/Defs-internal.gmk Sun Sep 11 08:59:09 2011 +0100 @@ -79,7 +79,7 @@ # Find all build_time_* files and print their contents in a list sorted # on the name of the sub repository. define ReportBuildTimes -$(PRINTF) "-- Build times ----------\nTarget %s\nStart %s\nEnd %s\n%s\n%s\n-------------------------\n" \ +$(PRINTF) "## Build times ##########\nTarget %s\nStart %s\nEnd %s\n%s\n%s\n#########################\n" \ For some reason printf was interpreting the initial "--" as command line argument and failed stating that "-" was not a valid option. - The really odd one was the hotspot build wasn't copying the necessary files into its import folder (failed to find the appropriate build target for the copy). I tracked it down the the hotspot/make/Makefile export folder settings weren't picking up the values for HS_ARCH and VM_PLATFORM from the hotspot/make/bsd/makefiles/defs.make file. I hacked (i.e. I wouldn't consider it a proper fix) HS_ARCH=x86 and VM_PLATFORM=bsd_amd64 into the top of the file and it all built correctly. Mike. From mroos at roos.com Sun Sep 11 17:14:53 2011 From: mroos at roos.com (Mark Roos) Date: Sun, 11 Sep 2011 17:14:53 -0700 Subject: hg: mlvm/mlvm/jdk: indy: first cut of support for new classfile features in JDK7 In-Reply-To: <20110911023228.CBEEE47543@hg.openjdk.java.net> References: <20110911023228.CBEEE47543@hg.openjdk.java.net> Message-ID: >From John Rose indy: first cut of support for new classfile features in JDK7 Where would I look for the features being added? In general is there a place where pending changes are listed? One of the 'bug' lists perhaps. thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110911/c922e648/attachment.html From john.r.rose at oracle.com Sun Sep 11 23:23:22 2011 From: john.r.rose at oracle.com (John Rose) Date: Sun, 11 Sep 2011 23:23:22 -0700 Subject: hg: mlvm/mlvm/jdk: indy: first cut of support for new classfile features in JDK7 In-Reply-To: References: <20110911023228.CBEEE47543@hg.openjdk.java.net> Message-ID: On Sep 11, 2011, at 5:14 PM, Mark Roos wrote: > Where would I look for the features being added? In general is there a place where pending > changes are listed? One of the 'bug' lists perhaps. Nothing new here: The "new classfile features" are those in JDK 7 (JSR 292): the invokedynamic instruction, etc. Pack200 needs an upgrade to support those features; it was not done in JDK 7. (Kind of like ASM needed an upgrade.) -- John From thomas.wuerthinger at oracle.com Mon Sep 12 10:23:21 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Mon, 12 Sep 2011 19:23:21 +0200 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> Message-ID: <4E6E4009.9010008@oracle.com> On 09.09.2011 03:00, John Rose wrote: > On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote: > >> The operand stack and locals manipulation in the generated bytecodes >> must exactly match the manipulations done by the scripting >> interpreter, but I think that it is possible to align those (although >> there might be some complexity due to the fact that certain value >> types require more than 1 stack slot). The safeAdd method could be >> intrinsified to deoptimize to the Java interpreter. So, in case an >> overflow occurs, there would be a two-level deoptimization: Java >> optimized code => Java interpreter (which now actually throws the >> DeoptimizationException) => Scripting language interpreter. > > Got it. I had missed the meaning of your phrase "at the JVM-level (in > fillInStackTrace)". So the exception has an extra-heavy backtrace. Yes, exactly. > The backtrace amounts to a JVM continuation. Is there a way to do > data hiding so that the language runtime can only see locals that it > has a right to observe? > That IMO is the problem with rich backtraces: They provide a very > deep punch into the JVM, which can be exploited (like reflection) to > break across trust boundaries. > I guess one answer is that we could trust language runtimes. I'd > rather find a more compartmentalized solution, hence my interest in > patterns expressible in current bytecodes. If this special exception class is declared as a checked exception, a method would itself chose if its stack is exposed or not based on its "throws" clause. I think in that case the possible exploitations are less than reflection (because it would not be possible to access data declared "private", but only the stacks of methods that are explicitly declared accessible). That this is a first step towards continuation support would be a nice side effect of this solution. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110912/6bd65539/attachment.html From john.r.rose at oracle.com Mon Sep 12 15:59:52 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 12 Sep 2011 15:59:52 -0700 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: <4E6E4009.9010008@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> <4E6E4009.9010008@oracle.com> Message-ID: <797288A6-B677-453A-8028-9C06CCCD5486@oracle.com> On Sep 12, 2011, at 10:23 AM, Thomas Wuerthinger wrote: > If this special exception class is declared as a checked exception, a method would itself chose if its stack is exposed or not based on its "throws" clause. I think in that case the possible exploitations are less than reflection (because it would not be possible to access data declared "private", but only the stacks of methods that are explicitly declared accessible). That this is a first step towards continuation support would be a nice side effect of this solution. We have explored reified JVM states already; it's interesting but hard to tame: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/callcc_old.txt Let's assume (for the moment) that each participating frame will have a handler which can contain special code (or metadata) to collect the required locals of the participating frame. There's a more direct way to solve the current problem, which doesn't require a complex security model, and decouples the local-grabbing hack from exceptions. The idea is to introduce something like the x86 "pusha" instruction to the JVM. Introduce a native-coded intrinsic which returns a Object[] array (or tuple) of all the locals in the *immediate* caller of the intrinsic. (Should be an instruction, maybe, but can be an intrinsic.) static int unity() { int x = 1; String y = "tu"; System.out.println(Arrays.asList(System.getLocalArray())); // might print [1, tu] or [1, null] return x; } This exposes the question of liveness: JVMs routinely nullify non-live variables, but what if the only remaining use is the getLocalArray intrinsic? Shouldn't it count as a weak reference? Or will we allow it to "reanimate" all local values? That would impose a systemic cost on the register allocator, for the whole method. Perhaps an argument to getLocalArray (64-bit bitmask) could be used to select locals explicitly. It's still gross, since you have to teach the register allocator to look at calls to getLocalArray; and what if the argument is non-constant? (This feels like the JVM version of JavaScript eval. BTW, I don't think the exception-based formulation helps clean this up.) The getLocalArray intrinsic could be defined in a way that is self-evidently secure. Just like pusha is a shorthand for a lot of individual pushes, the getLocalArray intrinsic could be defined as a shorthand for a lot of individual data motion instructions. Besides compactness, the advantage of the shorthand would be that it would hint to the system that the variable definitions could be put on the slow path. But all this could be accomplished more simply by just putting the data motion instructions (apush #N etc.) in the slow path, just before a well-crafted invokedynamic instruction. Let the normal profiling supply the required hint about slow paths, and sink the data movement instructions into the deopt. metadata. Now I want to back up to Thomas' specific suggestion. Instead of putting in a catch, suppose we use the "throws" clause of the method to control local capture. This is a clever way to have existing metadata encode an intention to collect locals "automagically", without explicit bytecodes or handlers. It requires an overloading of the idea of "throws", so it might be better to use a new attribute or annotation. In any case, it seems to me that magic frame metadata which causes fillInStackTrace (of selected Throwable types) to collect local values is almost completely equivalent (modulo some simulation overhead) to collecting the locals in each affected frame's handler. I say "almost" because the magic metadata can provide the local information in unpopped frames, while the less magic method (which can be done today) requires each dying frame to be popped, except perhaps for the oldest, in order for the local values (and other state) to be collected into the flying exception. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110912/bd595bff/attachment.html From john.r.rose at oracle.com Mon Sep 12 17:43:26 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 13 Sep 2011 00:43:26 +0000 Subject: hg: mlvm/mlvm: add bsd-port patch to forest root Message-ID: <20110913004326.8083E475C1@hg.openjdk.java.net> Changeset: a5e9cf599de1 Author: jrose Date: 2011-09-12 17:43 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/a5e9cf599de1 add bsd-port patch to forest root + forest-root/jdk7-b147-to-bsd-port.patch + forest-root/series ! make/Makefile ! make/each-patch-repo.sh ! make/link-patch-dirs.sh From john.r.rose at oracle.com Mon Sep 12 17:47:36 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 12 Sep 2011 17:47:36 -0700 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> Message-ID: <6AD11848-34C9-47F7-9866-51E4F16F7ABA@oracle.com> On Sep 11, 2011, at 1:10 AM, Michael Barker wrote: >> Please give it a whirl and let me know what breaks. > > I have a working build on Mac OS X Lion with gcc-4.2. I started with > stephenb's MLVM build scripts. Excellent work. Did you have to use patches/hotspot/snowleopard.patch for gcc-4.2, or can we delete that? > I have a couple of small issues to > crack as I went: > > - Bootstrapped with 64bit bsd-port openjdk 1.7 binaries from: > http://code.google.com/p/openjdk-osx-build/. Yes. Now that the sources are for JDK 8, they require a JDK 7 installation to build from. For Mac, this could require doing a separate build for the bootstrap JDK, or altering the sanity check logic. I used a saved JDK 7 build. > - Disabled warning as errors as per: > http://wikis.sun.com/display/OpenJDK/Darwin10Build Good. > - For some reason the /usr/bin/printf binary didn't like one of the > printf statements in the top-level make folder, so the made the > following change: > > --- a/make/Defs-internal.gmk Thu Sep 01 13:54:18 2011 -0700 > +++ b/make/Defs-internal.gmk Sun Sep 11 08:59:09 2011 +0100 > @@ -79,7 +79,7 @@ > # Find all build_time_* files and print their contents in a list sorted > # on the name of the sub repository. > define ReportBuildTimes > -$(PRINTF) "-- Build times ----------\nTarget %s\nStart %s\nEnd > %s\n%s\n%s\n-------------------------\n" \ > +$(PRINTF) "## Build times ##########\nTarget %s\nStart %s\nEnd > %s\n%s\n%s\n#########################\n" \ > > For some reason printf was interpreting the initial "--" as command > line argument and failed stating that "-" was not a valid option. Oops, this is a new change in bsd-port. I just moved it to the repo mlvm. > - The really odd one was the hotspot build wasn't copying the > necessary files into its import folder (failed to find the appropriate > build target for the copy). I tracked it down the the > hotspot/make/Makefile export folder settings weren't picking up the > values for HS_ARCH and VM_PLATFORM from the > hotspot/make/bsd/makefiles/defs.make file. I hacked (i.e. I wouldn't > consider it a proper fix) HS_ARCH=x86 and VM_PLATFORM=bsd_amd64 into > the top of the file and it all built correctly. That smells like a failed attempt to run "uname" somewhere. What did this line do in defs.make: ARCH:=$(shell uname -m) -- John From sebastian.sickelmann at gmx.de Tue Sep 13 12:57:41 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 13 Sep 2011 21:57:41 +0200 Subject: Remove public fields without breaking binary compatibility Message-ID: <4E6FB5B5.1040006@gmx.de> Hi i created a small concept-demo how i think we can manage to remove some flaws(public accessible fields) out of the jdk without breaking binary-compatibility. I uploaded the "code of cencept" to my github-incubator[0] and posted some description on my weblog[1]. It would be nice to get some discussion/comments on this, even if it destroys my dream that this can solve the above noted problem. I think discussion on the mailing list should be fine. Comments on my weblog are also welcome but i think discussion should went into the mailing-list. I copy the weblog-text here in a mailing-list compatible format. Sorry for the cross-post, i think core-libs-dev can be interessted in general in removing such fields. And I hope some of the mlvm people can say something about if this can be solved better on vm level. [0] https://github.com/picpromusic/incubator/tree/master/jdk/compatibleFieldAccess [1] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ ... more links at the bottom of the mail ---WEBLOG--COPY I think i made a small step in a concept how solutions that removes design flaws (such as public fields) can be solved in an binary compatible way. Public fields in public API are really nasty, and there isn't a solution how this can be resolved without completely removing this class (with a long deprecation phase in the meantime). It is because the missing encapsulation for accessing this field gives you no change to change behavoir (such as checking/permitting values and state). It is this nasty (for public instance fields) GET_FIELD bytecode instruction. It is like Dalibor Topic told it[2] : " Breaking binary compatibility is bad, bad, really, really bad" But than in saw a video[3] Virtual Extension Method with Brain Goetz which solves the compatibility problem introduced by extending the jdk for lambda expressions. After that i created a small concept-prototype which shows how it can work with simple bytecode transformations and invoke dynamic. I think there is much room for improvement and maybe it can be better implemented at the vm level, but actually i don't have the knowledge to do so. And in special : [4]"If you have a golden hammer,...." . I placed the implementation of the concept on my github incubator[5] What is this doing? 1. The build.xml looks complicated but this is not the point here. It compiles the needed things to show the concept here. There is much room optimizing this, but i don't do it because it is really unnecessary. 2. The Problem is the class OLD[6]. It has a public field cause which can be access be anyone. If you put this in an public API you can never change/remove this field without breaking binary compatibility. 2.1. There is a class NEW[7] which introduces the incompatibility in making the public field private. But is also introduces two methods that allows us to access the field in a controlled way. 2.2 There is a class NEW2[8] also which is nearer on my original problem (i tried to remove a public cause field in an exception-class in openjdk). It can throw an exception if changing the cause in the same manner java.lang.Throwable does it. 3. The Class GEN[9] generates three testclasses (TestOld,TestNew and TestNew2) with the same testsequence with is like this: OLD o = new OLD(); System.out.println(o.cause); o.cause = new RuntimeException("NEW"); System.out.println(o.cause); TestNew does it with NEW and TestNew2 does this with NEW2. I have done it with class generating techniques because it would not compile and it would need a really complicated build-file to show how it works, so it was easier to generate some bytecode. 4. The Class Main[10] does an overall test with the three testclasses TestOld, TestNew and TestNew2. [java] <> [java] java.lang.RuntimeException: INIT_OLD [java] java.lang.RuntimeException: NEW [java] <> [java] Exception in thread "main" java.lang.IllegalAccessError: tried to access field NEW.cause from class TestNew [java] at TestNew.testIt(TestNew.txt:3) [java] at Main.main(Main.java:7) The access of the cause field System.out.println(o.cause); crashes. The Test does not even reach the testcase TestNew2 But if you start the Main class with the jvmarg -javaagent:transformer.jar the output is [java] MOCKINJECT BCI [java] <> [java] java.lang.RuntimeException: INIT_OLD [java] java.lang.RuntimeException: NEW [java] <> [java] java.lang.RuntimeException: INIT_NEW [java] java.lang.RuntimeException: NEW [java] <> [java] java.lang.RuntimeException: INIT_NEW [java] ***java.lang.IllegalStateException: Not allowed to change I think this is realy cool. The methods getCause() and initCause are used instead of the field in the cases where the field is not accessable. 4. How does this work? The classes in the transformer.jar transforms the bytecode before loading into the vm. It replaces the GET_FIELD / PUT_FIELD instruction with something like: INVOKEDYNAMIC cause (LNEW;)Ljava/lang/Throwable; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] INVOKEDYNAMIC cause (LNEW;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] You can look the complete bytecode of the testclases if you search for the .txt files in the tmp dir after executing the build script. It invokes the bootstrap methods Bootstrapper.getFunction and Bootstrapper.setFunction in the Bootstrapper[11] class. 5. The Bootstapper class connects the invokedynamic call with the field if accessable or with the accordant annotated access method getCause or initCause. So what do you think? Please throw comments on me, also if you think binary compatible accessors for public fields is a really bad idea. I think there is much room for optimizations here, but first lets discuss about the idea and the concept. -- Sebastian [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007539.html [3] http://medianetwork.oracle.com/media/show/16999 [4] http://en.wikipedia.org/wiki/Law_of_the_instrument [5] https://github.com/picpromusic/incubator/tree/master/jdk/compatibleFieldAccess [6] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/OLD.java#L1 [7] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/NEW.java#L1 [8] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/NEW2.java#L1 [9] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/generator/GEN.java#L1 [10] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/Main.java#L1 [11] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/src/Bootstrapper.java#L1 From mikeb01 at gmail.com Tue Sep 13 14:28:35 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Tue, 13 Sep 2011 22:28:35 +0100 Subject: are there changes for building mlvm now that 1.7 is released? In-Reply-To: <6AD11848-34C9-47F7-9866-51E4F16F7ABA@oracle.com> References: <17B0F6E0-6A27-4AA7-B77A-C83E26057CD6@oracle.com> <1D6DEAE8-3623-4A7E-95EE-B91867832471@oracle.com> <6AD11848-34C9-47F7-9866-51E4F16F7ABA@oracle.com> Message-ID: > Did you have to use patches/hotspot/snowleopard.patch for gcc-4.2, or can we delete that? The snowleopard.patch was applied, I'll have a go at a build without it. >> - The really odd one was the hotspot build wasn't copying the >> necessary files into its import folder (failed to find the appropriate >> build target for the copy). ?I tracked it down the the >> hotspot/make/Makefile export folder settings weren't picking up the >> values for HS_ARCH and VM_PLATFORM from the >> hotspot/make/bsd/makefiles/defs.make file. ?I hacked (i.e. I wouldn't >> consider it a proper fix) HS_ARCH=x86 and VM_PLATFORM=bsd_amd64 into >> the top of the file and it all built correctly. > > That smells like a failed attempt to run "uname" somewhere. > What did this line do in defs.make: > ? ARCH:=$(shell uname -m) I think I see the problem, "uname -m" returns x86_64 and there is no condition in defs.make that will match. Only ARCH=amd64 or ARCH=i386 and ARCH_DATA_MODEL=64. Mike. From thomas.wuerthinger at oracle.com Wed Sep 14 10:10:21 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 14 Sep 2011 19:10:21 +0200 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: <797288A6-B677-453A-8028-9C06CCCD5486@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> <4E6E4009.9010008@oracle.com> <797288A6-B677-453A-8028-9C06CCCD5486@oracle.com> Message-ID: <4E70DFFD.3010800@oracle.com> On 13.09.2011 00:59, John Rose wrote: > This exposes the question of liveness: JVMs routinely nullify > non-live variables, but what if the only remaining use is the > getLocalArray intrinsic? Shouldn't it count as a weak reference? Or > will we allow it to "reanimate" all local values? That would impose a > systemic cost on the register allocator, for the whole method. I cannot think of a use case where nullifying non-live variables would be a problem. > Now I want to back up to Thomas' specific suggestion. Instead of > putting in a catch, suppose we use the "throws" clause of the method > to control local capture. This is a clever way to have existing > metadata encode an intention to collect locals "automagically", > without explicit bytecodes or handlers. It requires an overloading of > the idea of "throws", so it might be better to use a new attribute or > annotation. > > In any case, it seems to me that magic frame metadata which causes > fillInStackTrace (of selected Throwable types) to collect local values > is almost completely equivalent (modulo some simulation overhead) to > collecting the locals in each affected frame's handler. > > I say "almost" because the magic metadata can provide the local > information in unpopped frames, while the less magic method (which can > be done today) requires each dying frame to be popped, except perhaps > for the oldest, in order for the local values (and other state) to be > collected into the flying exception. Yes. The "simulation overhead" in terms of additional bytecodes and local variable liveness is however possibly significant. Also, the try-catch solution does not work for capturing expression stack values. The special-exception solution would enable language implementors to generate more compact (and simpler) bytecode methods (e.g., they could use the Java expression stack as their own expression stack implementation). - thomas From mroos at roos.com Wed Sep 14 12:58:58 2011 From: mroos at roos.com (Mark Roos) Date: Wed, 14 Sep 2011 12:58:58 -0700 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: <4E70DFFD.3010800@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> <4E6E4009.9010008@oracle.com> <4E70DFFD.3010800@oracle.com> Message-ID: >From Thomas (e.g., they could use the Java expression stack as their own expression stack implementation). I believe that this is both used and necessary to create reasonable performance implementation of Smalltalk on the jvm. I do this in Rtalk today mapping the Smalltalk stack to the jvm stack and then use jvmti to get access to the stack when I need it. There are some tradeoffs here with what can be done vs a true Smalltalk stack but I don't see them as that critical( mostly with the manipulations of continuations). It does bring up John's concern that with a debugger available security is more difficult. The Smalltalk I am referencing for my implementation converts the machine stack to objects and back as necessary. Perhaps this approach would give an opportunity to control visibility at a fixed point. I believe this is in line with some of this thread. This brings up what I see as a larger requirement to fulfill the promise of Smalltalk. In Smalltalk everything is an object ( including the stack, heap, vm ...) which can be manipulated from the application side at will. Even to the extent of modifying the vm's behavior or the gc. Most of this is possible if jvmti would be available from the object side. Having a controlled access api would also give a location where visibility and security could be enforced. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110914/3922539e/attachment.html From tom.rodriguez at oracle.com Wed Sep 14 13:20:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Sep 2011 13:20:30 -0700 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: <4E70DFFD.3010800@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> <4E6E4009.9010008@oracle.com> <797288A6-B677-453A-8028-9C06CCCD5486@oracle.com> <4E70DFFD.3010800@oracle.com> Message-ID: <570C441D-4951-4B28-8B69-B08D61B202C1@oracle.com> On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote: > On 13.09.2011 00:59, John Rose wrote: >> This exposes the question of liveness: JVMs routinely nullify >> non-live variables, but what if the only remaining use is the >> getLocalArray intrinsic? Shouldn't it count as a weak reference? Or >> will we allow it to "reanimate" all local values? That would impose a >> systemic cost on the register allocator, for the whole method. > I cannot think of a use case where nullifying non-live variables would > be a problem. But I don't think the compiler knows which locals are live in this case since the state is going to passed to some unknown piece of code. Any JVMState used by getLocalArray would have to treat all locals as live. tom > >> Now I want to back up to Thomas' specific suggestion. Instead of >> putting in a catch, suppose we use the "throws" clause of the method >> to control local capture. This is a clever way to have existing >> metadata encode an intention to collect locals "automagically", >> without explicit bytecodes or handlers. It requires an overloading of >> the idea of "throws", so it might be better to use a new attribute or >> annotation. >> >> In any case, it seems to me that magic frame metadata which causes >> fillInStackTrace (of selected Throwable types) to collect local values >> is almost completely equivalent (modulo some simulation overhead) to >> collecting the locals in each affected frame's handler. >> >> I say "almost" because the magic metadata can provide the local >> information in unpopped frames, while the less magic method (which can >> be done today) requires each dying frame to be popped, except perhaps >> for the oldest, in order for the local values (and other state) to be >> collected into the flying exception. > Yes. The "simulation overhead" in terms of additional bytecodes and > local variable liveness is however possibly significant. Also, the > try-catch solution does not work for capturing expression stack values. > The special-exception solution would enable language implementors to > generate more compact (and simpler) bytecode methods (e.g., they could > use the Java expression stack as their own expression stack implementation). > > - thomas > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From thomas.wuerthinger at oracle.com Wed Sep 14 15:05:35 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 15 Sep 2011 00:05:35 +0200 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: <570C441D-4951-4B28-8B69-B08D61B202C1@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> <4E6E4009.9010008@oracle.com> <797288A6-B677-453A-8028-9C06CCCD5486@oracle.com> <4E70DFFD.3010800@oracle.com> <570C441D-4951-4B28-8B69-B08D61B202C1@oracle.com> Message-ID: <4E71252F.4030308@oracle.com> On 9/14/11 10:20 PM, Tom Rodriguez wrote: > On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote: > >> On 13.09.2011 00:59, John Rose wrote: >>> This exposes the question of liveness: JVMs routinely nullify >>> non-live variables, but what if the only remaining use is the >>> getLocalArray intrinsic? Shouldn't it count as a weak reference? Or >>> will we allow it to "reanimate" all local values? That would impose a >>> systemic cost on the register allocator, for the whole method. >> I cannot think of a use case where nullifying non-live variables would >> be a problem. > But I don't think the compiler knows which locals are live in this case since the state is going to passed to some unknown piece of code. Any JVMState used by getLocalArray would have to treat all locals as live. > > tom Yes, true, I guess the fast-path version of a scripting language method might leave out usages of locals that are necessary in the slow-path version. But one could maybe disable the local variable liveness maps for the methods that use this functionality (i.e., the extended exception stack trace or the getLocalArray)? - thomas From john.r.rose at oracle.com Wed Sep 14 18:50:31 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Sep 2011 18:50:31 -0700 Subject: Hotspot loves PHP.reboot / stack capturing exception In-Reply-To: <4E71252F.4030308@oracle.com> References: <4E6405BC.1090108@univ-mlv.fr> <2B5900C3-20E4-48B7-AE40-B36F66D07070@oracle.com> <4E64C9F3.9040408@univ-mlv.fr> <4E663ECE.4080309@univ-mlv.fr> <10B1C667-F227-400D-9BCA-2788DA641D4D@oracle.com> <4E67C704.60909@oracle.com> <4E68ADC5.4020105@oracle.com> <4E694A61.8040901@oracle.com> <838F2FE9-1414-4F54-978D-9229FF3FA070@oracle.com> <4E695F53.2040103@oracle.com> <4E6E4009.9010008@oracle.com> <797288A6-B677-453A-8028-9C06CCCD5486@oracle.com> <4E70DFFD.3010800@oracle.com> <570C441D-4951-4B28-8B69-B08D61B202C1@oracle.com> <4E71252F.4030308@oracle.com> Message-ID: <77DA330A-4F31-42E4-AD4A-3E790910CCEC@oracle.com> On Sep 14, 2011, at 3:05 PM, Thomas Wuerthinger wrote: > But one could maybe disable the local variable liveness maps > for the methods that use this functionality (i.e., the extended > exception stack trace or the getLocalArray)? Yes, of course. But this will increase spilling throughout those methods. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110914/89228376/attachment.html From forax at univ-mlv.fr Sat Sep 17 02:33:10 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 17 Sep 2011 11:33:10 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: Message-ID: <4E746956.6070901@univ-mlv.fr> Hi Christian, hi all, I understand that you need such kind of logic but I think it's not compatible with the approach taken by Mark Roos i.e flush all callsites if more than a predefined number of callsites have installed an inlining cache. A possible solution is to add a way in the API to know if a callsite will trigger a deoptimization if the target changes. R?mi On 09/16/2011 02:02 PM, Christian Thalinger wrote: > [This change will be pushed after 7087357. So ignore the code removal in src/share/vm/classfile/javaClasses.cpp.] > > http://cr.openjdk.java.net/~twisti/7087838/ > > 7087838: JSR 292: add throttling logic for optimistic call site optimizations > Reviewed-by: > > The optimistic optimization for MutableCallSite and VolatileCallSite > invalidate compiled methods on every setTarget. This possibly results > in a recompile. For ever-changing call sites this is a performance > hit. > > The fix is to add some throttling logic that prevents the optimistic > optimization after a specified amount of invalidations per CallSite > object. > > This change also moves the flush_dependents_on methods from Universe > to CodeCache. > > src/share/vm/c1/c1_GraphBuilder.cpp > src/share/vm/ci/ciCallSite.cpp > src/share/vm/ci/ciCallSite.hpp > src/share/vm/classfile/javaClasses.cpp > src/share/vm/classfile/javaClasses.hpp > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/classfile/vmSymbols.hpp > src/share/vm/code/codeCache.cpp > src/share/vm/code/codeCache.hpp > src/share/vm/code/dependencies.cpp > src/share/vm/code/dependencies.hpp > src/share/vm/memory/universe.cpp > src/share/vm/memory/universe.hpp > src/share/vm/oops/methodOop.cpp > src/share/vm/opto/callGenerator.cpp > src/share/vm/opto/memnode.cpp > src/share/vm/prims/jvmtiRedefineClasses.cpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/runtime/globals.hpp > From kirill.shirokov at oracle.com Sat Sep 17 02:42:26 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Sat, 17 Sep 2011 02:42:26 -0700 (PDT) Subject: Auto Reply: Re: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations Message-ID: <9909142e-f5fb-4fec-af54-19f1c39b40c5@default> On vacation till October 3. Will be reading email occasionally. From kirill.shirokov at oracle.com Sat Sep 17 02:51:06 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Sat, 17 Sep 2011 02:51:06 -0700 (PDT) Subject: Auto Reply: Auto Reply: Re: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations Message-ID: <50abed5e-4928-457c-bd45-e8e62d17dbb0@default> On vacation till October 3. Will be reading email occasionally. From sebastian.sickelmann at gmx.de Sat Sep 17 12:05:26 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 17 Sep 2011 21:05:26 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. Message-ID: <4E74EF76.9080107@gmx.de> Hi, while doing further investigations on my idea [0] i observed a reproducable crash of the vm. It seems to me that it happens while the hotspot tries to inline (i think) a invokedynamic call. It happens only in my second Testcases (a case where an exception is thrown) so i tried to reduce it to a smaller amount of classes. I reduces the example of my idea to some core classes which i packed to [1]. You can run the example starting the Main class. If you start it with -Xint no crash happens. I have packed it with the java-source or with disassembled classfile for the invokedynamic call. What is the Programm doing? Main starts TestNew2.testIt() 20000 times and prints out the thrown exception every time. TestNew2 is a generated class which does something like(just with out the local variable): NEW2 o = new NEW2(); Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] // Which is effective cause = o.getCause(); System.out.println(cause); Throwable newCause = new RuntimeException("NEW"); INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] // Which is effective o.initCause(newCause) which throws the exception that is catched by Main. The Binding is done via the Bootstrapper class. It looks up if the field "NEW2.cause" can be accessed by TestNew2 which isn't the case and binds the two calls to the methods NEW2.getCause and NEW2.initCause. I have checked it with java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) i have put my hs_err_pid.log here [2]. maybe b127 this is not the newest, but i didn't found a newer one. Maybe its the same problem as the porter-stemmer (don't interested me much till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't solve it. I have cross-checked it also with my local openjdk8 builds. The builds are complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev 28cf2aec4dd7 and even if i don't think it's a hotspot problem i checked it also against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ rev 75d763111eec I am not 100% sure if the error is on my side or if it is on the vm, maybe i have done something wrong with the invokedynamic. But i think it is inside hotspot because hotspot / interpreted-mode should work the same way, isn't it? Please let me know if i can make further experiments that helps to isolate/solve this problem. -- Sebastian Sorry if the oss-patches.24.eu isn't as stable as it should be but this my only free webspace i have for this actually. [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar [2] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log From kirill.shirokov at oracle.com Sat Sep 17 12:14:00 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Sat, 17 Sep 2011 12:14:00 -0700 (PDT) Subject: Auto Reply: SIGSEGV while Parse::optimize_inlining an invokedynamic call. Message-ID: On vacation till October 3. Will be reading email occasionally. From mroos at roos.com Sun Sep 18 08:31:33 2011 From: mroos at roos.com (Mark Roos) Date: Sun, 18 Sep 2011 08:31:33 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <4E746956.6070901@univ-mlv.fr> References: <4E746956.6070901@univ-mlv.fr> Message-ID: >From Christian > The optimistic optimization for MutableCallSite and VolatileCallSite > invalidate compiled methods on every setTarget. This possibly results > in a recompile. For ever-changing call sites this is a performance > hit. What is the use model of callsites which drives this? In my case I am using callsites as inline caches so I would expect a flurry of set targets as the initial classes pass though and then occasional sets as new classes show up. The depth is usually about 1 or 2 but sometimes a lot more ( megamorphic ) The other problem is that the sites become stale after awhile so what I do is flush them all ( it would have been nice if that was easy, implied switch point) and let them rebuild as the new classes go by. It seems like it would be hard to differentiate callsites which are always changing from ones which are simply megamorphic or have just been around so long that they have seen lots of classes. By the way how many changes until you throttle? As in my case the GWT is a simple extract field, compare and jump. It would be interesting if the optimization realized that and created a different optimization when the site has lots of targets in its chain. For instance switching from a series of tests to a vTable like lookup. Or maybe just let me specify this some way. Perhaps this argues for finer grain control on the callsites themselves. Providing hints to the optimizer rather than depending on heuristics seems safer at the point in their evolution. At least a way to reset them to some initial state would be helpful as we are creating dynamic languages which are expected to run for long periods. Since this does seem to impact my means of dealing with stale sites do you have any thoughts on an alternative approach? regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110918/cee7ebfb/attachment.html From kirill.shirokov at oracle.com Sun Sep 18 08:33:20 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Sun, 18 Sep 2011 08:33:20 -0700 (PDT) Subject: Auto Reply: Re: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations Message-ID: <13536197-5f33-4e92-893a-7238e03c465a@default> On vacation till October 3. Will be reading email occasionally. From forax at univ-mlv.fr Sun Sep 18 08:44:24 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 18 Sep 2011 17:44:24 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: <4E746956.6070901@univ-mlv.fr> Message-ID: <4E7611D8.9060500@univ-mlv.fr> Hi Mark, the throttle occurs if you deoptimize an already JITed callsite 10 times. If the callsite is not JITed, you can call setTarget() without triggering the throttle logic. So the main problem you will have is if your program always calls very often the same hot code and is really big. Because your code is big, you will have to flush the callsites, so you will flush the hot code which will be recompiled just after (because it's a hot code). After 10 flushes, you will see a performance degradation because your hot code will be no more JITed. R?mi On 09/18/2011 05:31 PM, Mark Roos wrote: > From Christian > > The optimistic optimization for MutableCallSite and VolatileCallSite > > invalidate compiled methods on every setTarget. This possibly results > > in a recompile. For ever-changing call sites this is a performance > > hit. > > What is the use model of callsites which drives this? > > In my case I am using callsites as inline caches so I would expect a > flurry of set targets as > the initial classes pass though and then occasional sets as new > classes show up. The > depth is usually about 1 or 2 but sometimes a lot more ( megamorphic ) > The other problem > is that the sites become stale after awhile so what I do is flush them > all ( it would have been > nice if that was easy, implied switch point) and let them rebuild as > the new classes go by. > > It seems like it would be hard to differentiate callsites which are > always changing from ones > which are simply megamorphic or have just been around so long that > they have seen lots > of classes. By the way how many changes until you throttle? > > As in my case the GWT is a simple extract field, compare and jump. It > would be interesting if > the optimization realized that and created a different optimization > when the site has lots > of targets in its chain. For instance switching from a series of > tests to a vTable like lookup. > Or maybe just let me specify this some way. > > Perhaps this argues for finer grain control on the callsites > themselves. Providing hints to > the optimizer rather than depending on heuristics seems safer at the > point in their evolution. > At least a way to reset them to some initial state would be helpful as > we are creating dynamic > languages which are expected to run for long periods. > > Since this does seem to impact my means of dealing with stale sites do > you have any thoughts > on an alternative approach? > > regards > mark > > > > > > _______________________________________________ > 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/20110918/234c4b82/attachment.html From mroos at roos.com Sun Sep 18 09:49:20 2011 From: mroos at roos.com (Mark Roos) Date: Sun, 18 Sep 2011 09:49:20 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <4E7611D8.9060500@univ-mlv.fr> References: <4E746956.6070901@univ-mlv.fr> <4E7611D8.9060500@univ-mlv.fr> Message-ID: Hi R?mi you mentioned After 10 flushes, you will see a performance degradation because your hot code will be no more JITed. But I also have to setTarget on the callsites when the method code changes. The easy (most efficient) way is to reset them all. So after 10 replacement methods I lose all jitted optimizations? forever? This seems extreme to me. Should the throttle be more sensitive to rate of change and not absolute quantity? Or a means to setTarget which does not count towards throttling. Or (gasp) if I choose to do lots of setTargets maybe I should just take the hit myself leading me to avoid the issue if it matters to me. Since I don't understand the use case where deep/changing chains are common and so nned to be fast, this seems premature to me. I am still wondering what I would do if this is the case? Drop and replace all methods? Do my own callsite to somehow limit target changes ( callsite with a callsite as target)? regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110918/0f0fe350/attachment-0001.html From mroos at roos.com Sun Sep 18 10:16:15 2011 From: mroos at roos.com (Mark Roos) Date: Sun, 18 Sep 2011 10:16:15 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <4E746956.6070901@univ-mlv.fr> References: <4E746956.6070901@univ-mlv.fr> Message-ID: In looking at my code. In general 98% of the callsites are < 3 targets. Those that are larger I can catch and use a different lookup. I also believe that Charles Nutter limits his depth to 5. So the general case I see will not exceed the < 10. But I do have some cases where 10 is not the right number Part of my app is a compiler so some of its callsites see 20 or 30 classes ( AST node types). And part is a data flow evaluator where the data has about 30 types And as I watch the jit work it attacks these sites pretty fast so I could image exceeding the > 10. I would like both or these to jit as they are used a lot And my final use case which is dynamic method replacement. Here I have to reset the callsites so they get the correct code. In our system this happens doing feature loading ( small dynamic patches) and for changing math operations ( dataflow) and finally during edit. Both easily exceed the >10 during the execution life of the app (hopefully months). I would be fine if there was a way to tell the jitter to reset its counts on a callsite as all of my use cases can absorb time at that instance. I really would have issues with losing the jitting when the app is expected to be running at full speed and would have to find some clever hack around it. Another point is that the classes callsites see during startup can be quite different than during normal operation. This is another reason we do the bulk invalidation mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110918/cc9c4b03/attachment.html From mikeb01 at gmail.com Sun Sep 18 13:30:19 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Sun, 18 Sep 2011 21:30:19 +0100 Subject: Illegal Instruction in debug_build Message-ID: Hi, I've been trying to run a debug build on Mac OS, the normal build works fine, but the debug version fails with an Illegal Instruction. I've run it through gdb (output below), but I not sure how accurate the information is. I think that it's the result of a stack overflow, it takes around 2s to fail without any launch class specified. Has anyone witnessed anything similar? stub:davinci mikeb01$ sources/build/bsd-amd64-debug/bin/java Illegal instruction: 4 0x000000010199d2af in os::current_stack_pointer () at os_bsd_x86.cpp:284 284 return (address) esp; (gdb) disassemble Dump of assembler code for function _ZN2os21current_stack_pointerEv: 0x000000010199d290 <_ZN2os21current_stack_pointerEv+0>: push %rbp 0x000000010199d291 <_ZN2os21current_stack_pointerEv+1>: mov %rsp,%rbp 0x000000010199d294 <_ZN2os21current_stack_pointerEv+4>: mov -0x18(%rbp),%rax 0x000000010199d298 <_ZN2os21current_stack_pointerEv+8>: mov %rax,%rsp 0x000000010199d29b <_ZN2os21current_stack_pointerEv+11>: mov %rsp,%rax 0x000000010199d29e <_ZN2os21current_stack_pointerEv+14>: mov %rax,-0x10(%rbp) 0x000000010199d2a2 <_ZN2os21current_stack_pointerEv+18>: mov -0x10(%rbp),%rax 0x000000010199d2a6 <_ZN2os21current_stack_pointerEv+22>: mov %rax,-0x8(%rbp) 0x000000010199d2aa <_ZN2os21current_stack_pointerEv+26>: mov -0x8(%rbp),%rax 0x000000010199d2ae <_ZN2os21current_stack_pointerEv+30>: pop %rbp 0x000000010199d2af <_ZN2os21current_stack_pointerEv+31>: retq End of assembler dump. Current language: auto; currently c++ (gdb) bt #0 0x000000010199d2af in os::current_stack_pointer () at os_bsd_x86.cpp:284 (gdb) list 279 register void *esp; 280 __asm__("mov %%"SPELL_REG_SP", %0":"=r"(esp)); 281 return (address) ((char*)esp + sizeof(long)*2); 282 #else 283 register void *esp __asm__ (SPELL_REG_SP); 284 return (address) esp; 285 #endif 286 } 287 288 char* os::non_memory_address_word() { Mike. From kirill.shirokov at oracle.com Sun Sep 18 13:46:19 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Sun, 18 Sep 2011 13:46:19 -0700 (PDT) Subject: Auto Reply: Illegal Instruction in debug_build Message-ID: On vacation till October 3. Will be reading email occasionally. From forax at univ-mlv.fr Sun Sep 18 16:19:08 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 19 Sep 2011 01:19:08 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: <4E746956.6070901@univ-mlv.fr> Message-ID: <4E767C6C.9050202@univ-mlv.fr> On 09/18/2011 07:16 PM, Mark Roos wrote: > In looking at my code. > > In general 98% of the callsites are < 3 targets. > > Those that are larger I can catch and use a different lookup. I also > believe that Charles Nutter limits his > depth to 5. > > So the general case I see will not exceed the < 10. > > But I do have some cases where 10 is not the right number > > Part of my app is a compiler so some of its callsites see 20 > or 30 classes ( AST node types). > And part is a data flow evaluator where the data has about 30 > types For these callsites you should use a dispatch table (a vtable dedicated to a callsite) instead of a sequence of 20 guards, because your code is equivalent to looking up a class in a linkedlist, so it's awfully slow. Moreover, are you sure the code that contains these callsites is JITed, it's pretty easy to hit other thresholds like by example the max number of internal nodes (ideal nodes). > > And as I watch the jit work it attacks these sites pretty fast so I > could image exceeding the > 10. > > I would like both or these to jit as they are used a lot > > And my final use case which is dynamic method replacement. Here I > have to reset the callsites so they > get the correct code. In our system this happens doing feature > loading ( small dynamic patches) and for > changing math operations ( dataflow) and finally during edit. Both > easily exceed the >10 during the execution > life of the app (hopefully months). > > I would be fine if there was a way to tell the jitter to reset its > counts on a callsite as all of my use cases > can absorb time at that instance. I really would have issues with > losing the jitting when the app is expected > to be running at full speed and would have to find some clever hack > around it. > > Another point is that the classes callsites see during startup can be > quite different than during normal operation. > This is another reason we do the bulk invalidation > > mark R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110919/bd59e625/attachment.html From christian.thalinger at oracle.com Mon Sep 19 00:57:45 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Sep 2011 09:57:45 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: <4E746956.6070901@univ-mlv.fr> Message-ID: <9E0B2664-867F-4B99-B13D-E504D09C2417@oracle.com> On Sep 18, 2011, at 7:16 PM, Mark Roos wrote: > In looking at my code. > > In general 98% of the callsites are < 3 targets. > > Those that are larger I can catch and use a different lookup. I also believe that Charles Nutter limits his > depth to 5. > > So the general case I see will not exceed the < 10. > > But I do have some cases where 10 is not the right number You can adjust that number in your runtime startup script since the switch that drives that number is a product switch: -XX:PerCallSiteSetTargetTrapLimit=50 > > Part of my app is a compiler so some of its callsites see 20 or 30 classes ( AST node types). > And part is a data flow evaluator where the data has about 30 types > > And as I watch the jit work it attacks these sites pretty fast so I could image exceeding the > 10. > > I would like both or these to jit as they are used a lot > > And my final use case which is dynamic method replacement. Here I have to reset the callsites so they > get the correct code. In our system this happens doing feature loading ( small dynamic patches) and for > changing math operations ( dataflow) and finally during edit. Both easily exceed the >10 during the execution > life of the app (hopefully months). > > I would be fine if there was a way to tell the jitter to reset its counts on a callsite as all of my use cases > can absorb time at that instance. I really would have issues with losing the jitting when the app is expected > to be running at full speed and would have to find some clever hack around it. Tom suggested in a pre-review of the patch that we could (a) have a rate instead of a counter or (b) only count actual deoptimizations (which might be a simple fix for now and decide later if that's good or we need something else). As Remi mentioned we need throttling like this but we don't have enough data yet to tell what is the best approach. Mark, could you try that patch with your implementation? -- Christian > > Another point is that the classes callsites see during startup can be quite different than during normal operation. > This is another reason we do the bulk invalidation > > mark_______________________________________________ > 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/20110919/639ceaa2/attachment.html From kirill.shirokov at oracle.com Mon Sep 19 01:14:36 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Mon, 19 Sep 2011 01:14:36 -0700 (PDT) Subject: Auto Reply: Re: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations Message-ID: On vacation till October 3. Will be reading email occasionally. From christian.thalinger at oracle.com Mon Sep 19 02:09:52 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Sep 2011 11:09:52 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: <4E74EF76.9080107@gmx.de> References: <4E74EF76.9080107@gmx.de> Message-ID: [Moving hotspot-runtime-dev to Bcc] On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: > Hi, > while doing further investigations on my idea [0] i observed a > reproducable crash of the vm. > It seems to me that it happens while the hotspot tries to inline (i > think) a invokedynamic call. > It happens only in my second Testcases (a case where an exception is > thrown) so i tried > to reduce it to a smaller amount of classes. > > I reduces the example of my idea to some core classes which i packed to [1]. > You can run the example starting the Main class. If you start it with > -Xint no crash happens. > I have packed it with the java-source or with disassembled classfile for > the invokedynamic call. > > What is the Programm doing? > > Main starts TestNew2.testIt() 20000 times and prints out the thrown > exception every time. > TestNew2 is a generated class which does something like(just with out > the local variable): > NEW2 o = new NEW2(); > Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; > [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > (6)] > // Which is effective cause = o.getCause(); > System.out.println(cause); > Throwable newCause = new RuntimeException("NEW"); > INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V > [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > (6)] > // Which is effective o.initCause(newCause) which throws the > exception that is catched by Main. > The Binding is done via the Bootstrapper class. > It looks up if the field "NEW2.cause" can be accessed by > TestNew2 which isn't the case and binds the two calls to the methods > NEW2.getCause and NEW2.initCause. > > > I have checked it with > java version "1.7.0" > Java(TM) SE Runtime Environment (build 1.7.0-b147) > Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) > > i have put my hs_err_pid.log here [2]. > > maybe b127 this is not the newest, but i didn't found a newer one. Maybe > its the same problem as the porter-stemmer (don't interested me much > till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't > solve it. > > I have cross-checked it also with my local openjdk8 builds. > > The builds are > complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev > 28cf2aec4dd7 > and even if i don't think it's a hotspot problem i checked it also > against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ > rev 75d763111eec > > I am not 100% sure if the error is on my side or if it is on the vm, > maybe i have done something wrong with the invokedynamic. But i think it > is inside hotspot because hotspot / interpreted-mode should work the > same way, isn't it? I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path The the two classes involved in the is_subtype_of check are in different class loaders: (dbx) fr 8 Current function is ciKlass::is_subtype_of 69 assert(is_loaded() && that->is_loaded(), "must be loaded"); (dbx) p this->print() this->print() = (void) (dbx) p that->print() that->print() = (void) Putting your test case on the boot class path makes it work: $ java Main > /dev/null Abort $ java -Xbootclasspath/a:. Main > /dev/null $ I'm looking into it. -- Christian > > Please let me know if i can make further experiments that helps to > isolate/solve this problem. > > -- Sebastian > > Sorry if the oss-patches.24.eu isn't as stable as it should be but this > my only free webspace i have for this actually. > > [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ > [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar > [2] > http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Mon Sep 19 04:26:48 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Sep 2011 13:26:48 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: References: <4E74EF76.9080107@gmx.de> Message-ID: <341C19AD-87F5-4757-838B-870B2AA7E655@oracle.com> On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: > [Moving hotspot-runtime-dev to Bcc] > > On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: > >> Hi, >> while doing further investigations on my idea [0] i observed a >> reproducable crash of the vm. >> It seems to me that it happens while the hotspot tries to inline (i >> think) a invokedynamic call. >> It happens only in my second Testcases (a case where an exception is >> thrown) so i tried >> to reduce it to a smaller amount of classes. >> >> I reduces the example of my idea to some core classes which i packed to [1]. >> You can run the example starting the Main class. If you start it with >> -Xint no crash happens. >> I have packed it with the java-source or with disassembled classfile for >> the invokedynamic call. What format is the disassembled class file? How can I assemble it to a class file? I'd like to remove the println stuff. -- Christian >> >> What is the Programm doing? >> >> Main starts TestNew2.testIt() 20000 times and prints out the thrown >> exception every time. >> TestNew2 is a generated class which does something like(just with out >> the local variable): >> NEW2 o = new NEW2(); >> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >> (6)] >> // Which is effective cause = o.getCause(); >> System.out.println(cause); >> Throwable newCause = new RuntimeException("NEW"); >> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >> (6)] >> // Which is effective o.initCause(newCause) which throws the >> exception that is catched by Main. >> The Binding is done via the Bootstrapper class. >> It looks up if the field "NEW2.cause" can be accessed by >> TestNew2 which isn't the case and binds the two calls to the methods >> NEW2.getCause and NEW2.initCause. >> >> >> I have checked it with >> java version "1.7.0" >> Java(TM) SE Runtime Environment (build 1.7.0-b147) >> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >> >> i have put my hs_err_pid.log here [2]. >> >> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >> its the same problem as the porter-stemmer (don't interested me much >> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >> solve it. >> >> I have cross-checked it also with my local openjdk8 builds. >> >> The builds are >> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >> 28cf2aec4dd7 >> and even if i don't think it's a hotspot problem i checked it also >> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >> rev 75d763111eec >> >> I am not 100% sure if the error is on my side or if it is on the vm, >> maybe i have done something wrong with the invokedynamic. But i think it >> is inside hotspot because hotspot / interpreted-mode should work the >> same way, isn't it? > > I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: > > 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path > > The the two classes involved in the is_subtype_of check are in different class loaders: > > (dbx) fr 8 > Current function is ciKlass::is_subtype_of > 69 assert(is_loaded() && that->is_loaded(), "must be loaded"); > (dbx) p this->print() > this->print() = (void) > (dbx) p that->print() > that->print() = (void) > > Putting your test case on the boot class path makes it work: > > $ java Main > /dev/null > Abort > $ java -Xbootclasspath/a:. Main > /dev/null > $ > > I'm looking into it. > > -- Christian > >> >> Please let me know if i can make further experiments that helps to >> isolate/solve this problem. >> >> -- Sebastian >> >> Sorry if the oss-patches.24.eu isn't as stable as it should be but this >> my only free webspace i have for this actually. >> >> [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ >> [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar >> [2] >> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log >> _______________________________________________ >> 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 sebastian.sickelmann at gmx.de Mon Sep 19 04:40:50 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 19 Sep 2011 13:40:50 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: <341C19AD-87F5-4757-838B-870B2AA7E655@oracle.com> References: <4E74EF76.9080107@gmx.de> <341C19AD-87F5-4757-838B-870B2AA7E655@oracle.com> Message-ID: I can so this for Sound in a gewesen hours. Info it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should bei in the temp dir after running build.xml. ( Christian Thalinger schrieb: > >On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: > >> [Moving hotspot-runtime-dev to Bcc] >> >> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >> >>> Hi, >>> while doing further investigations on my idea [0] i observed a >>> reproducable crash of the vm. >>> It seems to me that it happens while the hotspot tries to inline (i >>> think) a invokedynamic call. >>> It happens only in my second Testcases (a case where an exception is >>> thrown) so i tried >>> to reduce it to a smaller amount of classes. >>> >>> I reduces the example of my idea to some core classes which i packed to [1]. >>> You can run the example starting the Main class. If you start it with >>> -Xint no crash happens. >>> I have packed it with the java-source or with disassembled classfile for >>> the invokedynamic call. > >What format is the disassembled class file? How can I assemble it to a class file? I'd like to remove the println stuff. > >-- Christian > >>> >>> What is the Programm doing? >>> >>> Main starts TestNew2.testIt() 20000 times and prints out the thrown >>> exception every time. >>> TestNew2 is a generated class which does something like(just with out >>> the local variable): >>> NEW2 o = new NEW2(); >>> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >>> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>> (6)] >>> // Which is effective cause = o.getCause(); >>> System.out.println(cause); >>> Throwable newCause = new RuntimeException("NEW"); >>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >>> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>> (6)] >>> // Which is effective o.initCause(newCause) which throws the >>> exception that is catched by Main. >>> The Binding is done via the Bootstrapper class. >>> It looks up if the field "NEW2.cause" can be accessed by >>> TestNew2 which isn't the case and binds the two calls to the methods >>> NEW2.getCause and NEW2.initCause. >>> >>> >>> I have checked it with >>> java version "1.7.0" >>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >>> >>> i have put my hs_err_pid.log here [2]. >>> >>> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >>> its the same problem as the porter-stemmer (don't interested me much >>> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >>> solve it. >>> >>> I have cross-checked it also with my local openjdk8 builds. >>> >>> The builds are >>> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >>> 28cf2aec4dd7 >>> and even if i don't think it's a hotspot problem i checked it also >>> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >>> rev 75d763111eec >>> >>> I am not 100% sure if the error is on my side or if it is on the vm, >>> maybe i have done something wrong with the invokedynamic. But i think it >>> is inside hotspot because hotspot / interpreted-mode should work the >>> same way, isn't it? >> >> I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: >> >> 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path >> >> The the two classes involved in the is_subtype_of check are in different class loaders: >> >> (dbx) fr 8 >> Current function is ciKlass::is_subtype_of >> 69 assert(is_loaded() && that->is_loaded(), "must be loaded"); >> (dbx) p this->print() >> this->print() = (void) >> (dbx) p that->print() >> that->print() = (void) >> >> Putting your test case on the boot class path makes it work: >> >> $ java Main > /dev/null >> Abort >> $ java -Xbootclasspath/a:. Main > /dev/null >> $ >> >> I'm looking into it. >> >> -- Christian >> >>> >>> Please let me know if i can make further experiments that helps to >>> isolate/solve this problem. >>> >>> -- Sebastian >>> >>> Sorry if the oss-patches.24.eu isn't as stable as it should be but this >>> my only free webspace i have for this actually. >>> >>> [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ >>> [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar >>> [2] >>> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log >>> _______________________________________________ >>> 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 -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. From sebastian.sickelmann at gmx.de Mon Sep 19 06:04:46 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 19 Sep 2011 15:04:46 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: References: <4E74EF76.9080107@gmx.de> <341C19AD-87F5-4757-838B-870B2AA7E655@oracle.com> Message-ID: I can do this for you in a few hours.if it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should be in the temp dir after running build.xml. Sorry for the previous mail. F*** german autocompletion of my smartphone. Sebastian Sickelmann schrieb: >I can so this for Sound in a gewesen hours. Info it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should bei in the temp dir after running build.xml. > ( > >Christian Thalinger schrieb: > >> >>On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: >> >>> [Moving hotspot-runtime-dev to Bcc] >>> >>> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >>> >>>> Hi, >>>> while doing further investigations on my idea [0] i observed a >>>> reproducable crash of the vm. >>>> It seems to me that it happens while the hotspot tries to inline (i >>>> think) a invokedynamic call. >>>> It happens only in my second Testcases (a case where an exception is >>>> thrown) so i tried >>>> to reduce it to a smaller amount of classes. >>>> >>>> I reduces the example of my idea to some core classes which i packed to [1]. >>>> You can run the example starting the Main class. If you start it with >>>> -Xint no crash happens. >>>> I have packed it with the java-source or with disassembled classfile for >>>> the invokedynamic call. >> >>What format is the disassembled class file? How can I assemble it to a class file? I'd like to remove the println stuff. >> >>-- Christian >> >>>> >>>> What is the Programm doing? >>>> >>>> Main starts TestNew2.testIt() 20000 times and prints out the thrown >>>> exception every time. >>>> TestNew2 is a generated class which does something like(just with out >>>> the local variable): >>>> NEW2 o = new NEW2(); >>>> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >>>> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>> (6)] >>>> // Which is effective cause = o.getCause(); >>>> System.out.println(cause); >>>> Throwable newCause = new RuntimeException("NEW"); >>>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >>>> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>> (6)] >>>> // Which is effective o.initCause(newCause) which throws the >>>> exception that is catched by Main. >>>> The Binding is done via the Bootstrapper class. >>>> It looks up if the field "NEW2.cause" can be accessed by >>>> TestNew2 which isn't the case and binds the two calls to the methods >>>> NEW2.getCause and NEW2.initCause. >>>> >>>> >>>> I have checked it with >>>> java version "1.7.0" >>>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>>> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >>>> >>>> i have put my hs_err_pid.log here [2]. >>>> >>>> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >>>> its the same problem as the porter-stemmer (don't interested me much >>>> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >>>> solve it. >>>> >>>> I have cross-checked it also with my local openjdk8 builds. >>>> >>>> The builds are >>>> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >>>> 28cf2aec4dd7 >>>> and even if i don't think it's a hotspot problem i checked it also >>>> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >>>> rev 75d763111eec >>>> >>>> I am not 100% sure if the error is on my side or if it is on the vm, >>>> maybe i have done something wrong with the invokedynamic. But i think it >>>> is inside hotspot because hotspot / interpreted-mode should work the >>>> same way, isn't it? >>> >>> I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: >>> >>> 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path >>> >>> The the two classes involved in the is_subtype_of check are in different class loaders: >>> >>> (dbx) fr 8 >>> Current function is ciKlass::is_subtype_of >>> 69 assert(is_loaded() && that->is_loaded(), "must be loaded"); >>> (dbx) p this->print() >>> this->print() = (void) >>> (dbx) p that->print() >>> that->print() = (void) >>> >>> Putting your test case on the boot class path makes it work: >>> >>> $ java Main > /dev/null >>> Abort >>> $ java -Xbootclasspath/a:. Main > /dev/null >>> $ >>> >>> I'm looking into it. >>> >>> -- Christian >>> >>>> >>>> Please let me know if i can make further experiments that helps to >>>> isolate/solve this problem. >>>> >>>> -- Sebastian >>>> >>>> Sorry if the oss-patches.24.eu isn't as stable as it should be but this >>>> my only free webspace i have for this actually. >>>> >>>> [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ >>>> [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar >>>> [2] >>>> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log >>>> _______________________________________________ >>>> 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 > >-- >Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. >_______________________________________________ >mlvm-dev mailing list >mlvm-dev at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. From sebastian.sickelmann at gmx.de Mon Sep 19 07:40:22 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 19 Sep 2011 16:40:22 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: References: <4E74EF76.9080107@gmx.de> <341C19AD-87F5-4757-838B-870B2AA7E655@oracle.com> Message-ID: <4E775456.8050701@gmx.de> Hi, i tried to simplify the TestNew2 class. But now it is to simple. The crash is gone. I tried to make the process between Main and NEW2 more complex, but this doesn't brings the crash back. i uploaded the new jar to http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash2.jar Can you send me your suggested code for TestNew2 class as pseudo-code. I will assemble and test it. The new actual disassembly looks like: // class version 51.0 (51) // access flags 0x1 public class TestNew2 { // compiled from: TestNew2.txt // debug info: // access flags 0x9 public static testIt()V L0 LINENUMBER 2 L0 NEW NEW2 DUP INVOKESPECIAL NEW2. ()V NEW java/lang/RuntimeException DUP LDC "NEW" INVOKESPECIAL java/lang/RuntimeException. (Ljava/lang/String;)V INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] RETURN MAXSTACK = 4 MAXLOCALS = 0 } -- Sebastian Am 19.09.2011 15:04, schrieb Sebastian Sickelmann: > I can do this for you in a few hours.if it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should be in the temp dir after running build.xml. > > Sorry for the previous mail. F*** german autocompletion of my smartphone. > > > Sebastian Sickelmann schrieb: > >> I can so this for Sound in a gewesen hours. Info it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should bei in the temp dir after running build.xml. >> ( >> >> Christian Thalinger schrieb: >> >>> On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: >>> >>>> [Moving hotspot-runtime-dev to Bcc] >>>> >>>> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >>>> >>>>> Hi, >>>>> while doing further investigations on my idea [0] i observed a >>>>> reproducable crash of the vm. >>>>> It seems to me that it happens while the hotspot tries to inline (i >>>>> think) a invokedynamic call. >>>>> It happens only in my second Testcases (a case where an exception is >>>>> thrown) so i tried >>>>> to reduce it to a smaller amount of classes. >>>>> >>>>> I reduces the example of my idea to some core classes which i packed to [1]. >>>>> You can run the example starting the Main class. If you start it with >>>>> -Xint no crash happens. >>>>> I have packed it with the java-source or with disassembled classfile for >>>>> the invokedynamic call. >>> What format is the disassembled class file? How can I assemble it to a class file? I'd like to remove the println stuff. >>> >>> -- Christian >>> >>>>> What is the Programm doing? >>>>> >>>>> Main starts TestNew2.testIt() 20000 times and prints out the thrown >>>>> exception every time. >>>>> TestNew2 is a generated class which does something like(just with out >>>>> the local variable): >>>>> NEW2 o = new NEW2(); >>>>> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >>>>> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>>> (6)] >>>>> // Which is effective cause = o.getCause(); >>>>> System.out.println(cause); >>>>> Throwable newCause = new RuntimeException("NEW"); >>>>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >>>>> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>>> (6)] >>>>> // Which is effective o.initCause(newCause) which throws the >>>>> exception that is catched by Main. >>>>> The Binding is done via the Bootstrapper class. >>>>> It looks up if the field "NEW2.cause" can be accessed by >>>>> TestNew2 which isn't the case and binds the two calls to the methods >>>>> NEW2.getCause and NEW2.initCause. >>>>> >>>>> >>>>> I have checked it with >>>>> java version "1.7.0" >>>>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>>>> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >>>>> >>>>> i have put my hs_err_pid.log here [2]. >>>>> >>>>> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >>>>> its the same problem as the porter-stemmer (don't interested me much >>>>> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >>>>> solve it. >>>>> >>>>> I have cross-checked it also with my local openjdk8 builds. >>>>> >>>>> The builds are >>>>> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >>>>> 28cf2aec4dd7 >>>>> and even if i don't think it's a hotspot problem i checked it also >>>>> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >>>>> rev 75d763111eec >>>>> >>>>> I am not 100% sure if the error is on my side or if it is on the vm, >>>>> maybe i have done something wrong with the invokedynamic. But i think it >>>>> is inside hotspot because hotspot / interpreted-mode should work the >>>>> same way, isn't it? >>>> I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: >>>> >>>> 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path >>>> >>>> The the two classes involved in the is_subtype_of check are in different class loaders: >>>> >>>> (dbx) fr 8 >>>> Current function is ciKlass::is_subtype_of >>>> 69 assert(is_loaded()&& that->is_loaded(), "must be loaded"); >>>> (dbx) p this->print() >>>> this->print() = (void) >>>> (dbx) p that->print() >>>> that->print() = (void) >>>> >>>> Putting your test case on the boot class path makes it work: >>>> >>>> $ java Main> /dev/null >>>> Abort >>>> $ java -Xbootclasspath/a:. Main> /dev/null >>>> $ >>>> >>>> I'm looking into it. >>>> >>>> -- Christian >>>> >>>>> Please let me know if i can make further experiments that helps to >>>>> isolate/solve this problem. >>>>> >>>>> -- Sebastian >>>>> >>>>> Sorry if the oss-patches.24.eu isn't as stable as it should be but this >>>>> my only free webspace i have for this actually. >>>>> >>>>> [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ >>>>> [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar >>>>> [2] >>>>> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log >>>>> _______________________________________________ >>>>> 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 >> -- >> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Mon Sep 19 12:44:45 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 12:44:45 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <9E0B2664-867F-4B99-B13D-E504D09C2417@oracle.com> References: <4E746956.6070901@univ-mlv.fr> <9E0B2664-867F-4B99-B13D-E504D09C2417@oracle.com> Message-ID: <7F484E77-D9F0-41BB-8A92-F41C594B0BD6@oracle.com> On Sep 19, 2011, at 12:57 AM, Christian Thalinger wrote: > On Sep 18, 2011, at 7:16 PM, Mark Roos wrote: > >> In looking at my code. >> >> In general 98% of the callsites are < 3 targets. >> >> Those that are larger I can catch and use a different lookup. I also believe that Charles Nutter limits his >> depth to 5. >> >> So the general case I see will not exceed the < 10. >> >> But I do have some cases where 10 is not the right number > > You can adjust that number in your runtime startup script since the switch that drives that number is a product switch: > > -XX:PerCallSiteSetTargetTrapLimit=50 This is the right short-term answer to see how our technique will affect Mark's system. In choosing heuristics like this it is best to start simple and then see whether it causes problems in practice. In addition, providing tuning knobs allows customers to perform experiments to see if their performance is affected by the heuristic. If there are only a few "megamutable" call sites, it may be the case that their performance is best managed by special techniques, rather than by adjusting the heuristics that affect all the other call sites. In particular, indirect (non-inlined) calls through method handles are slow right now; I'm working on fixing this. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110919/05adea9b/attachment.html From john.r.rose at oracle.com Mon Sep 19 14:58:15 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 14:58:15 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow Message-ID: http://cr.openjdk.java.net/~jrose/7030453/webrev.00 The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered. - It relies on internal details of WeakHashMap to avoid other race conditions. The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups. It is more correct and scalable. The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads. Experience with real workloads will probably lead to further modifications (under new Change Requests). I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back. The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published. I removed it because it is a false fix for user-caused race conditions. (False because it has the desired effect only on some platforms.) I think it is better to put that issue back onto the user. We still need a memory fence API to give users the right hook for such problems. There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java). Although this class is in java.lang, it is part of JSR 292. Therefore the review comments will be collected in mlvm-dev. The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang). -- John From john.r.rose at oracle.com Mon Sep 19 15:09:49 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 15:09:49 -0700 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Message-ID: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init http://cr.openjdk.java.net/~jrose/7077803/webrev.00 Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. -- John From john.r.rose at oracle.com Mon Sep 19 15:45:02 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 19 Sep 2011 22:45:02 +0000 Subject: hg: mlvm/mlvm/hotspot: update and consolidate jdk7-b147-to-bsd-port to match changes under review Message-ID: <20110919224502.B37F3477EA@hg.openjdk.java.net> Changeset: 05691d91779a Author: jrose Date: 2011-09-19 15:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/05691d91779a update and consolidate jdk7-b147-to-bsd-port to match changes under review - bsd.patch ! jdk7-b147-to-bsd-port.patch ! series - snowleopard.patch From kirill.shirokov at oracle.com Mon Sep 19 15:46:47 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Mon, 19 Sep 2011 15:46:47 -0700 (PDT) Subject: Auto Reply: hg: mlvm/mlvm/hotspot: update and consolidate jdk7-b147-to-bsd-port to match changes under review Message-ID: <08740a00-23e3-43be-97ed-152ea5eb7446@default> On vacation till October 3. Will be reading email occasionally. From tom.rodriguez at oracle.com Mon Sep 19 18:02:55 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 19 Sep 2011 18:02:55 -0700 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init In-Reply-To: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> References: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> Message-ID: Looks good. tom On Sep 19, 2011, at 3:09 PM, John Rose wrote: > 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init > http://cr.openjdk.java.net/~jrose/7077803/webrev.00 > > Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. > > -- John From rednaxelafx at gmail.com Mon Sep 19 19:00:43 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 20 Sep 2011 10:00:43 +0800 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: Hi John, On Tue, Sep 20, 2011 at 5:58 AM, John Rose wrote: > > The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by > looking at the behavior of artificial workloads. Experience with real > workloads will probably lead to further modifications (under new Change > Requests). I thought of making them tunable from JVM command line > properties, but since no other class in java.lang does this, I held back. FYI, There's one, java.lang.Integer's cache size is tunable via JVM command line flag -XX:AutoBoxCacheMax, which in turn sets Java system property "java.lang.Integer.IntegerCache.high", and affects the Integer cache size. But that's probably a special case anyway. Regards, Kris Mok -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110920/f284fbc7/attachment.html From kirill.shirokov at oracle.com Mon Sep 19 19:02:08 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Mon, 19 Sep 2011 19:02:08 -0700 (PDT) Subject: Auto Reply: Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow Message-ID: <41774493-d69a-41b4-b411-e0ef8d2f579d@default> On vacation till October 3. Will be reading email occasionally. From john.r.rose at oracle.com Mon Sep 19 21:21:19 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 21:21:19 -0700 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init In-Reply-To: References: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> Message-ID: Thanks! -- John (on my iPhone) On Sep 19, 2011, at 6:02 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Sep 19, 2011, at 3:09 PM, John Rose wrote: > >> 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init >> http://cr.openjdk.java.net/~jrose/7077803/webrev.00 >> >> Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. >> >> -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Mon Sep 19 22:35:06 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 22:35:06 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote: > FYI, There's one, java.lang.Integer's cache size is tunable via JVM command line flag -XX:AutoBoxCacheMax, which in turn sets Java system property "java.lang.Integer.IntegerCache.high", and affects the Integer cache size. But that's probably a special case anyway. Thanks for the reminder, Kris. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110919/d0d29b19/attachment.html From christian.thalinger at oracle.com Tue Sep 20 00:25:11 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 09:25:11 +0200 Subject: review request (S): 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init In-Reply-To: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> References: <6753F543-5290-465C-9898-C0193C22906B@oracle.com> Message-ID: <3666F423-2E26-4532-AC37-3FA605ED288F@oracle.com> Looks good. -- Christian On Sep 20, 2011, at 12:09 AM, John Rose wrote: > 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init > http://cr.openjdk.java.net/~jrose/7077803/webrev.00 > > Remove access checking and access narrowing logic from MethodHandles.unreflectX calls, if isAccessible is true. > > -- John From christian.thalinger at oracle.com Tue Sep 20 01:02:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 10:02:49 +0200 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 19, 2011, at 11:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 src/share/classes/java/lang/ClassValue.java: 233 /** Value stream for for hashCodeForCache. See similar structure in ThreadLocal. */ Two for's. 578 * from the ehad of a non-null run, which would allow them "ehad"? Otherwise I think this looks good. -- Christian > > The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: > - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. > - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered. > - It relies on internal details of WeakHashMap to avoid other race conditions. > > The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups. It is more correct and scalable. > > The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads. Experience with real workloads will probably lead to further modifications (under new Change Requests). I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back. > > The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published. I removed it because it is a false fix for user-caused race conditions. (False because it has the desired effect only on some platforms.) I think it is better to put that issue back onto the user. We still need a memory fence API to give users the right hook for such problems. > > There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java). > > Although this class is in java.lang, it is part of JSR 292. Therefore the review comments will be collected in mlvm-dev. The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang). > > -- John From christian.thalinger at oracle.com Tue Sep 20 01:32:17 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 10:32:17 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: <4E775456.8050701@gmx.de> References: <4E74EF76.9080107@gmx.de> <341C19AD-87F5-4757-838B-870B2AA7E655@oracle.com> <4E775456.8050701@gmx.de> Message-ID: <88B32042-8F11-4E8C-B3DA-FA29A6B2C4A0@oracle.com> On Sep 19, 2011, at 4:40 PM, Sebastian Sickelmann wrote: > Hi, > > i tried to simplify the TestNew2 class. But now it is to simple. > The crash is gone. I tried to make the process between Main and NEW2 > more complex, but this doesn't brings the crash back. > > i uploaded the new jar to > > http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash2.jar > > > Can you send me your suggested code for TestNew2 class as pseudo-code. I > will assemble and test it. This is what I have now and it still reproduces the crash: // class version 51.0 (51) // access flags 0x1 public class TestNew2 { // compiled from: TestNew2.txt // debug info: // access flags 0x9 public static testIt()V L0 LINENUMBER 3 L0 NEW NEW2 DUP INVOKESPECIAL NEW2. ()V DUP INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] POP DUP NEW java/lang/RuntimeException DUP LDC "NEW" INVOKESPECIAL java/lang/RuntimeException. (Ljava/lang/String;)V INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] POP RETURN MAXSTACK = 5 MAXLOCALS = 0 } -- Christian > > The new actual disassembly looks like: > > // class version 51.0 (51) > // access flags 0x1 > public class TestNew2 { > > // compiled from: TestNew2.txt > // debug info: > > // access flags 0x9 > public static testIt()V > L0 > LINENUMBER 2 L0 > NEW NEW2 > DUP > INVOKESPECIAL NEW2. ()V > NEW java/lang/RuntimeException > DUP > LDC "NEW" > INVOKESPECIAL java/lang/RuntimeException. (Ljava/lang/String;)V > INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V > [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > (6)] > RETURN > MAXSTACK = 4 > MAXLOCALS = 0 > } > > > -- Sebastian > > Am 19.09.2011 15:04, schrieb Sebastian Sickelmann: >> I can do this for you in a few hours.if it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should be in the temp dir after running build.xml. >> >> Sorry for the previous mail. F*** german autocompletion of my smartphone. >> >> >> Sebastian Sickelmann schrieb: >> >>> I can so this for Sound in a gewesen hours. Info it cannot wait you can clone my demo project mentioned in [0] and change the GEN class before starting the build.xml. The TestNew2.class and the Dissabled TestNew2.txt should bei in the temp dir after running build.xml. >>> ( >>> >>> Christian Thalinger schrieb: >>> >>>> On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: >>>> >>>>> [Moving hotspot-runtime-dev to Bcc] >>>>> >>>>> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >>>>> >>>>>> Hi, >>>>>> while doing further investigations on my idea [0] i observed a >>>>>> reproducable crash of the vm. >>>>>> It seems to me that it happens while the hotspot tries to inline (i >>>>>> think) a invokedynamic call. >>>>>> It happens only in my second Testcases (a case where an exception is >>>>>> thrown) so i tried >>>>>> to reduce it to a smaller amount of classes. >>>>>> >>>>>> I reduces the example of my idea to some core classes which i packed to [1]. >>>>>> You can run the example starting the Main class. If you start it with >>>>>> -Xint no crash happens. >>>>>> I have packed it with the java-source or with disassembled classfile for >>>>>> the invokedynamic call. >>>> What format is the disassembled class file? How can I assemble it to a class file? I'd like to remove the println stuff. >>>> >>>> -- Christian >>>> >>>>>> What is the Programm doing? >>>>>> >>>>>> Main starts TestNew2.testIt() 20000 times and prints out the thrown >>>>>> exception every time. >>>>>> TestNew2 is a generated class which does something like(just with out >>>>>> the local variable): >>>>>> NEW2 o = new NEW2(); >>>>>> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >>>>>> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>>>> (6)] >>>>>> // Which is effective cause = o.getCause(); >>>>>> System.out.println(cause); >>>>>> Throwable newCause = new RuntimeException("NEW"); >>>>>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >>>>>> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>>>> (6)] >>>>>> // Which is effective o.initCause(newCause) which throws the >>>>>> exception that is catched by Main. >>>>>> The Binding is done via the Bootstrapper class. >>>>>> It looks up if the field "NEW2.cause" can be accessed by >>>>>> TestNew2 which isn't the case and binds the two calls to the methods >>>>>> NEW2.getCause and NEW2.initCause. >>>>>> >>>>>> >>>>>> I have checked it with >>>>>> java version "1.7.0" >>>>>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>>>>> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >>>>>> >>>>>> i have put my hs_err_pid.log here [2]. >>>>>> >>>>>> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >>>>>> its the same problem as the porter-stemmer (don't interested me much >>>>>> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >>>>>> solve it. >>>>>> >>>>>> I have cross-checked it also with my local openjdk8 builds. >>>>>> >>>>>> The builds are >>>>>> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >>>>>> 28cf2aec4dd7 >>>>>> and even if i don't think it's a hotspot problem i checked it also >>>>>> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >>>>>> rev 75d763111eec >>>>>> >>>>>> I am not 100% sure if the error is on my side or if it is on the vm, >>>>>> maybe i have done something wrong with the invokedynamic. But i think it >>>>>> is inside hotspot because hotspot / interpreted-mode should work the >>>>>> same way, isn't it? >>>>> I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: >>>>> >>>>> 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path >>>>> >>>>> The the two classes involved in the is_subtype_of check are in different class loaders: >>>>> >>>>> (dbx) fr 8 >>>>> Current function is ciKlass::is_subtype_of >>>>> 69 assert(is_loaded()&& that->is_loaded(), "must be loaded"); >>>>> (dbx) p this->print() >>>>> this->print() = (void) >>>>> (dbx) p that->print() >>>>> that->print() = (void) >>>>> >>>>> Putting your test case on the boot class path makes it work: >>>>> >>>>> $ java Main> /dev/null >>>>> Abort >>>>> $ java -Xbootclasspath/a:. Main> /dev/null >>>>> $ >>>>> >>>>> I'm looking into it. >>>>> >>>>> -- Christian >>>>> >>>>>> Please let me know if i can make further experiments that helps to >>>>>> isolate/solve this problem. >>>>>> >>>>>> -- Sebastian >>>>>> >>>>>> Sorry if the oss-patches.24.eu isn't as stable as it should be but this >>>>>> my only free webspace i have for this actually. >>>>>> >>>>>> [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ >>>>>> [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar >>>>>> [2] >>>>>> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log >>>>>> _______________________________________________ >>>>>> 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 >>> -- >>> Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. >>> _______________________________________________ >>> 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 oracle.com Tue Sep 20 04:19:13 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 13:19:13 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: References: <4E74EF76.9080107@gmx.de> Message-ID: <6D7813E6-B006-4ECD-A474-213EC8C5B1F5@oracle.com> On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: > [Moving hotspot-runtime-dev to Bcc] > > On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: > >> Hi, >> while doing further investigations on my idea [0] i observed a >> reproducable crash of the vm. >> It seems to me that it happens while the hotspot tries to inline (i >> think) a invokedynamic call. >> It happens only in my second Testcases (a case where an exception is >> thrown) so i tried >> to reduce it to a smaller amount of classes. >> >> I reduces the example of my idea to some core classes which i packed to [1]. >> You can run the example starting the Main class. If you start it with >> -Xint no crash happens. >> I have packed it with the java-source or with disassembled classfile for >> the invokedynamic call. >> >> What is the Programm doing? >> >> Main starts TestNew2.testIt() 20000 times and prints out the thrown >> exception every time. >> TestNew2 is a generated class which does something like(just with out >> the local variable): >> NEW2 o = new NEW2(); >> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >> (6)] >> // Which is effective cause = o.getCause(); >> System.out.println(cause); >> Throwable newCause = new RuntimeException("NEW"); >> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >> (6)] >> // Which is effective o.initCause(newCause) which throws the >> exception that is catched by Main. >> The Binding is done via the Bootstrapper class. >> It looks up if the field "NEW2.cause" can be accessed by >> TestNew2 which isn't the case and binds the two calls to the methods >> NEW2.getCause and NEW2.initCause. >> >> >> I have checked it with >> java version "1.7.0" >> Java(TM) SE Runtime Environment (build 1.7.0-b147) >> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >> >> i have put my hs_err_pid.log here [2]. >> >> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >> its the same problem as the porter-stemmer (don't interested me much >> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >> solve it. >> >> I have cross-checked it also with my local openjdk8 builds. >> >> The builds are >> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >> 28cf2aec4dd7 >> and even if i don't think it's a hotspot problem i checked it also >> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >> rev 75d763111eec >> >> I am not 100% sure if the error is on my side or if it is on the vm, >> maybe i have done something wrong with the invokedynamic. But i think it >> is inside hotspot because hotspot / interpreted-mode should work the >> same way, isn't it? > > I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: > > 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path It's not a duplicate of 7055941. I filed: 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP -- Christian > > The the two classes involved in the is_subtype_of check are in different class loaders: > > (dbx) fr 8 > Current function is ciKlass::is_subtype_of > 69 assert(is_loaded() && that->is_loaded(), "must be loaded"); > (dbx) p this->print() > this->print() = (void) > (dbx) p that->print() > that->print() = (void) > > Putting your test case on the boot class path makes it work: > > $ java Main > /dev/null > Abort > $ java -Xbootclasspath/a:. Main > /dev/null > $ > > I'm looking into it. > > -- Christian > >> >> Please let me know if i can make further experiments that helps to >> isolate/solve this problem. >> >> -- Sebastian >> >> Sorry if the oss-patches.24.eu isn't as stable as it should be but this >> my only free webspace i have for this actually. >> >> [0] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ >> [1] http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/crash.jar >> [2] >> http://oss-patches.24.eu/crashreport/InvokeDynamic/2011-09-17/hs_err_pid7339.log >> _______________________________________________ >> 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 john.r.rose at oracle.com Tue Sep 20 10:43:50 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Sep 2011 10:43:50 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 20, 2011, at 1:02 AM, Christian Thalinger wrote: > On Sep 19, 2011, at 11:58 PM, John Rose wrote: > >> http://cr.openjdk.java.net/~jrose/7030453/webrev.00 > > src/share/classes/java/lang/ClassValue.java: > > 233 /** Value stream for for hashCodeForCache. See similar structure in ThreadLocal. */ > > Two for's. > > 578 * from the ehad of a non-null run, which would allow them > > "ehad"? "head" > Otherwise I think this looks good. Thanks! -- John From sebastian.sickelmann at gmx.de Tue Sep 20 14:05:37 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 20 Sep 2011 23:05:37 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: <6D7813E6-B006-4ECD-A474-213EC8C5B1F5@oracle.com> References: <4E74EF76.9080107@gmx.de> <6D7813E6-B006-4ECD-A474-213EC8C5B1F5@oracle.com> Message-ID: <4E790021.4010100@gmx.de> Am 20.09.2011 13:19, schrieb Christian Thalinger: > On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: > >> [Moving hotspot-runtime-dev to Bcc] >> >> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >> >>> Hi, >>> while doing further investigations on my idea [0] i observed a >>> reproducable crash of the vm. >>> It seems to me that it happens while the hotspot tries to inline (i >>> think) a invokedynamic call. >>> It happens only in my second Testcases (a case where an exception is >>> thrown) so i tried >>> to reduce it to a smaller amount of classes. >>> >>> I reduces the example of my idea to some core classes which i packed to [1]. >>> You can run the example starting the Main class. If you start it with >>> -Xint no crash happens. >>> I have packed it with the java-source or with disassembled classfile for >>> the invokedynamic call. >>> >>> What is the Programm doing? >>> >>> Main starts TestNew2.testIt() 20000 times and prints out the thrown >>> exception every time. >>> TestNew2 is a generated class which does something like(just with out >>> the local variable): >>> NEW2 o = new NEW2(); >>> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >>> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>> (6)] >>> // Which is effective cause = o.getCause(); >>> System.out.println(cause); >>> Throwable newCause = new RuntimeException("NEW"); >>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >>> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>> (6)] >>> // Which is effective o.initCause(newCause) which throws the >>> exception that is catched by Main. >>> The Binding is done via the Bootstrapper class. >>> It looks up if the field "NEW2.cause" can be accessed by >>> TestNew2 which isn't the case and binds the two calls to the methods >>> NEW2.getCause and NEW2.initCause. >>> >>> >>> I have checked it with >>> java version "1.7.0" >>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >>> >>> i have put my hs_err_pid.log here [2]. >>> >>> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >>> its the same problem as the porter-stemmer (don't interested me much >>> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >>> solve it. >>> >>> I have cross-checked it also with my local openjdk8 builds. >>> >>> The builds are >>> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >>> 28cf2aec4dd7 >>> and even if i don't think it's a hotspot problem i checked it also >>> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >>> rev 75d763111eec >>> >>> I am not 100% sure if the error is on my side or if it is on the vm, >>> maybe i have done something wrong with the invokedynamic. But i think it >>> is inside hotspot because hotspot / interpreted-mode should work the >>> same way, isn't it? >> I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: >> >> 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path > It's not a duplicate of 7055941. I filed: > > 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP > > -- Christian Is there a change to understand the details of this if i don't have years of hotspot knowledge? I anyway have the intention to have a closer look at hotspot to create a prototype for my binary compatibility project i mentioned [1] on my blog. I actually solve this in an experiment with byte-code transformation (to invokedynamic) in PreMain, but i think it can solved in a better way inside the vm. And if i think about solving this also for Reflection/MethodHandles$Lookup i think i have to dive into hotspot in some more depth. -- Sebasitan [1] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ [0] From john.r.rose at oracle.com Tue Sep 20 16:10:14 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Sep 2011 16:10:14 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> On Sep 19, 2011, at 2:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 After some comments from David Holmes (thanks David!) I added internal comments about race conditions. I refreshed the webrev with the additional comments. I also changed one variable to be volatile, with a paragraph of comments explaining why. (The change to volatile will inhibit CSE of ClassValue.get calls, but I think such CSE was unlikely anyway. There should be no other performance effects.) -- John From john.r.rose at oracle.com Tue Sep 20 16:12:01 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 20 Sep 2011 23:12:01 +0000 Subject: hg: mlvm/mlvm/jdk: update 7030453 and 7077803 to review versions Message-ID: <20110920231202.35D8B47835@hg.openjdk.java.net> Changeset: f0d08d7dda75 Author: jrose Date: 2011-09-20 16:11 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f0d08d7dda75 update 7030453 and 7077803 to review versions ! cval-tune-7030453.patch ! meth-acc-7077803.patch From mroos at roos.com Tue Sep 20 23:21:10 2011 From: mroos at roos.com (Mark Roos) Date: Tue, 20 Sep 2011 23:21:10 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <7F484E77-D9F0-41BB-8A92-F41C594B0BD6@oracle.com> References: <4E746956.6070901@univ-mlv.fr> <9E0B2664-867F-4B99-B13D-E504D09C2417@oracle.com> <7F484E77-D9F0-41BB-8A92-F41C594B0BD6@oracle.com> Message-ID: Thanks but I do have a few questions that are not being answered. First is the decision by the compiler to not jit a callsite reversible without restarting the program? I am very worried that the mere act of invalidating callsites to force them to use new code (something that happens a lot in Smalltalk) will send my app to interpreter purgatory. I really need a way to invalidate the sites ( which right now can only be done via a setTarget ( I think) without forcing them to not be jitted. Second Christian mentioned: As Remi mentioned we need throttling like this What is the use case that is being fixed by this? It seems that I can fix it on my end by watching the call depth ( which I do ) so why does the compiler need to do it for me? Third. I am sure there is a very cool vTable lookup in the low level code. How can I get to that? I am concerned that writing a high level vTable will be slow. At least slower that a few GWTs Thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110920/f2fb96d1/attachment.html From mroos at roos.com Tue Sep 20 23:21:10 2011 From: mroos at roos.com (Mark Roos) Date: Tue, 20 Sep 2011 23:21:10 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <9E0B2664-867F-4B99-B13D-E504D09C2417@oracle.com> References: <4E746956.6070901@univ-mlv.fr> <9E0B2664-867F-4B99-B13D-E504D09C2417@oracle.com> Message-ID: Hi Christian You requested: Mark, could you try that patch with your implementation? I am at a conference this week but I will set up a test case when I get back. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110920/e92f4db6/attachment.html From mroos at roos.com Tue Sep 20 23:21:11 2011 From: mroos at roos.com (Mark Roos) Date: Tue, 20 Sep 2011 23:21:11 -0700 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: <4E767C6C.9050202@univ-mlv.fr> References: <4E746956.6070901@univ-mlv.fr> <4E767C6C.9050202@univ-mlv.fr> Message-ID: >From Remi Moreover, are you sure the code that contains these callsites is JITed, No, but then how would I know and what would I do if I did know. If its JITed and I do the 10th ( or whatever) invalidate in three months because of uploading a patch and because of that the app slows down until I reboot it that is a problem for me. Smalltalk is dynamic not just in its use of variables but in its ability to redo methods on the fly ( and create new classes on demand etc). Because of this I will need to invalidate callsites in the cache. I really don't think it will be helpful if I have to drop the methods and recompile the byte codes to get 'fresh' callsites. Maybe I could have a way to put the site back into 'bootstrap' mode. Maybe even with a SwitchPoint. I think I can deal with depth control I am not sure I can deal with an 'helpful' compiler regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110920/404cfc8a/attachment.html From christian.thalinger at oracle.com Wed Sep 21 01:34:51 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Sep 2011 10:34:51 +0200 Subject: Request for review (L): 7087838: JSR 292: add throttling logic for optimistic call site optimizations In-Reply-To: References: <4E746956.6070901@univ-mlv.fr> <4E767C6C.9050202@univ-mlv.fr> Message-ID: <1E332598-E2A9-4FFB-9514-B86E159EDA69@oracle.com> On Sep 21, 2011, at 8:21 AM, Mark Roos wrote: > From Remi > > Moreover, are you sure the code that contains these callsites is JITed, > > No, but then how would I know and what would I do if I did know. If its JITed > and I do the 10th ( or whatever) invalidate in three months because of uploading a patch > and because of that the app slows down until I reboot it that is a problem for me. > > Smalltalk is dynamic not just in its use of variables but in its ability to redo methods on > the fly ( and create new classes on demand etc). Because of this I will need to invalidate > callsites in the cache. I really don't think it will be helpful if I have to drop the methods and > recompile the byte codes to get 'fresh' callsites. > > Maybe I could have a way to put the site back into 'bootstrap' mode. Maybe even with > a SwitchPoint. > > I think I can deal with depth control I am not sure I can deal with an 'helpful' compiler I got your point. It seems we have to rework this patch a little to meet the requirements. And I'm pretty sure it's too late for 7u2 anyway. A rate instead of an absolute counter seems to be the way to go. -- Christian > > regards > mark > > > _______________________________________________ > 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/20110921/80926841/attachment-0001.html From john.r.rose at oracle.com Wed Sep 21 17:02:54 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 22 Sep 2011 00:02:54 +0000 Subject: hg: mlvm/mlvm/jdk: indy: pack200 work-in-progress Message-ID: <20110922000255.114EF47893@hg.openjdk.java.net> Changeset: f34d7e9e09e2 Author: jrose Date: 2011-09-21 17:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f34d7e9e09e2 indy: pack200 work-in-progress ! indy.pack.patch From christian.thalinger at oracle.com Thu Sep 22 03:27:30 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Sep 2011 12:27:30 +0200 Subject: SIGSEGV while Parse::optimize_inlining an invokedynamic call. In-Reply-To: <4E790021.4010100@gmx.de> References: <4E74EF76.9080107@gmx.de> <6D7813E6-B006-4ECD-A474-213EC8C5B1F5@oracle.com> <4E790021.4010100@gmx.de> Message-ID: On Sep 20, 2011, at 11:05 PM, Sebastian Sickelmann wrote: > Am 20.09.2011 13:19, schrieb Christian Thalinger: >> On Sep 19, 2011, at 11:09 AM, Christian Thalinger wrote: >> >>> [Moving hotspot-runtime-dev to Bcc] >>> >>> On Sep 17, 2011, at 9:05 PM, Sebastian Sickelmann wrote: >>> >>>> Hi, >>>> while doing further investigations on my idea [0] i observed a >>>> reproducable crash of the vm. >>>> It seems to me that it happens while the hotspot tries to inline (i >>>> think) a invokedynamic call. >>>> It happens only in my second Testcases (a case where an exception is >>>> thrown) so i tried >>>> to reduce it to a smaller amount of classes. >>>> >>>> I reduces the example of my idea to some core classes which i packed to [1]. >>>> You can run the example starting the Main class. If you start it with >>>> -Xint no crash happens. >>>> I have packed it with the java-source or with disassembled classfile for >>>> the invokedynamic call. >>>> >>>> What is the Programm doing? >>>> >>>> Main starts TestNew2.testIt() 20000 times and prints out the thrown >>>> exception every time. >>>> TestNew2 is a generated class which does something like(just with out >>>> the local variable): >>>> NEW2 o = new NEW2(); >>>> Throwable cause = INVOKEDYNAMIC cause (LNEW2;)Ljava/lang/Throwable; >>>> [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>> (6)] >>>> // Which is effective cause = o.getCause(); >>>> System.out.println(cause); >>>> Throwable newCause = new RuntimeException("NEW"); >>>> INVOKEDYNAMIC cause (LNEW2;Ljava/lang/Throwable;)V >>>> [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; >>>> (6)] >>>> // Which is effective o.initCause(newCause) which throws the >>>> exception that is catched by Main. >>>> The Binding is done via the Bootstrapper class. >>>> It looks up if the field "NEW2.cause" can be accessed by >>>> TestNew2 which isn't the case and binds the two calls to the methods >>>> NEW2.getCause and NEW2.initCause. >>>> >>>> >>>> I have checked it with >>>> java version "1.7.0" >>>> Java(TM) SE Runtime Environment (build 1.7.0-b147) >>>> Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) >>>> >>>> i have put my hs_err_pid.log here [2]. >>>> >>>> maybe b127 this is not the newest, but i didn't found a newer one. Maybe >>>> its the same problem as the porter-stemmer (don't interested me much >>>> till now) but -XX:-UseLoopPredicate (which i think should fix it) doen't >>>> solve it. >>>> >>>> I have cross-checked it also with my local openjdk8 builds. >>>> >>>> The builds are >>>> complete build of http://hg.openjdk.java.net/jdk8/jdk8 rev >>>> 28cf2aec4dd7 >>>> and even if i don't think it's a hotspot problem i checked it also >>>> against my openjdk8 with http://hg.openjdk.java.net/jdk8/tl/jdk/ >>>> rev 75d763111eec >>>> >>>> I am not 100% sure if the error is on my side or if it is on the vm, >>>> maybe i have done something wrong with the invokedynamic. But i think it >>>> is inside hotspot because hotspot / interpreted-mode should work the >>>> same way, isn't it? >>> I can reproduce the bug and it is a VM issue (more precisely a C2 issue). Although the synopsis mentions deoptimization this is very likely a duplicate of: >>> >>> 7055941: JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path >> It's not a duplicate of 7055941. I filed: >> >> 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP >> >> -- Christian > Is there a change to understand the details of this if i don't have > years of hotspot knowledge? Maybe. Here is the webrev that also explains briefly why it failed: http://cr.openjdk.java.net/~twisti/7092712/ -- Christian > > I anyway have the intention to have a closer look at hotspot to create a > prototype for my binary compatibility project i mentioned [1] on my > blog. I actually solve this in an experiment with byte-code > transformation (to invokedynamic) in PreMain, but i think it can solved > in a better way inside the vm. > And if i think about solving this also for > Reflection/MethodHandles$Lookup i think i have to dive into hotspot in > some more depth. > > > -- Sebasitan > > [1] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ > [0] > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Thu Sep 22 09:37:27 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Sep 2011 18:37:27 +0200 Subject: Finally a test case for the ClassNotFound In-Reply-To: References: <4E57FE99.3010700@univ-mlv.fr> Message-ID: <19669CCC-DCDA-4BE5-9BCB-6589A323C494@oracle.com> I finally filed a CR for this error: 7093796: JSR 292: Rtalk test case fails with: NoClassDefFoundError: ri/core/rtalk/RtObject -- Christian On Aug 27, 2011, at 12:25 AM, Mark Roos wrote: > Thanks R?mi > > I tried to put just the offending class on the boot path but that was not enough. > > The entire app worked so I guess the solution is somewhere in between > > mark_______________________________________________ > 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/20110922/dae82729/attachment.html From christian.thalinger at oracle.com Thu Sep 22 09:38:58 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Sep 2011 18:38:58 +0200 Subject: possible fix for 7056328 In-Reply-To: <624A1BC3-083A-4FC5-8404-10E1228AAB83@oracle.com> References: <785C59DB-0BF1-4DE1-8FF4-CA4E239DC1F3@oracle.com> <4E01F376.1000703@gmail.com> <6B2B9EA1-EE59-41F7-9569-BFB7A621E0F8@oracle.com> <4E05EDD7.9090303@gmail.com> <624A1BC3-083A-4FC5-8404-10E1228AAB83@oracle.com> Message-ID: <0F8084E3-246D-4E20-8540-E20BEAF949C6@oracle.com> And I filed a CR for this bug too: 7093795: JSR 292: Seph bench/bench_arithmetic.sp fails with: NoClassDefFoundError: seph/lang/SephObject -- Christian On Jul 4, 2011, at 7:23 PM, Christian Thalinger wrote: > On Jun 25, 2011, at 4:16 PM, Ola Bini wrote: >>> Please try out the patch. I've also updated the mlvm patches to the >>> latest bsd-port which (quite awesomely) is b146. >> It runs fine for me. > > Hmm, this is odd. I'm just trying b147 and I still get the same problem when putting seph.jar on the classpath: > > intelsdv07:~/mlvm/seph$ bin/seph -J-d32 --server -J-Xcomp bench/bench_intrinsic_if.sp > intrinsic: if 0.342636147 > intrinsic: if 0.284139116 > intrinsic: if 0.282266751 > intrinsic: if 0.280147731 > intrinsic: if 0.275480242 > intrinsic: if 0.277431167 > intrinsic: if 0.268242772 > intrinsic: if 0.272036449 > intrinsic: if 0.271464497 > intrinsic: if 0.267593639 > java.lang.NoClassDefFoundError: seph/lang/SephObject > at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java) > at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java) > at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java) > at seph$gen$abstraction$1$hundred_ifs.hundred_ifs(bench/bench_intrinsic_if.sp:13) > at seph$gen$abstraction$0$toplevel.argument_4_3(bench/bench_intrinsic_if.sp:17) > at seph.lang.ControlDefaultBehavior.evaluateArgument(ControlDefaultBehavior.java:23) > at seph.lang.Base.benchmark(Base.java:103) > at seph.lang.bim.BaseBase.benchmark(BaseBase.java:102) > at seph.lang.Runtime.evaluateStream(Runtime.java:129) > at seph.lang.Runtime.evaluateFile(Runtime.java:142) > at seph.lang.Main.main(Main.java:60) > ... > > -- Christian > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From lukas.stadler at jku.at Tue Sep 27 10:59:38 2011 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Tue, 27 Sep 2011 17:59:38 +0000 Subject: hg: mlvm/mlvm/jdk: 3 new changesets Message-ID: <20110927175939.AE13347A1C@hg.openjdk.java.net> Changeset: f822e08b76c6 Author: Lukas Stadler Date: 2011-09-26 15:21 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f822e08b76c6 rebase coro to hsx/hotspot-comp ! series Changeset: cb58978c5fa2 Author: Lukas Stadler Date: 2011-09-27 18:36 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/cb58978c5fa2 Merge Changeset: aadba3bbd982 Author: Lukas Stadler Date: 2011-09-27 19:57 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/aadba3bbd982 coro: include coroutine classes in src.zip ! coro.patch From lukas.stadler at jku.at Tue Sep 27 11:00:58 2011 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Tue, 27 Sep 2011 18:00:58 +0000 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: <20110927180059.984FD47A1D@hg.openjdk.java.net> Changeset: 9bb80f812fd7 Author: Lukas Stadler Date: 2011-09-26 15:11 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9bb80f812fd7 rebase coro to current hsx/hotspot-comp ! coro.patch ! series Changeset: 1bdc6f420130 Author: Lukas Stadler Date: 2011-09-27 18:34 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1bdc6f420130 coro: fixes to stack walking, support for ricochet frames ! coro.patch From kirill.shirokov at oracle.com Tue Sep 27 11:08:09 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Tue, 27 Sep 2011 11:08:09 -0700 (PDT) Subject: Auto Reply: hg: mlvm/mlvm/jdk: 3 new changesets Message-ID: <9cc22b50-3ad8-4357-9a1a-f7c1f792877d@default> On vacation till October 3. Will be reading email occasionally. From forax at univ-mlv.fr Tue Sep 27 12:43:17 2011 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Sep 2011 21:43:17 +0200 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: Cool ! Remi lukas.stadler at jku.at wrote: >Changeset: 9bb80f812fd7 >Author: Lukas Stadler >Date: 2011-09-26 15:11 +0200 >URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9bb80f812fd7 > >rebase coro to current hsx/hotspot-comp > >! coro.patch >! series > >Changeset: 1bdc6f420130 >Author: Lukas Stadler >Date: 2011-09-27 18:34 +0200 >URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1bdc6f420130 > >coro: fixes to stack walking, support for ricochet frames > >! coro.patch > >_______________________________________________ >mlvm-dev mailing list >mlvm-dev at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From kirill.shirokov at oracle.com Tue Sep 27 12:47:31 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Tue, 27 Sep 2011 12:47:31 -0700 (PDT) Subject: Auto Reply: Re: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: <9ecabaa7-450f-414f-bee6-b94d18c44c58@default> On vacation till October 3. Will be reading email occasionally. From lukas.stadler at jku.at Tue Sep 27 14:12:35 2011 From: lukas.stadler at jku.at (Lukas Stadler) Date: Tue, 27 Sep 2011 23:12:35 +0200 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets In-Reply-To: References: Message-ID: Yes :-) and there's more: Pre-built binaries for linux x64 and more documentation at: http://ssw.jku.at/General/Staff/LS/coro/ The page is work in progress, though. I'll have to finish it by next week, in order to direct people to it at my JavaOne talk :-) - Lukas On Sep 27, 2011, at 21:43 , Remi Forax wrote: > Cool ! > > Remi > > > lukas.stadler at jku.at wrote: > >> Changeset: 9bb80f812fd7 >> Author: Lukas Stadler >> Date: 2011-09-26 15:11 +0200 >> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9bb80f812fd7 >> >> rebase coro to current hsx/hotspot-comp >> >> ! coro.patch >> ! series >> >> Changeset: 1bdc6f420130 >> Author: Lukas Stadler >> Date: 2011-09-27 18:34 +0200 >> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1bdc6f420130 >> >> coro: fixes to stack walking, support for ricochet frames >> >> ! coro.patch >> >> _______________________________________________ >> 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/20110927/db6bc4f5/attachment.html From forax at univ-mlv.fr Tue Sep 27 14:26:33 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 27 Sep 2011 23:26:33 +0200 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets In-Reply-To: References: Message-ID: <4E823F89.1080200@univ-mlv.fr> On 09/27/2011 11:12 PM, Lukas Stadler wrote: > Yes :-) and there's more: > Pre-built binaries for linux x64 and more documentation at: > http://ssw.jku.at/General/Staff/LS/coro/ > > The page is work in progress, though. > I'll have to finish it by next week, in order to direct people to it > at my JavaOne talk :-) > > - Lukas I was talking with Gilles Duboscq yesterday and I realized that I could write an example mixing UI code with blocking IO that will not freeze the event loop because you can use coroutine to fake blocking IO use async IO under the carpet. R?mi > > On Sep 27, 2011, at 21:43 , Remi Forax wrote: > >> Cool ! >> >> Remi >> >> >> lukas.stadler at jku.at wrote: >> >>> Changeset: 9bb80f812fd7 >>> Author: Lukas Stadler >> > >>> Date: 2011-09-26 15:11 +0200 >>> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9bb80f812fd7 >>> >>> rebase coro to current hsx/hotspot-comp >>> >>> ! coro.patch >>> ! series >>> >>> Changeset: 1bdc6f420130 >>> Author: Lukas Stadler >> > >>> Date: 2011-09-27 18:34 +0200 >>> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1bdc6f420130 >>> >>> coro: fixes to stack walking, support for ricochet frames >>> >>> ! coro.patch >>> >>> _______________________________________________ >>> 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/20110927/3cb8df52/attachment.html From kirill.shirokov at oracle.com Tue Sep 27 14:29:02 2011 From: kirill.shirokov at oracle.com (kirill.shirokov at oracle.com) Date: Tue, 27 Sep 2011 14:29:02 -0700 (PDT) Subject: Auto Reply: Re: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: On vacation till October 3. Will be reading email occasionally. From forax at univ-mlv.fr Tue Sep 27 14:42:30 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 27 Sep 2011 23:42:30 +0200 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets In-Reply-To: References: Message-ID: <4E824346.6020505@univ-mlv.fr> On 09/27/2011 11:12 PM, Lukas Stadler wrote: > Yes :-) and there's more: > Pre-built binaries for linux x64 and more documentation at: > http://ssw.jku.at/General/Staff/LS/coro/ > > The page is work in progress, though. > I'll have to finish it by next week, in order to direct people to it > at my JavaOne talk :-) > > - Lukas very cool, with the binary (product VM), ping pong works ! new Coroutine(new Runnable() { @Override public void run() { for(int i = 0; i < 5; i++) { System.out.println("pong " + i); Coroutine.yield(); } } }); for (int i = 0; i < 5; i++) { System.out.println("ping " + i); Coroutine.yield(); } output: ping 0 pong 0 ping 1 pong 1 ping 2 pong 2 ping 3 pong 3 ping 4 pong 4 R?mi > > On Sep 27, 2011, at 21:43 , Remi Forax wrote: > >> Cool ! >> >> Remi >> >> >> lukas.stadler at jku.at wrote: >> >>> Changeset: 9bb80f812fd7 >>> Author: Lukas Stadler >> > >>> Date: 2011-09-26 15:11 +0200 >>> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9bb80f812fd7 >>> >>> rebase coro to current hsx/hotspot-comp >>> >>> ! coro.patch >>> ! series >>> >>> Changeset: 1bdc6f420130 >>> Author: Lukas Stadler >> > >>> Date: 2011-09-27 18:34 +0200 >>> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1bdc6f420130 >>> >>> coro: fixes to stack walking, support for ricochet frames >>> >>> ! coro.patch >>> >>> _______________________________________________ >>> 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/20110927/63d2914c/attachment-0001.html From forax at univ-mlv.fr Tue Sep 27 15:22:43 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 28 Sep 2011 00:22:43 +0200 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets In-Reply-To: References: Message-ID: <4E824CB3.5020306@univ-mlv.fr> On 09/27/2011 11:12 PM, Lukas Stadler wrote: > Yes :-) and there's more: > Pre-built binaries for linux x64 and more documentation at: > http://ssw.jku.at/General/Staff/LS/coro/ > > The page is work in progress, though. > I'll have to finish it by next week, in order to direct people to it > at my JavaOne talk :-) > > - Lukas and you can reify the stack, see below. Lukas, I think you should store a special singleton object instead of null in the object array (objectValues) because currently there is no way to know if null is null or a scalar. Also I think we should have a way to ask to an overload of AsymRunnable.call() to throw an exception that will be thrown by ret() in the coroutine and vice versa. R?mi Coroutine coroutine = new Coroutine() { @Override protected void run() { int i = 3; int j = 4; Object o = null; int k = 2 + myYield(); } private int myYield() { yield(); return 0; } }; Coroutine.yield(); CoroutineFrame[] frames = coroutine.serialize(); for(int i=0; i > On Sep 27, 2011, at 21:43 , Remi Forax wrote: > >> Cool ! >> >> Remi >> >> >> lukas.stadler at jku.at wrote: >> >>> Changeset: 9bb80f812fd7 >>> Author: Lukas Stadler >> > >>> Date: 2011-09-26 15:11 +0200 >>> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9bb80f812fd7 >>> >>> rebase coro to current hsx/hotspot-comp >>> >>> ! coro.patch >>> ! series >>> >>> Changeset: 1bdc6f420130 >>> Author: Lukas Stadler >> > >>> Date: 2011-09-27 18:34 +0200 >>> URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1bdc6f420130 >>> >>> coro: fixes to stack walking, support for ricochet frames >>> >>> ! coro.patch >>> >>> _______________________________________________ >>> 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/20110928/78ee10b0/attachment.html From john.r.rose at oracle.com Tue Sep 27 19:02:26 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 28 Sep 2011 02:02:26 +0000 Subject: hg: mlvm/mlvm/hotspot: tagu: first experiment with 64-bit tagged unions Message-ID: <20110928020227.2DD3747A30@hg.openjdk.java.net> Changeset: 0afdd88556bc Author: jrose Date: 2011-09-27 19:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0afdd88556bc tagu: first experiment with 64-bit tagged unions ! series + tagu.patch + tagu.txt From mroos at roos.com Tue Sep 27 21:37:03 2011 From: mroos at roos.com (Mark Roos) Date: Tue, 27 Sep 2011 21:37:03 -0700 Subject: JSR 292 supported by JVMTI any status? Message-ID: Just wondering if anyone is working on this. Particularly breakpoints and stepping thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110927/021b70d3/attachment.html From tom.rodriguez at oracle.com Wed Sep 28 09:31:15 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Sep 2011 09:31:15 -0700 Subject: JSR 292 supported by JVMTI any status? In-Reply-To: References: Message-ID: <880C4938-F03C-411A-8E8D-13150C9FC378@oracle.com> On Sep 27, 2011, at 9:37 PM, Mark Roos wrote: > Just wondering if anyone is working on this. Particularly breakpoints and stepping That was fixed a while back, at least as far our tests say. It was 6990212. Are you still seeing problems? The only JVMTI feature still not working is class redefinition and that will be fixed for 7u4. tom > > thanks > > mark_______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mroos at roos.com Wed Sep 28 15:31:29 2011 From: mroos at roos.com (Mark Roos) Date: Wed, 28 Sep 2011 15:31:29 -0700 Subject: JSR 292 supported by JVMTI any status? In-Reply-To: <880C4938-F03C-411A-8E8D-13150C9FC378@oracle.com> References: <880C4938-F03C-411A-8E8D-13150C9FC378@oracle.com> Message-ID: >From Tom That was fixed a while back, at least as far our tests say. It was 6990212. Are you still seeing problems? The only JVMTI feature still not working is class redefinition and that will be fixed for 7u4. Would that have been fixed in b147? or in one of the updates? I think I still had the problems with b147 but I'll give it another try thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110928/7bc89392/attachment.html From tom.rodriguez at oracle.com Wed Sep 28 16:27:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 28 Sep 2011 16:27:30 -0700 Subject: JSR 292 supported by JVMTI any status? In-Reply-To: References: <880C4938-F03C-411A-8E8D-13150C9FC378@oracle.com> Message-ID: <46735FC1-9A55-440B-8DC3-4A15117F6C68@oracle.com> On Sep 28, 2011, at 3:31 PM, Mark Roos wrote: > From Tom > That was fixed a while back, at least as far our tests say. It was 6990212. Are you still seeing problems? The only JVMTI feature still not working is class redefinition and that will be fixed for 7u4. > > Would that have been fixed in b147? or in one of the updates? It was broken in b147 but it's fixed in the latest jdk8 bits. It is also fixed in 7u2. You can always just grab libjvm from jdk8 and drop it into your jdk7 for testing. I'd really like it if you tried this out so I can get some outside confirmation that it's working as expected. tom > > I think I still had the problems with b147 but I'll give it another try > > thanks > mark > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mroos at roos.com Wed Sep 28 18:31:46 2011 From: mroos at roos.com (Mark Roos) Date: Wed, 28 Sep 2011 18:31:46 -0700 Subject: JSR 292 supported by JVMTI any status? In-Reply-To: <46735FC1-9A55-440B-8DC3-4A15117F6C68@oracle.com> References: <880C4938-F03C-411A-8E8D-13150C9FC378@oracle.com> <46735FC1-9A55-440B-8DC3-4A15117F6C68@oracle.com> Message-ID: Thanks Tom I'll set it up on a later version, will take a few days as i have to redo my side mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110928/fdb72d4e/attachment.html From lukas.stadler at jku.at Thu Sep 29 06:03:39 2011 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 29 Sep 2011 13:03:39 +0000 Subject: hg: mlvm/mlvm/hotspot: coro: bugfix Message-ID: <20110929130339.90ACD47A8D@hg.openjdk.java.net> Changeset: 47f0b00a6005 Author: Lukas Stadler Date: 2011-09-29 15:03 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/47f0b00a6005 coro: bugfix (crash when termination of one coroutine is immediately followed by starting another one) ! coro.patch From john.r.rose at oracle.com Fri Sep 30 09:39:50 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 30 Sep 2011 09:39:50 -0700 Subject: Illegal Instruction in debug_build In-Reply-To: References: Message-ID: <3A0D0B72-80EF-4DDB-ABCE-E5AC79637E0B@oracle.com> On Sep 18, 2011, at 1:30 PM, Michael Barker wrote: > I've been trying to run a debug build on Mac OS, the normal build > works fine, but the debug version fails with an Illegal Instruction. > I've run it through gdb (output below), but I not sure how accurate > the information is. I think that it's the result of a stack overflow, > it takes around 2s to fail without any launch class specified. Has > anyone witnessed anything similar? The JVM bootstrap logic does not always robustly report errors. Try running outside of GDB but with -XX:+ShowMessageBoxOnError. If you run outside of gdb sometimes you can get extra bits of crash data from Mac OS or from the JVM's own crash dumper. I set the "Developer" option in this control panel to get extra backtrace info: /Developer/Applications/Utilities/CrashReporterPrefs.app That will show the OS's idea of the symbolic backtrace. The JVM should do this also in its crash dump logs, but doesn't on Mac OS. I have recently had a bug in the JVM's bootstrap logic (in tagu.patch), which reported awkwardly by blowing the stack in the error reporter. That may be happening for you also. The Mac OS popup was helpful to diagnose this. Good luck! -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110930/27bdbf10/attachment.html