From: Lothar Scholz Date: 2004-07-21T18:43:46+09:00 Subject: Re: Ruby Specification Hello Ruben, R> At Wed, 21 Jul 2004 14:05:43 +0900, R> Lothar Scholz wrote: >> >> Arachno Ruby as a larger program is using the Boehm Weisser GC. That >> does not only consider all elements on the stack but also everything >> in the heap as possible pointers, so there are many things that can be >> wrongly considered as a still in use data. But this seems to be not R> Do you use it as a drop-in replacement for "malloc" ? Because, from Yes i only changed malloc and calloc. R> what i remember, this GC provides several functions to give it more R> precise information about the data in your heap. I think there are R> functions to tell it to allocate for example a chunk of memory for R> binary data for which you, as the programmer, guarantee that it will R> never contain pointers. Right, it can completely avoid scanning heap data if you give a type descriptor for allocated memory that tells the GC where it must look for embedded pointers. But this requires a larger hack in the SmartEiffel compiler and i hope that the new 2.0 release will fix the bugs in there internal GC. >> the problem, when i compare it with the exact SmartEiffel Internal GC, >> the overhead in non released data seems to be around 20%. The much >> more serious problem in the Boehm Weisser GC is the high internal heap >> fragmentation it seems to get stable after having 5 times the >> dataset size, from previous posts here i believe that the ruby GC is >> working well. R> This behavior depends for a great deal on the behavior of your R> application. For BDW, fragmentation could only be improved by having a R> better allocation strategy. Right, i heared about the same numbers on the smalleiffel mailing list from other persons. R> Compacting is only possible if you know the root set and have exact R> information about which cells contain a pointer and which cells R> don't. AFAIK, a pure compacting collector isn't possible with ruby R> because of the C extensions... or scanning the raw stack for finding R> pointers in the root set (?) Right, it is impossible with the current design and it needs a lot of changes to external C extensions and also the use of an own ruby thread instead of mixing it with the C stack. It's just that when you talk about a complete rewrite, like the OP's wish for a "rubycc" then it should be discussed. "matz" already pointed out that he don't care about fragmentation is will not add something like this to the official ruby implementation. -- Best regards, emailto: scholz at scriptolutions dot com Lothar Scholz http://www.ruby-ide.com CTO Scriptolutions Ruby, PHP, Python IDE 's