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 14:57:31 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 9 January 2014 at 14:40:16 UTC, Paulo Pinto wrote:
>> On a game you might miss a few rendering frames, a GC induced
>> delay on a missile tracking system might turn out a bit ugly.
>
> You have GC in games, but you limit it to a small set of 
> objects (<50000?)
> So you can have real time with GC with an upper-bound.
>
> Putting everything under GC is probably not a future proof 
> concept, since memory capacity most likely will increase faster 
> than CPU speed for technical reasons.
>

Sure. As I mentioned in another thread, the other GC enabled 
system programming languages I know, also allow for static, 
global and stack allocation.

And you also have an escape hatch to do manual memory management 
if you really have to.

Namely Oberon(-2), Component Pascal, Active Oberon, Modula-3, 
Sing# and Cedar. Just in case you feel like looking any of them 
up.

While those ended up never being adopted by the industry at 
large, we can draw lessons from the experience of their users. 
Positive features and related flaws.

Currently I am digging up the Mesa/Cedar reports from Xerox PARC.

I think D already has the necessary features, their performance 
just needs to be improved.

--
Paulo