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

[Roman Kennke]

While you are looking at this, you could also check whether or not it
makes a difference if we used BitMap::clear_large_range() (which uses
memset) instead of BitMap::clear_range() (which uses a simple for-loop) 
:-) I strongly suspect that memset might be faster. Requires some
additions to CMBitMap class though.

Roman

Am Mittwoch, den 02.11.2016, 20:31 +0100 schrieb 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
>