A betterC base

Dmitry Olshansky dmitry.olsh at gmail.com
Sat Feb 10 22:30:58 UTC 2018


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



More information about the Digitalmars-d mailing list