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

[Doerr, Martin]

Hi Tobias,

thanks for the review.

Best regards,
Martin


> -----Original Message-----
> From: Tobias Hartmann <tobias.hartmann at oracle.com>
> Sent: Montag, 4. November 2019 08:33
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR(S): 8233081: C1: PatchingStub for field access copies too
> much
> 
> 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/we
> brev.00/
> >
> >
> >
> > Please review.
> >
> >
> >
> > Best regards,
> >
> > Martin
> >
> >
> >