8034761: Remove the do_code_roots parameter from process_strong_roots

[Jon Masamitsu]

On 2/12/14 11:51 PM, Stefan Karlsson wrote:
> On 13/02/14 03:14, Jon Masamitsu wrote:
>> Stefan,
>>
>> I understand now that the same work is being
>> done (maybe in a different place) and that
>> the  amount of extra work being
>> done (the call to test_set_oops_do_mark())
>> will scale with the number of nmethods.
>>
>> Is that correct?
>
> Yes, that's correct.
>

Ok.

Change looks good.  Thanks for an explanation of
the performance measurements done.

Jon

> StefanK
>>
>> Jon
>>
>> On 2/12/2014 11:40 AM, 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)?  Which benchmarks did you use for performance testing?
>>>
>>> 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/0d840df5/attachment.htm>