Charlie,
Is it acceptable and solves the problem for you?
This is acceptable for JRuby. Our worst-case Ruby method handle chain
will include at most:
* Two CatchExceptions for pre/post logic (heap frames, etc). Perf of
CatchException compared to literal Java try/catch is important here.
* Up
Am 02.09.2014 16:38, schrieb Vladimir Ivanov:
[...]
It's possible to optimize some shapes of method handle chains (like
nested GWTs) and tailor special LambdaForm shape or do some inlining
during bytecode translation. Though such specialization contradicts LF
sharing goal, probable benefits may w
Jochen,
>> "N frames per chain of N method handles" looks reasonable for me, but it
depends on average number of transformations users apply. If the case of
deep method handle chains is common in practice, we need to optimize for
it as well and linear dependency in stack space may be too much.
Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
Best regards,
Vladimir Ivanov
On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
https://bugs.openjdk.java.net/browse/JDK-8057042
LambdaFormEditor provides an API to transform LambdaForms. Deriving new
LambdaForms from a base one allows to
https://bugs.openjdk.java.net/browse/JDK-8057042
LambdaFormEditor provides an API to transform LambdaForms. Deriving new
LambdaForms from a base one allows to cache and reuse results of
repeated transformations.
BMH binding is rewritten to use LambdaFormEditor.
Testing: jdk/java/lang/invoke,
Hi,
I just wanted to ask, why Class#getSimpleName() is used in
MethodType#toString(). People knowing this method from Class will also
know that getSimpleName makes assumption about the inner class names,
that are based on the JLS, which allows only a fraction of the names the
JVM allows. Resu
