From Christian.Thalinger at Sun.COM Mon Feb 1 00:41:01 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 01 Feb 2010 09:41:01 +0100 Subject: hg: mlvm/mlvm/hotspot: dynopt, trustfinal: update to match JDK7 pushes In-Reply-To: References: <20100127074247.97E5B41D18@hg.openjdk.java.net> Message-ID: <4B66939D.6070301@Sun.COM> On 02/ 1/10 08:31 AM, Charles Oliver Nutter wrote: > I think I lost track of patches for a while...trustfinal is the > optimization to not repeatedly access finals, correct? I'll have a > look at the patch, but perhaps a description of when final accesses > will be elided? This patch adds a command line option (-XX:+TrustFinalNonStaticFields) to turn on for user classes what we already do for system classes in {java,sun}.dyn: treat final non-static fields as constants. This enables to inline MethodHandle chains completely that e.g. have a GuardWithTest in between. -- Christian From Christian.Thalinger at Sun.COM Mon Feb 1 01:16:58 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 09:16:58 +0000 Subject: hg: mlvm/mlvm/hotspot: series: Rebased to jdk7-b81. Message-ID: <20100201091700.3248E41910@hg.openjdk.java.net> Changeset: b9c4ee26ce76 Author: twisti Date: 2010-02-01 10:09 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b9c4ee26ce76 series: Rebased to jdk7-b81. osxpaths.patch: Removed. - osxpaths.patch ! series From Christian.Thalinger at Sun.COM Mon Feb 1 01:17:17 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 09:17:17 +0000 Subject: hg: mlvm/mlvm/jdk: series: Rebased to jdk7-b81. Message-ID: <20100201091718.9A38441911@hg.openjdk.java.net> Changeset: f8750be16e41 Author: twisti Date: 2010-02-01 10:10 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f8750be16e41 series: Rebased to jdk7-b81. osxpaths.patch: Removed. - osxpaths.patch ! series From Christian.Thalinger at Sun.COM Mon Feb 1 01:17:32 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 09:17:32 +0000 Subject: hg: mlvm/mlvm/langtools: series: Rebased to jdk7-b81. Message-ID: <20100201091733.09F4841912@hg.openjdk.java.net> Changeset: 5e88ba2b38fc Author: twisti Date: 2010-02-01 10:11 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/5e88ba2b38fc series: Rebased to jdk7-b81. ! series From Christian.Thalinger at Sun.COM Mon Feb 1 04:33:18 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 01 Feb 2010 13:33:18 +0100 Subject: JSR 292 x86 C1 support In-Reply-To: <1264684023.16310.128.camel@macbook> References: <1264587776.6889.63.camel@macbook> <4B6070D5.7070007@univ-mlv.fr> <1264674841.16310.1.camel@macbook> <4B6171B6.8010306@univ-mlv.fr> <1264682758.16310.121.camel@macbook> <1264684023.16310.128.camel@macbook> Message-ID: <4B66CA0E.4060103@Sun.COM> On 01/28/10 02:07 PM, Christian Thalinger wrote: > It should also work as final non-static field and using -XX: > +TrustFinalNonStaticFields. That switch does for user classes what > happens per default for {java,sun}.dyn classes: we trust final > non-static to be effectively final. But it does not work and I don't > know yet why. My fault. It does work but the MH chain has to start with a MH that the compiler can guarantee to be a constant. Then final non-static fields in user classes in the chain can also be inlined. -- Christian From Christian.Thalinger at Sun.COM Mon Feb 1 05:37:28 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 13:37:28 +0000 Subject: hg: mlvm/mlvm/hotspot: indy-c1-x86: Renamed to indy-c1-x86-6919934. Message-ID: <20100201133730.DF72541957@hg.openjdk.java.net> Changeset: 7a6d77330310 Author: twisti Date: 2010-02-01 14:36 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/7a6d77330310 indy-c1-x86: Renamed to indy-c1-x86-6919934. + indy-c1-x86-6919934.patch - indy-c1-x86.patch ! series From Christian.Thalinger at Sun.COM Mon Feb 1 05:47:38 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 13:47:38 +0000 Subject: hg: mlvm/mlvm/hotspot: series: Removed trustfinal-6912065.patch. Message-ID: <20100201134738.68D364195A@hg.openjdk.java.net> Changeset: 88fd4dcbacd0 Author: twisti Date: 2010-02-01 14:47 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/88fd4dcbacd0 series: Removed trustfinal-6912065.patch. callcc.patch: Updated. dynopt-6912064.patch: Updated. ! callcc.patch ! dynopt-6912064.patch ! series From Christian.Thalinger at Sun.COM Mon Feb 1 06:28:14 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 01 Feb 2010 14:28:14 +0000 Subject: hg: mlvm/mlvm/hotspot: indy-c1-x86-6919934.patch: Bugfixes. Message-ID: <20100201142814.6042841967@hg.openjdk.java.net> Changeset: a252d84cdf60 Author: twisti Date: 2010-02-01 15:27 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a252d84cdf60 indy-c1-x86-6919934.patch: Bugfixes. ! indy-c1-x86-6919934.patch From headius at headius.com Mon Feb 1 06:48:03 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 1 Feb 2010 08:48:03 -0600 Subject: hg: mlvm/mlvm/hotspot: dynopt, trustfinal: update to match JDK7 pushes In-Reply-To: <4B66939D.6070301@Sun.COM> References: <20100127074247.97E5B41D18@hg.openjdk.java.net> <4B66939D.6070301@Sun.COM> Message-ID: On Mon, Feb 1, 2010 at 2:41 AM, Christian Thalinger wrote: > This patch adds a command line option (-XX:+TrustFinalNonStaticFields) > to turn on for user classes what we already do for system classes in > {java,sun}.dyn: treat final non-static fields as constants. > > This enables to inline MethodHandle chains completely that e.g. have a > GuardWithTest in between. Ok, then it is the work I discussed with John and Tom Rodriguez some time ago. I'll have to play with it; in JRuby's normal mode (non-indy) there are a number of final accesses that could potentially go away with this. I think Tom ran some numbers and didn't see improvement, but he did not have any of JRuby's more experimental flags turned on. - Charlie From Christian.Thalinger at Sun.COM Mon Feb 1 07:19:41 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 01 Feb 2010 16:19:41 +0100 Subject: hg: mlvm/mlvm/hotspot: dynopt, trustfinal: update to match JDK7 pushes In-Reply-To: References: <20100127074247.97E5B41D18@hg.openjdk.java.net> <4B66939D.6070301@Sun.COM> Message-ID: <4B66F10D.2000806@Sun.COM> On 02/ 1/10 03:48 PM, Charles Oliver Nutter wrote: > On Mon, Feb 1, 2010 at 2:41 AM, Christian Thalinger > wrote: >> This patch adds a command line option (-XX:+TrustFinalNonStaticFields) >> to turn on for user classes what we already do for system classes in >> {java,sun}.dyn: treat final non-static fields as constants. >> >> This enables to inline MethodHandle chains completely that e.g. have a >> GuardWithTest in between. > > Ok, then it is the work I discussed with John and Tom Rodriguez some > time ago. I'll have to play with it; in JRuby's normal mode (non-indy) > there are a number of final accesses that could potentially go away > with this. I think Tom ran some numbers and didn't see improvement, > but he did not have any of JRuby's more experimental flags turned on. Right, I remember the discussion. Let me know if I can help. -- Christian From John.Rose at Sun.COM Mon Feb 1 18:20:13 2010 From: John.Rose at Sun.COM (John Rose) Date: Mon, 01 Feb 2010 18:20:13 -0800 Subject: indy and tailc In-Reply-To: References: <4B5EE7E3.4060904@gmail.com> <54D3382B-8F8E-4787-A4AC-8A5CE0A349D9@sun.com> <64efa1ba1001270030m27abb630v90682bb0bfe4993b@mail.gmail.com> <30A24D13-7713-458F-8B5B-7BD18FC6FF3E@sun.com> <64efa1ba1001270103i6770d83eo72bd86e6bff864dc@mail.gmail.com> <27BA458B-A63F-40C5-9E27-343DF0FEAB41@sun.com> Message-ID: <90D9C071-F72F-4397-A9CF-22CE150E042E@sun.com> On Jan 31, 2010, at 11:19 PM, Charles Oliver Nutter wrote: > The other use case, which I did not attempt, was in regenerating call > sites a la the DLR's DynamicSite logic (which repeatedly regenerates a > call site with a series of instanceof checks, to specialize the call > paths iteratively). Again, InvokeDynamic potentially handles this > better? It is designed to do this; e.g., see section 5.3 in my VMIL paper. One bit of engineering that needs investigation is how to build up DLR-style call sites incrementally without doing quadratic recompilation work. >> The uses you and Charlie point out are less important that they seemed at first for two reasons: >> >> 1. Method handles provide a better replacement for the swarm of tiny classes. >> >> 2. Hotspot is in the process of weaning itself off of perm gen. One of the main features of perm-gen is that its objects never move except during full GC, and the code cache relied on this invariant until just last year, with the 'ScavengeRootsInCode' changes. > > If permgen goes away, there's still the classloader-rooting problem > that requires constructing a new classloader for every tiny class you > want to be GCable. If JRuby, for example, wanted to start "tiering" > our optimization phases, we'd have to use scads and scads of > classloaders to ensure the old method bodies could go away. So that > use case is still alive and well. Yes; this is probably the enduring use of anonk as it stands. Interestingly, I just learned (from a link on Lambda-the-ultimate) that Microsoft just put the equivalent feature into .NET 4. It's called Collectible Assemblies: http://msdn.microsoft.com/en-us/library/dd554932%28VS.100%29.aspx -- John From headius at headius.com Mon Feb 1 23:02:49 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 2 Feb 2010 01:02:49 -0600 Subject: indy and tailc In-Reply-To: <90D9C071-F72F-4397-A9CF-22CE150E042E@sun.com> References: <4B5EE7E3.4060904@gmail.com> <54D3382B-8F8E-4787-A4AC-8A5CE0A349D9@sun.com> <64efa1ba1001270030m27abb630v90682bb0bfe4993b@mail.gmail.com> <30A24D13-7713-458F-8B5B-7BD18FC6FF3E@sun.com> <64efa1ba1001270103i6770d83eo72bd86e6bff864dc@mail.gmail.com> <27BA458B-A63F-40C5-9E27-343DF0FEAB41@sun.com> <90D9C071-F72F-4397-A9CF-22CE150E042E@sun.com> Message-ID: On Mon, Feb 1, 2010 at 8:20 PM, John Rose wrote: > On Jan 31, 2010, at 11:19 PM, Charles Oliver Nutter wrote: > >> The other use case, which I did not attempt, was in regenerating call >> sites a la the DLR's DynamicSite logic (which repeatedly regenerates a >> call site with a series of instanceof checks, to specialize the call >> paths iteratively). Again, InvokeDynamic potentially handles this >> better? > > It is designed to do this; e.g., see section 5.3 in my VMIL paper. > > One bit of engineering that needs investigation is how to build up DLR-style call sites incrementally without doing quadratic recompilation work. I'll have another look and offer any suggestions I might have :) > Yes; this is probably the enduring use of anonk as it stands. > > Interestingly, I just learned (from a link on Lambda-the-ultimate) that Microsoft just put the equivalent feature into .NET 4. ?It's called Collectible Assemblies: > ?http://msdn.microsoft.com/en-us/library/dd554932%28VS.100%29.aspx I think this is slightly different, though it's not clear from browsing docs. CLR already had DynamicMethods, which allowed them to generate callable code bodies that could be collected once they were no longer used. Collectible Assemblies seem to be an analog to either being able to ditch a whole classloader (which we already have) or being able to dynamically generate, use, and unload a module/superpackage in the upcoming modularization stuff. I'm not really clear on why they needed this with DynamicMethod already available. The use cases they list for dynamically generating assemblies (http://msdn.microsoft.com/en-us/library/tt9483fk(VS.100).aspx) don't really clarify things for me, but they don't really sound like the use case of regenerating individual method bodies. Hmm...perhaps it's for generating whole interconnected type graphs? DynamicMethod would suite *my* needs and the needs of the DLR fine, but it wouldn't really allow you to reify an entire mostly-settled set of Ruby classes into a live type graph with more "static" call paths, or something along those lines. Any JRockit or J9 folks out there know whether your classloaders hold hard reference to loaded classes as well? In general, I believe Code Generation Cures All, but the cost of iteratively regenerating and reoptimizing code is really high without AnonymousClassloader :( Oh, and while we're at it, can we get OSR, so I can swap out methods on the fly? :) (or perhaps someone has a suggestion for how to do aggressive optimizations in e.g. JRuby but still be able to bail out if necessary with live method activations in flight) - Charlie From forax at univ-mlv.fr Tue Feb 2 08:08:13 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 02 Feb 2010 17:08:13 +0100 Subject: indy and tailc In-Reply-To: <90D9C071-F72F-4397-A9CF-22CE150E042E@sun.com> References: <4B5EE7E3.4060904@gmail.com> <54D3382B-8F8E-4787-A4AC-8A5CE0A349D9@sun.com> <64efa1ba1001270030m27abb630v90682bb0bfe4993b@mail.gmail.com> <30A24D13-7713-458F-8B5B-7BD18FC6FF3E@sun.com> <64efa1ba1001270103i6770d83eo72bd86e6bff864dc@mail.gmail.com> <27BA458B-A63F-40C5-9E27-343DF0FEAB41@sun.com> <90D9C071-F72F-4397-A9CF-22CE150E042E@sun.com> Message-ID: <4B684DED.1010404@univ-mlv.fr> Le 02/02/2010 03:20, John Rose a ?crit : > On Jan 31, 2010, at 11:19 PM, Charles Oliver Nutter wrote: > > >> The other use case, which I did not attempt, was in regenerating call >> sites a la the DLR's DynamicSite logic (which repeatedly regenerates a >> call site with a series of instanceof checks, to specialize the call >> paths iteratively). Again, InvokeDynamic potentially handles this >> better? >> > It is designed to do this; e.g., see section 5.3 in my VMIL paper. > CallSite.setTarget() is your friend :) > One bit of engineering that needs investigation is how to build up DLR-style call sites incrementally without doing quadratic recompilation work. > In general, the full adapter blob is created before the compilation is triggered. Otherwise a way to do this is to provide a specific mutable adapter : public class MethodHandles { /** create a dispatch table */ public static DispatchMethodHandle dispatchTable(MethodType type, int pos) } public class DispatchTable extends MethodHandle { public addTarget(Class clazz, MethodHandle mh) { ... } } R?mi From lukas.stadler at jku.at Wed Feb 3 02:47:59 2010 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Wed, 03 Feb 2010 10:47:59 +0000 Subject: hg: mlvm/mlvm/hotspot: hotswap: New patch. Main changes are: Message-ID: <20100203104800.8167341C26@hg.openjdk.java.net> Changeset: 4f9420785686 Author: Thomas Wuerthinger (thomas.wuerthinger at gmx.at) Date: 2010-02-03 10:43 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4f9420785686 hotswap: New patch. Main changes are: - Improved instance update performance (mark&compact modification, compressed storage of instance update information) - Improved stability (increased own test suite, more tests of the standard class redefinition test suite passing) - Correct handling of static fields: Values are copied from old class instead of reexecuting the static initializer of the new class. - Introduction of mutator methods: On every changed instance the method $mutator() is executed if available. - Rebiased to jdk7-b81 ! hotswap.patch ! hotswap.txt From John.Rose at Sun.COM Wed Feb 3 16:29:51 2010 From: John.Rose at Sun.COM (John Rose) Date: Wed, 03 Feb 2010 16:29:51 -0800 Subject: hg: mlvm/mlvm/hotspot: hotswap: New patch. Main changes are: In-Reply-To: <20100203104800.8167341C26@hg.openjdk.java.net> References: <20100203104800.8167341C26@hg.openjdk.java.net> Message-ID: <2F71E8CB-876A-4AA0-8211-D9196F87E74D@sun.com> Thanks, Lukas and Thomas. -- John From Christian.Thalinger at Sun.COM Tue Feb 9 06:31:26 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 09 Feb 2010 14:31:26 +0000 Subject: hg: mlvm/mlvm/hotspot: Rebased to jdk7-b82. Message-ID: <20100209143127.33CE74187A@hg.openjdk.java.net> Changeset: ec763af298e8 Author: twisti Date: 2010-02-09 15:25 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ec763af298e8 Rebased to jdk7-b82. ! series From Christian.Thalinger at Sun.COM Tue Feb 9 06:31:42 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 09 Feb 2010 14:31:42 +0000 Subject: hg: mlvm/mlvm/jdk: Rebased to jdk7-b82. Message-ID: <20100209143143.357714187B@hg.openjdk.java.net> Changeset: 41eefe741ebf Author: twisti Date: 2010-02-09 15:25 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/41eefe741ebf Rebased to jdk7-b82. ! series From Christian.Thalinger at Sun.COM Tue Feb 9 06:31:52 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 09 Feb 2010 14:31:52 +0000 Subject: hg: mlvm/mlvm/langtools: Rebased to jdk7-b82. Message-ID: <20100209143152.E84E64187C@hg.openjdk.java.net> Changeset: 03a56b07130b Author: twisti Date: 2010-02-09 15:25 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/03a56b07130b Rebased to jdk7-b82. ! series From Christian.Thalinger at Sun.COM Mon Feb 15 05:47:49 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 15 Feb 2010 13:47:49 +0000 Subject: hg: mlvm/mlvm/hotspot: deopt-mh-6921352.patch: New patch as pushed to jdk7/ hotspot-comp/. Message-ID: <20100215134751.0623D421A5@hg.openjdk.java.net> Changeset: 208811eec443 Author: twisti Date: 2010-02-15 14:44 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/208811eec443 deopt-mh-6921352.patch: New patch as pushed to jdk7/ hotspot-comp/. dont-fixup-6921799.patch: Likewise. series: Added above files. callcc.patch: Updated indy-c1-x86-6919934.patch: Likewise. ! callcc.patch + deopt-mh-6921352.patch + dont-fixup-6921799.patch ! indy-c1-x86-6919934.patch ! series From Christian.Thalinger at Sun.COM Mon Feb 15 06:20:12 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 15 Feb 2010 14:20:12 +0000 Subject: hg: mlvm/mlvm/hotspot: callcc: Fixed compilation. Message-ID: <20100215142012.E3CF8421AE@hg.openjdk.java.net> Changeset: 50f6c2cbdea6 Author: twisti Date: 2010-02-15 15:19 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/50f6c2cbdea6 callcc: Fixed compilation. ! callcc.patch From Christian.Thalinger at Sun.COM Mon Feb 15 06:22:17 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 15 Feb 2010 14:22:17 +0000 Subject: hg: mlvm/mlvm/hotspot: series: Enabled indy-c1-x86-6919934 by default. Message-ID: <20100215142217.484A0421B0@hg.openjdk.java.net> Changeset: 3736c05ba9e9 Author: twisti Date: 2010-02-15 15:21 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/3736c05ba9e9 series: Enabled indy-c1-x86-6919934 by default. ! series From Christian.Thalinger at Sun.COM Tue Feb 16 01:16:20 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 16 Feb 2010 09:16:20 +0000 Subject: hg: mlvm/mlvm/hotspot: Rebased to jdk7-b83. Message-ID: <20100216091621.0FDD9422F1@hg.openjdk.java.net> Changeset: 9e6a20f84575 Author: twisti Date: 2010-02-16 10:14 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9e6a20f84575 Rebased to jdk7-b83. ! indy-c1-x86-6919934.patch ! series From Christian.Thalinger at Sun.COM Tue Feb 16 01:16:39 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 16 Feb 2010 09:16:39 +0000 Subject: hg: mlvm/mlvm/jdk: Rebased to jdk7-b83. Message-ID: <20100216091639.677DE422F2@hg.openjdk.java.net> Changeset: 9e7142d8da87 Author: twisti Date: 2010-02-16 10:14 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9e7142d8da87 Rebased to jdk7-b83. ! series From Christian.Thalinger at Sun.COM Tue Feb 16 01:16:50 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 16 Feb 2010 09:16:50 +0000 Subject: hg: mlvm/mlvm/langtools: Rebased to jdk7-b83. Message-ID: <20100216091650.46022422F3@hg.openjdk.java.net> Changeset: f4a615a3bc58 Author: twisti Date: 2010-02-16 10:15 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/f4a615a3bc58 Rebased to jdk7-b83. ! series From Christian.Thalinger at Sun.COM Tue Feb 16 01:32:14 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 16 Feb 2010 09:32:14 +0000 Subject: hg: mlvm/mlvm/hotspot: indy-c1-x86-6919934: SPARC build fixes. Message-ID: <20100216093214.E2B60422F7@hg.openjdk.java.net> Changeset: 41443854c6c5 Author: twisti Date: 2010-02-16 10:31 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/41443854c6c5 indy-c1-x86-6919934: SPARC build fixes. ! indy-c1-x86-6919934.patch From raffaello.giulietti at gmail.com Tue Feb 16 06:07:46 2010 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 16 Feb 2010 15:07:46 +0100 Subject: general inlining Message-ID: <4B7AA6B2.2060507@gmail.com> A general question about inlining. Take the following code: void m() { ensureSomething(); ... } void ensureSomething() { if (someTest()) return; doSomething(); } boolean someTest() { return ... // a simple boolean expression; } void doSomething() { // heavy and long code ... } I would like the lightweight test in ensureSomething(), but not the heavy doSomething(), to be inlined at each call site, like that in m(). Is a general jvm (HotSpot in primis) smart enough to do the inlining by itself or is it better to code the pattern more explicitly by using method handles to factor out the test, e.g., using guarded method handles? Thanks Raffaello From Christian.Thalinger at Sun.COM Tue Feb 16 08:09:46 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Feb 2010 17:09:46 +0100 Subject: general inlining In-Reply-To: <4B7AA6B2.2060507@gmail.com> References: <4B7AA6B2.2060507@gmail.com> Message-ID: <4B7AC34A.4060601@Sun.COM> On 02/16/10 03:07 PM, Raffaello Giulietti wrote: > A general question about inlining. Take the following code: > > void m() { > ensureSomething(); > ... > } > > void ensureSomething() { > if (someTest()) return; > doSomething(); > } > > boolean someTest() { > return ... // a simple boolean expression; > } > > void doSomething() { > // heavy and long code > ... > } > > I would like the lightweight test in ensureSomething(), but not the > heavy doSomething(), to be inlined at each call site, like that in m(). > Is a general jvm (HotSpot in primis) smart enough to do the inlining by > itself or is it better to code the pattern more explicitly by using > method handles to factor out the test, e.g., using guarded method handles? If doSomething() is heavy enough to not be inlined (or cold) and someTest() is light enough to be inlined (or hot) in regard to the inlining heuristics, yes, the JVM should do the right thing for you. You can verify if HotSpot does what you want with: -XX:+PrintCompilation -XX:+PrintInlining -- Christian From raffaello.giulietti at gmail.com Tue Feb 16 10:04:22 2010 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 16 Feb 2010 19:04:22 +0100 Subject: general inlining In-Reply-To: <4B7AC34A.4060601@Sun.COM> References: <4B7AA6B2.2060507@gmail.com> <4B7AC34A.4060601@Sun.COM> Message-ID: <4B7ADE26.1030204@gmail.com> On 2010-02-16 17:09, Christian Thalinger wrote: > On 02/16/10 03:07 PM, Raffaello Giulietti wrote: >> A general question about inlining. Take the following code: >> >> void m() { >> ensureSomething(); >> ... >> } >> >> void ensureSomething() { >> if (someTest()) return; >> doSomething(); >> } >> >> boolean someTest() { >> return ... // a simple boolean expression; >> } >> >> void doSomething() { >> // heavy and long code >> ... >> } >> >> I would like the lightweight test in ensureSomething(), but not the >> heavy doSomething(), to be inlined at each call site, like that in m(). >> Is a general jvm (HotSpot in primis) smart enough to do the inlining by >> itself or is it better to code the pattern more explicitly by using >> method handles to factor out the test, e.g., using guarded method handles? > > If doSomething() is heavy enough to not be inlined (or cold) and > someTest() is light enough to be inlined (or hot) in regard to the > inlining heuristics, yes, the JVM should do the right thing for you. > > You can verify if HotSpot does what you want with: > > -XX:+PrintCompilation -XX:+PrintInlining > I asked because this kind of inlining seems quite clever to my uneducated eyes. Inlining, in m() or at other call sites, only a part of ensureSomething() while skipping the other heavier part and morphing it to another callable method appears quite a wonder without hints from part of the programmer in form of objects like method handles and the guarded counterparts. Kudos to the implementors! From Christian.Thalinger at Sun.COM Wed Feb 17 05:48:35 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 17 Feb 2010 14:48:35 +0100 Subject: general inlining In-Reply-To: <4B7ADE26.1030204@gmail.com> References: <4B7AA6B2.2060507@gmail.com> <4B7AC34A.4060601@Sun.COM> <4B7ADE26.1030204@gmail.com> Message-ID: <4B7BF3B3.60001@Sun.COM> On 02/16/10 07:04 PM, Raffaello Giulietti wrote: > I asked because this kind of inlining seems quite clever to my > uneducated eyes. Inlining, in m() or at other call sites, only a part of > ensureSomething() while skipping the other heavier part and morphing it > to another callable method appears quite a wonder without hints from > part of the programmer in form of objects like method handles and the > guarded counterparts. Kudos to the implementors! It's not that complicated if you have call profiles :-) But I admit that inlining heuristics could be even better in HotSpot. -- Christian From Kirill.Shirokov at Sun.COM Thu Feb 18 01:44:11 2010 From: Kirill.Shirokov at Sun.COM (Kirill Shirokov) Date: Thu, 18 Feb 2010 12:44:11 +0300 Subject: InvokeDynamic throws NoClassDefFoundError Message-ID: <4B7D0BEB.3070404@Sun.COM> John, I don't know if it is a known issue, but I noticed that InvokeDynamic throws NoClassDefFoundError in the following test: package test; import java.dyn.InvokeDynamic; import java.dyn.InvokeDynamicBootstrapError; public class Self { public static void main(String[] args) { try { InvokeDynamic.greet(new Self()); } catch ( InvokeDynamicBootstrapError e ) { System.out.println("TEST PASSED"); } catch ( Throwable t ) { System.err.println("Oops!"); t.printStackTrace(); } } } ...when it is launched with -classpath: $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -classpath bin test.Self Oops! java.lang.NoClassDefFoundError: test/Self at test.Self.main(Self.java:10) If we replace -classpath with -Xbootclasspath: $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -Xbootclasspath/a:bin test.Self TEST PASSED The JDK was 7 b82. Best regards, Kirill From forax at univ-mlv.fr Thu Feb 18 03:22:25 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 18 Feb 2010 12:22:25 +0100 Subject: InvokeDynamic throws NoClassDefFoundError In-Reply-To: <4B7D0BEB.3070404@Sun.COM> References: <4B7D0BEB.3070404@Sun.COM> Message-ID: <4B7D22F1.6000002@univ-mlv.fr> Le 18/02/2010 10:44, Kirill Shirokov a ?crit : > John, > > I don't know if it is a known issue, but I noticed that InvokeDynamic > throws NoClassDefFoundError in the following test: > > package test; > > import java.dyn.InvokeDynamic; > import java.dyn.InvokeDynamicBootstrapError; > > public class Self { > public static void main(String[] args) { > try { > InvokeDynamic.greet(new Self()); > } catch ( InvokeDynamicBootstrapError e ) { > System.out.println("TEST PASSED"); > } catch ( Throwable t ) { > System.err.println("Oops!"); > t.printStackTrace(); > } > } > } > > > ...when it is launched with -classpath: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic > -classpath bin test.Self > Oops! > java.lang.NoClassDefFoundError: test/Self > at test.Self.main(Self.java:10) > > If we replace -classpath with -Xbootclasspath: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic > -Xbootclasspath/a:bin test.Self > TEST PASSED > > The JDK was 7 b82. > Yes, this is a known bug that exist from the beginning. > Best regards, > Kirill > R?mi From Christian.Thalinger at Sun.COM Mon Feb 22 01:46:31 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 22 Feb 2010 09:46:31 +0000 Subject: hg: mlvm/mlvm/hotspot: Rebased to jdk7-b84. Message-ID: <20100222094635.8687B42C5F@hg.openjdk.java.net> Changeset: 9ece76f65954 Author: twisti Date: 2010-02-22 10:43 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9ece76f65954 Rebased to jdk7-b84. ! series From Christian.Thalinger at Sun.COM Mon Feb 22 01:46:56 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 22 Feb 2010 09:46:56 +0000 Subject: hg: mlvm/mlvm/jdk: Rebased to jdk7-b84. Message-ID: <20100222094657.0273A42C60@hg.openjdk.java.net> Changeset: bac9502b795c Author: twisti Date: 2010-02-22 10:43 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bac9502b795c Rebased to jdk7-b84. ! series From Christian.Thalinger at Sun.COM Mon Feb 22 01:47:09 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 22 Feb 2010 09:47:09 +0000 Subject: hg: mlvm/mlvm/langtools: Rebased to jdk7-b84. Message-ID: <20100222094710.622C642C61@hg.openjdk.java.net> Changeset: b434d0ee9439 Author: twisti Date: 2010-02-22 10:44 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/b434d0ee9439 Rebased to jdk7-b84. ! series From larry.chester at googlemail.com Sun Feb 28 15:48:40 2010 From: larry.chester at googlemail.com (Larry Chester) Date: Sun, 28 Feb 2010 23:48:40 +0000 Subject: Invokedynamic and Multiple Dispatch Message-ID: <4166759f1002281548o38084816t837d7eb0ee989a71@mail.gmail.com> Hi all So I've been playing around with invokedynamic (with build 84), however I've stumbled on something I find quite strange! Consider two objects a and b that both reference a String. a is declared as a String but b is only an Object. When I dynamically invoke with either a or b as an argument I would expect the MethodType passed to the bootstrap method to be identical. String a = "hello"; Object b = a; InvokeDynamic.foo(a); InvokeDynamic.foo(b); However, when called with a, the MethodType is (java.lang.String)void; but with b, it is (java.lang.Object)void. I've dug around all over the place but can't find anything that confirms what the behaviour should be in this case. I was hoping invokedynamic could be used for multiple dispatch but that doesn't appear possible. I'm interested what the intended functionality is in this case. Is that a bug or intended? Thanks, Larry