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