On 09/03/2014 07:46 PM, John Rose wrote:
On Sep 3, 2014, at 10:35 AM, Mark Roos mr...@roos.com wrote:
From Morris
All that assert laden code is nice to see.
I just finished watching a video from Doug Lea where he mentioned that having
asserts can
inhibit inlining due to the
On 08/14/2014 12:52 PM, Florian Weimer wrote:
Is there an end-user accessible way of defining anonymous classes (by
which I mean classes which are kept alive only by explicit references
or their instances, and not their class loader)?
Searching for the term anonymous classes isn't
http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057654
The idea is to separate construction logic and different checks
performed before/during method handle construction.
For example: move checks from MHs.foldArguments into
http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057656
There are some corner cases which MT.isCastableTo()
MT.isConvertibleTo() don't treat right (e.g. int-String converstion of
return type in MT.isCastableTo()).
Testing:
I think that in term of concepts there is a kind of convergence between
the couples Graal/Truffle and c2/java.lang.invoke.
The force of Graal is to be able to do partial evaluation directed user
code or by annotations, for me, Hotspot is moving in that direction too,
it already has special
Hi,
On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax fo...@univ-mlv.fr wrote:
I think that in term of concepts there is a kind of convergence between
the couples Graal/Truffle and c2/java.lang.invoke.
The force of Graal is to be able to do partial evaluation directed user
code or by
http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057657
Add ability to annotate LambdaForm parameters with their types.
Type info could be useful during LambdaForm compilation to produce
better bytecode.
Testing: jdk/java/lang/invoke,
+1
On 05 Sep 2014, at 12:46, Aleksey Shipilev aleksey.shipi...@oracle.com wrote:
On 09/05/2014 12:09 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057654
Random style rant of the week, not particularly about
On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul, thanks for review.
Generally looks good (re: Peter's observation of continue/break).
- LambdaFormEditor
61 private static final class Transform {
62 final long packedBytes;
63
On 09/05/2014 11:41 AM, Ali Ebrahimi wrote:
Hi,
On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax fo...@univ-mlv.fr
mailto:fo...@univ-mlv.fr wrote:
I think that in term of concepts there is a kind of convergence
between the couples Graal/Truffle and c2/java.lang.invoke.
The force of
This is why Graal’s inlining heuristics are not based on the number of
bytecodes, but the complexity of the compiler graph after applying
canonicalisation. Adding asserts to the bytecodes should not influence peak
performance when they are disabled. Same for expressing the same logic with a
Paul, Peter, Morris, thanks for review.
Best regards,
Vladimir Ivanov
On 9/5/14, 3:51 PM, Paul Sandoz wrote:
On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul, thanks for review.
Generally looks good (re: Peter's observation of continue/break).
-
Totally agree on that bytecode based metrics are evil.
On 05 Sep 2014, at 14:32, Thomas Wuerthinger thomas.wuerthin...@oracle.com
wrote:
This is why Graal’s inlining heuristics are not based on the number of
bytecodes, but the complexity of the compiler graph after applying
http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8050173
Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided
implementation for all subclasses.
Also, some cleanups:
* rewrote MH.viewAsType on top of MH.copyWith;
* extended
On Sep 5, 2014, at 3:15 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Looks good, just one comment.
MethodHandles.restrictReceiver
This method has:
1578 private MethodHandle restrictReceiver(MemberName method,
MethodHandle mh, Class? caller) throws
Remi,
That assert in a static method could be pulled out to a static block.
Regarding the asserts in the LambdaForms code, my feeling is that in
code that is still in the process of being refactored, that they are
critical to maintain integrity. After the dust settles, creating a
debugging
http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057656
854 if (!canConvert(returnType(), newType.returnType()))
855 return false;
856 Class?[] srcTypes = newType.ptypes;
857 Class?[] dstTypes =
On Jul 16, 2014, at 1:50 AM, Paul Sandoz paul.san...@oracle.com wrote:
Why not make the second parameter be DirectMethodHandle mh ?
Good suggestion; thanks. Makes the restrictReceiver logic less magic. — John
___
mlvm-dev mailing list
Hello,
Please review the change in testlibrary
https://bugs.openjdk.java.net/browse/JDK-8057707
This change is needed for new tests for the feature Lambda Form
Reduction and Caching https://bugs.openjdk.java.net/browse/JDK-8046703
Webrev of the testlibrary change:
Hello,
Please review the new tests for the feature Lambda Form Reduction and
Caching https://bugs.openjdk.java.net/browse/JDK-8046703
JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719
Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/
These tests also depend on
On 05/09/2014 18:57, Konstantin Shefov wrote:
Hello,
Please review the change in testlibrary
https://bugs.openjdk.java.net/browse/JDK-8057707
This change is needed for new tests for the feature Lambda Form
Reduction and Caching https://bugs.openjdk.java.net/browse/JDK-8046703
Webrev of the
On 09/05/2014 04:07 PM, Morris Meyer wrote:
Remi,
That assert in a static method could be pulled out to a static block.
Regarding the asserts in the LambdaForms code, my feeling is that in
code that is still in the process of being refactored, that they are
critical to maintain integrity.
These test are for core-libs feature, but we want to test that unused lambda
forms are garbage collected using WhiteBox.fullGC() method. There are three
tests that use one common class, only one of them uses whitebox api. So it is
hard to move one of tests to hotspot repo.
- Konstantin
23 matches
Mail list logo
