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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
Hi,

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.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/

Best regards,
  Goetz
Reply | Threaded
Open this post in threaded view
|

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

Volker Simonis
Hi Goetz,

this seems to be a little strange flag for me because it can not be
used for really controlling the emission of immediate oops. It only
records if a platform can emit immediate oops or not.

So wouldn't it be better to either have a flag like
"EmitImmediateOops" which really controls the emission of immediate
oops. I.e. it could be used to switch the emission of immediate oops
off even on platforms which usually do that. Or if that's not
reasonable, don't introduce a new flag at all but just declare a
platform specific method instead which returns if immediate oops can
be emitted on that platform or not.

Thanks,
Volker

On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz
<[hidden email]> wrote:

> Hi,
>
> 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.
>
> Please review this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/
>
> Best regards,
>   Goetz
Reply | Threaded
Open this post in threaded view
|

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

Aleksey Shipilev-4
In reply to this post by Lindenmaier, Goetz
On 12/21/2017 09:30 AM, Lindenmaier, Goetz wrote:
> 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.

From the description, it seems to be equivalent to ScavengeRootsInCode=0?

  diagnostic(intx, ScavengeRootsInCode, 2,                                  \
          "0: do not allow scavengable oops in the code cache; "            \
          "1: allow scavenging from the code cache; "                       \
          "2: emit as many constants as the compiler can see")              \
          range(0, 2)                                                       \

If so, don't we want to reuse that? In fact, IIRC code cache scanning code would even skip
registering nmethods for scan in ScavengeRootsInCode=0.

Thanks,
-Aleksey


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
Hi Aleksey,

If I understand correctly, ScavengeRootsInCode=0 means there
are no oops in the nmethod.
What I am optimizing is that there are no oops in the code as
immediates, there still are some in the constant section of the
nmethod.

Also, ScavengeRootsInCode is forced to >0 in arguments.cpp,
which makes no sense in my case.  On ppc/s390 ... you need not
do the two walks skipped in nmethod.cpp in any case.

Best regards,
  Goetz.



> -----Original Message-----
> From: Aleksey Shipilev [mailto:[hidden email]]
> Sent: Donnerstag, 21. Dezember 2017 16:23
> To: Lindenmaier, Goetz <[hidden email]>; hotspot-compiler-
> [hidden email]
> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>
> On 12/21/2017 09:30 AM, Lindenmaier, Goetz wrote:
> > 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.
>
> From the description, it seems to be equivalent to ScavengeRootsInCode=0?
>
>   diagnostic(intx, ScavengeRootsInCode, 2,                                  \
>           "0: do not allow scavengable oops in the code cache; "            \
>           "1: allow scavenging from the code cache; "                       \
>           "2: emit as many constants as the compiler can see")              \
>           range(0, 2)                                                       \
>
> If so, don't we want to reuse that? In fact, IIRC code cache scanning code
> would even skip
> registering nmethods for scan in ScavengeRootsInCode=0.
>
> Thanks,
> -Aleksey

Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
In reply to this post by Volker Simonis
Hi Volker,

you are right, encapsulating it in a function is a better solution:
http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.02

Making it switchable would require changes to x86, which is
not my scope.

Best regards,
  Goetz.

> -----Original Message-----
> From: Volker Simonis [mailto:[hidden email]]
> Sent: Donnerstag, 21. Dezember 2017 14:51
> To: Lindenmaier, Goetz <[hidden email]>
> Cc: [hidden email]
> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>
> Hi Goetz,
>
> this seems to be a little strange flag for me because it can not be
> used for really controlling the emission of immediate oops. It only
> records if a platform can emit immediate oops or not.
>
> So wouldn't it be better to either have a flag like
> "EmitImmediateOops" which really controls the emission of immediate
> oops. I.e. it could be used to switch the emission of immediate oops
> off even on platforms which usually do that. Or if that's not
> reasonable, don't introduce a new flag at all but just declare a
> platform specific method instead which returns if immediate oops can
> be emitted on that platform or not.
>
> Thanks,
> Volker
>
> On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz
> <[hidden email]> wrote:
> > Hi,
> >
> > 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.
> >
> > Please review this change. I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/
> >
> > Best regards,
> >   Goetz
Reply | Threaded
Open this post in threaded view
|

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

Volker Simonis
Hi Goetz,

looks good now! Thanks for doing the change.

I'm pretty sure you could return 'false' on zero as well as zero
doesn't generate any code at all.

Regards,
Volker


On Thu, Dec 21, 2017 at 5:18 PM, Lindenmaier, Goetz
<[hidden email]> wrote:

> Hi Volker,
>
> you are right, encapsulating it in a function is a better solution:
> http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.02
>
> Making it switchable would require changes to x86, which is
> not my scope.
>
> Best regards,
>   Goetz.
>
>> -----Original Message-----
>> From: Volker Simonis [mailto:[hidden email]]
>> Sent: Donnerstag, 21. Dezember 2017 14:51
>> To: Lindenmaier, Goetz <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>>
>> Hi Goetz,
>>
>> this seems to be a little strange flag for me because it can not be
>> used for really controlling the emission of immediate oops. It only
>> records if a platform can emit immediate oops or not.
>>
>> So wouldn't it be better to either have a flag like
>> "EmitImmediateOops" which really controls the emission of immediate
>> oops. I.e. it could be used to switch the emission of immediate oops
>> off even on platforms which usually do that. Or if that's not
>> reasonable, don't introduce a new flag at all but just declare a
>> platform specific method instead which returns if immediate oops can
>> be emitted on that platform or not.
>>
>> Thanks,
>> Volker
>>
>> On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz
>> <[hidden email]> wrote:
>> > Hi,
>> >
>> > 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.
>> >
>> > Please review this change. I please need a sponsor.
>> > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/
>> >
>> > Best regards,
>> >   Goetz
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
Hi Volker,

> looks good now! Thanks for doing the change.
thanks!

> I'm pretty sure you could return 'false' on zero as well as zero
> doesn't generate any code at all.
If there are no nmethods, the returned value of the function
is pointless on zero.

Best regards,
  Goetz.



>
> Regards,
> Volker
>
>
> On Thu, Dec 21, 2017 at 5:18 PM, Lindenmaier, Goetz
> <[hidden email]> wrote:
> > Hi Volker,
> >
> > you are right, encapsulating it in a function is a better solution:
> > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.02
> >
> > Making it switchable would require changes to x86, which is
> > not my scope.
> >
> > Best regards,
> >   Goetz.
> >
> >> -----Original Message-----
> >> From: Volker Simonis [mailto:[hidden email]]
> >> Sent: Donnerstag, 21. Dezember 2017 14:51
> >> To: Lindenmaier, Goetz <[hidden email]>
> >> Cc: [hidden email]
> >> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
> >>
> >> Hi Goetz,
> >>
> >> this seems to be a little strange flag for me because it can not be
> >> used for really controlling the emission of immediate oops. It only
> >> records if a platform can emit immediate oops or not.
> >>
> >> So wouldn't it be better to either have a flag like
> >> "EmitImmediateOops" which really controls the emission of immediate
> >> oops. I.e. it could be used to switch the emission of immediate oops
> >> off even on platforms which usually do that. Or if that's not
> >> reasonable, don't introduce a new flag at all but just declare a
> >> platform specific method instead which returns if immediate oops can
> >> be emitted on that platform or not.
> >>
> >> Thanks,
> >> Volker
> >>
> >> On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz
> >> <[hidden email]> wrote:
> >> > Hi,
> >> >
> >> > 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.
> >> >
> >> > Please review this change. I please need a sponsor.
> >> > http://cr.openjdk.java.net/~goetz/wr17/8193927-
> oopsInCode/webrev.01/
> >> >
> >> > Best regards,
> >> >   Goetz
Reply | Threaded
Open this post in threaded view
|

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

Andrew Haley
In reply to this post by Lindenmaier, Goetz
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
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
Hi Andrew,

so I'll leave it as is.  Thanks for checking.

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew Haley [mailto:[hidden email]]
> Sent: Dienstag, 2. Januar 2018 10:15
> To: Lindenmaier, Goetz <[hidden email]>; hotspot-compiler-
> [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

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

Doerr, Martin
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:[hidden email]] On Behalf Of Lindenmaier, Goetz
Sent: Dienstag, 2. Januar 2018 11:04
To: Andrew Haley <[hidden email]>; [hidden email]
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:[hidden email]]
> Sent: Dienstag, 2. Januar 2018 10:15
> To: Lindenmaier, Goetz <[hidden email]>; hotspot-compiler-
> [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
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 <[hidden email]>; Andrew Haley
> <[hidden email]>; [hidden email]
> 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-
> [hidden email]] On Behalf Of Lindenmaier, Goetz
> Sent: Dienstag, 2. Januar 2018 11:04
> To: Andrew Haley <[hidden email]>; hotspot-compiler-
> [hidden email]
> 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:[hidden email]]
> > Sent: Dienstag, 2. Januar 2018 10:15
> > To: Lindenmaier, Goetz <[hidden email]>; hotspot-compiler-
> > [hidden email]
> > 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
Reply | Threaded
Open this post in threaded view
|

RE: 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 <[hidden email]>; Andrew Haley <[hidden email]>; [hidden email]
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 <[hidden email]>; Andrew Haley
> <[hidden email]>; [hidden email]
> 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-
> [hidden email]] On Behalf Of Lindenmaier, Goetz
> Sent: Dienstag, 2. Januar 2018 11:04
> To: Andrew Haley <[hidden email]>; hotspot-compiler-
> [hidden email]
> 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:[hidden email]]
> > Sent: Dienstag, 2. Januar 2018 10:15
> > To: Lindenmaier, Goetz <[hidden email]>; hotspot-compiler-
> > [hidden email]
> > 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
Reply | Threaded
Open this post in threaded view
|

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

Andrew Haley
In reply to this post by Doerr, Martin
On 02/01/18 10:48, Doerr, Martin wrote:

> 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++".

Ah, OK.  We don't use oop_Relocation::spec_for_immediate(), so you're
right, this is x86 only.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
Hi,

I please need a sponsor.

I changed the flag on both arm platforms and edited the comment:
http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.03/

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew Haley [mailto:[hidden email]]
> Sent: Dienstag, 2. Januar 2018 14:39
> To: Doerr, Martin <[hidden email]>; Lindenmaier, Goetz
> <[hidden email]>; [hidden email]
> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>
> On 02/01/18 10:48, Doerr, Martin wrote:
>
> > 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++".
>
> Ah, OK.  We don't use oop_Relocation::spec_for_immediate(), so you're
> right, this is x86 only.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

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

Doerr, Martin
Hi Götz,

this looks good, now.

Thanks and best regards,
Martin


-----Original Message-----
From: Lindenmaier, Goetz
Sent: Dienstag, 2. Januar 2018 15:21
To: Andrew Haley <[hidden email]>; Doerr, Martin <[hidden email]>; [hidden email]
Subject: RE: RFR(S): 8193927: Optimize scanning code for oops.

Hi,

I please need a sponsor.

I changed the flag on both arm platforms and edited the comment:
http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.03/

Best regards,
  Goetz.

> -----Original Message-----
> From: Andrew Haley [mailto:[hidden email]]
> Sent: Dienstag, 2. Januar 2018 14:39
> To: Doerr, Martin <[hidden email]>; Lindenmaier, Goetz
> <[hidden email]>; [hidden email]
> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>
> On 02/01/18 10:48, Doerr, Martin wrote:
>
> > 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++".
>
> Ah, OK.  We don't use oop_Relocation::spec_for_immediate(), so you're
> right, this is x86 only.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

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

Vladimir Kozlov
In reply to this post by Lindenmaier, Goetz
Hi Goetz,

I started testing. Will push it if testing pass.

Regards,
Vladimir

On 1/2/18 6:20 AM, Lindenmaier, Goetz wrote:

> Hi,
>
> I please need a sponsor.
>
> I changed the flag on both arm platforms and edited the comment:
> http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.03/
>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: Andrew Haley [mailto:[hidden email]]
>> Sent: Dienstag, 2. Januar 2018 14:39
>> To: Doerr, Martin <[hidden email]>; Lindenmaier, Goetz
>> <[hidden email]>; [hidden email]
>> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>>
>> On 02/01/18 10:48, Doerr, Martin wrote:
>>
>>> 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++".
>>
>> Ah, OK.  We don't use oop_Relocation::spec_for_immediate(), so you're
>> right, this is x86 only.
>>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

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

Lindenmaier, Goetz
Hi Vladimir,

thanks for sponsoring!

Best regards,
  Goetz.

> -----Original Message-----
> From: Vladimir Kozlov [mailto:[hidden email]]
> Sent: Mittwoch, 3. Januar 2018 00:45
> To: Lindenmaier, Goetz <[hidden email]>; Andrew Haley
> <[hidden email]>; Doerr, Martin <[hidden email]>; hotspot-
> [hidden email]
> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
>
> Hi Goetz,
>
> I started testing. Will push it if testing pass.
>
> Regards,
> Vladimir
>
> On 1/2/18 6:20 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I please need a sponsor.
> >
> > I changed the flag on both arm platforms and edited the comment:
> > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.03/
> >
> > Best regards,
> >    Goetz.
> >
> >> -----Original Message-----
> >> From: Andrew Haley [mailto:[hidden email]]
> >> Sent: Dienstag, 2. Januar 2018 14:39
> >> To: Doerr, Martin <[hidden email]>; Lindenmaier, Goetz
> >> <[hidden email]>; [hidden email]
> >> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops.
> >>
> >> On 02/01/18 10:48, Doerr, Martin wrote:
> >>
> >>> 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++".
> >>
> >> Ah, OK.  We don't use oop_Relocation::spec_for_immediate(), so you're
> >> right, this is x86 only.
> >>
> >> --
> >> Andrew Haley
> >> Java Platform Lead Engineer
> >> Red Hat UK Ltd. <https://www.redhat.com>
> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671