More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

On 11 May 2014 08:40, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/10/2014 8:54 AM, Manu via Digitalmars-d wrote:
>>
>> I can't think of many situations where that wouldn't be the case. What
>> sort of software is it not an issue to experience intermittent
>> freezing?
>
>
> Batch programs, for example a compiler.

Indeed, that was the only one that came to my mind. GC might be better
for shell apps because it is unlikely that a collect will ever occur,
it'll usually terminate before it gets to it, but there's certainly no
hard-dependency on GC in this use case.
This is truly a niche usage case though, and yet, it also has no
particular incompatibility with any choice of technology, only a
slight preference towards GC for the reason that you never bother
freeing memory in DMD.

If you're prepared to label the largest entertainment industry on the
planet a niche, then this sort of work is a hyper-niche... and
regardless, not actually incompatible with any particular option.

I'd like to consider this form of software for a moment though.
Assuming the GC was a library offered beside the language, DDMD for
instance would be able to make particularly easy and convenient use of
it.
Shell apps by comparison _are_ generally small and self-contained.
It's far more reasonable to suggest that a shell app can adopt
specific and custom allocation patterns when the code is relatively
small, function is specific, the life is short, the probability of
running into incompatible 3rd party libraries is almost zero by
comparison.
How many libs does DMD link?

This thought has actually left me slightly concerned, that as much as
Andrei is accusing me of unreasonably arguing my "staunch niche
position that ignores factual realities" (a somewhat offensive and
dismissive notion), that there might be some silent, but significant
(perhaps even unconscious) element of the same in reverse.


> Essentially any program that is not interactive and does not have hard
> realtime requirements, which is (possibly) most programs.

I'm hard pressed to think of any software I see people using every day
which isn't realtime in some sense. The majority of relevant software
today is on embedded devices, and visceral touch-based UI is key to
their impression of quality.


>> Recall too that D has significant opportunity to
>> improve on ARC as implemented by other languages,
>
>
> Compiler improvements to improve on ARC are the same technology as used to
> improve GC.
>
> You're essentially arguing that one is easy pickings and the other is
> impractically difficult, but they're actually about the same level.

Are they? This is the first I've heard such a claim. If that's the
case, then that why is there an argument? That work just needs to be
done, and we can experiment with both targets...
I can fairly easily visualise the path to ARC, but by all prior
reports I've heard, awesome GC is practically incompatible with D for
various reasons. There were discussions about different advanced
options by the experts at dconf last year, which seemed to hit various
impasses.
And I'm still not even sure if 'awesome GC' will solve my problems?
Will it? No matter how awesome it is, it seems conceptually
incompatible with my environment.
I keep saying, I'm more than happy to be proved wrong (really!), but
until someone can, then it's unfair to dismiss my arguments so
easily... and I just don't think it's that unreasonable. ARC is an
extremely successful technology, particularly in the
compiled/native/systems language space (OC, C++/CX, Rust). Is there
actually any evidence of significant GC success in this space?
Successes all seem to be controlled VM based languages like Java and
C#; isolated languages with no intention to interact with existing
native worlds. There must be good reason for that apparent separation
in trends?