From wenlei.xie at gmail.com Tue May 2 19:29:38 2017 From: wenlei.xie at gmail.com (Wenlei Xie) Date: Tue, 2 May 2017 12:29:38 -0700 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class Message-ID: Hi, We are implementing Lambda function with capture support in a SQL Engine. We currently implement by compiling user-written Lambda Expression into a MethodHandle. And use bindTo to captured fields. Thus for each row we will have a Bound Method Handle. However, we found JVM will generate the byte code Bound Method Handle once it's invoked more than 128 times. This cause in some cases (when the table has large arrays), the Metaspace fills with generated LambdaForm$BMH class. Here is the simple code to reproduce the issue: https://github.com/wenleix/BMHTest . It looks we cannot increase java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD beyond 128. Any suggestions to implement Lambda with Capture Support on JVM? Thank you !! Best, Wenlei -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue May 2 20:02:11 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 2 May 2017 22:02:11 +0200 (CEST) Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: References: Message-ID: <911723965.1133864.1493755331536.JavaMail.zimbra@u-pem.fr> Hi Wenei, The idea of bindTo()/insertArguments is that you are requesting a partial evaluation, so you are asking the VM/JIT to specialize the method handle if the method handle is used often. So compiling a method handle to a bytecode snippet in that case is the expected behavior, not a bug. What i do not understand is why you need to have a different method handle for each row ? Did you try to use invokeWithArguments instead of bindTo().invokeExact() ? cheers, R?mi > De: "Wenlei Xie" > ?: mlvm-dev at openjdk.java.net > Envoy?: Mardi 2 Mai 2017 21:29:38 > Objet: Implementing Lambda with Capture support makes Metaspace fills > LambdaForms$BMH class > Hi, > We are implementing Lambda function with capture support in a SQL Engine. We > currently implement by compiling user-written Lambda Expression into a > MethodHandle. And use bindTo to captured fields. Thus for each row we will have > a Bound Method Handle. > However, we found JVM will generate the byte code Bound Method Handle once it's > invoked more than 128 times. This cause in some cases (when the table has large > arrays), the Metaspace fills with generated LambdaForm$BMH class. > Here is the simple code to reproduce the issue: > https://github.com/wenleix/BMHTest . It looks we cannot increase > java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD beyond 128. Any suggestions > to implement Lambda with Capture Support on JVM? > Thank you !! > Best, > Wenlei > _______________________________________________ > 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: From wenlei.xie at gmail.com Tue May 2 20:22:36 2017 From: wenlei.xie at gmail.com (Wenlei Xie) Date: Tue, 2 May 2017 13:22:36 -0700 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: <911723965.1133864.1493755331536.JavaMail.zimbra@u-pem.fr> References: <911723965.1133864.1493755331536.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Thank you for the prompt response!! Consider the following query: SELECT transform(arr, x->x + value) FROM test_table The underlying table is arr | value -------------------------------- [1, 2] | 1 [7, 8, 9] | 2 The expected output is [2, 3] [9, 10, 11] Now our implementation is first to generate a MethodHandle mh that takes two argument and output the sum. During the query processing, for each row, we first call capturedMh = mh.bindTo(value) And then use capturedMh for each value in the array. That's why we are having a different method handle for each row. Best, Wenlei On Tue, May 2, 2017 at 1:02 PM, Remi Forax wrote: > Hi Wenei, > The idea of bindTo()/insertArguments is that you are requesting a partial > evaluation, so you are asking the VM/JIT to specialize the method handle if > the method handle is used often. > So compiling a method handle to a bytecode snippet in that case is the > expected behavior, not a bug. > > What i do not understand is why you need to have a different method handle > for each row ? > > Did you try to use invokeWithArguments instead of bindTo().invokeExact() ? > > cheers, > R?mi > > ------------------------------ > > *De: *"Wenlei Xie" > *?: *mlvm-dev at openjdk.java.net > *Envoy?: *Mardi 2 Mai 2017 21:29:38 > *Objet: *Implementing Lambda with Capture support makes Metaspace fills > LambdaForms$BMH class > > Hi, > We are implementing Lambda function with capture support in a SQL Engine. > We currently implement by compiling user-written Lambda Expression into a > MethodHandle. And use bindTo to captured fields. Thus for each row we will > have a Bound Method Handle. > > However, we found JVM will generate the byte code Bound Method Handle once > it's invoked more than 128 times. This cause in some cases (when the table > has large arrays), the Metaspace fills with generated LambdaForm$BMH class. > > Here is the simple code to reproduce the issue: https://github.com/ > wenleix/BMHTest . It looks we cannot increase > java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD beyond 128. Any > suggestions to implement Lambda with Capture Support on JVM? > > Thank you !! > > Best, > Wenlei > > > > > _______________________________________________ > 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 > > -- Best Regards, Wenlei Xie (???) Email: wenlei.xie at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Wed May 3 12:34:13 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 3 May 2017 15:34:13 +0300 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: References: Message-ID: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> Thanks for the report and for the test case, Wenlei. What you observe is an unfortunate consequence of LambdaForm customization. It was introduced to speedup invocations of non-constant method handles (MH.invoke/invokeExact on a method handle which isn't a constant during JIT compilation). As an example from your use case, in order to optimize for the value of bound argument, the JIT compiler has to "see" it during the compilation. The only way to achieve it right now is by issuing "specialized" bytecode for the particular method handle and that's exactly what happens during LambdaForm customization. The generated class should go away once the method handle it was generated for becomes unreachable, but it seems you construct plenty of method handles for every query. As a workaround, you can turn it off by specifying: -Djava.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD=-1 But I agree with Remi that it's a sign of a deeper problem in how you use method handles. MH.bindTo() always produces a new method handle and doesn't look like a good fit for implementing lambda capturing. Method handles are designed for fast invocation. Some non-trivial amount of work happens during method handle instantiation, so it should be avoided in hot code. From performance perspective, one-time usage of method handles never pays off. You should try to cache and reuse them in order to observe speedups. In particular, reusing the same method handle chain for all rows and passing the value (from the table) explicitly should lead to a better generated code. Best regards, Vladimir Ivanov On 5/2/17 10:29 PM, Wenlei Xie wrote: > Hi, > > We are implementing Lambda function with capture support in a SQL > Engine. We currently implement by compiling user-written Lambda > Expression into a MethodHandle. And use bindTo to captured fields. Thus > for each row we will have a Bound Method Handle. > > However, we found JVM will generate the byte code Bound Method Handle > once it's invoked more than 128 times. This cause in some cases (when > the table has large arrays), the Metaspace fills with generated > LambdaForm$BMH class. > > Here is the simple code to reproduce the > issue: https://github.com/wenleix/BMHTest . It looks we cannot increase > java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD beyond 128. Any > suggestions to implement Lambda with Capture Support on JVM? > > Thank you !! > > Best, > Wenlei > > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From wenlei.xie at gmail.com Thu May 4 04:37:43 2017 From: wenlei.xie at gmail.com (Wenlei Xie) Date: Wed, 3 May 2017 21:37:43 -0700 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> Message-ID: Thank you Vladimir for the help ! I see the point why MH.bindTo() is not a good fit for implementing lambda capturing. We cannot easily directly pass the values from table explicitly to the generated MethodHandle, as we allow UDF/extract function used in lambda functions. I see Brain talked about use InvokeDynamic to implement Java lambda capture (http://wiki.jvmlangsummit.com/images/7/7b/Goetz-jvmls-lambda.pdf) and the LambdaMetaFactoryBenchmark class, I did some benchmark and it seems to have better performance for capture support :). However I do see some strange performance regression after the invocation number exceeds some threshold, which is probably better fit in a separate email thread :) Best, Wenlei On Wed, May 3, 2017 at 5:34 AM, Vladimir Ivanov < vladimir.x.ivanov at oracle.com> wrote: > Thanks for the report and for the test case, Wenlei. > > What you observe is an unfortunate consequence of LambdaForm > customization. It was introduced to speedup invocations of non-constant > method handles (MH.invoke/invokeExact on a method handle which isn't a > constant during JIT compilation). > > As an example from your use case, in order to optimize for the value of > bound argument, the JIT compiler has to "see" it during the compilation. > The only way to achieve it right now is by issuing "specialized" bytecode > for the particular method handle and that's exactly what happens during > LambdaForm customization. > > The generated class should go away once the method handle it was generated > for becomes unreachable, but it seems you construct plenty of method > handles for every query. > > As a workaround, you can turn it off by specifying: > -Djava.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD=-1 > > But I agree with Remi that it's a sign of a deeper problem in how you use > method handles. MH.bindTo() always produces a new method handle and doesn't > look like a good fit for implementing lambda capturing. > > Method handles are designed for fast invocation. Some non-trivial amount > of work happens during method handle instantiation, so it should be avoided > in hot code. From performance perspective, one-time usage of method handles > never pays off. You should try to cache and reuse them in order to observe > speedups. > > In particular, reusing the same method handle chain for all rows and > passing the value (from the table) explicitly should lead to a better > generated code. > > Best regards, > Vladimir Ivanov > > > On 5/2/17 10:29 PM, Wenlei Xie wrote: > >> Hi, >> >> We are implementing Lambda function with capture support in a SQL >> Engine. We currently implement by compiling user-written Lambda >> Expression into a MethodHandle. And use bindTo to captured fields. Thus >> for each row we will have a Bound Method Handle. >> >> However, we found JVM will generate the byte code Bound Method Handle >> once it's invoked more than 128 times. This cause in some cases (when >> the table has large arrays), the Metaspace fills with generated >> LambdaForm$BMH class. >> >> Here is the simple code to reproduce the >> issue: https://github.com/wenleix/BMHTest . It looks we cannot increase >> java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD beyond 128. Any >> suggestions to implement Lambda with Capture Support on JVM? >> >> Thank you !! >> >> Best, >> Wenlei >> >> >> >> >> >> _______________________________________________ >> 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 > -- Best Regards, Wenlei Xie (???) Email: wenlei.xie at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Thu May 4 06:16:35 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 3 May 2017 23:16:35 -0700 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> Message-ID: On May 3, 2017, at 9:37 PM, Wenlei Xie wrote: > > Thank you Vladimir for the help ! I see the point why MH.bindTo() is not a good fit for implementing lambda capturing. A simple rule for using MHs is that they are designed to be another form of code. Creating many of them at a high rate is likely to stress JVM in ways similar to loading many small classes at a high rate. So bindTo is really code customization, which is not the same thing as data capture. The MH before bindTo is an algorithm with a variable "hole" in it, where the MH after bindTo is a customized version of the algorithm, with the hole filed by a constant. It's a little like a C++ template instance. I'd like high-count bindTo to be cheaper, of course, but it's not the design center, and it's not where we are investing optimization effort. Maybe in the future. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From blackdrag at gmx.org Thu May 4 12:39:37 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 4 May 2017 14:39:37 +0200 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> Message-ID: I think avoiding to create many of them is actually not trivial. The indy port of Groovy has a similar problem. And I do have to use a lot of insertArguments, exception catching handles and other things. So the stress is actually pretty high at times. example... foo(x,y) is mapped to MyInvokerFallback.handle(receiver, "foo", x, y); with the method taking a String and an Object[]. How do I get the name in there without insertArguments? Don't I have to create at least one handle per name I find? bye Jochen On 04.05.2017 08:16, John Rose wrote: > On May 3, 2017, at 9:37 PM, Wenlei Xie > wrote: >> >> Thank you Vladimir for the help ! I see the point why MH.bindTo() is >> not a good fit for implementing lambda capturing. > > A simple rule for using MHs is that they are designed to be another form > of code. > Creating many of them at a high rate is likely to stress JVM in ways similar > to loading many small classes at a high rate. > > So bindTo is really code customization, which is not the same thing as > data capture. > The MH before bindTo is an algorithm with a variable "hole" in it, where > the MH after > bindTo is a customized version of the algorithm, with the hole filed by > a constant. > It's a little like a C++ template instance. > > I'd like high-count bindTo to be cheaper, of course, but it's not the > design center, > and it's not where we are investing optimization effort. Maybe in the > future. > > ? John > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From vladimir.x.ivanov at oracle.com Thu May 4 13:05:48 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 4 May 2017 16:05:48 +0300 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> Message-ID: <3b203d8f-a19c-80f3-364e-a131ecc1e40b@oracle.com> Jochen, > I think avoiding to create many of them is actually not trivial. The > indy port of Groovy has a similar problem. And I do have to use a lot of > insertArguments, exception catching handles and other things. So the > stress is actually pretty high at times. Can you elaborate a bit, please? What kind of stress do you observe: MH instantiation overhead or increased footprint? Does memory increase come from method handles alone or there are plenty of classes loaded at runtime for compiled LFs? > example... foo(x,y) is mapped to MyInvokerFallback.handle(receiver, > "foo", x, y); with the method taking a String and an Object[]. How do I > get the name in there without insertArguments? Don't I have to create at > least one handle per name I find? One important detail is how method handles are actually used. Yes, you do have to create a method handle per call site, but it is placed in a CallSite instance and bound to indy call site. In that case, there's no need in LambdaForm specialization: JIT-compiler will inline the whole method handle chain at indy call site which is equivalent to bytecode specialization. Also, LambdaForms are aggressively shared, so you shouldn't observe significant growth in their number at runtime (unless there are lots of unique "erased" signatures present; that's where LF sharing can't help now). Hope it helps. FTR I covered some of those topics in details in my j.l.i-related talk at JVMLS'15 [1]. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/talks/2015-JVMLS_State_of_JLI.pdf > On 04.05.2017 08:16, John Rose wrote: >> On May 3, 2017, at 9:37 PM, Wenlei Xie > > wrote: >>> >>> Thank you Vladimir for the help ! I see the point why MH.bindTo() is >>> not a good fit for implementing lambda capturing. >> >> A simple rule for using MHs is that they are designed to be another form >> of code. >> Creating many of them at a high rate is likely to stress JVM in ways >> similar >> to loading many small classes at a high rate. >> >> So bindTo is really code customization, which is not the same thing as >> data capture. >> The MH before bindTo is an algorithm with a variable "hole" in it, where >> the MH after >> bindTo is a customized version of the algorithm, with the hole filed by >> a constant. >> It's a little like a C++ template instance. >> >> I'd like high-count bindTo to be cheaper, of course, but it's not the >> design center, >> and it's not where we are investing optimization effort. Maybe in the >> future. >> >> ? John >> >> >> _______________________________________________ >> 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 blackdrag at gmx.org Fri May 5 10:33:09 2017 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 5 May 2017 12:33:09 +0200 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: <3b203d8f-a19c-80f3-364e-a131ecc1e40b@oracle.com> References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> <3b203d8f-a19c-80f3-364e-a131ecc1e40b@oracle.com> Message-ID: <71f310d5-9149-ad54-0ca4-926ef7409dc2@gmx.org> On 04.05.2017 15:05, Vladimir Ivanov wrote: > Jochen, > >> I think avoiding to create many of them is actually not trivial. The >> indy port of Groovy has a similar problem. And I do have to use a lot of >> insertArguments, exception catching handles and other things. So the >> stress is actually pretty high at times. > > Can you elaborate a bit, please? What kind of stress do you observe: MH > instantiation overhead or increased footprint? Does memory increase come > from method handles alone or there are plenty of classes loaded at > runtime for compiled LFs? My biggest problem in terms of creation performance are transformations of the handle using asType so far. Having to create many many different MethodHandles increases the memory footprint, but probably stabilizes. As for plenty of classes... well.. potentially yes. I can easily create such a program in Groovy. >> example... foo(x,y) is mapped to MyInvokerFallback.handle(receiver, >> "foo", x, y); with the method taking a String and an Object[]. How do I >> get the name in there without insertArguments? Don't I have to create at >> least one handle per name I find? > > One important detail is how method handles are actually used. > > Yes, you do have to create a method handle per call site, but it is > placed in a CallSite instance and bound to indy call site. In that case, > there's no need in LambdaForm specialization: JIT-compiler will inline > the whole method handle chain at indy call site which is equivalent to > bytecode specialization. is that now true for all handles? Since the forms do no longer show up in the traces I cannot tell. Also I am required to have MutableCallsite, since I have to handle the dispatch based on runtime types. This multiplies the number of handles I create. Example: Object myMethod(Object singleArg); Object myMethod(String singleArg); myMethod(x) In Java, now depending on the defined type of x we know which of the two methods to call. Which means, if I could use a static callsite here. In Groovy I have to first put in a handle, that directs to my method selector, which will then install the target handle (and call it), as well as a guard to check that the argument is as expected. > Also, LambdaForms are aggressively shared, so you shouldn't observe > significant growth in their number at runtime (unless there are lots of > unique "erased" signatures present; that's where LF sharing can't help > now). there is a high number of "runtime signatures" bye Jochen From vladimir.x.ivanov at oracle.com Fri May 5 12:44:32 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 5 May 2017 15:44:32 +0300 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: <71f310d5-9149-ad54-0ca4-926ef7409dc2@gmx.org> References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> <3b203d8f-a19c-80f3-364e-a131ecc1e40b@oracle.com> <71f310d5-9149-ad54-0ca4-926ef7409dc2@gmx.org> Message-ID: <972ce253-074c-949b-a663-36096e928fad@oracle.com> Jochen, >> Can you elaborate a bit, please? What kind of stress do you observe: MH >> instantiation overhead or increased footprint? Does memory increase come >> from method handles alone or there are plenty of classes loaded at >> runtime for compiled LFs? > > My biggest problem in terms of creation performance are transformations > of the handle using asType so far. Having to create many many different > MethodHandles increases the memory footprint, but probably stabilizes. > As for plenty of classes... well.. potentially yes. I can easily create > such a program in Groovy. > >>> example... foo(x,y) is mapped to MyInvokerFallback.handle(receiver, >>> "foo", x, y); with the method taking a String and an Object[]. How do I >>> get the name in there without insertArguments? Don't I have to create at >>> least one handle per name I find? >> >> One important detail is how method handles are actually used. >> >> Yes, you do have to create a method handle per call site, but it is >> placed in a CallSite instance and bound to indy call site. In that case, >> there's no need in LambdaForm specialization: JIT-compiler will inline >> the whole method handle chain at indy call site which is equivalent to >> bytecode specialization. > > is that now true for all handles? Since the forms do no longer show up > in the traces I cannot tell. Also I am required to have MutableCallsite, > since I have to handle the dispatch based on runtime types. This > multiplies the number of handles I create. Example: Yes, it's true for all handles. LF specialization is tightly coupled with JIT-compilers and is triggered only for method handles which aren't inlined into all callers. It never happens for indy call sites - JITs can always inline (and do so) through them. (Even when they are linked to mutable CSs. In that case, there's a dependency on compiled method registered to track future modifications.) But I suspect it's not what you asked about. FYI with -XX:+ShowHiddenFrames the JVM will include LF frames in stack trackes. But it's not about stack frames: there's still a single frame per method handle in a method handle chain in interpreter. LambdaForm specialization is about generating a dedicated class for a LambdaForm instance. So, irrespective of LF specialization, you'll observe the same number of stack frames, but the methods being executed will refer to either shared or customized LFs. In other words, LF specialization influence how many classes for compiled LFs are loaded, but doesn't change what actually happen during MH invocation. (No inlining on bytecode level is needed during specialization. JIT will already do that during compilation. No need to help it.) > Object myMethod(Object singleArg); > Object myMethod(String singleArg); > > myMethod(x) > > In Java, now depending on the defined type of x we know which of the two > methods to call. Which means, if I could use a static callsite here. In > Groovy I have to first put in a handle, that directs to my method > selector, which will then install the target handle (and call it), as > well as a guard to check that the argument is as expected. I'd like to differentiate method handles and lambda forms. If you create a new method handle, it doesn't imply a new lambda form is also created. Method handles aren't compiled to bytecode themselves, only lambda forms are. So, when you instantiate a new method handle, from footprint perspective you pay a cost of a single object instance. Most likely, the costs of the lambda form & associated class are amortized across all method handles which share them. For example, my experiments with Nashorn showed 1000x ratio between instantiated MHs & LFs (millions handles vs thousands LFs on Octane benchmarks). Also, LF caches are SoftReference-based, so footprint measurements don't reflect how many LFs are actually used. It's pretty expensive to construct a LF, so it's benefitical to keep it alive longer that weak references allow. You mentioned MH.asType() and, unfortunately, from LF sharing perspective it's a weak point right now. There's some sharing possible, but the current LF shape for asType() transformation is hard to share. It hasn't been addressed yet mostly because we don't have a good understanding how much overhead does it cause. So, if you have any data on that, please, share. >> Also, LambdaForms are aggressively shared, so you shouldn't observe >> significant growth in their number at runtime (unless there are lots of >> unique "erased" signatures present; that's where LF sharing can't help >> now). > > there is a high number of "runtime signatures" What is important is how many unique erased signatures exist (erased to basic types [1]). It's still possible to trigger explosion in number of LFs (5^255 is still pretty large, isn't it? ;-)), but now it's a corner case. Best regards, Vladimir Ivanov [1] 5 in total: int, long, float, double, Object From john.r.rose at oracle.com Fri May 5 22:48:46 2017 From: john.r.rose at oracle.com (John Rose) Date: Fri, 5 May 2017 15:48:46 -0700 Subject: Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class In-Reply-To: <972ce253-074c-949b-a663-36096e928fad@oracle.com> References: <1817bb02-4b45-eb18-e80b-18c8bc9bf71a@oracle.com> <3b203d8f-a19c-80f3-364e-a131ecc1e40b@oracle.com> <71f310d5-9149-ad54-0ca4-926ef7409dc2@gmx.org> <972ce253-074c-949b-a663-36096e928fad@oracle.com> Message-ID: On May 5, 2017, at 5:44 AM, Vladimir Ivanov wrote: > > In other words, LF specialization influence how many classes for compiled LFs are loaded, but doesn't change what actually happen during MH invocation. (No inlining on bytecode level is needed during specialization. JIT will already do that during compilation. No need to help it.) Not that hidden frames are terribly important, but it does strike me as odd, at this moment, that stack traces for customized MHs and "raw" MHs look the pretty much the same. Idea: Have two levels of hiding: Hide always, and hide if inlined into some caller. That way a successfully optimized MH will show fewer stack frames on close inspection. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Thu May 18 19:55:30 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 18 May 2017 12:55:30 -0700 Subject: the End of History in the constant pool In-Reply-To: <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> Message-ID: <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> (I'm moving an amber-dev conversation about condy to mlvm-dev.) We are working on a condy JEP and spec. as well as a prototype, which is good progress. I'll post some info about that in a moment. On May 18, 2017, at 12:16 PM, Remi Forax wrote: > > I would prefer 17 to 21, because 21 is already used internally by ASM :) I don't think anyone is objecting to 17 for CONSTANT_ConstantDynamic, and I expect 17 is what we will land on. It's been held open for (approximately) this purpose. Fun facts from History: CONSTANT_17 was used by a prototype version of invokedynamic which was discarded. (The EG wisely discarded a couple of designs, including a design without method handles!) The prototype in that case overloaded the invokeinterface instruction, in ways which are useless to recall. In order to make a clean break, we helped ourselves to another constant tag. Soon after that, I realized a future need for expression-like structures threaded through the constant pool and bootstrap specifiers, although it was a bridge too far at the time. So we made no effort to "compact" our constant pool tag usage, knowing there might be followup work in the future. Also: From the primordial days of Java there is CONSTANT_Unicode (tag 2) which AFAIK has never been used from JDK 1 forward. I think modern "take" on character sets is to have one format for text (usually UTF8) and one for binary octets. (This is exemplified, for example, in CBOR.) I expect some day to use the constant tag 2 for such a purpose. Basically, it would amount to giving class files the power to "swallow" resource files (or smaller random byte snippets). It has an obvious multiplicative effect on condy, but we don't need it yet, so we are going with the minimal proposal. I think the Ultimate, End-of-History CP tags are CONSTANT_ConstantDynamic, CONSTANT_Data, and CONSTANT_Group. The Group is simply a subsequence of CP values (probably of limited set of types). It would be used for packing array constants and other aggregate types. Today we use bootstrap specifiers, which can be as long as 2^16-1 items, so there's no immediate motivation for a new grouping construct. But the main point of a Group would be to lift the restriction that all CP constants are defined in one space of 2^16-1 code points. Instead, a group would contain serialized CP entries that have no absolute CP index, but rather are loaded as part of the group. The group's size limit could also be raised to a u4 from u2. I think the octet data size limit should be u8 but that requires further API work in the JDK. My hope is that both Data and Group can serve at a wide range of length scales, O(10) to O(10^10). In the interests of incremental delivery, the forthcoming JEP only deals with a limited subset of this stuff. The bug JDK-8161256 is a "kitchen sink" description of proposals (both live and abandoned) for futures in this direction. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Thu May 18 20:03:07 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 18 May 2017 13:03:07 -0700 Subject: the End of History in the constant pool In-Reply-To: <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> Message-ID: On May 18, 2017, at 12:55 PM, John Rose wrote: > > I'll post some info about that in a moment. Here's what we are thinking about doing with condy in the short term. Comments are welcome. This work is landing in branches of the Amber project. ? John Just as the linkage of an invokedynamic call site involves an upcall from the JVM to Java-based linkage logic, we can apply this same trick to the resolution of a constant pool entry. A CONSTANT_Dynamic constant pool entry encodes the bootstrap method to perform the resolution (a MethodHandle), the type of the constant (a Class), and any static bootstrap arguments (an arbitrary sequence of constants, barring cycles in the CP between dynamic constants.) We add a new constant pool form, CONSTANT_Dynamic (new constant tag 17), which has two components following its tag byte: the index of a bootstrap method, in the same format as the index found in a CONSTANT_InvokeDynamic, and a CONSTANT_NameAndType) which encodes the expected type. Behaviorally, a CONSTANT_Dynamic constant is resolved by executing its bootstrap method on the following parameters: 1. a local Lookup object, 2. the String representing the name component of the constant, 3. the Classrepresenting the expected constant type, and 4. any remaining bootstrap arguments. As with invokedynamic, multiple threads can race to resolve, but a unique winner will be chosen and any other contending answers discarded. Instead of returning a CallSite object (as the invokedynamicinstruction requires) the bootstrap method would return a value which would be immediately converted to the required type. As with invokedynamic, the name component is an additional channel, besides the type, for passing expression information to the bootstrap method. It is expected that just as invokedynamic instructions find uses for the name component (e.g., a method name or some ad hoc descriptor) dynamic constants will also find uses for the name (e.g., the name of a enum constant or the spelling of a symbolic constant). Putting the CONSTANT_NameAndTypein both places makes for a more regular design. In effect, a CONSTANT_Methodref and CONSTANT_Fieldref constants are used to refer to named members of classes, while the analogous CONSTANT_InvokeDynamic and CONSTANT_Dynamic constants are used to refer to named entities with user-programmed bootstraps. The type component of the constant, with both invokedynamic andCONSTANT_Dynamic, determines the effective type of the call site or constant (respectively). The bootstrap method does not contribute or constrain this type information, so that bootstrap methods may be (and often are) weakly typed whereas the bytecodes themselves are always strongly typed. To relax length restrictions on bootstrap specifiers, the language which defines the invocation of bootstrap methods will be adjusted (with complete backward compatibility) to allow variable arity (ACC_VARARGS) bootstrap methods to absorb, into their trailing arguments, all remaining static arguments, even if there are 2^16-1 of them. (The classfile format already allows this, although there is no way to read over-long bootstrap argument lists.) For consistency, the invokeWithArguments methods of MethodHandle will also be expanded in this way, if the target method has variable arity. In this way the invocation of bootstrap methods can be specified in terms of the weakly typed methods invokeWithArguments and invoke, just as today it is specified in terms of invoke alone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rednaxelafx at gmail.com Thu May 18 20:11:11 2017 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 18 May 2017 13:11:11 -0700 Subject: the End of History in the constant pool In-Reply-To: <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> Message-ID: Hi John, Thanks for moving the conversation to mlvm-dev! The condy stuff is finally coming, yay! Just out of curiousity, since we're on this topic, may I ask about what constant tags 13 and 14 used to mean? All I could find was that 13 was used in JavaCard VM (JCVM) as CONSTANT_Package. But what was the full story behind the missing 13 and 14 here? Thanks, Kris On Thu, May 18, 2017 at 12:55 PM, John Rose wrote: > (I'm moving an amber-dev conversation about condy to mlvm-dev.) > > We are working on a condy JEP and spec. as well as a prototype, which is > good progress. I'll post some info about that in a moment. > > On May 18, 2017, at 12:16 PM, Remi Forax wrote: > > > I would prefer 17 to 21, because 21 is already used internally by ASM :) > > > I don't think anyone is objecting to 17 for CONSTANT_ConstantDynamic, > and I expect 17 is what we will land on. It's been held open for > (approximately) > this purpose. > > Fun facts from History: CONSTANT_17 was used by a prototype version of > invokedynamic which was discarded. (The EG wisely discarded a couple of > designs, > including a design without method handles!) The prototype in that case > overloaded > the invokeinterface instruction, in ways which are useless to recall. In > order to make > a clean break, we helped ourselves to another constant tag. Soon after > that, > I realized a future need for expression-like structures threaded through > the constant > pool and bootstrap specifiers, although it was a bridge too far at the > time. So > we made no effort to "compact" our constant pool tag usage, knowing there > might > be followup work in the future. > > Also: From the primordial days of Java there is CONSTANT_Unicode (tag 2) > which AFAIK has never been used from JDK 1 forward. I think modern "take" > on > character sets is to have one format for text (usually UTF8) and one for > binary > octets. (This is exemplified, for example, in CBOR.) I expect some day > to use > the constant tag 2 for such a purpose. Basically, it would amount to > giving class > files the power to "swallow" resource files (or smaller random byte > snippets). > It has an obvious multiplicative effect on condy, but we don't need it > yet, so > we are going with the minimal proposal. > > I think the Ultimate, End-of-History CP tags are CONSTANT_ConstantDynamic, > CONSTANT_Data, and CONSTANT_Group. > > The Group is simply a subsequence of CP values (probably of limited set of > types). > It would be used for packing array constants and other aggregate types. > Today we use bootstrap specifiers, which can be as long as 2^16-1 items, > so there's no immediate motivation for a new grouping construct. But the > main point > of a Group would be to lift the restriction that all CP constants are > defined in one > space of 2^16-1 code points. Instead, a group would contain serialized CP > entries that have no absolute CP index, but rather are loaded as part of > the group. > > The group's size limit could also be raised to a u4 from u2. I think the > octet data > size limit should be u8 but that requires further API work in the JDK. My > hope is that > both Data and Group can serve at a wide range of length scales, O(10) to > O(10^10). > > In the interests of incremental delivery, the forthcoming JEP only deals > with a limited > subset of this stuff. The bug JDK-8161256 is a "kitchen sink" > description of proposals > (both live and abandoned) for futures in this direction. > > ? 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: From forax at univ-mlv.fr Thu May 18 21:13:59 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 18 May 2017 23:13:59 +0200 (CEST) Subject: the End of History in the constant pool In-Reply-To: <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> Message-ID: <1326432780.2840306.1495142039117.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "R?mi Forax" > Cc: "paul sandoz" , "Da Vinci Machine Project" > > Envoy?: Jeudi 18 Mai 2017 21:55:30 > Objet: the End of History in the constant pool > (I'm moving an amber-dev conversation about condy to mlvm-dev.) > We are working on a condy JEP and spec. as well as a prototype, which is > good progress. I'll post some info about that in a moment. > On May 18, 2017, at 12:16 PM, Remi Forax < forax at univ-mlv.fr > wrote: >> I would prefer 17 to 21, because 21 is already used internally by ASM :) > I don't think anyone is objecting to 17 for CONSTANT_ConstantDynamic, > and I expect 17 is what we will land on. It's been held open for (approximately) > this purpose. > Fun facts from History: CONSTANT_17 was used by a prototype version of > invokedynamic which was discarded. (The EG wisely discarded a couple of designs, > including a design without method handles!) The prototype in that case > overloaded > the invokeinterface instruction, in ways which are useless to recall. In order > to make > a clean break, we helped ourselves to another constant tag. Here is my own recollection (cross checked with the SVN history of ASM), there were 4 versions of invokedynamic, the first one that was like doesNotUnderstand in SmallTalk (or method_missing of Ruby) and uses invokeinterface then the spec was rebooted, the second version has it's own bytecode 186, has method handles but has no specific constant pool constant and the bootstrap method was called with the actual values of the first call, i join the EG at that point and we worked on a the third version that was using the constant 17 and was working like invokedynamic today but has no bootstrap arguments. Happily (for invokedynamic) at that point, Sun died, so we get some the extra time to add the bootstrap arguments and uses the constant 18 to avoid to change the invokedynamic opcode because an opcode index is more precious than a constant pool tag. > Soon after that, I realized a future need for expression-like structures > threaded through the constant > pool and bootstrap specifiers, although it was a bridge too far at the time. So > we made no effort to "compact" our constant pool tag usage, knowing there might > be followup work in the future. > Also: From the primordial days of Java there is CONSTANT_Unicode (tag 2) > which AFAIK has never been used from JDK 1 forward. I think modern "take" on > character sets is to have one format for text (usually UTF8) and one for binary > octets. (This is exemplified, for example, in CBOR.) I expect some day to use > the constant tag 2 for such a purpose. Basically, it would amount to giving > class > files the power to "swallow" resource files (or smaller random byte snippets). > It has an obvious multiplicative effect on condy, but we don't need it yet, so > we are going with the minimal proposal. > I think the Ultimate, End-of-History CP tags are CONSTANT_ConstantDynamic, > CONSTANT_Data, and CONSTANT_Group. > The Group is simply a subsequence of CP values (probably of limited set of > types). > It would be used for packing array constants and other aggregate types. > Today we use bootstrap specifiers, which can be as long as 2^16-1 items, > so there's no immediate motivation for a new grouping construct. But the main > point > of a Group would be to lift the restriction that all CP constants are defined in > one > space of 2^16-1 code points. Instead, a group would contain serialized CP > entries that have no absolute CP index, but rather are loaded as part of the > group. > The group's size limit could also be raised to a u4 from u2. I think the octet > data > size limit should be u8 but that requires further API work in the JDK. My hope > is that > both Data and Group can serve at a wide range of length scales, O(10) to > O(10^10). > In the interests of incremental delivery, the forthcoming JEP only deals with a > limited > subset of this stuff. The bug JDK-8161256 is a "kitchen sink" description of > proposals > (both live and abandoned) for futures in this direction. > ? John R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Thu May 18 22:07:57 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 18 May 2017 15:07:57 -0700 Subject: the End of History in the constant pool In-Reply-To: <1326432780.2840306.1495142039117.JavaMail.zimbra@u-pem.fr> References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> <1326432780.2840306.1495142039117.JavaMail.zimbra@u-pem.fr> Message-ID: On May 18, 2017, at 2:13 PM, forax at univ-mlv.fr wrote: > > uses invokeinterface then the spec was rebooted, the second version has it's own bytecode 186, There was another in between that used invokeinterface and reified a CallSite with patchable state. I did a really nasty design for this w/o MHs, but it was like cooking blindfolded. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Thu May 18 22:33:49 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 18 May 2017 16:33:49 -0600 Subject: Call for Speakers -- 2017 JVM Language Summit In-Reply-To: <7B1486AA-6901-4F3C-BC5F-1E9C3B5839A2@oracle.com> References: <7B1486AA-6901-4F3C-BC5F-1E9C3B5839A2@oracle.com> Message-ID: Reminder: deadline is next Monday. Please get your talk abstracts in! > On Apr 24, 2017, at 3:26 PM, Dan Smith wrote: > > CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY-AUGUST 2017 > > We are pleased to announce the 2017 JVM Language Summit to be held at Oracle's Santa Clara campus on July 31-August 2, 2017. Registration is now open for speaker submissions and will remain open through May 22, 2017. There is no registration fee for speakers. > > A limited number of early registration slots are also available for regular attendees. > > The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. > > Presentations will be recorded and made available to the public. > > This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. > > Format > > The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. > > The schedule consists of a single track of traditional presentations (about 6 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-4 each day) and, possibly, impromptu "lightning talks." > > Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. > > Instructions for Speaker Registration > > If you'd like to give a presentation, please register as a Speaker and include a detailed abstract. Speaker registration will remain open through May 22. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. > > For a successful speaker submission, please note the following: > > - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here! > > - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) > > - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers. > > To register: > register.jvmlangsummit.com > > For further information: > jvmlangsummit.com > > Questions: > inquire2017 at jvmlangsummit.com > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mroos at roos.com Fri May 19 01:55:41 2017 From: mroos at roos.com (Mark Roos) Date: Thu, 18 May 2017 18:55:41 -0700 Subject: the End of History in the constant pool In-Reply-To: References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Fri May 19 03:17:21 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 18 May 2017 20:17:21 -0700 Subject: the End of History in the constant pool In-Reply-To: References: <201705162339.v4GNd5rl025054@aojmv0008.oracle.com> <287676888.2827267.1495135012396.JavaMail.zimbra@u-pem.fr> <46785D9D-0B45-448B-A025-38957E4E6F2A@oracle.com> Message-ID: <43D05C2D-DE7D-447F-BFE8-85CC7CB31415@oracle.com> On May 18, 2017, at 6:55 PM, Mark Roos wrote: > > Does this allow the use of a byteArray as one or more of the bootstrap constants? > > I seem to recall that was something I wished for when I did a similar effort with > constant call sites. Yes, it does. The byte array would be its own condy node, which could then be used as a BSM argument. This is why condy is more than just a slightly better way to do indy-of-no-arguments. Also, by tweaking MH.invokeWithArguments to support thousands of arguments, the set of possible BSM argument lists is much more interesting (limited to 64k at present, until we get Groups). ? John From daniel.smith at oracle.com Tue May 30 18:56:51 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 30 May 2017 12:56:51 -0600 Subject: General Registration -- 2017 JVM Language Summit Message-ID: GENERAL REGISTRATION -- JVM LANGUAGE SUMMIT, JULY-AUGUST 2017 General registration for the 2017 JVM Language Summit is now open. The event will be held at Oracle's Santa Clara campus on July 31-August 2, 2017. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers?no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected. The schedule consists of a single track of traditional presentations (about 6 each day) interspersed with less-formal multitrack "workshop" discussion groups (2-4 each day) and, possibly, impromptu "lightning talks." Workshops will be less structured than in the past, favoring an open discussion format with only a small amount of prepared material. Thus, rather than collecting workshop abstracts from speakers, we're asking each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2017 at jvmlangsummit.com