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