RFR(S): 8233081: C1: PatchingStub for field access copies too much
dean.long at oracle.com
dean.long at oracle.com
Mon Nov 4 18:58:50 UTC 2019
Looks good. If I am reading it right, you also fixed a (latent?) bug in
Sparc by changing the max size return from 7 words to 8 words.
dl
On 10/30/19 8:38 AM, 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