RFR(XS) 8075118: JVM stuck in infinite loop during verification
harold seigel
harold.seigel at oracle.com
Thu Mar 19 01:26:20 UTC 2015
Hi Dean,
Thanks for your help.
Harold
On 3/18/2015 9:13 PM, Dean Long wrote:
> Hi Harold, this looks good now. Thanks for adding the
> IsolatedHandlerInTry test.
>
> dl
>
> On 3/18/2015 7:32 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this new fix for JDK-8075118. This fix keeps a list of
>> catch handlers that have been scanned to prevent the infinite loop
>> described below. This change removes the previous fix's check if
>> the catch handler is inside the TRY block, preventing the problem
>> that Dean brought up.
>>
>> The webrev includes 2 tests, HandlerInTry.jasm, that is based on the
>> test case provided in the bug, that caused the infinite loop. And,
>> IsolatedHandlerInTry.jasm, that tests a catch handler that is inside
>> its TRY block but only reachable as a handler.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/
>>
>> The new 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, the JTREG hotspot tests, and with the two tests described above.
>>
>> Thanks, 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