8034761: Remove the do_code_roots parameter from process_strong_roots
jon.masamitsu at oracle.com
Wed Feb 12 18:14:15 PST 2014
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?
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
>> 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?
>> This cleanup is needed/wanted for G1 Class Unloading.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev