[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> =

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> =

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

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

From: SASADA Koichi <ko1@...>
Date: 2014-01-06 07:06:34 UTC
List: ruby-core #59577
Hi,

Now, method cache technique is important and we need more measurement
and techniques.

##

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.

funny_falcon's approach is very impressive to solve this problem.
However, now I'm not sure how it increase memory imapct.

tmm1 measured the memory impact on
https://bugs.ruby-lang.org/issues/9262#change-43840 . This survery is
very impressive. I think it is better we measure other cases. For
example, if some classes calls many methods at onece, it will memory
issue. I think the simple limitation (cap) approach with funny_falcon's
patch works fine.

##

New years holiday (Japanese take holidays in new years week), I'm
thinking about this issue. Some ideas are available.

(1) inline cache
  (1-1) polymorphic inline cache
  (1-2) per class inline cache other than call site
  (1-3) per-method cache invalidation
(2) global cache
  (2-1) per class method cache w/ cap

Now the above ideas are not implemented/verified. And huge effort is
needed (because we need to change the method entry data structure).
Before the try, I need to know the why and how method cache is missed.

##

Basically I don't against to introduce and backport some proposed
patches (w/ measurement, if we can). In my opinion, simple variable
global cache entry size approach will fine for backport.

And also I try above ideas for Ruby 2.2. Current patches are good
starting point, I think.

-- 
// SASADA Koichi at atdot dot net

In This Thread