More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

On 6 May 2014 21:39, Paulo Pinto via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 6 May 2014 at 10:58:14 UTC, Manu via Digitalmars-d wrote:
>>
>> On 6 May 2014 16:33, Jacob Carlborg via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On 06/05/14 08:07, HaraldZealot wrote:
>>>
>>>> I notice that I view only part of problem, can anybody link or describe
>>>> me completely state and problems of current garbage collection and other
>>>> resource management? It help me in finding of existence solution (at
>>>> least theoretical).
>>>
>>>
>>>
>>> The major issue with the garbage collector is that it's not guaranteed to
>>> run a collection. When a collection is run the GC will call the
>>> destructors
>>> for the objects it collects. If there's no guarantee a collection is run
>>> there can be no guarantee that destructors are called. A collection is
>>> usually run when allocating new memory and there's not enough memory
>>> available.
>>
>>
>> I think it's also an important consideration that GC is incompatible
>> with low-memory and real-time environments.
>>
>> ...
>
>
> I guess outside the gaming world, embedded and real-time seem to be getting
> lots of Java and .NET love:
>
> https://www.aicas.com/cms/
>
> http://www.is2t.com/products/
>
> http://www.mountaineer.org/netmf-for-stm32/
>
> Just a small sample of the partners providing the said support.

True, much embedded work isn't realtime. There are a lot of purpose
devices where performance is not particularly important, probably
correctness is, hence Java may be popular in this environment, and
@safe D may have a great application here.

In another realm, if we're talking about really small systems
(microcontrollers with memory in the megabytes), the tendency to rely
on libraries is reduced significantly, since you probably can't afford
the memory for the libs. This environment is the one where it's
realistic to say "tag main() with @nogc, and work from there", ie, ban
the GC throughout the whole project.

However, another very popular use for embedded systems IS realtime software.
Games consoles are the obvious one here, but also POS/retail devices,
kiosks, televisions, PVR's/dvd/bluray and other entertainment related
devices, cars and automobile HUD's, music players, advertising
displays, etc. There's no shortage of realtime devices in the embedded
space.
Notably, I didn't say 'phones'. Although I think they do generally
fall into this category, I think they're drifting away. Since they run
full OS stack's, it's typical to have unknown amounts of free memory
for user-space apps and virtual memory managers that can page swap, so
having excess memory overhead probably isn't such a big deal. It's
still a major performance hazard though. Stuttering realtime
applications is never a professional look, and Android suffers
chronically in this department compared to iOS.

I spent my last weekend trying to get a PS4 game (built with Unity;
uses mono as a scripting environment) running at an acceptable frame
rate. I didn't succeed, and a significant factor was the JS/C# garbage
collector. We'll probably need to cut content from the game, such that
it leaves plenty of 'excess' resource available to absorb the spikes
it causes when they occur. What a waste of the machine!
Note, C#'s GC is much better than D's. It does seem to run in the
realm of single-digit milliseconds.