More radical ideas about gc and reference counting

[Paulo Pinto via Digitalmars-d]

On Tuesday, 6 May 2014 at 12:05:10 UTC, Manu via Digitalmars-d 
wrote:
> 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.

I can provide more examples for JVMs in all areas you list.

However those JVMs do cheat a bit, as they provide a fine grain
control over GC and also allow for region based allocations and 
immortal memory.

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

Just as info regarding your experience, please note that both 
Android and Unity have not so good GC implementations.

Dalvik's GC is hardly touched since Android 2.3, hopefully it 
will be improved with the new ART runtime.

Unity's Mono implementation is  a legacy one, based on the old 
Novell Mono implementation as Unity is not willing to pay the 
royalties Xamarin is asking for modern Mono implementations.


As for the gaming world, I don't really have the required 
experience to talk much about it. Just doing the heads up that D 
GC != GC that many of us use.

--
Paulo