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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Dec 21 15:49:23 UTC 2017


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:shade at redhat.com]
> Sent: Donnerstag, 21. Dezember 2017 16:23
> 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 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



More information about the hotspot-compiler-dev mailing list