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
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
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.
10 matches
Mail list logo
