RFR(S): 8233081: C1: PatchingStub for field access copies too much

Tobias Hartmann tobias.hartmann at oracle.com
Mon Nov 4 07:33:06 UTC 2019


Hi Martin,

nice cleanup, x86/Sparc looks good to me.

Best regards,
Tobias

On 30.10.19 16:38, Doerr, Martin wrote:
> Hi,
> 
>  
> 
> I'd like to fix an issue in C1's PatchingStub implementation for "access_field_id".
> 
> We had noticed that the code in the template exceeded the 255 byte limitation when switching on
> VerifyOops on PPC64.
> 
> I'd like to improve the situation for all platforms.
> 
>  
> 
> More detailed bug description:
> 
> https://bugs.openjdk.java.net/browse/JDK-8233081
> 
>  
> 
> I need a function to determine how many bytes are needed for the NativeMovRegMem.
> 
> x86 has next_instruction_address() which could in theory be used, but I noticed that it's dead code
> which is no longer correct.
> 
> Is it ok to remove it?
> 
> I’d also like to remove the constant instruction_size from NativeMovRegMem because it’s not constant.
> 
> I'd prefer to introduce num_bytes_to_end_of_patch() for the purpose of determining how many bytes to
> copy for the "access_field_id" PatchingStub.
> 
> We can factor out the offset computation from offset() and set_offset() and reuse it. This enforces
> consistency.
> 
>  
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8233081_C1_access_field_patching/webrev.00/
> 
>  
> 
> Please review.
> 
>  
> 
> Best regards,
> 
> Martin
> 
>  
> 


More information about the hotspot-compiler-dev mailing list