[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70603] [Ruby trunk - Bug #11490] [Open] Allocation tracer sometimes attributes allocations to the wrong source file/line
From:
godfreykfc@...
Date:
2015-08-27 07:38:55 UTC
List:
ruby-core #70603
Issue #11490 has been reported by Godfrey Chan. ---------------------------------------- Bug #11490: Allocation tracer sometimes attributes allocations to the wrong source file/line https://bugs.ruby-lang.org/issues/11490 * Author: Godfrey Chan * Status: Open * Priority: Normal * Assignee: * ruby -v: * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- See the reproduction script in https://gist.github.com/chancancode/dc175e702c02cdfa5ffb This was originally brought to my attention via https://github.com/skylightio/skylight-ruby/issues/36 As you can see in the Github ticket, we overwrote `Kernel#require` and was incorrectly blamed for allocating a lot of objects/memory. I checked the source and saw that the file/line info is filled by the [last Ruby-land control frame](https://github.com/ruby/ruby/blob/7cf523c7db67c22ffc09b38a9c5bea057f578db2/vm_trace.c#L752), so I was almost ready to accept this as an unfortunate artifact that cannot be fixed. However, when I made the standalone reproduction script to test my theory, I noticed that it actually gets it right sometimes (the lines that reports `nokogiri.bundle:0` instead of `allocation_tracker_bug.rb:11`), so it seems like something else is going on here. By the way, since RubyGems overwrites `Kernel#require`, even without any other third-party libraries loaded, you can already observe allocation tracer attributing a lot of allocations to RubyGem's `kernel_require.rb` out of the box. ---Files-------------------------------- allocation_tracker_bug.rb (786 Bytes) -- https://bugs.ruby-lang.org/