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
