RFR (S): 8230395: Code checks for NULL value returned from NEW_C_HEAP_ARRAY which can not happen
David Holmes
david.holmes at oracle.com
Thu Sep 19 11:59:28 UTC 2019
Hi Leo,
Thanks for looking at this.
On 19/09/2019 9:31 pm, Leo Korinth wrote:
> On 19/09/2019 07:57, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230395
>> webrev: http://cr.openjdk.java.net/~dholmes/8230395/webrev/
>>
>> First, thanks to Leo for going through and finding the places that
>> needed to be fixed. I didn't go looking for others.
>
> I tried to find all places for NEW_C_HEAP_ARRAY. Thanks for not only
> fixing the problematic use but also doing some cleanup around it! It was
> not obvious for me where to remove the check and where to add
> RETURN_NULL, so thank you for doing this.
Noticing that we were new'ing CHeapObj made it clearer in the perf code
that there was no point using RETURN_NULL, as we would abort on the new
anyway. :) Otherwise it's all pretty subjective.
Cheers,
David
>>
>> For the most part I have deleted the NULL checks. A few notes:
>>
>> - changed to NEW_C_HEAP_ARRAY_RETURN_NULL in a couple of places where
>> it was more consistent with the general recoverability approach of the
>> code in question (and did the opposite change in one place)
>> - for the "perf" changes I also noticed that we were checking for NULL
>> after doing "new SomeCHeapObj()" which also cannot return NULL, so
>> removed those NULL checks too
>> - the JVMCI thread counter changes became a bit more extensive due to
>> the fact a boolean method could now only every return true. So it was
>> changed to void and that had to filter all the way back up to the
>> JVMCI Java API. The JVMCI/Graal folk need to approve this
>>
>> Testing: tier 1-3 sanity tests (in progress)
>>
>> Thanks,
>> David
>
> This change looks good to me (I am not a reviewer).
>
> Thanks,
> Leo
More information about the hotspot-compiler-dev
mailing list