[#31589] [Bug #3457] URI.encode does not escape square brackets — Shyouhei Urabe <redmine@...>
Issue #3457 has been updated by Shyouhei Urabe.
4 messages
2010/08/02
[#31614] Release engineering status of 1.9.2-p0 — Yusuke ENDOH <mame@...>
Hi,
4 messages
2010/08/04
[#31666] [Bug #3677] unable to run certain gem binaries' in windows 7 — Roger Pack <redmine@...>
Bug #3677: unable to run certain gem binaries' in windows 7
10 messages
2010/08/10
[#31668] [Bug #3677][Rejected] unable to run certain gem binaries' in windows 7
— Roger Pack <redmine@...>
2010/08/10
Issue #3677 has been updated by Roger Pack.
[#31681] [Bug #3683] getgrnam on computer with NIS group (+)? — Rocky Bernstein <redmine@...>
Bug #3683: getgrnam on computer with NIS group (+)?
13 messages
2010/08/11
[#32106] [Ruby 1.9-Bug#3683] getgrnam on computer with NIS group (+)?
— Rocky Bernstein <redmine@...>
2010/09/07
Issue #3683 has been updated by Rocky Bernstein.
[#32112] Re: [Ruby 1.9-Bug#3683] getgrnam on computer with NIS group (+)?
— Nobuyoshi Nakada <nobu@...>
2010/09/07
Hi,
[#31706] [Bug #3690] method_missing in a BasicObject's singleton class - infinite recursion segfaults — Jan Lelis <redmine@...>
Bug #3690: method_missing in a BasicObject's singleton class - infinite recursion segfaults
6 messages
2010/08/13
[#31730] [Bug #3701] Gem.find_files returns empty array — Yusuke Endoh <redmine@...>
Bug #3701: Gem.find_files returns empty array
4 messages
2010/08/16
[#31739] [Backport #3702] segmentation fault while compiling 1.9.1-p430 on debian squeeze — Tomasz Pajor <redmine@...>
Backport #3702: segmentation fault while compiling 1.9.1-p430 on debian squeeze
7 messages
2010/08/17
[#31757] [Bug #3712] SEGV fails to produce stack dump / backtrace in debug build — Peter Weldon <redmine@...>
Bug #3712: SEGV fails to produce stack dump / backtrace in debug build
5 messages
2010/08/18
[#31761] [Feature #3714] Add getters for Enumerator — Marc-Andre Lafortune <redmine@...>
Feature #3714: Add getters for Enumerator
6 messages
2010/08/18
[#31762] [Backport #3715] Enumerator#size and #size= — Marc-Andre Lafortune <redmine@...>
Backport #3715: Enumerator#size and #size=
8 messages
2010/08/18
[#31798] [Bug #3726] require degradation from 1.9.1 — Yura Sokolov <redmine@...>
Bug #3726: require degradation from 1.9.1
8 messages
2010/08/20
[#31805] [Backport #3728] IO.select is not documented. — Mike Perham <redmine@...>
Backport #3728: IO.select is not documented.
5 messages
2010/08/20
[#31806] 1.9.1 has marshal bugs in everything but p129 — Ryan Davis <ryand-ruby@...>
Is there any chance we can release a 1.9.1 that fixes the current =
3 messages
2010/08/20
[#31843] Garbage Collection Question — Asher <asher@...>
This question is no doubt a function of my own lack of understanding, =
17 messages
2010/08/25
[#31861] Re: Garbage Collection Question
— Roger Pack <rogerdpack2@...>
2010/08/26
> The question in short: when an object goes out of scope and has no
[#31862] Re: Garbage Collection Question
— Asher <asher@...>
2010/08/26
Right - so how does a pointer ever get off the stack?
[#31873] Re: Garbage Collection Question
— Kurt Stephens <ks@...>
2010/08/27
On 8/26/10 11:51 AM, Asher wrote:
[#31894] Re: Garbage Collection Question
— Asher <asher@...>
2010/08/27
I very much appreciate the response, and this is helpful in describing =
[#31896] Re: Garbage Collection Question
— Evan Phoenix <evan@...>
2010/08/27
You have introduced something called a "root node" without defining it. =
[#31899] Re: Garbage Collection Question
— Asher <asher@...>
2010/08/27
[#31851] [Bug #3747] Possible bug of String#count? — Ruohao Li <redmine@...>
Bug #3747: Possible bug of String#count?
4 messages
2010/08/26
[#31868] [Bug #3750] SEGV: ruby -rprofile test/ruby/test_assignment.rb — Peter Weldon <redmine@...>
Bug #3750: SEGV: ruby -rprofile test/ruby/test_assignment.rb
5 messages
2010/08/26
[#31885] Avoiding $LOAD_PATH pollution — Eric Hodel <[email protected]>
Last year Nobu asked me to propose an API for adding an object to
21 messages
2010/08/27
[#31906] Re: Avoiding $LOAD_PATH pollution
— Run Paint Run Run <runrun@...>
2010/08/28
> The lookup object pushed onto $LOAD_PATH must respond to #path_for. The
[#31910] Re: Avoiding $LOAD_PATH pollution
— Eric Hodel <[email protected]>
2010/08/28
On Aug 28, 2010, at 19:30, Run Paint Run Run wrote:
[#31911] Re: Avoiding $LOAD_PATH pollution
— Run Paint Run Run <runrun@...>
2010/08/28
>> How confident are we that this API would be sufficient for replacing the
[#34260] Re: Avoiding $LOAD_PATH pollution
— "zimbatm ..." <jonas@...>
2011/01/08
Hi Eric,
[#34262] Re: Avoiding $LOAD_PATH pollution
— "Jonas Pfenniger (zimbatm)" <jonas@...>
2011/01/08
Just a note for future references. While playing with require, I found
[#34264] Re: Avoiding $LOAD_PATH pollution
— Eric Hodel <[email protected]>
2011/01/09
On Jan 8, 2011, at 12:08, zimbatm ... wrote:
[#31914] [Ruby 1.8.7-RubySpec#3757][Open] GC bug after loading gem — Joel VanderWerf <redmine@...>
RubySpec #3757: GC bug after loading gem
5 messages
2010/08/28
[#31929] Proposal: Autoload with block — Magnus Holm <judofyr@...>
= A proposal for autoload w/block:
8 messages
2010/08/29
[#31930] Re: Proposal: Autoload with block
— James Tucker <jftucker@...>
2010/08/29
Sorry to plug my own stuff, but you might find subload of some interest =
[#31933] Re: Proposal: Autoload with block
— Run Paint Run Run <runrun@...>
2010/08/29
Magnus, have you seen http://redmine.ruby-lang.org/issues/show/462 ?
[#31934] Re: Proposal: Autoload with block
— Magnus Holm <judofyr@...>
2010/08/29
That's interesting, but I don't buy matz' argument:
[#31947] not use system for default encoding — Roger Pack <rogerdpack2@...>
It strikes me as a bit "scary" to use system locale settings to
19 messages
2010/08/30
[#31960] Re: not use system for default encoding
— Run Paint Run Run <runrun@...>
2010/08/30
> It strikes me as a bit "scary" to use system locale settings to *arbitrar=
[#33235] Re: not use system for default encoding
— Brian Candler <B.Candler@...>
2010/11/17
NARUSE, Yui wrote on 2010-11-15 11:07:
[#31969] [Ruby 1.9-Feature#3773][Open] Module#parent — Thomas Sawyer <redmine@...>
Feature #3773: Module#parent
9 messages
2010/08/31
[#31971] Change Ruby's License to BSDL + Ruby's dual license — "NARUSE, Yui" <naruse@...>
Ruby's License will change to BSDL + Ruby's dual license
16 messages
2010/08/31
[#31972] Re: Change Ruby's License to BSDL + Ruby's dual license
— "NARUSE, Yui" <naruse@...>
2010/08/31
(2010/09/01 1:30), NARUSE, Yui wrote:
[#32002] Re: Change Ruby's License to BSDL + Ruby's dual license
— Joshua Ballanco <jballanc@...>
2010/09/01
On Aug 31, 2010, at 9:50 AM, NARUSE, Yui wrote:
[#31976] Re: Change Ruby's License to BSDL + Ruby's dual license
— Lucas Nussbaum <lucas@...>
2010/08/31
On 01/09/10 at 01:30 +0900, NARUSE, Yui wrote:
[#31978] Re: Change Ruby's License to BSDL + Ruby's dual license
— "NARUSE, Yui" <naruse@...>
2010/08/31
(2010/09/01 2:36), Lucas Nussbaum wrote:
[#32364] Re: Change Ruby's License to BSDL + Ruby's dual license
— "NARUSE, Yui" <naruse@...>
2010/09/13
I wrote a concrete patch.
[ruby-core:31873] Re: Garbage Collection Question
From:
Kurt Stephens <ks@...>
Date:
2010-08-27 02:43:33 UTC
List:
ruby-core #31873
On 8/26/10 11:51 AM, Asher wrote:
> Right - so how does a pointer ever get off the stack?
>
When a C function returns, the C stack pointer register (usually called
"SP") is reset to the frame pointer (sometimes this register is called
"FP"). The FP points to the current function arguments. The area
between the SP and the FP +- the space for arguments (and the other
machine registers) represent the local variables, temporaries and
arguments of the current function call (sometimes called an "activation
record").
Load any C program under a debugger and you can see the assembly code.
The MRI GC knows where "top" (SP) and the bottom of the stack is because
of mostly portable conventions on how C compilers generate code that
manipulate SP and FP and how the operating system lays out the process'
memory. The stack, the machine registers and some global variables are
part of what is sometimes called the "root set".
The MRI GC scans the root set for values that "look like they point to
Ruby objects" and "marks" those objects recursively as "in use". Any
unmarked objects ("not in use") are definitely not referenced by
anything else and can be deallocated ("sweeped"). The GC must
"stop-the-world" while it does this "marking" and "sweeping" -- nothing
else can happen till this finishes. If the GC couldn't sweep anything,
it allocates more memory from the OS (by calling malloc(), which calls
something at a much lower level (sbrk() or mmap() or something else).
> For instance, in my example, where the variable with reference to the object has been assigned nil - the same thing occurs if the variable goes out of scope.
>
> So in both of those cases, the object "should" be garbage collected; I understand that it's possible, due to conservative GC, that it might mistake a number on the stack (a long), etc. as a valid pointer, but generally when GC runs it should decide that the var (which has no valid ruby references) is no longer live and should be GC'd. Or am I missing something?
>
> So we have a var with no references in Ruby that is being marked as live by the GC because the pointer has not yet been deallocated. So how does it ever get deallocated in order to not be marked as live?
>
> If what I am seeing is the case (and I assume it cannot be and that I am missing something) then the object would never be garbage collected.
>
> So how does GC actually occur?
Collection occurs in MRI when a new object is needed and there are no
unused objects left around and/or there was a certain number of
allocations since the last GC.
> What causes the pointer to be deallocated?
>
"Pointers" are never allocated or deallocated as in malloc()/free().
Only objects that have no references to them are deallocated.
The C compiler generates code that simply increments or decrements the
SP or changes the FP -- Stacks are FIFOs.
The MRI GC is a very simple "stop-the-world", "mark-and-sweep"
"conservative" collector. Conservative meaning "treat anything that
looks like a pointer to an object as a pointer to an object". This can
cause conservative collectors to keep some objects around longer than
they should. This is also be cause most C compilers leave garbage (old
pointers) on the stack.
The Rubinius GC is different. The MRI Enterprise Edition uses
additional techniques on top of the standard MRI GC to improve
performance in web servers and long-running processes.
> Asher
>
> On Aug 26, 2010, at 12:32 PM, Roger Pack wrote:
>
>> It walks the stack, and (for sake of ease of understanding) marks all
>> pointers still on the stack as "live"
>> then it marks all of their children as "live"
>> then all of their grandchildren, etc.
>>
>> Then it traverses the entire heap, looking for objects that haven't
>> been marked as live, and "frees" them.
>>
>> NB that these two stages are separate, so they don't conflict.
>> HTH.
>> -r
>
>
Yea, what Roger said. :)
More here:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29
A widely-ported and long-used GC can be downloaded here:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
ACM has a long rich history of GC research -- there's even a yearly
symposium on the subject. Appel's book is a great reference.
This book (sadly out of print) is a good introduction:
http://www.amazon.com/Topics-Advanced-Language-Implementation-Peter/dp/0262121514
There are far more complex GC algorithms that perform better in most
cases. Conservative mark-and-sweep collectors are far easier to
interface with C code than other approaches -- most others require
considerable cooperation between the code and the collector.
HTH^2,
-- KAS