Re: Copy-on-write friendly garbage collector

Hi,

In message "Re: Copy-on-write friendly garbage
collector"
    on Thu, 20 Mar 2008 21:54:04 +0900, Hongli Lai
<hongliplan99.net> writes:

|Yes, I use the following tool for benchmarking:
|http://pastebin.com/m26
839d72

I feel this one is bit too simple.  Since GC behavior
heavily depends
on object allocation pattern of programs, I guess we need
more
realistic cases to benchmark.  Perhaps we should contact
Lloyd for his
cases in <http://lloy
dforge.org/projects/ruby/>.

By the way, I'd like to know how much effective this
copy-on-write
friendly patch is.  Does anyone have a good (even
artificial) case?

|I'd like to know whether my patches are acceptable, now
that it's just 
|as fast as the normal Ruby by default. And if it's not
acceptable, I'd 
|like to know how many % speed hit would be acceptable.

2% loss for almost all cases are good enough.  But I cannot
be sure
for 2% for this specific case.

							matz.

Yukihiro Matsumoto wrote:
> By the way, I'd like to know how much effective this
copy-on-write
> friendly patch is.  Does anyone have a good (even
artificial) case?

I use the following test:
http://pastebin.com/f35
3f2ade
It loads Ruby on Rails (2.0.2), then runs garbage collection
in a child 
process.

The results are as follows:

== Standard Ruby:

After forking, before gc:
- Parent process: 64 KB private dirty memory
- Child process 1: 60 KB private dirty memory
- Child process 2: 128 KB private dirty memory

After forking, after gc:
- Parent process: 64 KB private dirty memory
- Child process 1: 60 KB private dirty memory
- Child process 2: 9.1 MB private dirty memory

== My Ruby:

After forking, before gc:
- Parent process: 64 KB private dirty memory
- Child process 1: 60 KB private dirty memory
- Child process 2: 156 KB private dirty memory

After forking, after gc:
- Parent process: 64 KB private dirty memory
- Child process 1: 60 KB private dirty memory
- Child process 2: 1.1 MB private dirty memory

Some parts of the memory are made dirty for as yet unknown
reasons. It 
seems to have something to do with the way the system
malloc() is 
implemented.

Yukihiro Matsumoto wrote:
> By the way, I'd like to know how much effective this
copy-on-write
> friendly patch is.  Does anyone have a good (even
artificial) case?

Very artificial: [ruby-talk:186561]

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665
3407