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
>
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 performa
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
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? W
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 MyInvoker
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
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
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).
A
Arguments instead of bindTo().invokeExact() ?
>
> cheers,
> Rémi
>
> --
>
> *De: *"Wenlei Xie"
> *À: *mlvm-dev@openjdk.java.net
> *Envoyé: *Mardi 2 Mai 2017 21:29:38
> *Objet: *Implementing Lambda with Capture support makes Metaspace fills
&
t; 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
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 by
11 matches
Mail list logo
