[ruby-core:60145] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically

Issue #9262 has been updated by Eric Wong.


 SASADA Koichi <[e-mail]> wrote:
 > From Ruby 2.0, we use inline/global method cache aggressively. So
 > performance impact on method cache miss has huge impact (compare with
 > Ruby 1.8, 1.9), that guys already show.
 
 Not a serious patch or benchmark, but I don't think it's too bad without
 global method cache (inline cache enabled).
 
 OPT_GLOBAL_METHOD_CACHE did not disable write to method cache,
  only writes before
 
 http://bogomips.org/ruby.git/patch/?id=a899e54e6abc13b8816e6c5f69ff560918db4be1
 
 git://80x24.org/ruby nomethodcache
 
 I'll rerun the test later tonight when my machine is quieter.

----------------------------------------
Bug #9262: global_method_cache should be configurable or grow automatically
https://bugs.ruby-lang.org/issues/9262#change-44639

* Author: Aman Gupta
* Status: Open
* Priority: Normal
* Assignee: Koichi Sasada
* Category: 
* Target version: next minor
* ruby -v: trunk
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN
----------------------------------------
The global_method_cache is currently a fixed 2048 entries. This is not configurable, and can be inadequate for large applications with thousands of classes and methods.

In our app, increasing the size of the cache to 32768 entries reduced time spent in search_method and overall pressure on st_lookup:

before
      420  14.0% st_lookup
      182   6.1% vm_search_method (inline)

after
      265   9.5% st_lookup
      125   4.5% vm_search_method (inline)

It's possible the VM could grow global_method_cache automatically, using some heuristic based on the number of long-lived classes or method_entries that are defined.
However this would break the hashing in the current implementation.



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