From jan.lahoda at oracle.com  Fri Nov 22 10:52:09 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 22 Nov 2019 11:52:09 +0100
Subject: RFR: JDK-8234634: JShell could leverage the better
 NullPointerException analysis
Message-ID: <a524dd28-3fd4-0672-41fb-2e739117ef5e@oracle.com>

Hi,

Maurizio suggested on core-libs-dev that JShell could leverage the 
better NullPointerException analysis. This patch tried to do it. The 
outcome for the user is e.g.:
---
jshell> String s = null;
s ==> null

jshell> s.length()
|  Exception java.lang.NullPointerException: Cannot invoke 
"String.length()" because "s" is null
|        at (#2:1)

jshell> String test(Object o) { return o.toString(); }
|  created method test(Object)

jshell> test(null)
|  Exception java.lang.NullPointerException: Cannot invoke 
"Object.toString()" because "o" is null
|        at test (#3:1)
|        at (#4:1)
---

There are three parts of this patch:
1. enabling -g:vars, so that the NPE analysis has more data to work on
2. enabling -XX:+ShowCodeDetailsInExceptionMessages, so that the 
enhanced analysis runs. It feels a little bit unfortunate to depend on a 
non-standard VM option, but this is only done in the tool (not in the 
engine), so it may be OK.
3. processing of the NPE message to strip references to the synthetic 
JShell classes.

Webrev: http://cr.openjdk.java.net/~jlahoda/8234634/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8234634

How does this look?

Thanks,
     Jan

From jan.lahoda at oracle.com  Wed Nov 27 11:49:54 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 27 Nov 2019 12:49:54 +0100
Subject: RFR: JDK-8234896: Tab completion does not work for method references
 in jshell.
Message-ID: <3fa30208-e398-73c9-66f5-509dee8a649b@oracle.com>

Hi,

The tab completion does not propose methods for method references. E.g.:
---
jshell> class C { public static void test() { } }
| created class C

jshell> Runnable r = C::<tab>
---

Produces no proposals. This patch tries to fix that, by proposing 
methods (and the smart code completion will filter methods that have 
acceptable parameter/return types).

Webrev: http://cr.openjdk.java.net/~jlahoda/8234896/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8234896

How does this look?

Thanks,
     Jan

From maurizio.cimadamore at oracle.com  Wed Nov 27 13:12:20 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 Nov 2019 13:12:20 +0000
Subject: NPE when rewriting stack trace
Message-ID: <972df1f0-2c54-4ced-7f03-fa0461054c60@oracle.com>

Hi,
I was experimenting with the Panama memory access API in jshell and I 
got this:


jshell> arr_elem_h.set(segment.baseAddress(), 4, 3);
|? Exception java.lang.IndexOutOfBoundsException: Out of bound access on 
segment MemorySegment{ id=0x60ec3cd3 limit: 40 }; new offset = 40; new 
length = 8
|??????? at MemorySegmentImpl.checkBounds (MemorySegmentImpl.java:201)
|??????? at MemorySegmentImpl.checkRange (MemorySegmentImpl.java:180)
|??????? at MemoryAddressImpl.checkAccess (MemoryAddressImpl.java:86)
|??????? at VarHandleMemoryAddressAsDoubles.checkAddress 
(VarHandleMemoryAddressAsDoubles.java:55)
|??????? at VarHandleMemoryAddressAsDoubles.set0 
(VarHandleMemoryAddressAsDoubles.java:80)
|??????? at VarHandleMemoryAddressAsDoubles1/0x0000000800b9f440.set 
(Unknown Source)
|??????? at VarHandleGuards.guard_LII_V (VarHandleGuards.java:719)
|??????? at (#9:1)


The following patch (discussed with Jan) fixes it:

http://cr.openjdk.java.net/~mcimadamore/panama/8234814_v3/src/jdk.jshell/share/classes/jdk/jshell/Eval.java.udiff.html

For now I've refrained from fixing this in Panama directly - as it will 
probably be better to fix it more generally in the upstream JDK (after 
all, we can have VarHandle or MethodHandle throwing exceptions w/o 
Panama as well).


If you want I can go ahead an file a bug for this

Maurizio


From maurizio.cimadamore at oracle.com  Wed Nov 27 13:18:19 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 Nov 2019 13:18:19 +0000
Subject: RFR: JDK-8234634: JShell could leverage the better
 NullPointerException analysis
In-Reply-To: <a524dd28-3fd4-0672-41fb-2e739117ef5e@oracle.com>
References: <a524dd28-3fd4-0672-41fb-2e739117ef5e@oracle.com>
Message-ID: <83815f05-f112-7cfc-caae-9cb45b85d441@oracle.com>

I like it very much - great work.

I get what you say about depending on XX options, but this is, I think, 
a nice usability boost, and I'm not too picky about what we have to do 
in order to get it :-)

Maurizio

On 22/11/2019 10:52, Jan Lahoda wrote:
> Hi,
>
> Maurizio suggested on core-libs-dev that JShell could leverage the 
> better NullPointerException analysis. This patch tried to do it. The 
> outcome for the user is e.g.:
> ---
> jshell> String s = null;
> s ==> null
>
> jshell> s.length()
> |? Exception java.lang.NullPointerException: Cannot invoke 
> "String.length()" because "s" is null
> |??????? at (#2:1)
>
> jshell> String test(Object o) { return o.toString(); }
> |? created method test(Object)
>
> jshell> test(null)
> |? Exception java.lang.NullPointerException: Cannot invoke 
> "Object.toString()" because "o" is null
> |??????? at test (#3:1)
> |??????? at (#4:1)
> ---
>
> There are three parts of this patch:
> 1. enabling -g:vars, so that the NPE analysis has more data to work on
> 2. enabling -XX:+ShowCodeDetailsInExceptionMessages, so that the 
> enhanced analysis runs. It feels a little bit unfortunate to depend on 
> a non-standard VM option, but this is only done in the tool (not in 
> the engine), so it may be OK.
> 3. processing of the NPE message to strip references to the synthetic 
> JShell classes.
>
> Webrev: http://cr.openjdk.java.net/~jlahoda/8234634/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234634
>
> How does this look?
>
> Thanks,
> ??? Jan

From maurizio.cimadamore at oracle.com  Wed Nov 27 13:19:42 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 27 Nov 2019 13:19:42 +0000
Subject: NPE when rewriting stack trace
In-Reply-To: <972df1f0-2c54-4ced-7f03-fa0461054c60@oracle.com>
References: <972df1f0-2c54-4ced-7f03-fa0461054c60@oracle.com>
Message-ID: <1fdd8d89-0495-b22e-8c89-7cfc53183a5c@oracle.com>

Actually, is this a dupe of

https://bugs.openjdk.java.net/browse/JDK-8210527

?

The fix looks identical in spirit.

Maurizio

On 27/11/2019 13:12, Maurizio Cimadamore wrote:
> Hi,
> I was experimenting with the Panama memory access API in jshell and I 
> got this:
>
>
> jshell> arr_elem_h.set(segment.baseAddress(), 4, 3);
> |? Exception java.lang.IndexOutOfBoundsException: Out of bound access 
> on segment MemorySegment{ id=0x60ec3cd3 limit: 40 }; new offset = 40; 
> new length = 8
> |??????? at MemorySegmentImpl.checkBounds (MemorySegmentImpl.java:201)
> |??????? at MemorySegmentImpl.checkRange (MemorySegmentImpl.java:180)
> |??????? at MemoryAddressImpl.checkAccess (MemoryAddressImpl.java:86)
> |??????? at VarHandleMemoryAddressAsDoubles.checkAddress 
> (VarHandleMemoryAddressAsDoubles.java:55)
> |??????? at VarHandleMemoryAddressAsDoubles.set0 
> (VarHandleMemoryAddressAsDoubles.java:80)
> |??????? at VarHandleMemoryAddressAsDoubles1/0x0000000800b9f440.set 
> (Unknown Source)
> |??????? at VarHandleGuards.guard_LII_V (VarHandleGuards.java:719)
> |??????? at (#9:1)
>
>
> The following patch (discussed with Jan) fixes it:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8234814_v3/src/jdk.jshell/share/classes/jdk/jshell/Eval.java.udiff.html 
>
>
> For now I've refrained from fixing this in Panama directly - as it 
> will probably be better to fix it more generally in the upstream JDK 
> (after all, we can have VarHandle or MethodHandle throwing exceptions 
> w/o Panama as well).
>
>
> If you want I can go ahead an file a bug for this
>
> Maurizio
>

From jan.lahoda at oracle.com  Wed Nov 27 14:04:28 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 27 Nov 2019 15:04:28 +0100
Subject: RFR: JDK-8234634: JShell could leverage the better
 NullPointerException analysis
In-Reply-To: <83815f05-f112-7cfc-caae-9cb45b85d441@oracle.com>
References: <a524dd28-3fd4-0672-41fb-2e739117ef5e@oracle.com>
 <83815f05-f112-7cfc-caae-9cb45b85d441@oracle.com>
Message-ID: <d930f576-d150-73f4-6232-8f6c25f8f2b3@oracle.com>

Actually, Robert expressed concerns about this offline. The current 
proposal is to not use the -XX parameter, but prepare jshell for the 
state where that will be default (by using -g:vars and cleaning of the 
exception messages). The users will still be able to enable the better 
behavior using -R-XX...:

http://cr.openjdk.java.net/~jlahoda/8234634/webrev.01/

Jan

On 27. 11. 19 14:18, Maurizio Cimadamore wrote:
> I like it very much - great work.
> 
> I get what you say about depending on XX options, but this is, I think, 
> a nice usability boost, and I'm not too picky about what we have to do 
> in order to get it :-)
> 
> Maurizio
> 
> On 22/11/2019 10:52, Jan Lahoda wrote:
>> Hi,
>>
>> Maurizio suggested on core-libs-dev that JShell could leverage the 
>> better NullPointerException analysis. This patch tried to do it. The 
>> outcome for the user is e.g.:
>> ---
>> jshell> String s = null;
>> s ==> null
>>
>> jshell> s.length()
>> |? Exception java.lang.NullPointerException: Cannot invoke 
>> "String.length()" because "s" is null
>> |??????? at (#2:1)
>>
>> jshell> String test(Object o) { return o.toString(); }
>> |? created method test(Object)
>>
>> jshell> test(null)
>> |? Exception java.lang.NullPointerException: Cannot invoke 
>> "Object.toString()" because "o" is null
>> |??????? at test (#3:1)
>> |??????? at (#4:1)
>> ---
>>
>> There are three parts of this patch:
>> 1. enabling -g:vars, so that the NPE analysis has more data to work on
>> 2. enabling -XX:+ShowCodeDetailsInExceptionMessages, so that the 
>> enhanced analysis runs. It feels a little bit unfortunate to depend on 
>> a non-standard VM option, but this is only done in the tool (not in 
>> the engine), so it may be OK.
>> 3. processing of the NPE message to strip references to the synthetic 
>> JShell classes.
>>
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8234634/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234634
>>
>> How does this look?
>>
>> Thanks,
>> ??? Jan

From jan.lahoda at oracle.com  Thu Nov 28 08:53:16 2019
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 28 Nov 2019 09:53:16 +0100
Subject: RFR 8210527: NullPointerException in
 jdk.jshell.Eval.translateExceptionStack
In-Reply-To: <8ff12294-eb70-5fff-e27e-a25b5193d54e@oracle.com>
References: <8ff12294-eb70-5fff-e27e-a25b5193d54e@oracle.com>
Message-ID: <403f0967-4236-61d3-186d-7adac1ce6390@oracle.com>

Looks good to me. My only question is whether we would prefer a more 
robust test (test that would not depend on the JDK internals creating a 
stack trace without a file name). Like the attached sketch.

Jan

On 27. 08. 19 3:09, Robert Field wrote:
> Bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8210527
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~rfield/8210527/
> 
> 
> Thanks,
> Robert
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8210527-test.diff
Type: text/x-diff
Size: 3828 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/kulla-dev/attachments/20191128/cb4bc476/8210527-test.diff>