RFR(S): Merge GC thread pools

[Roman Kennke]

Am Montag, den 13.02.2017, 15:47 -0500 schrieb Zhengyu Gu:
> On 02/13/2017 03:31 PM, Roman Kennke wrote:
> 
> > Am Montag, den 13.02.2017, 15:28 -0500 schrieb Zhengyu Gu:
> > > On 02/13/2017 03:20 PM, Roman Kennke wrote:
> > > 
> > > > For mark-compact, you setup workers once for marking and then
> > > > again
> > > > for
> > > > the rest? Any specific reason for that? Else I think it should
> > > > be
> > > > set
> > > > up once for everything in mark-compact.
> > > 
> > > The rest phases are proportional to live set size, which is
> > > obtained
> > > after marking.
> > > 
> > > Maybe I missed something, what other factors should be considered
> > > for
> > > phase 2, 3, and 4?
> > 
> > Maybe I don't understand all of it yet.
> > 
> > To me it looks like you calculate num-threads for init-marking,
> > which
> > is meant for scanning roots real quick. But then it's used for
> > marking
> > all the heap, which is, as you say, LDS-size dependend. I would
> > throw a
> > generous number of threads on it. ;-)
> 
> I am not saying that I got heuristics right :-) and probably not.
> 
> But for these 3 phases, that only factor, I can see, is LDS size.

As is the case for phase#1. (except that we don't know yet what the
actual LDS is...)

> However, we can tune size/worker ratio if it the number comes out
> low.

Ok then.

Roman