RFR(XS) 8075118: JVM stuck in infinite loop during verification
harold seigel
harold.seigel at oracle.com
Tue Mar 17 19:13:53 UTC 2015
Hi Dean,
I see your point. Instead of this fix, I may try instead keeping a
separate list of handlers that have been scanned and not push a handler
on the stack if it has already been scanned.
Harold
On 3/17/2015 3:06 PM, Dean Long wrote:
> Hi Harold. How does this change guarantee that the catch handler is
> always scanned? If it was an island of code surrounded by gotos, so
> that it is only reachable through the handler, then it looks like it
> will now be skipped entirely.
>
> dl
>
> On 3/17/2015 11:37 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this fix for bug JDK-8075118. The code being verified
>> contained a TRY block whose catch handler was inside the TRY block.
>> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY
>> block and then scans the bytecodes in the TRY block's handler and
>> then scans the bytecodes of its handler's handler, etc. Since, the
>> bytecodes in the handler and the bytecode's handler's handler were
>> the same, it just kept scanning the same bytecodes over and over.
>>
>> The fix prevents re-scanning a handler's bytecodes if they are
>> contained in the TRY block.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118
>>
>> The fix was tested with the test program provided by the bug, the JCK
>> Lang, VM, and API tests, the testbase quick and split verifier tests,
>> and with the JTREG hotspot tests.
>>
>> Thanks! Harold
>
More information about the hotspot-runtime-dev
mailing list