On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
a precise GC will enable data with isolated or immutable
indirections to
be safely moved between threads
I think you could in any case. What precise allows is to copy
object during collection if there is no conservative pointers to
the object, of course.
I would focus on a generational GC first for two reasons. The
first is that you can delay the scans of the later gens if the
Gen0 (nursery) has enough space, so for a lot of programs it
would result in a significant cut-down in collection times.
This is like saying that having a large heap will allow you to
cut-down
collection time. The reason gen0 is fast is that it's mostly dead
and you limit the amount of memory Gen0 scans to that of live set
in Gen0 heap + remebered set in old gen.
It has nothing to do with delaying the scan, in fact Gen0 scans
are way more frequent then scans of a simple single-gen GC.
The second is that you still typically have to stop the
execution of the thread on the Gen0 collection (the objects
most likely to be hot).
If your Gen0 collector is Stop the World, like all of Java
collectors except for the most recent ones - ZGC and Shenandoah.
Ironically both are not generational :)
So with a non-generational concurrent collector you have to
stop the thread for the entirety of the scan,
False again. Any "mostly" concurrent GC can scan with a super
small pause that is typically used only to mark stacks of
Threads. See also the 2 collectors I mentioned.
Go's GC is also non-generational (and SUUUPER popular) to put the
last nail in the coffin of "I need generational GC because you
can't do X without it?".
because you have no way to know which objects are hot and which
are cold.
Why would that stop collector? There is no need to know what is
hot, and garbage is always cold.
