8034761: Remove the do_code_roots parameter from process_strong_roots

[Stefan Karlsson]

On 13/02/14 15:45, Jon Masamitsu wrote:
>
> 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.

Thanks, Jon.

StefanK
>
> 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/56bf5a4d/attachment.htm>