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