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

[Doerr, Martin]

Hi Dean,

thank you for the review.

You can call it a bug fix for SPARC, but I'd rather call it removal of dead an incorrect code.

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of dean.long at oracle.com
> Sent: Montag, 4. November 2019 19:59
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S): 8233081: C1: PatchingStub for field access copies too
> much
> 
> 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/we
> brev.00/
> >
> > Please review.
> >
> > Best regards,
> > Martin
> >