8034761: Remove the do_code_roots parameter from process_strong_roots

[Stefan Karlsson]

On 12/02/14 20:40, Jon Masamitsu wrote:
>
> On 2/12/2014 1:43 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to remove the do_code_roots parameter from 
>> SharedHeap::process_strong_roots.
>>
>> The changes done are:
>> - Change the code to rely on the ScannningOption so parameter instead 
>> of do_code_roots.
>> - Change GenMarkSweep and G1MarkSweep to adjust the code roots with 
>> the help of process_strong_roots instead of doing it as a separate 
>> phase after process_strong_roots.
>> - Removed the unused FalseClosure.
>>
>> After this patch the adjust phase of the GenMarkSweep and G1MarkSweep 
>> will use the generic code in process_strong_roots, which mark/claim 
>> the nmethods before they are processed. Before the patch these two 
>> Serial Old GC adjust phases skipped the mark/claim part. No 
>> noticeable Serial Old GC time increases were found when this patch 
>> was performance tested.
>
> Does this mean ("adjust phase ...") that the "mark/claim"  does not  
> have any affect
> on later processing?  Or actually does nothing (even though the closures
> are applied)?

I think you answered this in your second mail.

> Which benchmarks did you use for performance testing?

I ran SPECjbb2005 and SPECjvm2008 compiler.compiler, with a low tenuring 
threshold so that we promote more out to the old gen. The benchmarks 
were run with and without -Xcomp and with heap size of 3G and 256m. In 
the different combinations we had around 5000 - 10000 nmethods.

The performance team ran WLS benchmarks and SPECjvm2008. They filled the 
heap heap with a javaagent to make sure that we triggered old GCs more 
often than we usually do. They also saw around 10000 nmethods in their runs.

StefanK

>
> Jon
>>
>> This cleanup is needed/wanted for G1 Class Unloading.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~stefank/8034761/webrev.00/
>>
>> RFE:
>> https://bugs.openjdk.java.net/browse/JDK-8034761
>>
>> thanks,
>> StefanK
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140213/cc009f89/attachment.htm>