[15] RFR: 8248476: No helpful NullPointerException message after calling fillInStackTrace
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Jul 14 20:27:05 UTC 2020
On 7/14/20 4:17 PM, Mandy Chung wrote:
> fillInStackTrace and setStackTrace replace the stack trace of a NPE
> instance. Therefore I think both should behave consistently for any
> NPE instances with and without an explicit message.
>
> For webrev.06/webrev.07, this would behave as if NPE was created with
> an extended message which cannot be altered once constructed. I
> expect that it'd be rare to see NPE instance thrown by VM (not
> explicitly constructed) but whose stack trace is replaced. So I'm
> fine with this approach.
>
> webrev.06 is okay while I think checking Throwable::backtrace != null
> is clearer as I suggested.
I like that version 06 isolates knowledge to NullPointerException.java
and doesn't have to know what the expected value of backtrace is in the
super class. I maintain my vote for 06.
Thanks, I was trying to understand the fillInStackTrace vs.
setStackTrace issue, and your description makes sense to me.
Coleen
>
> Mandy
>
> On 7/14/20 12:55 PM, coleen.phillimore at oracle.com wrote:
>>
>> Goetz and all,
>>
>> I have to admit, the version with the counter 06 is more intuitive to
>> me. It would be even better if it was a boolean. I don't think an
>> extra 32 bits in an NPE Throwable matters considering the backtrace
>> is a lot bigger. The NPE Throwable in general shouldn't be a long
>> lived object, and there shouldn't be thousands of them.
>>
>> There seemed to be disagreement on the issue of the message not
>> matching the stack trace if the code calls setStackTrace(). It
>> doesn't seem like it should be the same at all to fillInStackTrace()
>> to me, but this latest patch maintains the status quo. If you want
>> to explore this further, I think you should file a separate RFE, and
>> fix the reported bug with this patch.
>>
>> So if I get a vote, I'd pick 06.
>>
>> Thanks,
>> Coleen
>>
>> On 7/14/20 9:48 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> Yes, Coleen, you are right. We must preserve the lazy
>>> computation, and also reduce overhead on discarded
>>> exceptions.
>>>
>>> And yes, we can do it with a counter:
>>> http://cr.openjdk.java.net/~goetz/wr20/8248476-NPE_fillInStackTrace-jdk15/06/
>>>
>>> but I would prefer placeholder strings:
>>> http://cr.openjdk.java.net/~goetz/wr20/8248476-NPE_fillInStackTrace-jdk15/07/
>>>
>>> This way we need only one new field.
>>>
>>> (I need two placeholders, because the getExtendedNPEMessage0()
>>> sometimes returns null. If I write null into the extendedMessage field,
>>> fillInStackTrace sets it to mustComputeExtendedNPEMessage a second
>>> time.)
>>>
>>> With webrev 07 the overhead on discarded exceptions is basically the
>>> same as with webrev 05: one additional field, one assignment in
>>> fillInStackTrace().
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> Goetz.
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Holmes <david.holmes at oracle.com>
>>>> Sent: Tuesday, July 14, 2020 1:55 PM
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
>>>> 'forax at univ-mlv.fr'
>>>> <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>
>>>> Subject: Re: [15] RFR: 8248476: No helpful NullPointerException
>>>> message
>>>> after calling fillInStackTrace
>>>>
>>>> Correction ...
>>>>
>>>> On 14/07/2020 12:11 pm, David Holmes wrote:
>>>>> Hi Goetz,
>>>>>
>>>>> Okay ... if I understand your position correctly you are looking
>>>>> at this
>>>>> as if the extended message is created at the time the NPE is
>>>>> thrown, and
>>>>> it is an implementation detail that we actually determine it
>>>>> lazily. If
>>>>> it were eagerly determined then neither fillInstacktrace() nor
>>>>> setStackTrace() would make any difference to the message - just as
>>>>> with
>>>>> any other exception message.
>>>>>
>>>>> However, the lazy determination of the message causes a problem with
>>>>> fillInStackTrace() because that call will destroy the original
>>>>> backtrace
>>>>> needed to produce the original message, and create an incorrect
>>>>> message.
>>>>> setStackTrace() does not have a similar problem because, simply by
>>>>> the
>>>>> way the current implementation works it doesn't touch the original
>>>>> backtrace.
>>>>>
>>>>> So you are proposing to only fix the bug that is evident in
>>>>> relation to
>>>>> fillInStackTrace() by no longer evaluating the extended message if
>>>>> fillInStackTrace() is called after the NPE was constructed.
>>>>>
>>>>> But in doing so you break the illusion that the extended message acts
>>>>> as-if determined at construction time, because you now effectively
>>>>> clear
>>>>> it when fillInStackTrace is called.
>>>>>
>>>>> My position was that if fillInStackTrace can be seen to clear it,
>>>>> then
>>>>> setStackTrace (which is logically somewhat equivalent) should also be
>>>>> seen to clear it.
>>>>>
>>>>> Alternatively, add a new field to NPE to cache the extended error
>>>>> message, and explicitly evaluate the message if fillInStackTrace() is
>>>>> called. That will continue the illusion that the extended message was
>>>>> actually set at construction time. No changes needed to
>>>>> setStackTrace()
>>>>> as we can still lazily compute the extended message.
>>>>>
>>>>> Something like:
>>>>>
>>>>> private String extendedMessage;
>>>>>
>>>>> public synchronized Throwable fillInStackTrace() {
>>>>> if (extendedMessage == NULL) {
>>>>> extendedMessage = getExtendedNPEMessage();
>>>>> }
>>>>> return super.fillInStackTrace();
>>>>> }
>>>> Coleen pointed out to me that we can't do it like this because we need
>>>> the initial fillInStacktrace to be fast and we want the extended
>>>> message
>>>> computed lazily. So it will still need a counter so we only do this on
>>>> the second call.
>>>>
>>>>
>>>> private String extendedMessage;
>>>> private int fillInCount;
>>>>
>>>> public synchronized Throwable fillInStackTrace() {
>>>> if (extendedMessage == NULL && (fillInCount++ == 1)) {
>>>> extendedMessage = getExtendedNPEMessage();
>>>> }
>>>> return super.fillInStackTrace();
>>>> }
>>>>
>>>> or something to that effect.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> public String getMessage() {
>>>>> String message = super.getMessage();
>>>>> synchronized(this) {
>>>>> if (message == null) {
>>>>> // This NPE should have an extended message.
>>>>> if (extendedMessage == NULL) {
>>>>> extendedMessage = getExtendedNPEMessage();
>>>>> }
>>>>> message = extendedMessage;
>>>>> }
>>>>> }
>>>>> return message;
>>>>> }
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> On 14/07/2020 12:48 am, Lindenmaier, Goetz wrote:
>>>>>> Hi David,
>>>>>>
>>>>>>> Your extended message is only computed when there is no original
>>>>>>> message.
>>>>>> Hmm. I would say the extended message is only computed when
>>>>>> The NPE was raised by the runtime. It happens to never have a
>>>>>> message so far in these cases.
>>>>>> But this is two views to the same thing ��
>>>>>>
>>>>>>> You're concerned about this scenario:
>>>>>>>
>>>>>>> catch (NullPointerException npe) {
>>>>>>> String msg1 = npe.getMessage(); // gets extends NPE message
>>>>>>> npe.setStackTrace(...);
>>>>>>> String msg2 = npe.getMessage(); // gets null
>>>>>>> }
>>>>>>>
>>>>>>> While I find it hard to imagine anyone doing this
>>>>>> Well, all the scenario are quite artificial:
>>>>>> - why would you call fillInStackTrace on an exception thrown
>>>>>> by the VM?
>>>>>> - why would you call setStackTrace at all?
>>>>>>> you can easily have
>>>>>>> specified that the extended message is only available with the
>>>>>>> original
>>>>>>> stacktrace, hence after a second call to fillInStackTrace, or a
>>>>>>> call to
>>>>>>> setStackTrace, then the message reverts to being empty.
>>>>>> The message is not meant to be a special thing that behaves
>>>>>> different
>>>>>> from other messages. Like sometime be available, sometime not.
>>>>>> It ended up being different through requirements during the
>>>>>> review.
>>>>>>
>>>>>>> To me that makes
>>>>>>> far more sense than having msg2 continue to report the extended
>>>>>>> info
>>>> for
>>>>>>> the original stacktrace when it now has a new stacktrace.
>>>>>>>
>>>>>>> I'm really not seeing why calling fillInstackTrace() a second time
>>>>>>> should be treated any differently to calling setStackTrace(). They
>>>>>>> should be handled consistently IMO.
>>>>>> But then you treat setStackTrace() differently from setStackTrace()
>>>>>> with other exceptions.
>>>>>> The reason to treat fillInStackTrace differently is that we lost
>>>>>> information
>>>>>> needed to compute it. This is not the case with setStackTrace().
>>>>>>
>>>>>> A different solution, the one I would have proposed if I had not
>>>>>> considered previous comments from reviews, would be to just
>>>>>> compute the message in the runtime in the call of fillInStackTrace
>>>>>> before the old stack trace is lost and assign it to the message
>>>>>> field.
>>>>>> This way it would behave similar to all other exceptions. The
>>>>>> message
>>>>>> would just be there ... just that it's computed lazily.
>>>>>> The cost of the algorithm wouldn't harm that much as other costly
>>>>>> algorithms (walking the stack) are performed at this point, too.
>>>>>>
>>>>>>> We are not talking about all exceptions only about your NPE
>>>>>>> extended
>>>>>>> error message.
>>>>>> Hmm, the inconsistency caused by the code you posted above
>>>>>> holds for all exceptions. If you fiddle with the stack trace,
>>>>>> the message might become pointless. Wrt. setStackTrace
>>>>>> they all behave the same.
>>>>>> Wrt. fillInStackTrace the message will be wrong. Only this
>>>>>> needs to be fixed.
>>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> I implemented an example where wrong stack traces are
>>>>>>>> printed with LinkageError and NPE, modifying a jtreg test:
>>>>>>>> http://cr.openjdk.java.net/~goetz/wr20/8248476-
>>>> NPE_fillInStackTrace-
>>>>>>> jdk15/05/mess_with_exceptions.patch
>>>>>>>> See also the generated output added to a comment in the patch.
>>>>>>>> If the NEP message text was missing in the second printout, I
>>>>>>>> think
>>>>>>>> this really would be unexpected.
>>>>>>>> Please note that the correct message is printed after messing
>>>>>>>> with the stack trace, it's the stack trace that is wrong.
>>>>>>>> (Not as with the problem I am fixing here where a wrong
>>>>>>>> message is printed.)
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> I guess the normal usecase of setStackTrace is the other way
>>>>>>>>>> around:
>>>>>>>>>> Change the message and throw a new exception with the existing
>>>>>>>>>> stack trace:
>>>>>>>>>>
>>>>>>>>>> try {
>>>>>>>>>> a.x;
>>>>>>>>>> catch (NullPointerException e) {
>>>>>>>>>> throw new NullPointerException("My own error
>>>>>>>>> message").setStackTrace(e.getStackTrace);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> And not taking an arbitrary stack trace and put it into an
>>>>>>>>>> exception
>>>>>>>>>> with existing message.
>>>>>>>>> Interesting usage.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: David Holmes <david.holmes at oracle.com>
>>>>>>>>>>> Sent: Friday, July 3, 2020 9:30 AM
>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
>>>> 'forax at univ-
>>>>>>>>> mlv.fr'
>>>>>>>>>>> <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>
>>>>>>>>>>> Subject: Re: [15] RFR: 8248476: No helpful NullPointerException
>>>>>>> message
>>>>>>>>>>> after calling fillInStackTrace
>>>>>>>>>>>
>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>
>>>>>>>>>>> On 3/07/2020 4:32 pm, Lindenmaier, Goetz wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>> True. To ensure you process the original backtrace only you
>>>>>>>>>>>>> need to
>>>>>>>>> add
>>>>>>>>>>>>> synchronization in getMessage():
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr20/8248476-
>>>>>>> NPE_fillInStackTrace-
>>>>>>>>>>> jdk15/05/
>>>>>>>>>>>> I added the volatile, too, but as I understand the
>>>>>>>>>>>> synchronized
>>>>>>>>>>>> block brings sufficient memory barriers that this also works
>>>>>>>>>>>> without.
>>>>>>>>>>> No "volatile" needed, or wanted, when all access is within
>>>>>>>>>>> synchronized
>>>>>>>>>>> regions.
>>>>>>>>>>>
>>>>>>>>>>>>> To be honest the idea that someone would share an exception
>>>>>>> instance
>>>>>>>>>>> and
>>>>>>>>>>>>> concurrently mutate it with fillInStackTrace() whilst
>>>>>>>>>>>>> printing out
>>>>>>>>>>>>> information about it just seems highly unrealistic.
>>>>>>>>>>>> Yes, contention here is quite unlikely, so it should not harm
>>>>>>> performance
>>>>>>>>>>> ��
>>>>>>>>>>>
>>>>>>>>>>> Contention was not my concern at all. :)
>>>>>>>>>>>
>>>>>>>>>>>>> Though after looking at comments in the test I would also
>>>>>>>>>>>>> suggest that setStackTrace be updated:
>>>>>>>>>>>> The test shows that after setStackTrace still the correct
>>>>>>>>>>>> message
>>>>>>>>>>>> is computed. This is because the algorithm uses
>>>>>>>>>>>> Throwable::backtrace
>>>>>>>>>>>> and not Throwable::stacktrace. Throwable::backtrace is not
>>>>>>>>>>>> affected by setStackTrace.
>>>>>>>>>>>> The behavior is just as with any exception. If you fiddle
>>>>>>>>>>>> with the stack trace, but don't adapt the message text,
>>>>>>>>>>>> the message might refer to other code than the stack trace
>>>>>>>>>>>> points to.
>>>>>>>>>>> But you can't adapt the message text - there is no
>>>>>>>>>>> setMessage! If
>>>>>>>>>>> the
>>>>>>>>>>> message is NULL and you call setStackTrace() then
>>>>>>>>>>> getMessage(), it
>>>>>>> makes
>>>>>>>>>>> no sense to return the extended error message that was
>>>>>>>>>>> associated
>>>>>>> with
>>>>>>>>>>> the original stack/backtrace.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: David Holmes <david.holmes at oracle.com>
>>>>>>>>>>>>> Sent: Friday, July 3, 2020 3:37 AM
>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
>>>>>>> 'forax at univ-
>>>>>>>>>>> mlv.fr'
>>>>>>>>>>>>> <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>
>>>>>>>>>>>>> Subject: Re: [15] RFR: 8248476: No helpful
>>>>>>>>>>>>> NullPointerException
>>>>>>>>> message
>>>>>>>>>>>>> after calling fillInStackTrace
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/07/2020 5:30 am, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>> True. To ensure you process the original backtrace only you
>>>>>>>>>>>>> need to
>>>>>>>>> add
>>>>>>>>>>>>> synchronization in getMessage():
>>>>>>>>>>>>>
>>>>>>>>>>>>> public String getMessage() {
>>>>>>>>>>>>> String message = super.getMessage();
>>>>>>>>>>>>> // If the stack trace was changed the
>>>>>>>>>>>>> extended
>>>>>>>>>>>>> NPE algorithm
>>>>>>>>>>>>> // will compute a wrong message.
>>>>>>>>>>>>> + synchronized(this) {
>>>>>>>>>>>>> ! if (message == null &&
>>>>>>>>>>>>> numStackTracesFilledIn ==
>>>>>>>>>>>>> 1) {
>>>>>>>>>>>>> ! return getExtendedNPEMessage();
>>>>>>>>>>>>> ! }
>>>>>>>>>>>>> + }
>>>>>>>>>>>>> return message;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> To be honest the idea that someone would share an exception
>>>>>>> instance
>>>>>>>>>>> and
>>>>>>>>>>>>> concurrently mutate it with fillInStackTrace() whilst
>>>>>>>>>>>>> printing out
>>>>>>>>>>>>> information about it just seems highly unrealistic. But the
>>>>>>>>>>>>> above fixes
>>>>>>>>>>>>> it simply. Though after looking at comments in the test I
>>>>>>>>>>>>> would
>>>>>>>>>>>>> also
>>>>>>>>>>>>> suggest that setStackTrace be updated:
>>>>>>>>>>>>>
>>>>>>>>>>>>> synchronized (this) {
>>>>>>>>>>>>> if (this.stackTrace == null && //
>>>>>>>>>>>>> Immutable stack
>>>>>>>>>>>>> backtrace == null) // Test for out of
>>>>>>>>>>>>> protocol state
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> + numStackTracesFilledIn++;
>>>>>>>>>>>>> this.stackTrace = defensiveCopy;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> as that would seem to be another hole in the mechanism.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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/
>>>>>>>>>>>>>
>>>>>>>>>>>>> I much prefer the latest version that recognises that only
>>>>>>>>>>>>> the
>>>>>>>>>>>>> original
>>>>>>>>>>>>> stack can be processed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the test:
>>>>>>>>>>>>>
>>>>>>>>>>>>> + // This holds for explicitly crated NPEs, but also
>>>>>>>>>>>>> for implicilty
>>>>>>>>>>>>>
>>>>>>>>>>>>> Two typos: crated & implicilty
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It's drawback is only that for this code:
>>>>>>>>>>>>>> ex = null;
>>>>>>>>>>>>>> ex.fillInStackTrace()
>>>>>>>>>>>>>> no message is created.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think this really is acceptable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remi, I didn't comment on this statement from a previous
>>>>>>>>>>>>>> mail:
>>>>>>>>>>>>>>>> Hmm, Throwable.stackTrace is used for the stack trace at
>>>> some
>>>>>>>>> point.
>>>>>>>>>>>>>>> yes, it contains the Java stack trace, but if the Java
>>>>>>>>>>>>>>> stack
>>>>>>>>>>>>>>> trace is
>>>>>>> filled
>>>>>>>>>>> you
>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> compute any helpful message anyway.
>>>>>>>>>>>>>> The internal structure is no more deleted when the stack
>>>>>>>>>>>>>> trace
>>>>>>>>>>>>>> is filled. So the message can be computed later, too.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: forax at univ-mlv.fr <forax at univ-mlv.fr>
>>>>>>>>>>>>>>> Sent: Thursday, July 2, 2020 8:52 PM
>>>>>>>>>>>>>>> To: Alan Bateman <Alan.Bateman at oracle.com>
>>>>>>>>>>>>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
>>>> Christoph
>>>>>>>>> Dreis
>>>>>>>>>>>>>>> <christoph.dreis at freenet.de>; hotspot-runtime-dev <hotspot-
>>>>>>>>> runtime-
>>>>>>>>>>>>>>> dev at openjdk.java.net>; David Holmes
>>>>>>> <david.holmes at oracle.com>
>>>>>>>>>>>>>>> Subject: Re: [15] RFR: 8248476: No helpful
>>>> NullPointerException
>>>>>>>>>>> message
>>>>>>>>>>>>>>> after calling fillInStackTrace
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> yes,
>>>>>>>>>>>>>>> it's what i was saying,
>>>>>>>>>>>>>>> given that a NPE can be thrown very early, before
>>>>>>>>>>>>>>> VarHandle is
>>>>>>>>>>> initialized,
>>>>>>>>>>>>> i
>>>>>>>>>>>>>>> believe that declaring numStackTracesFilledIn volatile
>>>>>>>>>>>>>>> is the
>>>>>>>>>>>>>>> best
>>>>>>> way
>>>>>>>>> to
>>>>>>>>>>>>>>> tackle that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Rémi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ----- Mail original -----
>>>>>>>>>>>>>>>> De: "Alan Bateman" <Alan.Bateman at oracle.com>
>>>>>>>>>>>>>>>> À: "Goetz Lindenmaier" <goetz.lindenmaier at sap.com>,
>>>>>>> "Christoph
>>>>>>>>>>>>> Dreis"
>>>>>>>>>>>>>>> <christoph.dreis at freenet.de>
>>>>>>>>>>>>>>>> Cc: "hotspot-runtime-dev" <hotspot-runtime-
>>>>>>>>> dev at openjdk.java.net>,
>>>>>>>>>>>>>>> "David Holmes" <david.holmes at oracle.com>, "Remi Forax"
>>>>>>>>>>>>>>>> <forax at univ-mlv.fr>
>>>>>>>>>>>>>>>> Envoyé: Jeudi 2 Juillet 2020 20:47:31
>>>>>>>>>>>>>>>> Objet: Re: [15] RFR: 8248476: No helpful
>>>> NullPointerException
>>>>>>>>> message
>>>>>>>>>>>>>>> after calling fillInStackTrace
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 02/07/2020 17:45, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>> Hi Christoph,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I fixed the comment, thanks for pointing that out.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One other thing is that NPE::getMessage reads
>>>>>>>>> numStackTracesFilledIn
>>>>>>>>>>>>>>>> without synchronization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Alan
>>
>
More information about the hotspot-runtime-dev
mailing list