Issue #4990 has been updated by Kurt  Stephens.


Shyouhei Urabe wrote:
> Don't blame valgind it supports such situation http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

I'm not "blaming" valgrind, I'm not even "blaming" gc.c.  Valgrind has hooks for recognizing custom allocators, but only if the allocator is instrumented.  It's obvious, MRI 1.9 uses some of the VALGRIND_*() hooks, however the hooks are enabled at compile-time. 

Again, this is part of a proof-of-concept -- that different allocators and features can be selected at boot-time (and/or compile-time).  This is not the final work -- there is a larger goal stated in the description.

BTW: using the RUBY_MEM_SYS=malloc allocator during "make" and "make install" appears to improve speed with only a modest memory increase.  Some ruby programs are short-lived and do not create much collectable garbage.

If anyone thinks the larger goal, or even this dinky "malloc-only" allocator, is useful, please speak up. :)


----------------------------------------
Feature #4990: Proposal: Internal GC/memory subsystem API
http://redmine.ruby-lang.org/issues/4990

Author: Kurt  Stephens
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


There is significant interest in improving/altering the performance, behavior and features of MRI's GC in 1.8 and 1.9 series.

Proposal: MRI should support an internal GC API -- to separate MRI core from its current GC implementation,
and provide hooks for additional features:

1) Interfaces between MRI internals and any GC/allocator implementation:
  * stock MRI GC
  * malloc() without free() to support valgrind testing (or short-lived programs)
  * variants of stock MRI GC (http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html and REE)
  * BDW (http://www.hpl.hp.com/personal/Hans_Boehm/gc/)
  * other collectors (https://github.com/kstephens/smal)

2) Support selecting GC implementations at run-time or compile time.

3) Support malloc() replacements, at run-time and/or compile time, such as:
  * tcmalloc
  * jemalloc

4) Support callback hooks in allocation and GC phases to orthogonally add features, such as:
  * performant/correct WeakReferences and ReferenceQueues (http://redmine.ruby-lang.org/issues/4168).
  * allocation tracing/debugging.
  * instance caching (e.g.: Floats)
  * computational caching.
  * cache invalidation.
  * metrics collection.

5) Interfaces to common features of alternate GCs:
  * finalization
  * weak references
  * atomic allocations (e.g.: string or binary data)
  * mostly read-only/static allocations (e.g.: code, global bindings)

A prototype GC phase callback API for 1.8, REE and 1.9 is here:

  https://github.com/kstephens/ref/tree/master-mri-gc_api/patch

This GC API should be supported on both 1.8 and 1.9 code lines.




-- 
http://redmine.ruby-lang.org