https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112013-12-21T11:14:22ZRuby Issue Tracking SystemRuby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=437922013-12-21T11:14:22Ztmm1 (Aman Karmani)ruby@tmm1.net
<ul></ul><p>funny-falcon proposed removing the global_method_cache altogether, in favor of a per-klass method cache:</p>
<p><a href="https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache" class="external">https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache</a><br>
<a href="https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache.diff" class="external">https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache.diff</a></p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=438372013-12-23T10:27:27Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>Before I measure the changes proposed by funny falcon I wanted to present the sad state of affairs.</p>
<p>I applied this patch to gather method cache statistics: <a href="https://github.com/SamSaffron/ruby/commit/e6ecf6d8390b2e4036b91778268a7544f364b8f1" class="external">https://github.com/SamSaffron/ruby/commit/e6ecf6d8390b2e4036b91778268a7544f364b8f1</a></p>
<p>I then wrote some middleware to measure the impact of the method cache while browsing around Discourse in production mode:</p>
<p>class CacheStatMiddleware<br>
def initialize(app, config={})<br>
@app = app<br>
end</p>
<pre><code>def call(env)
start = Time.new
hits = Kernel.cache_hits
misses = Kernel.cache_misses
time = Kernel.cache_miss_time
r = @app.call(env)
lost = Kernel.cache_miss_time - time
total = ((Time.new - start)* 1000 * 1000).to_i
pct = (lost.to_f / total.to_f) * 100
puts "hits #{Kernel.cache_hits - hits} " <<
"misses #{Kernel.cache_misses - misses } " <<
"microsecs lost #{lost} #{pct.round(2)}% " <<
"cache usage #{Kernel.cache_entries} / #{Kernel.cache_size} " <<
"req duration #{total} "
r
end
</code></pre>
<p>end</p>
<p>config.middleware.insert 0, CacheStatMiddleware</p>
<hr>
<p>Here are some results:</p>
<p>hits 74383 misses 5095 microsecs lost 4620 7.75% cache usage 2048 / 2048 req duration 59613<br>
hits 74033 misses 5093 microsecs lost 4750 8.04% cache usage 2048 / 2048 req duration 59070<br>
hits 73962 misses 5106 microsecs lost 4509 7.74% cache usage 2048 / 2048 req duration 58253<br>
hits 677 misses 229 microsecs lost 393 6.23% cache usage 2048 / 2048 req duration 6305<br>
hits 523 misses 35 microsecs lost 211 3.68% cache usage 2048 / 2048 req duration 5738<br>
hits 549 misses 31 microsecs lost 279 3.58% cache usage 2048 / 2048 req duration 7804<br>
hits 4412 misses 143 microsecs lost 97 3.14% cache usage 2048 / 2048 req duration 3088<br>
hits 47 misses 18 microsecs lost 21 8.97% cache usage 2048 / 2048 req duration 234<br>
hits 3405 misses 130 microsecs lost 152 4.88% cache usage 2048 / 2048 req duration 3115<br>
hits 519 misses 158 microsecs lost 214 8.1% cache usage 2048 / 2048 req duration 2641<br>
hits 114133 misses 14584 microsecs lost 14338 9.31% cache usage 2048 / 2048 req duration 154000<br>
hits 44835 misses 2754 microsecs lost 2850 8.16% cache usage 2048 / 2048 req duration 34914<br>
hits 75084 misses 8601 microsecs lost 8048 10.95% cache usage 2048 / 2048 req duration 73475</p>
<hr>
<p>Conclusion:</p>
<p>For an app like Discourse 3-10% of request time is occupied looking up methods, due to cache inefficiency.</p>
<p>Out of the box cache is just too small to fit all the entries required, so its thrashing.</p>
<hr>
<p>If we raise the method cache x16 size we see:</p>
<p>hits 720 misses 5 microsecs lost 11 0.44% cache usage 17045 / 32768 req duration 2509<br>
hits 40 misses 0 microsecs lost 0 0.0% cache usage 17061 / 32768 req duration 242<br>
hits 53076 misses 266 microsecs lost 685 1.67% cache usage 17090 / 32768 req duration 41001<br>
hits 47234 misses 238 microsecs lost 315 1.24% cache usage 17117 / 32768 req duration 25418<br>
hits 53012 misses 281 microsecs lost 850 2.03% cache usage 17145 / 32768 req duration 41803<br>
hits 720 misses 5 microsecs lost 15 0.65% cache usage 17163 / 32768 req duration 2308<br>
hits 52353 misses 261 microsecs lost 605 1.63% cache usage 17190 / 32768 req duration 37031<br>
hits 46785 misses 190 microsecs lost 429 1.32% cache usage 17207 / 32768 req duration 32392<br>
hits 52893 misses 273 microsecs lost 610 1.71% cache usage 17240 / 32768 req duration 35571<br>
hits 720 misses 5 microsecs lost 7 0.45% cache usage 17258 / 32768 req duration 1551<br>
hits 52295 misses 261 microsecs lost 709 1.75% cache usage 17287 / 32768 req duration 40552<br>
hits 46784 misses 191 microsecs lost 393 1.35% cache usage 17308 / 32768 req duration 29146<br>
hits 86409 misses 2013 microsecs lost 2655 3.4% cache usage 17829 / 32768 req duration 78033<br>
hits 644 misses 7 microsecs lost 22 0.64% cache usage 17843 / 32768 req duration 3458<br>
hits 46729 misses 295 microsecs lost 423 1.73% cache usage 17864 / 32768 req duration 24385<br>
hits 82777 misses 893 microsecs lost 1807 2.57% cache usage 17972 / 32768 req duration 70341<br>
hits 46819 misses 191 microsecs lost 400 1.18% cache usage 17989 / 32768 req duration 33862<br>
hits 82412 misses 865 microsecs lost 1426 2.12% cache usage 18099 / 32768 req duration 67163</p>
<hr>
<p>Even when the cache has room, too many collisions are happening forcing cache eviction when uneeded, leave 2% of the perf on the table, this is significantly better than 2-10% though.</p>
<p>This can be fixed possibly by introducing quadratic probing or perhaps a cuckoo like algorithm.</p>
<p>The global method cache has a couple of advantages over per class cache and a few disadvantage.</p>
<p>Advantages:</p>
<ol>
<li>Size is cleanly capped</li>
<li>Very easy to gather stats and info about it</li>
<li>Expiry semantics are fairly clean, can force a method_state increment when utilization is too high</li>
</ol>
<p>Disadvantages:</p>
<ol>
<li>Extra hashing required to look up elements, you need the klass hash</li>
<li>Extra storage required (klass_seq stored per element)</li>
</ol> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=438402013-12-23T13:56:25Ztmm1 (Aman Karmani)ruby@tmm1.net
<ul></ul><p>I ran some benchmarks with funny-falcon's patch. Memory usage is increased by 5-10mb RSS in our app, and response time is improved by 4-8%.</p>
<p>before:</p>
<p>500 requests to <a href="https://github.com/dashboard" class="external">https://github.com/dashboard</a> as tmm1<br>
peak memory: 349.4 MB RSS<br>
cpu time: 7,171ms total (14ms avg/req, 13ms - 21ms)<br>
500 requests to <a href="https://github.com/github/github/pull/17695" class="external">https://github.com/github/github/pull/17695</a> as tmm1<br>
peak memory: 404.6 MB RSS<br>
cpu time: 98,713ms total (197ms avg/req, 184ms - 285ms)</p>
<p>after:</p>
<p>500 requests to <a href="https://github.com/dashboard" class="external">https://github.com/dashboard</a> as tmm1<br>
peak memory: 359.2 MB RSS<br>
cpu time: 6,806ms total (13ms avg/req, 12ms - 20ms)<br>
500 requests to <a href="https://github.com/github/github/pull/17695" class="external">https://github.com/github/github/pull/17695</a> as tmm1<br>
peak memory: 410.3 MB RSS<br>
cpu time: 95,559ms total (191ms avg/req, 177ms - 280ms)</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=438432013-12-23T16:11:53Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>There was a concern that gettimeofday is expensive and adds too much time to my results</p>
<p>I measured:</p>
<p>static VALUE<br>
rb_timing_overhead_per_100k(VALUE klass){<br>
int i, iterations = 100000;<br>
struct timeval temp,tv1,tv2,res;</p>
<pre><code>gettimeofday(&tv1, NULL);
for(i=0; i<iterations; i++) {
gettimeofday(&temp, NULL);
}
gettimeofday(&tv2, NULL);
timersub(&tv2, &tv1, &res);
return INT2FIX(res.tv_sec*100000 + res.tv_usec);
</code></pre>
<p>}</p>
<p>turns out that its 2000 microseconds per 100k calls, so the additional time involved due to measuring is negligible, the numbers can be trusted</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=438472013-12-23T16:35:21Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>Discourse Bench,</p>
<p>Disabled Method Cache vs Current cache vs 16x larger method cache vs Funny Falcon</p>
<p>Disabled Method cache:</p>
<a name="Your-Results-note-for-timings--percentile-is-first-duration-is-second-in-millisecs"></a>
<h2 >Your Results: (note for timings- percentile is first, duration is second in millisecs)<a href="#Your-Results-note-for-timings--percentile-is-first-duration-is-second-in-millisecs" class="wiki-anchor">¶</a></h2>
<p>home_page:<br>
50: 43<br>
75: 44<br>
90: 48<br>
99: 67<br>
topic_page:<br>
50: 14<br>
75: 15<br>
90: 16<br>
99: 39<br>
home_page_admin:<br>
50: 57<br>
75: 60<br>
90: 64<br>
99: 89<br>
topic_page_admin:<br>
50: 23<br>
75: 24<br>
90: 26<br>
99: 35<br>
timings:<br>
load_rails: 2733<br>
ruby-version: 2.1.0-p-1<br>
architecture: amd64<br>
operatingsystem: Ubuntu<br>
kernelversion: 3.11.0<br>
memorysize: 5.89 GB<br>
physicalprocessorcount: 1<br>
processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz</p>
<p>Current Method Cache:</p>
<hr>
<p>home_page:<br>
50: 37<br>
75: 39<br>
90: 43<br>
99: 60<br>
topic_page:<br>
50: 12<br>
75: 13<br>
90: 14<br>
99: 40<br>
home_page_admin:<br>
50: 48<br>
75: 50<br>
90: 55<br>
99: 77<br>
topic_page_admin:<br>
50: 20<br>
75: 21<br>
90: 23<br>
99: 32<br>
timings:<br>
load_rails: 2721<br>
ruby-version: 2.1.0-p-1<br>
architecture: amd64<br>
operatingsystem: Ubuntu<br>
kernelversion: 3.11.0<br>
memorysize: 5.89 GB<br>
physicalprocessorcount: 1<br>
processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz</p>
<p>16x larger method cache</p>
<a name="Your-Results-note-for-timings--percentile-is-first-duration-is-second-in-millisecs-2"></a>
<h2 >Your Results: (note for timings- percentile is first, duration is second in millisecs)<a href="#Your-Results-note-for-timings--percentile-is-first-duration-is-second-in-millisecs-2" class="wiki-anchor">¶</a></h2>
<p>home_page:<br>
50: 35<br>
75: 38<br>
90: 41<br>
99: 67<br>
topic_page:<br>
50: 11<br>
75: 11<br>
90: 13<br>
99: 34<br>
home_page_admin:<br>
50: 45<br>
75: 47<br>
90: 52<br>
99: 79<br>
topic_page_admin:<br>
50: 18<br>
75: 19<br>
90: 20<br>
99: 29<br>
timings:<br>
load_rails: 2761<br>
ruby-version: 2.1.0-p-1<br>
architecture: amd64<br>
operatingsystem: Ubuntu<br>
kernelversion: 3.11.0<br>
memorysize: 5.89 GB<br>
physicalprocessorcount: 1<br>
processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz</p>
<p>Funny Falcon</p>
<a name="Your-Results-note-for-timings--percentile-is-first-duration-is-second-in-millisecs-3"></a>
<h2 >Your Results: (note for timings- percentile is first, duration is second in millisecs)<a href="#Your-Results-note-for-timings--percentile-is-first-duration-is-second-in-millisecs-3" class="wiki-anchor">¶</a></h2>
<p>home_page:<br>
50: 34<br>
75: 35<br>
90: 38<br>
99: 53<br>
topic_page:<br>
50: 10<br>
75: 11<br>
90: 12<br>
99: 37<br>
home_page_admin:<br>
50: 43<br>
75: 45<br>
90: 49<br>
99: 68<br>
topic_page_admin:<br>
50: 18<br>
75: 19<br>
90: 20<br>
99: 32<br>
timings:<br>
load_rails: 2771<br>
ruby-version: 2.1.0-p-1<br>
architecture: amd64<br>
operatingsystem: Ubuntu<br>
kernelversion: 3.11.0<br>
memorysize: 5.89 GB<br>
physicalprocessorcount: 1<br>
processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz</p>
<hr>
<p>Observations:</p>
<p>Funny Falcon patch is clearly fastest, x10 cache size improvement makes a very big difference, method caching impact is about 20% give or take a bit.</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=438482013-12-23T16:56:35Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>Note: for comparison see the results on an unpatched 2.0.0 p353</p>
<hr>
<p>home_page:<br>
50: 35<br>
75: 40<br>
90: 107<br>
99: 119<br>
topic_page:<br>
50: 12<br>
75: 13<br>
90: 17<br>
99: 150<br>
home_page_admin:<br>
50: 45<br>
75: 55<br>
90: 118<br>
99: 127<br>
topic_page_admin:<br>
50: 19<br>
75: 21<br>
90: 76<br>
99: 100<br>
timings:<br>
load_rails: 3644<br>
ruby-version: 2.0.0-p353<br>
architecture: amd64<br>
operatingsystem: Ubuntu<br>
kernelversion: 3.11.0<br>
memorysize: 5.89 GB<br>
physicalprocessorcount: 1<br>
processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz</p>
<p>either the 16x size increase or the optimal falcon implementation means Ruby 2.1 no longer regress performance.</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=438522013-12-23T20:28:22Zfunny_falcon (Yura Sokolov)funny.falcon@gmail.com
<ul></ul><p>Add couple of fixes to patch:</p>
<ol>
<li>fix rb_mcache_resize - it didn't copy method_state and class_serial on resize, so that cache were invalidated on next check.</li>
<li>add "gargabe collection" of "undefined" cache entries - do not copy them on resize, shrink cache size if it is too sparse after resize.</li>
</ol>
<p><a href="https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache" class="external">https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache</a><br>
<a href="https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache.diff" class="external">https://github.com/funny-falcon/ruby/compare/trunk...class_local_cache.diff</a></p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=440592014-01-03T20:12:20Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>FYI it seems perf of method lookups has regressed in 2.1:</p>
<p><a href="https://gist.github.com/SamSaffron/8232978" class="external">https://gist.github.com/SamSaffron/8232978</a></p>
<p>This makes this change particularly important</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=441112014-01-06T16:23:17Zko1 (Koichi Sasada)
<ul></ul><p>Hi,</p>
<p>Now, method cache technique is important and we need more measurement<br>
and techniques.</p>
<h2></h2>
<p>From Ruby 2.0, we use inline/global method cache aggressively. So<br>
performance impact on method cache miss has huge impact (compare with<br>
Ruby 1.8, 1.9), that guys already show.</p>
<p>funny_falcon's approach is very impressive to solve this problem.<br>
However, now I'm not sure how it increase memory imapct.</p>
<p>tmm1 measured the memory impact on<br>
<a href="https://bugs.ruby-lang.org/issues/9262#change-43840" class="external">https://bugs.ruby-lang.org/issues/9262#change-43840</a> . This survery is<br>
very impressive. I think it is better we measure other cases. For<br>
example, if some classes calls many methods at onece, it will memory<br>
issue. I think the simple limitation (cap) approach with funny_falcon's<br>
patch works fine.</p>
<h2></h2>
<p>New years holiday (Japanese take holidays in new years week), I'm<br>
thinking about this issue. Some ideas are available.</p>
<p>(1) inline cache<br>
(1-1) polymorphic inline cache<br>
(1-2) per class inline cache other than call site<br>
(1-3) per-method cache invalidation<br>
(2) global cache<br>
(2-1) per class method cache w/ cap</p>
<p>Now the above ideas are not implemented/verified. And huge effort is<br>
needed (because we need to change the method entry data structure).<br>
Before the try, I need to know the why and how method cache is missed.</p>
<h2></h2>
<p>Basically I don't against to introduce and backport some proposed<br>
patches (w/ measurement, if we can). In my opinion, simple variable<br>
global cache entry size approach will fine for backport.</p>
<p>And also I try above ideas for Ruby 2.2. Current patches are good<br>
starting point, I think.</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=446392014-01-27T23:41:42Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>From Ruby 2.0, we use inline/global method cache aggressively. So<br>
performance impact on method cache miss has huge impact (compare with<br>
Ruby 1.8, 1.9), that guys already show.</p>
</blockquote>
<p>Not a serious patch or benchmark, but I don't think it's too bad without<br>
global method cache (inline cache enabled).</p>
<p>OPT_GLOBAL_METHOD_CACHE did not disable write to method cache,<br>
only writes before</p>
<p><a href="http://bogomips.org/ruby.git/patch/?id=a899e54e6abc13b8816e6c5f69ff560918db4be1" class="external">http://bogomips.org/ruby.git/patch/?id=a899e54e6abc13b8816e6c5f69ff560918db4be1</a></p>
<p>git://80x24.org/ruby nomethodcache</p>
<p>I'll rerun the test later tonight when my machine is quieter.</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=447052014-01-29T19:20:43Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>It looks like the performance regressions w/o global method cache are<br>
because rb_funcall and friends do not have call info, so they don't<br>
hit the inline cache. So perhaps we should just add a call info-aware<br>
version of rb_funcall-like functions so we can just use inline cache<br>
everywhere.</p>
<p>I'm pretty sure ko1 already knows that, but I just discovered it :x<br>
tmm1: what do you think?</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=447062014-01-29T19:30:40Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>Eric Wong <a href="mailto:normalperson@yhbt.net" class="email">normalperson@yhbt.net</a> wrote:</p>
<blockquote>
<p>So perhaps we should just add a call info-aware<br>
version of rb_funcall-like functions so we can just use inline cache<br>
everywhere.</p>
</blockquote>
<p>I should add: a cheap way to do this might be to just use a do/while<br>
macro wrapping rb_funcall with a static __thread rb_call_info_t<br>
variable in its scope.</p>
<p>__thread works on gcc and clang, and maybe other compilers, too,<br>
but other compilers may be stuck with the slow version (or non-MT-safe).<br>
(I prefer we use __thread in case we get rid of GVL)</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=448492014-01-31T05:31:04Zko1 (Koichi Sasada)
<ul><li><strong>ruby -v</strong> changed from <i>trunk</i> to <i>-</i></li></ul><p>(2014/01/30 4:17), Eric Wong wrote:</p>
<blockquote>
<p>It looks like the performance regressions w/o global method cache are<br>
because rb_funcall and friends do not have call info, so they don't<br>
hit the inline cache. So perhaps we should just add a call info-aware<br>
version of rb_funcall-like functions so we can just use inline cache<br>
everywhere.</p>
<p>I'm pretty sure ko1 already knows that, but I just discovered it :x<br>
tmm1: what do you think?</p>
</blockquote>
<p>charliesome have proposed a simiar API (sorry I forget the URL).<br>
He use only static variable (not thread-local) and it seems works well.<br>
However, I think it may have pitfalls (recursive call) so I can't decide<br>
to introduce it.</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=448542014-01-31T07:34:25Zfunny_falcon (Yura Sokolov)funny.falcon@gmail.com
<ul></ul><p>I tried to do once with static variables, but had performance regression. Perhaps, i missed something.</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=455672014-03-02T03:29:06Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:normalperson@yhbt.net" class="email">normalperson@yhbt.net</a> wrote:</p>
<blockquote>
<p><a href="http://bogomips.org/ruby.git/patch/?id=a899e54e6abc13b8816e6c5f69ff560918db4be1" class="external">http://bogomips.org/ruby.git/patch/?id=a899e54e6abc13b8816e6c5f69ff560918db4be1</a></p>
</blockquote>
<p>Btw, I'd like to commit just the vm_method.c change for this<br>
to avoid writing to method cache if disabled.</p>
<p>It also replaces CPP #if with C if for readability.</p>
<p>Ugh, commit message was long, just the vm_method.c change:<br>
<a href="http://bogomips.org/ruby.git/diff/vm_method.c?id=a899e54e6abc1" class="external">http://bogomips.org/ruby.git/diff/vm_method.c?id=a899e54e6abc1</a></p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=455682014-03-02T05:54:14Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Eric Wong wrote:</p>
<blockquote>
<p>Btw, I'd like to commit just the vm_method.c change for this<br>
to avoid writing to method cache if disabled.</p>
</blockquote>
<p>Agreed.</p>
<blockquote>
<p>It also replaces CPP #if with C if for readability.</p>
</blockquote>
<p>I don't think it is needed.</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=455702014-03-02T07:21:49Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:nobu@ruby-lang.org" class="email">nobu@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Eric Wong wrote:</p>
<blockquote>
<p>It also replaces CPP #if with C if for readability.</p>
</blockquote>
<p>I don't think it is needed.</p>
</blockquote>
<p>OK, does it that mean UNDEFINED_METHOD_ENTRY_P is unnecessary<br>
with cache disabled? Could just do this:<br>
<a href="http://80x24.org/gmc_disable.patch" class="external">http://80x24.org/gmc_disable.patch</a></p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=455822014-03-02T23:33:05Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>Eric Wong <a href="mailto:normalperson@yhbt.net" class="email">normalperson@yhbt.net</a> wrote:</p>
<blockquote>
<p><a href="mailto:nobu@ruby-lang.org" class="email">nobu@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Eric Wong wrote:</p>
<blockquote>
<p>It also replaces CPP #if with C if for readability.</p>
</blockquote>
<p>I don't think it is needed.</p>
</blockquote>
<p>OK, does it that mean UNDEFINED_METHOD_ENTRY_P is unnecessary<br>
with cache disabled? Could just do this:<br>
<a href="http://80x24.org/gmc_disable.patch" class="external">http://80x24.org/gmc_disable.patch</a></p>
</blockquote>
<p>r45261. I used my original hunk in rb_method_entry_get_without_cache<br>
since I got "make test" failures on my 32-bit machine without checking<br>
UNDEFINED_METHOD_ENTRY_P(me) when bypassing GMC</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=455832014-03-03T00:46:40Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Eric Wong wrote:</p>
<blockquote>
<p><a href="mailto:nobu@ruby-lang.org" class="email">nobu@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Eric Wong wrote:</p>
<blockquote>
<p>It also replaces CPP #if with C if for readability.</p>
</blockquote>
<p>I don't think it is needed.</p>
</blockquote>
<p>OK, does it that mean UNDEFINED_METHOD_ENTRY_P is unnecessary<br>
with cache disabled? Could just do this:<br>
<a href="http://80x24.org/gmc_disable.patch" class="external">http://80x24.org/gmc_disable.patch</a></p>
</blockquote>
<p>I meant "replace CPP #if with C".</p> Ruby master - Bug #9262: global_method_cache should be configurable or grow automaticallyhttps://bugs.ruby-lang.org/issues/9262?journal_id=628822017-02-06T03:46:44Zko1 (Koichi Sasada)
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li><li><strong>Backport</strong> deleted (<del><i>1.9.3: UNKNOWN, 2.0.0: UNKNOWN</i></del>)</li></ul><p>I close this issue because I want to try another approach.<br>
Otherwise, current MRI has global variable to configure this size.</p>