[15] RFR: 8248476: No helpful NullPointerException message after calling fillInStackTrace

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Goetz Lindenmaier" <goetz.lindenmaier at sap.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "Christoph Dreis" <christoph.dreis at freenet.de>, "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>, "David
> Holmes" <david.holmes at oracle.com>
> Envoyé: Jeudi 2 Juillet 2020 21:30:16
> Objet: RE: [15] RFR: 8248476: No helpful NullPointerException message after calling fillInStackTrace

> Hi Remi,
> 
> But how does volatile help?
> I see the test for numStackTracesFilledIn == 1 then gets always the
> right value.
> But the backtrace may not be changed until I read it in
> getExtendedNPEMessage.  The other thread could change it after
> checking numStackTracesFilledIn and before I read the backtrace.

it helps because if it's not the same thread that explicitly calls fillInStackTrace and calls getExtendedNPEMessage, the one that calls getExtendedNPEMessage() can see 0 instead of 1 but have the stack trace changed.
because there is no happen before relationship between the write to the stacktrace field and the write to numStackTracesFilledIn.

> 
> I want to vote again for the much more simple version
> proposed in webrev 02:
> http://cr.openjdk.java.net/~goetz/wr20/8248476-NPE_fillInStackTrace-jdk15/02/
> 
> It's drawback is only that for this code:
>  ex = null;
>  ex.fillInStackTrace()
> no message is created.
> 
> I think this really is acceptable.

as i said earlier, for me too it's a better idea than add a bunch of code in NPE.java just for one corner of a corner case (explicitly calling fillInStackTrace() ... with null).

Rémi