RFR (S): Reset bitmaps in MarkCompact should use parallel threads

[Aleksey Shipilev]

On 11/02/2016 08:20 PM, Roman Kennke wrote:
>>   3. VMThread (!): Reset prev bitmap
> 
> Duh. How did that happen?

There was a TODO that we want to use workers to clear this bitmap. So
here we are :)

>> Aside: At some point, we'd have to see if we can decouple
>> SHConcurrentMark enough to use Parallel, not Concurrent, threads for
>> MarkCompact cycle.
> 
> I argued with Christine a bunch of times whether or not we should just
> use a single thread pool, and simply change the number of threads used
> on demand. Would you see any benefit in that? Or disadvantage?

I think having a single thread pool simplifies things for us.

As long as the same observed behavior for Concurrent/Parallel thread
count stays. E.g. having a machine of 10 cores, I might want to tune
down mutator to have 4 cores, concurrent GC to have other 6, and
parallel GC, if it happens to run and stop my mutator, to have all 10!
Now, I can do that by saying -XX:ParallelGCThreads=10
-XX:ConcurrentGCThreads=6.

Thanks,
-Aleksey