From: Tom Sawyer <transami@...>
Date: 2002-07-05T11:34:36+09:00
Subject: Re: Ruby implementation Q's

i know next to nothing about GC's, yet i wonder: when is it, in ones
code, that references are lost?

my initital answers:

1. for all objects: when the program ends execution
2. for local instances in a method: when the method completes execution

when else? 

is there a pattern here that can be tapped into such that by monitoring
a type of "scope" for an object, when that scope is completed all
objects within it should be destroyed?

just some thoughts,
~transami

p.s. if you really want speed for an embedded solution why do GC at all?
just take the c/c++ approach.


On Mon, 2002-07-01 at 10:50, Justin Johnson wrote:
> Apologies in advance for this meaty posting:
> 
> I'm currently in the process of developing a Ruby implementation
> that's more suited to embedding.
> I had a look at many languages, Smalltalk, Lisp, Scheme, Self, Python,
> Java, C#, Lua, ElastiC, but figured that Ruby has the cleanest and
> most appealing OO model and language syntax.
>    
> Here's a few differences with regards to my implementation. I wonder
> if anybody here would like to comment:
>    
> 1. I support the Ruby core language and object model but won't be
> implementing all of the libraries.  For example, file handling and
> regexp will be optional.  Networking and net programming won't be
> supported.
> 2. I've written a generational garbage collector that should be much
> faster than the Ruby mark-and-sweep collector.  The young generation
> is implemented using a Cheney-style copying collector which means that
> allocations are very fast and only the 'live' set is visited.  There
> is a seperate 'large-chunk' space for dealing with large binary
> resources.
> 3. In the current Ruby implementation, everything is represented by
> linked nodes.  Unless I'm mistaken, that means that even code is
> scanned for garbage collection.  I have the concept of an atom or
> slot.  These are 64bit elementes that represent 32bits of flags/counts
> and a data element.  Objects, even internal hash tables and arrays,
> are composed of these slots and are allocated in a unified way.
> 4. Methods are represented as bytecodes.  The method bytecodes are
> stored in the 'large-chunk' manager and so are not a burden on the
> garbage collector.  I'm still working out the best opcode arrangment.
> 5. I'm developing in C++.
>                          
> So far, I have the garbage collector and the Ruby class and object
> code written, methods and class/instance variables can be accessed. 
> Mixins via include are fully supported and I have the initial Ruby
> metaclasses and class hierarchy initialized.  I have the beginnings of
> the lexer and parser.
> 
> After having a look at the original Ruby source code, a few things
> struck me:
> 
> 1. The internal symbol function is called rb_intern().  This generates
> a unique number with embedded symbol type and is used as a selector
> for method and variable lookups.  But a hash must be generated from
> this number each time which is a little time consuming.  Perhaps a
> speed improvement would be to have the intern return a pointer to a
> unique data structure which contains the precalculated hash value?
> 
> 	intern_symbol* pSymbol = rb_inter( ... );
> 	int hash = pSymbol->hash;
> 	int type = pSymbol->type;
>                          
> 2. The code implements a method cache to accelerate method lookup. 
> How about a cache for object variable lookup?  This would accelerate
> class variable lookup.
> 
> As a final point, I hear a lot of talk about finalization and it's
> pitfalls.  It seems to me that finalization happens to late to be
> truly useful.  What would the theoretical implications be of an
> optional destroy mechanism?
> 
> 	a = MyClass.new
> 	a.show			=> "I live!"
> 	a.destroy
> 	a.show			=> exception! 'a' does not exist!
>              
> The 'destroy' method would have the effect of broadcasting the
> 'destroy' message to all variables belonging to 'a'. 'a' would then be
> marked as destroyed, any pointers to 'a' would be treated similar to
> weak pointers - if they pointed to a destroyed object they could
> become pointers to 'Nil'.  The garbage collector could easily be made
> aware of this.
> This would allow the programmer to override the 'destroy' method and
> do _useful_ resource deallocation, file closing and all the other
> stuff that people complain about.
> 
> What issue might this raise? Not all classes should define 'destroy'
> for obvious reasons....
> 
> Lastly, gratitude to matz for developing such an elegant, powerful and
> simple language.
>               
> Justin Johnson
> justinj@mobiusent.com
> 
-- 
~transami

"They that can give up essential liberty to obtain a little
 temporary safety deserve neither liberty nor safety."
	-- Benjamin Franklin