A benchmark, mostly GC

Robert Jacques sandford at jhu.edu
Wed Dec 14 19:52:00 PST 2011


On Wed, 14 Dec 2011 02:38:17 -0500, Paulo Pinto <pjmlp at progtools.org> wrote:

> No need to reference Wikipedia articles, I am well aware of the implementation specifics.
>
> Still Singularity was just an example. I can pinpoint several other operating systems done in GC enabled systems languages, where besides the given language, only assembly was used, Native Oberon is such an OS for example.
>
> Many times C and C++ get used in such operating systems because of available tools that speed up development, instead of spending time rewriting them.
>
> I think we will eventually get there as the trend nowadays is that everything is slowly done in GC enabled languages anyway. Even Microsoft and Apple are extending their systems languages (Objective-C and C+) to offer some form of automatic memory management.
>
> --
> Paulo

 From Oberon's FAQ:
I know that the Native Oberon garbage collector is mark-and-sweep, not copying, but does it ever move objects, for instance to compact memory if it becomes excessively fragmented?
A: No, objects are never moved by the Mark/Sweep collector. To avoid fragmentation with a program that continuously allocates memory, call the Garbage collector (Oberon.Collect) from time to time to free unused memory. Avoid calling it too much though, because it does take some milliseconds to run, depending on the number of reachable objects on the heap.


I feel like we are having a bit of a semantic issue. My position is not that GC can't or shouldn't be used by or in systems programming, indeed it should, it's that generally speaking the types of garbage collectors available to high-performance systems languages are not the same as those available to more restrictive languages such as JAVA and C#.

P.S.
It seems my GC education is a bit out of date as there has been work into precise garbage collection for C in recent years (i.e. Magpie). I didn't see any references to more advanced garbage collection algorithms, but give graduate students hard problems and generally solutions fall out.


More information about the Digitalmars-d mailing list