More radical ideas about gc and reference counting

[Xavier Bigand via Digitalmars-d]

Le 06/05/2014 14:04, Manu via Digitalmars-d a écrit :
> 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 suspect iOS and Android to have best of swap management. I think that 
almost every time you switch applications, the previous one see his 
memory collected and swapped on the Flash (maybe also compressed).

> 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.
>