On Aug 29, 2014, at 12:45 AM, John Rose wrote:
> On Aug 28, 2014, at 7:38 AM, Paul Sandoz wrote:
>
>> On Jul 8, 2014, at 9:09 PM, John Rose 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
On Aug 28, 2014, at 7:38 AM, Paul Sandoz wrote:
> On Jul 8, 2014, at 9:09 PM, John Rose 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
On Jul 8, 2014, at 9:09 PM, John Rose 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 had some enlightenin
I have logged the following issue for redundant null checks:
https://bugs.openjdk.java.net/browse/JDK-8054492
Paul.
On Jul 9, 2014, at 8:04 PM, John Rose wrote:
> On Jul 9, 2014, at 3:14 AM, Paul Sandoz 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++) {
>
On Jul 9, 2014, at 3:14 AM, Paul Sandoz 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);
> testLoopOne(snull);
On Jul 8, 2014, at 9:09 PM, John Rose 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.
>
> Generally speaking,
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 07/08/20
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
correct
On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov
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
conversion/casting/verification but i could se
I'd like to revive this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/
Paul, I'd like to address your case (if possible) separately. Right now,
I don't see any way to avoid null check you see with your tests.
Best regards,
Vladimir Ivanov
On 3/24/14 8
On Apr 2, 2014, at 4:16 PM, Paul Sandoz 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 be
On Apr 1, 2014, at 6:21 PM, Vladimir Ivanov
wrote:
> On 4/1/14 7:29 PM, Paul Sandoz wrote:
>>
>> On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov
>> wrote:
>>
>>> Paul,
>>>
>>> Unfortunately, additional profiling doesn't work for Accessor.checkCast
>>> case. The problem is Accessor.checkCast is
Best regards,
Vladimir Ivanov
On 4/1/14 7:29 PM, Paul Sandoz wrote:
On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov
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 i
On Apr 1, 2014, at 4:10 PM, Vladimir Ivanov
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 kills the benefits.
>
So
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 represen
On Mar 14, 2014, at 5:36 PM, Vladimir Ivanov
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 casting. I believe
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, t
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 casting. I believe it might reduce the "ceremony" for array
setter/getter MHs [1].
I
On Mar 14, 2014, at 2:17 PM, Vladimir Ivanov
wrote:
> Paul,
>
> You are looking at the other fix (8037210).
> The correct link is [1].
>
Doh! crossed webrevs, thanks.
Just had a quick look, this looks like a really nice improvement to the array
setter/getter support, definitely simplified.
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 a
Paul,
You are looking at the other fix (8037210).
The correct link is [1].
Best regards,
Vladimir Ivanov
[1]
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html
On 3/14/14 4:38 PM, Paul Sandoz wrote:
On Mar 14, 2014, at
On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov
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 so i don't see
relevant
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 3/
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: jdk/java/{la
25 matches
Mail list logo
