[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-compiler-dev
Subject:    RFR(S): 8233081: C1: PatchingStub for field access copies too much
From:       "Doerr, Martin" <martin.doerr () sap ! com>
Date:       2019-10-30 15:38:31
Message-ID: VI1PR0201MB24798B4FFDCAEE55104A74279A600 () VI1PR0201MB2479 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]

Hi,

I'd like to fix an issue in C1's PatchingStub implementation for "access_fi=
eld_id".
We had noticed that the code in the template exceeded the 255 byte limitati=
on 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 NativeMovR=
egMem.
x86 has next_instruction_address() which could in theory be used, but I not=
iced 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 dete=
rmining 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

[prev in list] [next in list] [prev in thread] [next in thread]