RFR(S) 8190817: deopt special-case for _return_register_finalizer is confusing and leads to bugs

dean.long at oracle.com dean.long at oracle.com
Fri Nov 17 20:01:05 UTC 2017


Thanks Dmitrij!  I have updated the test as well.  Good suggestion.

dl

http://cr.openjdk.java.net/~dlong/8190817/webrev.1/


On 11/17/17 11:15 AM, Dmitrij Pochepko wrote:
> Hi,
>
> I've built clean fastdebug build with this patch and run 
> compiler/runtime/Test8168712.java on AArch64 (ThunderX) and it passed.
>
> Please note that this test can't be run on AArch64 by default because 
> of @requires tag. I had to update this tag first. Btw: I wonder if it 
> should be also updated as a part of this patch?
>
>
> I also took a look at Aarch64-specific change and it looks good to 
> me(not a Reviewer).
>
>
> Thanks,
>
> Dmitrij
>
>
> On 13.11.2017 20:32, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8190817
>>
>> http://cr.openjdk.java.net/~dlong/8190817/webrev/
>>
>> This fix replaces the problematic use of 
>> _normal_table.entry(Bytecodes::_return).entry(vtos) as a 
>> deoptimization entry point with a proper deopt entry point returned 
>> by deopt_reexecute_return_entry().  This is needed to handle the 
>> situation where compiled code is calling register_finalizer() and 
>> gets deoptimized.
>>
>> I also noticed that we generate duplicate entry points unnecessarily, 
>> so I cleaned that up at the same time.
>>
>> aarch64/ppc64/s390 folks, please check that 
>> compiler/runtime/Test8168712.java still passes.
>>
>> dl
>>
>



More information about the hotspot-compiler-dev mailing list