From: ahoward <ahoward@...>
Date: 2002-10-23T00:37:14+09:00
Subject: Re: rb_gc_register_address problem

On Tue, 22 Oct 2002, William Djaja Tjokroaminata wrote:

> (deleted)
> > But if the GC stores a VALUE* instead of a VALUE, this is an extra (and
> > seemingly unnecessary) indirection.  I was curious if there was a reason
> > for it, other than to prevent me from doing what I did.
>
> I think this is because all Ruby VALUE's of type pointer (not immediate
> object) is allocated from a single heap.  As you call
> rb_global_variable(), Matz created a linked list containing all the
> addresses of the global variables.  During the gc marking process, Matz
> simply goes through this list and marks the VALUE pointed by each
> VALUE*.  If you had given Matz a VALUE instead, during the gc marking
> process Matz has to go through the heap to find the exact VALUE and mark
> it for each global variable, and now the process is of O(N**2) instead of
> O(N).

sounds complicated - why not this simple explanation illustrated here :

  #include <stdlib.h>
  #include <stdio.h>

  void
  i_can_change_what_memory_you_point_to (ptr)
    char **ptr;
  {
    *ptr = "barfoo";
  }

  void
  i_can_change_the_memory_you_point_to (ptr)
    char *ptr;
  {
    *ptr = 'b';
  }


  int
  main (int argc, char **argv, char **env)
  {
    char *buf = malloc(42);
    char *ptr;

    ptr = buf;
    strcpy (ptr, "foobar");
    printf("%s\n", ptr);                  /* -->> "foobar" */
    i_can_change_what_memory_you_point_to (&ptr);
    printf("%s\n", ptr);                  /* -->> "barfoo" */

    ptr = buf;
    strcpy (ptr, "foo");
    printf("%s\n", ptr);                  /* -->> "foo" */
    i_can_change_the_memory_you_point_to (ptr);
    printf("%s\n", ptr);                  /* -->> "boo"    */

    return 0;
  }


the gc _must_ have a prototype like 'i_can_change_what_memory_you_point_to' so
it may, for example, point an object to nil.  otherwise it could only change
the objects pointed to themselves!

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================