On Aug 29, 2014, at 12:45 AM, John Rose john.r.r...@oracle.com wrote:
On Aug 28, 2014, at 7:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com wrote:
Regarding the extra cast in accessor logic that Paul picked up on: That
may
On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com wrote:
Regarding the extra cast in accessor logic that Paul picked up on: That may
be a left-over from obsolete versions of the code, or it may cover for some
corner cases, or it could possibly be a re-assurance to the JIT.
I
On Aug 28, 2014, at 7:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com wrote:
Regarding the extra cast in accessor logic that Paul picked up on: That may
be a left-over from obsolete versions of the code, or it may cover for some
I have logged the following issue for redundant null checks:
https://bugs.openjdk.java.net/browse/JDK-8054492
Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com wrote:
Regarding the extra cast in accessor logic that Paul picked up on: That may
be a left-over from obsolete versions of the code, or it may cover for some
corner cases, or it could possibly be a re-assurance to the JIT.
On Jul 9, 2014, at 3:14 AM, Paul Sandoz paul.san...@oracle.com wrote:
I quickly verified the fold up does as you expect. Also, if i do the
following the null check goes away:
...
void testLoop() {
for (int i = 0; i 100; i++) {
testLoopOne(a);
On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
I'd like to revive this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/
Seems ok. I don't claim to be knowledgable enough in the finer points of
Regarding the extra cast in accessor logic that Paul picked up on: That may be
a left-over from obsolete versions of the code, or it may cover for some corner
cases, or it could possibly be a re-assurance to the JIT.
Generally speaking, we lean heavily on MH types to guarantee a priori
In my opinion, there are two issues here,
the first one is the extra Class.cast which is inserted and as John said
it should be interesting to try to remove them.
the second one is why when there is a Class.cast, the cast is
effectively removed but a null check stay.
regards,
Rémi
On
On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
On 4/1/14 7:29 PM, Paul Sandoz wrote:
On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Unfortunately, additional profiling doesn't work for Accessor.checkCast
case.
On Apr 2, 2014, at 4:16 PM, Paul Sandoz paul.san...@oracle.com wrote:
Regarding redundant null check, do you have a test case so I can play with
it myself?
I will send something to you later today or tomorrow.
Still plan to send you something today :-) but later on...
See below
On Mar 14, 2014, at 5:36 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Doh! crossed webrevs, thanks.
Just had a quick look, this looks like a really nice improvement to the
array setter/getter support, definitely simplified. IIUC the mh.viewAsType
will now handle the appropriate
Paul,
Unfortunately, additional profiling doesn't work for Accessor.checkCast
case. The problem is Accessor.checkCast is called from multiple places,
so type profile is very likely to be polluted. And it kills the benefits.
I don't think MethodType helps with profiling in any way. It
On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
Unfortunately, additional profiling doesn't work for Accessor.checkCast case.
The problem is Accessor.checkCast is called from multiple places, so type
profile is very likely to be polluted. And it
Updated version:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.01/
Changes:
- rebased to enum-based BasicType;
- decided to integrate changes for typed array getters/setters
separately;
Best regards,
Vladimir Ivanov
On 3/14/14 8:36 PM, Vladimir Ivanov wrote:
Doh! crossed webrevs,
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8037209
440 lines changed: 313 ins; 67 del; 60 mod
This is a cleanup of JSR292 code to improve bytecode assembly code for
lambda forms.
Contributed-by: john.r.r...@oracle.com
Testing:
FYI, this change isn't limited to only bytecode assembly improvements,
but also contains caching of lambda forms for setters/getter of typed
arrays.
If there are any objections, I can back the caching logic out and
include it into one of upcoming changes.
Best regards,
Vladimir Ivanov
On
On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
FYI, this change isn't limited to only bytecode assembly improvements, but
also contains caching of lambda forms for setters/getter of typed arrays.
Do you mean for MethodHandles.arrayElementGetter/Setter? If
To get into this faster it would be nice if the new private fields (or the
existing ones for that matter) had a comment describing what they were for, e.g.
+ private final byte[] localTypes;
+ private final Class?[] localClasses;
I can figure it out from the code, but it would have been
19 matches
Mail list logo
