* gc.c (vm_xrealloc, vm_xfree): use malloc_usable_size() to obtain old
size if available.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43760 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
They are not only used initial values.
Chikanaga-san: Congratulations on RubyPrize!
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43757 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Without this option, some application consumes huge memory.
(and there are only a few performance down)
Introduced new environment variables:
* RUBY_GC_HEAP_OLDSPACE (default 16MB)
* RUBY_GC_HEAP_OLDSPACE_MAX (default 128 MB)
* RUBY_GC_HEAP_OLDSPACE_GROWTH_FACTOR (default 1.2)
* gc.c (initial_malloc_limit): rename to initial_malloc_limit_min.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43755 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Basically, make an object graph of all of living objects before and
after marking and check status.
[Before marking: check WB sanity]
If there is a non-old object `obj' pointed from old object
(`parent') then `parent' or `obj' should be remembered.
[After marking: check marking miss]
Traversible objects with the object graph should be marked.
(However, this alert about objects pointed by machine context
can be false positive. We only display alert.)
[Implementation memo]
objspace_allrefs() creates an object graph.
The object graph is represented by st_table, key is object (VALUE)
and value is referring objects. Referring objects are stored by
"struct reflist".
* gc.c (init_mark_stack): do not use push_mark_stack_chunk() at init.
This pre-allocation causes failure on is_mark_stask_empty()
without any pushing.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43744 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rb_fstring() used rb_gc_mark() to avoid freeing used string.
However, rb_gc_mark() set mark bit *and* pushes mark_stack.
rb_gc_resurrect() does only set mark bit if it is before sweeping.
* string.c (rb_fstring): use rb_gc_resurrect.
* internal.h: add decl.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43718 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
To reduce memory usage, sweep as soon as possible.
This behavior is same as Ruby 2.0.0 and before.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43623 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
If GC_PROFILE_MORE_DETAIL && GC_PROFILE_DETAIL_MEMORY,
maxrss, minflt and majflt are added to each profile record.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43591 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
vm_malloc_increase() can be called without GVL.
However, gc_rest_sweep() assumes acquiring GVL.
To avoid this problem, check GVL before gc_rest_sweep().
[Bug #9090]
This workaround introduces possibility to set malloc_limit as
wrong value (*1). However, this may be rare case. So I commit it.
*1: Without rest_sweep() here, gc_rest_sweep() can decrease
malloc_increase due to ruby_sized_xfree().
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43574 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
conservative for closing to memory consumption of ruby 2.0.
* gc.c (GC_MALLOC_LIMIT, GC_MALLOC_LIMIT_GROWTH_FACTOR):
Adjust parameters for new algorithm.
Example: make gcbench-rdoc on a pc
time maxrss
2.0.0p343 285.27 281853952
trunk before patch 207.19 690405376
trunk after patch 211.59 312500224
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43558 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This is another approach to solve an issue discussed at r43530.
This feature is diabled as default.
This feature measures an increment of memory consuption by oldgen
objects. It measures memory consumption for each objects when
the object is promoted. However, measurement of memory consumption
is not accurate now. So that this measurement is `estimation'.
To implement this feature, move memsize_of() function from
ext/objspace/objspace.c and expose rb_obj_memsize_of().
Some memsize() functions for T_DATA (T_TYPEDDATA) have problem to
measure memory size, so that we ignores T_DATA objects now.
For example, some functions skip NULL check for pointer.
The macro RGENGC_ESTIMATE_OLDSPACE enables/disables this feature,
and turned off as default.
We need to compare 3gen GC and this feature carefully.
(it is possible to enable both feature)
We need a help to compare them.
* internal.h: expose rb_obj_memsize_of().
* ext/objspace/objspace.c: use rb_obj_memsize_of() function.
* cont.c (fiber_memsize): fix to check NULL.
* variable.c (autoload_memsize): ditto.
* vm.c (vm_memsize): ditto.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43532 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
RGenGC is designed as 2 generational GC, young and old generation.
Young objects will be promoted to old objects after one GC.
Old objects are not collect until major (full) GC.
The issue of this approach is some objects can promoted as old
objects accidentally and not freed until major GC.
Major GC is not frequently so short-lived but accidentally becoming
old objects are not freed.
For example, the program "loop{Array.new(1_000_000)}" consumes huge
memories because short lived objects (an array which has 1M
elements) are promoted while GC and they are not freed before major
GC.
To solve this problem, generational GC with more generations
technique is known. This patch implements three generations gen GC.
At first, newly created objects are "Infant" objects.
After surviving one GC, "Infant" objects are promoted to "Young"
objects.
"Young" objects are promoted to "Old" objects after surviving
next GC.
"Infant" and "Young" objects are collected if it is not marked
while minor GC. So that this technique solves this problem.
Representation of generations:
* Infant: !FL_PROMOTED and !oldgen_bitmap [00]
* Young : FL_PROMOTED and !oldgen_bitmap [10]
* Old : FL_PROMOTED and oldgen_bitmap [11]
The macro "RGENGC_THREEGEN" enables/disables this feature, and
turned off as default because there are several problems.
(1) Failed sometimes (Heisenbugs).
(2) Performance down.
Especially on write barriers. We need to detect Young or Old
object by oldgen_bitmap. It is slower than checking flags.
To evaluate this feature on more applications, I commit this patch.
Reports are very welcome.
This patch includes some refactoring (renaming names, etc).
* include/ruby/ruby.h: catch up 3gen GC.
* .gdbinit: fix to show a prompt "[PROMOTED]" for promoted objects.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43530 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This flag represents that "this object is promoted at least once."
* gc.c, debug.c, object.c: catch up this change.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43527 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* gc.c (obj_free): suppress a false shorten-64-to-32 warning,
RUBY_TYPED_FREE_IMMEDIATELY never exceed the limit of int.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43516 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
performance. Add before_sweep condition to heap_page structure.
* gc.c (rb_gc_force_recycle): Use before_sweep member.
* gc.c (heap_is_before_sweep, is_before_sweep): Remove. They has not
already been used.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43508 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* gc.c (is_live_object): finalizer may not run because of lazy-sweep.
[ruby-dev:47786] [Bug #9069]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43502 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* RUBY_TYPED_FREE_IMMEDIATELY: free the data given by DATA_PTR()
with dfree function immediately. Otherwise (default), the data
freed at finalizaton point.
* RUBY_TYPED_WB_PROTECTED: make this object with FL_WB_PROTECT
(not shady).
* gc.c (obj_free): support RUBY_TYPED_FREE_IMMEDIATELY.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43463 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We only need one sweep time measurement without lazy sweep.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43427 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* gc.c (GC_MALLOC_LIMIT): change default value to 16MB.
* gc.c (GC_MALLOC_LIMIT_GROWTH_FACTOR): change default value to 2.0.
* gc.c (gc_before_sweep): change decrease ratio of `malloc_limit'
from 1/4 to 1/10.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43425 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
gc_rest_sweep() can reduce malloc_increase, so try it before GC.
Otherwise, malloc_increase can be less than malloc_limit at
gc_before_sweep(). This means that re-calculation of malloc_limit
may be wrong value.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43424 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
nobu
ko1
ktsj
tarui
tmm1