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 550266
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: Comment by Laurence
by moondevil on Thu 24th Jan 2013 06:46 UTC in reply to "RE[6]: Comment by Laurence"
moondevil
Member since:
2005-07-08

Another solution used in languages like C#, Modula-3, Oberon family or D, is to allow in a very controlled way to request and release memory from the runtime.

But this is only allowed in system/unsafe code blocks.

Reply Parent Score: 2

RE[8]: Comment by Laurence
by Neolander on Thu 24th Jan 2013 07:39 in reply to "RE[7]: Comment by Laurence"
Neolander Member since:
2010-03-08

Another solution used in languages like C#, Modula-3, Oberon family or D, is to allow in a very controlled way to request and release memory from the runtime.

But this is only allowed in system/unsafe code blocks.

Does it amount to disabling automatic GC and thus forcing garbage collection to run only when you want it to, like gc.disable() in Python ?

Or is it a more in-depth alteration of the language mechanics, that requires extensive programming practice changes, such as disabling garbage collection altogether and thus making all standard library code which relies on it fail ?

Edited 2013-01-24 07:50 UTC

Reply Parent Score: 1

RE[9]: Comment by Laurence
by moondevil on Thu 24th Jan 2013 08:18 in reply to "RE[8]: Comment by Laurence"
moondevil Member since:
2005-07-08

Is it kind of like acquiring a mutex that forbids the GC from running and thus forces it to behave exactly as you want it to ?


Well, first of all this type of code is relegated to such blocks, because manual memory management is usually used together with other tricks, so in safer languages you want to minimize its use unless it is really required.

Usually this is memory that is outside GC knowledge so it should be handled with care and not escape unsafe code.

In most languages with such features you can use compiler switches to prevent compilation of unsafe code.

Here are some links about how to do this

Modula-3
http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_7Uns...

C#
http://msdn.microsoft.com/en-us/library/system.intptr.topointer.asp...

D
http://dlang.org/memory.html

Go

A bit cumbersome, but you can do it via cgo
http://golang.org/cmd/cgo/

Oberon
Oberon's case is special, since the GC is implemented at the kernel level. So only a small piece of code, written in Assembly does manual memory management.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.1857

But for the cases where the language is implemented on top of other operating systems, there are language extensions to mark pointers as not being tracked by GC.

Reply Parent Score: 2

RE[8]: Comment by Laurence
by henderson101 on Fri 25th Jan 2013 13:19 in reply to "RE[7]: Comment by Laurence"
henderson101 Member since:
2006-05-30

Another solution used in languages like C#, Modula-3, Oberon family or D, is to allow in a very controlled way to request and release memory from the runtime.


I remember a co-worker driving himself insane with CF1.0 and SqlClient. Somewhere is wasn't releasing memory correctly and basically using up all the free memory on the device. In the end, he put a number of explicit GC.Collect()'s in the code. It was a documented bug, I think it was fixed in CF2.0, but we had to use 1.0 because the devices being used didn't support 2.0 (IIRC, they were mixed, some were running PocketPC 2000 or something like that... plus most had bugger all RAM.)

Reply Parent Score: 2