Request for review (L) - 6593758

Ramki Ramakrishna y.s.ramakrishna at oracle.com
Thu Oct 27 23:13:17 PDT 2011



On 10/27/2011 10:28 PM, poonam.bajaj at oracle.com wrote:
> ...
>
> On 10/28/2011 12:11 AM, Jon Masamitsu wrote:
>>
>>
>> On 10/27/11 02:49, poonam.bajaj at oracle.com wrote:
>>> ...
>>> - concurrentMarkSweepGeneration.cpp, line 5551
>>>
>>> Here, flag UseDynamicNumberOfGCThreads can be checked to make the 
>>> decision if we need to use 'active_workers', the way you have done 
>>> it in collectionSetChooser.cpp at line 258
>>
>> What I meant to say was that at 5551 I wanted to use whatever value of
>> active_workers that was calculated when calc_active_workers() was last
>> called.  That would likely be the value at the last young GC or at the
>> initial-mark.  I had at one point thought there was a dependency between
>> the number of GC threads used in a young collection and the number used
>> in the remark.  I've been told that is not the case but have not proven
>> that to myself and since lots of testing has already been done with this
>> code, I left it unchanged with a note to myself to look at it again.

If there is a dependency, it is merely an artifact of the implementation
and should, in principle not be there -- after all the optimal 
parallelism for
scavenge could well be different from what's optimal for parallel remark.
Thus, it makes sense to control the two independently. Leaving it as is
for now is quite fine, with any remaining dependencies to be removed at
a later time when more policy/tuning is done.

>>
>> Did I understand your comment?
>
> Yes.
>
> So, if the active_workers was not set then we will not calculate the
> active_workers with calc_active_workers() again and instead
> use ParallelGCThreads.

Yes.

>
> Where in the code are the active_workers set for initial-marking
> phase?

Unfortunately, CMS initial mark is currently single-threaded, so it's 
likely there isn't any code
to change (to set #active workers) there.

>
>>>
>>> - concurrentMarkSweepGeneration.cpp at line 5899
>>>
>>> same as above comment
>>
>> My intent was to set a number of GC workers for a
>> collection (minor or full or initial-mark or remark)
>> so didn't want to change within the collection (Reference
>> processing being done as part of the remark) so that's
>> why I'm here just using what has previously been
>> calculated.
>>
> Ok.

Once again, as has been discussed in perhaps a different context,
there is no reason that the optimal # for parallel reference processing
should be identical to that used for either parallel remark or
for scavenge. Thus (in general) it is possible that optimal settings
for all three could be quite different. (It could well be that they turn out
to be the same, but we should not assume for the purposes of an
initial design that they should be the same.) Once again, lacking any 
good policy/tuning
at the moment, it is fine to leave the code as is in Jon's webrev, with
those dependencies removed at a later point when optimal/policy/tuning
is done.

>
> ...
>>>> http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/
>>>>

-- ramki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20111027/3ff83c7d/attachment-0001.html 


More information about the hotspot-gc-dev mailing list