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

[Paulo Pinto]

On Thursday, 9 January 2014 at 13:44:10 UTC, Ola Fosheim Grøstad 
wrote:
> 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.

That could possibly be achieved with a generational parallel GC.


--
Paulo