Linked by kragil on Wed 23rd Jan 2013 20:26 UTC
Google "Native Client enables Chrome to run high-performance apps compiled from your C and C++ code. One of the main goals of Native Client is to be architecture-independent, so that all machines can run NaCl content. Today we're taking another step toward that goal: our Native Client SDK now supports ARM devices, from version 25 and onwards."
Thread beginning with comment 550426
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[10]: Comment by Laurence
by moondevil on Fri 25th Jan 2013 08:02 UTC in reply to "RE[9]: Comment by Laurence"
Member since:

This means that you can release memory back at a pace that is dictated by yourself rather than the GC, a pace which would minimize 'latency bubbles'.

Also, given that you control exactly which memory is to be released back at any specific time, you can limit the non-deterministic impact of the 'free' call.

You think that you control when memory is returned.

Actually what happens in most languages with manual memory management is that you release the memory in the language runtime, but the runtime does not release it back to the operating system. There are heuristics in place to only return memory in blocks of certain size.

Additionally depending how you allocate/release memory you can have issues with memory fragmentation.

So in the end you end up having as much control as with a GC based language.

This is why in memory critical applications, developers end up writing their own memory manager.

But these are very special cases, and in most system languages with GC, there are also mechanisms available to perform that level of control if really needed.

So you get the memory safety of using a GC language, with the benefit to control the memory if you really need to.

As a side note, reference counting is also GC in computer science speak and with it you also get determinist memory usage.

Reply Parent Score: 2