gen gc

gen gc

[Han-Wen]

How is this supposed to portable to GenGC? 

   SCM_DEFINE (scm_object_address, "object-address", 1, 0, 0,
            (SCM obj),
	    "Return an integer that for the lifetime of @var{obj} is uniquely\n"
	    "returned by this function for @var{obj}")

This is used in some of the goops code -- should I retain it? 

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> writes:

> How is this supposed to portable to GenGC? 
> 
>    SCM_DEFINE (scm_object_address, "object-address", 1, 0, 0,
>             (SCM obj),
> 	    "Return an integer that for the lifetime of @var{obj} is uniquely\n"
> 	    "returned by this function for @var{obj}")
> 
> This is used in some of the goops code -- should I retain it? 

It would be cool if you could fake it.  It doesn't need to be the real
memory address of the object, just a unique integer.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Han-Wen]

mvo@zagadka.ping.de writes:
> Han-Wen <hanwen@cs.uu.nl> writes:
> 
> > How is this supposed to portable to GenGC? 
> > 
> >    SCM_DEFINE (scm_object_address, "object-address", 1, 0, 0,
> >             (SCM obj),
> > 	    "Return an integer that for the lifetime of @var{obj} is uniquely\n"
> > 	    "returned by this function for @var{obj}")
> > 
> > This is used in some of the goops code -- should I retain it? 
> 
> It would be cool if you could fake it.  It doesn't need to be the real
> memory address of the object, just a unique integer.

?

What if I can't?  Memory cells are going to move around. I don't see a
way to generate a unique number without making some kind of table for
objects subjected to object-address. 

Btw, I can imagine that internal hash tables might use the address of
a cell as a source for a hash index. Does that happen anywhere?

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Han-Wen Nienhuys]

miro@puremagic.com writes:
> >>>   SCM_DEFINE (scm_object_address, "object-address", 1, 0, 0,
> >>>            (SCM obj),
> >>>	    "Return an integer that for the lifetime of @var{obj} is uniquely\n"
> >>>	    "returned by this function for @var{obj}")

> >What if I can't?  Memory cells are going to move around. I don't see a
> >way to generate a unique number without making some kind of table for
> >objects subjected to object-address. 
> >  
> >
> Actually it only says it should be unique, not never-changing. In 
> particular,
> all it needs for eq? to grok it is uniqueness. I guess just returning 
> the address
> ought to work, no?

It says "for the lifetime of this object".

Anyways, the goops code only uses the address for printing, so it
would safe to return the address. I suggest that the documentation be
changed to

	"Return the address of OBJ as an integer. Note that this
	address may change between runs due to garbage collection."

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Miroslav Silovic]

Han-Wen wrote:

>mvo@zagadka.ping.de writes:
>  
>
>>Han-Wen <hanwen@cs.uu.nl> writes:
>>
>>    
>>
>>>How is this supposed to portable to GenGC? 
>>>
>>>   SCM_DEFINE (scm_object_address, "object-address", 1, 0, 0,
>>>            (SCM obj),
>>>	    "Return an integer that for the lifetime of @var{obj} is uniquely\n"
>>>	    "returned by this function for @var{obj}")
>>>
>>>This is used in some of the goops code -- should I retain it? 
>>>      
>>>
>>It would be cool if you could fake it.  It doesn't need to be the real
>>memory address of the object, just a unique integer.
>>    
>>
>
>?
>
>What if I can't?  Memory cells are going to move around. I don't see a
>way to generate a unique number without making some kind of table for
>objects subjected to object-address. 
>  
>
Actually it only says it should be unique, not never-changing. In 
particular,
all it needs for eq? to grok it is uniqueness. I guess just returning 
the address
ought to work, no?

    Miro



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Dirk Herrmann]

On Thu, 18 Jul 2002, Han-Wen wrote:

> mvo@zagadka.ping.de writes:
> > Han-Wen <hanwen@cs.uu.nl> writes:
> > 
> > > How is this supposed to portable to GenGC? 
> > > 
> > >    SCM_DEFINE (scm_object_address, "object-address", 1, 0, 0,
> > >             (SCM obj),
> > > 	    "Return an integer that for the lifetime of @var{obj} is uniquely\n"
> > > 	    "returned by this function for @var{obj}")
> > > 
> > > This is used in some of the goops code -- should I retain it? 
> > 
> > It would be cool if you could fake it.  It doesn't need to be the real
> > memory address of the object, just a unique integer.
> 
> ?
> 
> What if I can't?  Memory cells are going to move around. I don't see a
> way to generate a unique number without making some kind of table for
> objects subjected to object-address. 
> 
> Btw, I can imagine that internal hash tables might use the address of
> a cell as a source for a hash index. Does that happen anywhere?

Look into hash.[ch].  scm_hashq seems to be what you think of.

Best regards,
Dirk Herrmann


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Han-Wen Nienhuys]

dirk@sallust.ida.ing.tu-bs.de writes:
> > What if I can't?  Memory cells are going to move around. I don't see a
> > way to generate a unique number without making some kind of table for
> > objects subjected to object-address. 
> > 
> > Btw, I can imagine that internal hash tables might use the address of
> > a cell as a source for a hash index. Does that happen anywhere?
> 
> Look into hash.[ch].  scm_hashq seems to be what you think of.

OK. In that case, how is this handled?  Can we simply disallow plain
cells as hash keys?  Oh wait scm_hasher doesn't use the adress of an
object. Good.


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Rob Browning]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> Anyways, the goops code only uses the address for printing, so it
> would safe to return the address. I suggest that the documentation be
> changed to
>
> 	"Return the address of OBJ as an integer. Note that this
> 	address may change between runs due to garbage collection."

Alternately if we really need a unique value, and if it's only used
for printing -- couldn't we just use a good old fashioned integer
counter?  What's the point of printing the address of the object if
it's only the transient address of the object, unless perhaps the
value's only intended for debugging?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Han-Wen]

rlb@defaultvalue.org writes:
> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > Anyways, the goops code only uses the address for printing, so it
> > would safe to return the address. I suggest that the documentation be
> > changed to
> >
> > 	"Return the address of OBJ as an integer. Note that this
> > 	address may change between runs due to garbage collection."
> 
> Alternately if we really need a unique value, and if it's only used
> for printing -- couldn't we just use a good old fashioned integer
> counter?  What's the point of printing the address of the object if
> it's only the transient address of the object, unless perhaps the
> value's only intended for debugging?

What do you mean by integer counter? You have to store a reference to
the object when object-address is first invoked on it; then you might
as well store the object in a list and simply mark it conservatively.
(and then you have to add support to maintain the list weakly --
argh).

The value is only intended for human consumption (i.e. debugging)


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Rob Browning]

Han-Wen <hanwen@cs.uu.nl> writes:

> What do you mean by integer counter?

A unique per-object value taken from a plain old integer sequence.
i.e. the first object is 1, the second is 2, etc.

> The value is only intended for human consumption (i.e. debugging)

OK, that's one thing I wasn't sure of, and given that, I wasn't sure
whether a unique number that's constant across the lifetime of the
object (an integer), or the address (which may change) would be more
useful.  I suppose it depends on what type of debugging you're trying
to do, and of course, the address would be cheaper to provide.

Note though, that if there's not supposed to be a way to look up an
object by its object-address value, then you don't need to store the
values in a hash table mapping to objects or similar.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Tom Lord]

I think that assuming a bibop memory manager can solve the "stable
value assocated with possibly moving object" problem in some nice
ways.

-t

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Han-Wen Nienhuys]

rlb@defaultvalue.org writes:
> Han-Wen <hanwen@cs.uu.nl> writes:
> 
> > What do you mean by integer counter?
> 
> A unique per-object value taken from a plain old integer sequence.
> i.e. the first object is 1, the second is 2, etc.

The point is that the number should be associated with the object, and
you have to remember that association, since addresses might change
between any two calls of object-address.

If we don't have to keep an association, then ...  well we could
return any random number (say, the outcome of rand() ) and the whole
procedure is pointless.

--
Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Rob Browning]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> The point is that the number should be associated with the object, and
> you have to remember that association, since addresses might change
> between any two calls of object-address.
>
> If we don't have to keep an association, then ...  well we could
> return any random number (say, the outcome of rand() ) and the whole
> procedure is pointless.

Apparently I'm misunderstanding you or the issue.

Earlier I thought you posted that object-address's docs say that it's
supposed to return a value that's unique to the object, and I thought
you also said that that the returned value was only ever used for
display purposes (i.e. no one will ever say "give me the object
corresponding to address N").  

If both of those bits are true, then all I was saying was that when
you create an object, you could assign it a unique integer (from a
counter) -- i.e. stick the integer into the object, and object-address
could just look in the object and return that integer whenever called.

Of course if object-address is infrequently used, this may be a
wasteful approach (storage-wise), but if the value isn't supposed to
change across the lifetime of the object (which is what the docs you
posted made it sound like initially, and what I was thinking about
when I responded initially), then it's a better idea than printing the
(transient) address.

Of course if the object-address docs are wrong, then that's a
different story.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Han-Wen]

rlb@defaultvalue.org writes:
> Earlier I thought you posted that object-address's docs say that it's
> supposed to return a value that's unique to the object, and I thought
> you also said that that the returned value was only ever used for
> display purposes (i.e. no one will ever say "give me the object
> corresponding to address N").  
> 
> If both of those bits are true, then all I was saying was that when
> you create an object, you could assign it a unique integer (from a
> counter) -- i.e. stick the integer into the object, and object-address
> could just look in the object and return that integer whenever called.

Most objects don't allow for places to insert extra
integers. object-address takes a general scheme object, and eg. in a
cons there is no room for an extra number.

> Of course if the object-address docs are wrong, then that's a
> different story.

Unless I'm mistaken, object-address is not standard Scheme, so we can
pretty much change the docs to suit our needs :)

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> writes:

> mvo@zagadka.ping.de writes:
>
> > It would be cool if you could fake it.  It doesn't need to be the real
> > memory address of the object, just a unique integer.
> 
> What if I can't?

Then we can remove object-address.  If people need something like it,
we can keep it, but with a different name and the warning that the
address of an object might change over its lifetime.

> Memory cells are going to move around. I don't see a way to generate
> a unique number without making some kind of table for objects
> subjected to object-address.

Yes.  But for a deprecation period, this will be good enough, no?

> Btw, I can imagine that internal hash tables might use the address of
> a cell as a source for a hash index. Does that happen anywhere?

Yes, in scm_ihashq and scm_ihashv and maybe elsewhere.  There are
techniques to deal with this, I believe...

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> Anyways, the goops code only uses the address for printing, so it
> would safe to return the address. I suggest that the documentation be
> changed to
> 
> 	"Return the address of OBJ as an integer. Note that this
> 	address may change between runs due to garbage collection."

I'd say it would be better to also change the name of the function so
that nobody is tricked by the changed semantics.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Rob Browning]

Han-Wen <hanwen@cs.uu.nl> writes:

> Most objects don't allow for places to insert extra
> integers. object-address takes a general scheme object, and eg. in a
> cons there is no room for an extra number.

Ahh, OK.  I did misunderdstand.  I didn't realize this was for all
objects.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: gen gc

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Then we can remove object-address.  If people need something like it,
    Marius> we can keep it, but with a different name and the warning that the
    Marius> address of an object might change over its lifetime.

It would be good to post a heads-up to guile-user on this.

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel