Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Thursday, 9 January 2014 at 10:14:08 UTC, Benjamin Thaut wrote:
> If requested I can make a list with all language features / 
> decisions so far that prevent the implementation of a state of 
> the art GC.

I am also interested in this, so that I can avoid those 
constructs.

I am in general in agreement with you. I think regular ownership 
combined with a segmented GC that only scan pointers to a 
signified GC type would not be such a big deal and could be a 
real bonus. With whole program analysis you could then reject a 
lot of the branches you otherwise have to follow and you would 
not have to stop threads that cannot touch those GC types. Of 
course, you would then avoid using generic pointers. So, you 
might not need an advanced GC, just partition the GC scan better.

Scanning stacks could be really fast if you know the call order 
of stack frames (and you have that opportunity with whole program 
analysis): e.g.: top frame is a(), but only b() and c() can call 
a() and b() and c() have same stack frame size and cannot hold 
pointers to GC object => skip over a() and b/c() in one go.

It doesn't matter much if the GC takes even 20% of your 
efficiency away, as long as it doesn't lock you down for more 
than 1-2 milliseconds: that's <4 million cycles for a single 
core. If you need 25 cycles per pointer you can scan <80.000 
pointers per core. So if the search space can be partitioned in a 
way that makes that possible by not following all pointers, then 
the GC would be fine. 100.000 cache lines = 3.2MB which is not 
too horrible either.

I'd rather have 1000% less efficiency in the GC by having 
frequent GC calls than 400% more latency less frequently.