On Saturday, February 10, 2018 14:06:09 Timon Gehr via Digitalmars-d wrote:
> On 08.02.2018 16:55, JN wrote:
> > On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote:
> >> Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels.
> >
> > Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython). Unless you mean garbage collection as in "not manual memory management"? ...
>
> Even if "garbage collection" is taken to mean "collecting garbage", reference counting is garbage collection. Referring to RC as not GC makes no sense at all and was probably only invented because some people want to think that RC is good but GC is bad, being too lazy to say "tracing GC".

Except that RC and what folks typically mean what they talk about GC are fundamentally different. Yes, they both automatically free memory for you, but one is deterministic, whereas the other involves periodically running a collection to find memory that can be freed. So, yes, in a sense, RC is a form of GC, but they're very different beasts.

- Jonathan M Davis

On Saturday, 10 February 2018 at 19:22:51 UTC, Jonathan M Davis wrote:
> On Saturday, February 10, 2018 14:06:09 Timon Gehr via Digitalmars-d wrote:
>> On 08.02.2018 16:55, JN wrote:
>> > On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote:
>> >> Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels.
>> >
>> > Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython). Unless you mean garbage collection as in "not manual memory management"? ...
>>
>> Even if "garbage collection" is taken to mean "collecting garbage", reference counting is garbage collection. Referring to RC as not GC makes no sense at all and was probably only invented because some people want to think that RC is good but GC is bad, being too lazy to say "tracing GC".
>
> Except that RC and what folks typically mean what they talk about GC are fundamentally different. Yes, they both automatically free memory for you, but one is deterministic, whereas the other involves periodically running a collection to find memory that can be freed. So, yes, in a sense, RC is a form of GC, but they're very different beasts.
>
> - Jonathan M Davis

People like to think that RC is deterministic.

First of all, unless they are atomic, there are no guarantees of pause time during locking on counter access.

Second, Herb Sutter has a great CppCon talk about non-deterministic releases, with the possibility of stack overflow, in complex datastructures.

Herb Sutter “Leak-Freedom in C++... By Default.”

https://www.youtube.com/watch?v=JfmTagWcqoE

On 2/10/2018 7:14 AM, Dmitry Olshansky wrote:
> RC is a form of GC.

Pedantically, yes. But common usage regards the two as disjoint, and it's inconvenient to treat RC as a subset of GC when discussing tradeoffs between the two. Nobody bothers with s/GC/GC excluding RC/.

On Saturday, 10 February 2018 at 18:40:43 UTC, Andrei Alexandrescu wrote:
> On 2/10/18 10:14 AM, Dmitry Olshansky wrote:
>> On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright wrote:
>>> Of course, the issue can get more complex. GC uses 3x the memory of RC,
>> 
>>   I’ve seen figures of about x2 but that was in an old paper on Boehm GC.
>
> This is the classic reference: https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf. Executive review in the abstract: "With only three times as much memory, the collector runs on average 17% slower than explicit memory management.

Reading the whole paper is a tad more important:

On particular “manual” memory management is aided by precompted trace of lifetimes w/o any bookkeeping performed by the application.

Citation #1:
Oracular memory management framework. As Figure 1(a) shows, it first executes the Java pro- gram to calculate object lifetimes and generate the program heap trace. The system processes the program heap trace uses the Mer- lin algorithm to compute object reachability times and generate the reachability-based oracle. [...] Using these oracles, the oracular memory manager executes the program as shown in Figure 1(b), allocating objects using calls to malloc and invoking free on objects when directed by the oracle

Plus - single threaded only... (e.g. parallel GC is a thing)

Citation #2:
In the experiments we present here, we assume a single-processor environment and disable atomic operations both for Jikes RVM and for the Lea allocator. In a multithreaded environment, most thread- safe memory allocators also require at least one atomic operation for every call to malloc and free: a test-and-set operation for lock-based allocator...

> However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management." -- Andrei

On 2/10/18 4:41 PM, Walter Bright wrote:
> On 2/10/2018 7:14 AM, Dmitry Olshansky wrote:
>> RC is a form of GC.
> 
> Pedantically, yes. But common usage regards the two as disjoint, and it's inconvenient to treat RC as a subset of GC when discussing tradeoffs between the two. Nobody bothers with s/GC/GC excluding RC/.

"Tracing GC" is the common way of referring to GC techniques outside of reference counting. -- Andrei

On Friday, 9 February 2018 at 16:54:35 UTC, Seb wrote:
>
> FYI: and for the lazy ones, there will hopefully be std.experimental.scripting soon:
>
> https://github.com/dlang/phobos/pull/5916

Shouldn't something like this be handled by better tooling (i.e. IDEs)? In Java you have to import every single class you want to use, but it's not a manual effort, in 99% of cases you just press Ctrl+Shift+I and IDE adds all the necessary imports. It only requires manual intervention when there's a conflict, and you get to choose between possible candidates, e.g. java.xml.Document vs java.pdf.Document.