RFR: 8265484: Fix up TRAPS usage in GenerateOopMap::compute_map and callers [v3]

Dean Long dlong at openjdk.java.net
Fri Apr 23 00:48:27 UTC 2021


On Thu, 22 Apr 2021 07:31:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If compute_map encounters malformed bytecode, or an OOM condition then it can raise a LinkageError to be thrown in regular JavaThreads, and this is reflected in the use of TRAPS in a couple of methods. But for non-JavaThreads, and compiler threads, the occurrence of such an error is treated as a fatal error and we abort the VM.
>> 
>> In addition, most of the callers of compute_map actually use the CATCH macro, which just clears the exception and will abort a non-product VM.
>> 
>> This use of TRAPS is a problem for the change to convert TRAPS to JavaThread, because these methods are called by non-JavaThreads. To address this we change compute_map to create, but not throw, the exception and return a bool indicating whether an error occurred, and the caller can then choose to throw the exception itself. 
>> 
>> Testing: tiers 1-3
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace assert(false) with fatal()
>   
>   After a number of people examined this code it was decided that the best approach was to re-instate
>   the call to fatal() in product builds, that would have been present in the CATCH macro, until recent
>   changes converted that to an assert(). The code here is not prepared to continue if compute_map fails
>   so we have to abort. Such failures are extremely unlikely (metaspace or resource-area OOM, or malformed
>   bytecode where verification has been disabled).

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3580


More information about the hotspot-compiler-dev mailing list