RFR(S): 8193927: Optimize scanning code for oops.

[Doerr, Martin]

Hi Götz,

yes, thanks. I don't need to see a new webrev for it.

Best regards,
Martin


-----Original Message-----
From: Lindenmaier, Goetz 
Sent: Dienstag, 2. Januar 2018 13:37
To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; hotspot-compiler-dev at openjdk.java.net
Subject: RE: RFR(S): 8193927: Optimize scanning code for oops.

Hi Martin,

I'll add "and not in the oop section" to the comment, does that
help?

Thanks,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin
> Sent: Dienstag, 2. Januar 2018 11:48
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Andrew Haley
> <aph at redhat.com>; hotspot-compiler-dev at openjdk.java.net
> Subject: RE: RFR(S): 8193927: Optimize scanning code for oops.
> 
> Hi,
> 
> I think, ideally, ImmediateOopsEmitted should only be true on x86 and
> maybe zero (where it is pointless).
> 
> If I understand it correctly, only usages of
> oop_Relocation::spec_for_immediate() need it which uses oop_index = 0.
> Other oop_Relocations use the CodeBlob's oop pool and the oops will be
> found there by iterating over "oop* p = oops_begin(); p < oops_end(); p++".
> 
> I think the comment should be a little more precise because every uses
> immediate oops. The point is that the affected ones are not part of the
> CodeBlob's oop pool.
> +   /* Knowing whether oops are emitted to the code cache as immediates */
> \
> +   /* allows to skip walks of the code cache if there are none.        */    \
> 
> So I think the optimization may be nice to have for aarch/arm as well, but
> ARM experts should decide on that.
> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> Sent: Dienstag, 2. Januar 2018 11:04
> To: Andrew Haley <aph at redhat.com>; hotspot-compiler-
> dev at openjdk.java.net
> Subject: RE: RFR(S): 8193927: Optimize scanning code for oops.
> 
> Hi Andrew,
> 
> so I'll leave it as is.  Thanks for checking.
> 
> Best regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: Andrew Haley [mailto:aph at redhat.com]
> > Sent: Dienstag, 2. Januar 2018 10:15
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-compiler-
> > dev at openjdk.java.net
> > Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
> >
> > On 21/12/17 08:30, Lindenmaier, Goetz wrote:
> >
> > > Some platforms don't emit immediate oops to the code. If so, scans
> > > of the code for oops can be skipped.
> > >
> > > Add flag ImmediateOopsEmitted to each platform specifying the
> behavior.
> > > Only search code for immediate oops if this flag is set. Make sure no
> > > oops are emitted to code if the flag is not set.
> > >
> > > @aarch people: should the flag set to 'false' on aarch/arm?  So far it
> > > is true, which defaults to the old behavior.
> >
> > Sure, we emit immediate oops in generated code.
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671