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
spelling typo, based on patch by @artfuldodger [Fixes GH-426]
https://github.com/ruby/ruby/pull/426
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43571 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* vm_trace.c (rb_threadptr_exec_event_hooks_orig): errinfo should not
be propagated to trace blocks so that no argument raise does not
throw internal objects. [ruby-dev:47793] [Bug #9088]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43561 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
These GC benchmarks do not reflect practical applications.
They are only for tuning.
* benchmark/bm_vm1_gc_short_with_complex_long.rb: added.
* benchmark/bm_vm1_gc_short_with_long.rb: added.
* benchmark/bm_vm1_gc_short_with_symbol.rb: added.
* benchmark/bm_vm1_gc_wb_ary.rb: added.
* benchmark/bm_vm1_gc_wb_obj.rb: added.
* benchmark/bm_vm_thread_queue.rb: added.
Thie benchmark is added to know how fast C verion of thread.so.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43547 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* eval_intern.h (rb_threadptr_tag_state, rb_threadptr_tag_jump):
rename prefix ruby as rb, same as other rb_threadptr functions.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@43536 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
nobu
zzak
ko1
hsbt
svn
kazu
glass
tarui
duerst
naruse
eregon
tenderlove
akr