RFR - JDK-8218650: LineNumberTable records for method invocations with arguments

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Feb 21 16:49:03 UTC 2019


On 21/02/2019 16:30, Vicente Romero wrote:
>
>
> On 2/21/19 10:54 AM, Maurizio Cimadamore wrote:
>>
>>
>> On 21/02/2019 15:22, Vicente Romero wrote:
>>>
>>>
>>> On 2/21/19 8:43 AM, Maurizio Cimadamore wrote:
>>>>
>>>> Hate to be the party pooper :-)
>>>>
>>>> What happens with method calls?
>>>>
>>>> class Test {
>>>> public static void main(String[] args) {
>>>>    Object o = null;
>>>>    o.
>>>>     toString(); <-- NPE here
>>>> }
>>>>
>>>> }
>>>>
>>>> So, while at some level I sympathize with the argument of not 
>>>> making LNT more bloated, I can't help noting the asymmetry between 
>>>> field and method access.
>>>>
>>>
>>> yep that's a difference but shouldn't we wait and see if the bug 
>>> referred by Remi solves the problem of the stack trace not being 
>>> exact in some cases?
>>
>> I think that bug refers mostly to the message associated with the 
>> NPE, not with the *line* at which it is reported. At least that's my 
>> understanding.
>>
>
> I'm not opposed to adding more lines to the LNT if that's what you are 
> proposing, but I wonder about the benefit. I mean how bad it is to 
> miss for one, two lines vs having bigger class files. Actually, this 
> is an interesting experiment @Eddie could you please run an experiment 
> to see how bigger would the class files for the whole JDK be with your 
> patch? I'm also interested in redundant lines, it could be that this 
> code adds redundant lines to the LNT and we should avoid that

I guess what I'm arguing is not that we should add LNT - but that I see 
no solid basis for doing this for methods, but not for field access. If 
8218628 will cure us from all sins :-) then the same argument surely 
could be applied to method access?

Maurizio

>
>> Maurizio
>>
>
> Vicente
>
>>>
>>>> Maurizio
>>>
>>> Vicente
>>>
>>>>
>>>> On 20/02/2019 14:20, Remi Forax wrote:
>>>>> I don't think you need to bloat the line number table for this 
>>>>> case because soon the NPE error message will be more precise [1].
>>>>>
>>>>> Rémi
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>>>>>     *À: *"Eddie Aftandilian" <eaftan at google.com>
>>>>>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>>>>>     *Envoyé: *Mercredi 20 Février 2019 14:38:45
>>>>>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for
>>>>>     method invocations with arguments
>>>>>
>>>>>
>>>>>
>>>>>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>>>>>
>>>>>         Hi Vicente,
>>>>>
>>>>>         Thanks for the reply.  Can I ask why you don't think the
>>>>>         LNT should contain entries for accesses to fields?  It
>>>>>         seems that results in incorrect line numbers in certain
>>>>>         cases.  For example, consider the following code:
>>>>>
>>>>>         1: class LineNumbers {
>>>>>         2:
>>>>>         3:   static class T {
>>>>>         4:     boolean b;
>>>>>         5:   }
>>>>>         6:
>>>>>         7:   static void doIt(boolean... values) {}
>>>>>         8:
>>>>>         9:   public static void main(String[] args) {
>>>>>         10:     T a = new T();
>>>>>         11:     T b = null;
>>>>>         12:
>>>>>         13:     doIt(
>>>>>         14:         a.b,
>>>>>         15:         b.b);
>>>>>         16:   }
>>>>>         17: }
>>>>>
>>>>>         $ javac LineNumbers.java
>>>>>         $ java LineNumbers
>>>>>         Exception in thread "main" java.lang.NullPointerException
>>>>>         at LineNumbers.main(LineNumbers.java:13)
>>>>>
>>>>>         I would expect the exception to be at line 15, not 13.
>>>>>
>>>>>
>>>>>     having the exception at 13 is plain bad or good enough? It
>>>>>     seems to me that you want to do some automation based on the
>>>>>     exact line where the exception was produced. I'm just worried
>>>>>     that generating LNT entries for every expression would
>>>>>     produce, probably unnecessarily, fluffier class files.
>>>>>
>>>>>
>>>>>         Thanks,
>>>>>         Eddie
>>>>>
>>>>>
>>>>>     Thanks,
>>>>>     Vicente
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>>>>>         <vicente.romero at oracle.com
>>>>>         <mailto:vicente.romero at oracle.com>> wrote:
>>>>>
>>>>>             Hi Eddie,
>>>>>
>>>>>             Thanks for the patch. But first I'm not sure that
>>>>>             there is a bug in the
>>>>>             LNT. There is an entry in the LNT, I'm talking about
>>>>>             the example at [1],
>>>>>             for the invocation of method `id`. What we need to
>>>>>             understand is why the
>>>>>             stack trace is not referring to that line and is
>>>>>             referring to line 12.
>>>>>             In any case I don't think that the LNT should contain
>>>>>             entries for
>>>>>             accesses to fields.
>>>>>
>>>>>             Thanks,
>>>>>             Vicente
>>>>>
>>>>>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>>
>>>>>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>>>>>             > Hi,
>>>>>             >
>>>>>             > I have attached a patch for JDK-8218650, in which
>>>>>             there are missing
>>>>>             > line number table entries for field accesses. This
>>>>>             is my first attempt
>>>>>             > to contribute to OpenJDK, so I'm happy to take
>>>>>             feedback.  Please see
>>>>>             > the attached patch.
>>>>>             >
>>>>>             > Bug report:
>>>>>             https://bugs.openjdk.java.net/browse/JDK-8218650
>>>>>             >
>>>>>             > Thanks,
>>>>>             > Eddie Aftandilian
>>>>>
>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/ccb094ea/attachment.html>


More information about the compiler-dev mailing list