Mac Apps That Use Garbage Collection Must Move to ARC

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 24 02:57:12 PST 2015


On Tuesday, 24 February 2015 at 09:30:33 UTC, Tobias Pankrath 
wrote:
>>>> I suspect it would be a terrible performance hit.
>>>
>>> It would be nice to have some numbers backing this up.
>>
>>
>> This the approach taken by Active Oberon and Modula-3.
>>
>> Pointers are GC by default, but can be declared as untraced 
>> pointers in code considered @system like in D.
>>
>
> Do they have concurrent gc and emit barriers for each write to a
> default pointer? Do they have precise scanning and don't scan 
> the
> untraced pointers? Are the meaningful performance comparisons
> between the two pointer types that would enable us to estimate
> how costly emitting those barriers in D would be?

Both Active Oberon and Modula-3 support threading at language 
level, so multi-threading is a presence on their runtimes.

The latest documentation available for Active Oberon is from 2002.

http://e-collection.library.ethz.ch/view/eth:26082

Originally it was a concurrent mark-and-sweep GC, with stop the 
world phase for collection.

Other algorithms are discussed on the paper. Sadly ETHZ is done 
with Oberon as their startup failed to pick up steam in the 
industry (selling Component Pascal, an evolution of Oberon-2).

As for Modula-3, due to the way the the whole DEC, Olivetti, 
Compaq, HP process went, it isn't easy to find much documentation 
online. I had a few books.

The latest implementation had a concurrent incremental 
generational GC.

https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html

2002 is also around the same time that Modula-3 developed was 
stopped.

Dylan, which I just remembered while writing this, used the MPS 
collector.

http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ismm2002.html

Sadly the industry went JVM/CLR instead, and only now we are 
getting back to native systems programming with GC languages.

If those languages had been picked up by the industry instead of 
JVM/CLR, the situation could be quite different.

As always, it is a matter where the money for research gets 
pumped into.

--
Paulo


More information about the Digitalmars-d mailing list