[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: after gbc hook

From: Camm Maguire
Subject: [Gcl-devel] Re: after gbc hook
Date: 01 Dec 2005 19:02:02 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Robert Boyer <address@hidden> writes:

> I am studying your last two messages intently.  I can at least answer one
> question.
> > Have you tried not collecting anything, and letting the area fill up
> > as long as possible?
> Things work very well at least until a GC happens.  Even after many GCs,
> things often continue working very well.  But occasionally, after a GC call,
> or the subsequent *after-gbc-hook* call, or the unfortunate absence of same,
> things get screwy.
> > Also please know that only the honses reachable from the 'root set' will be
> > marked -- i.e the lisp stacks, the C stack, explicitly entered mark
> > origins, and internal and external symbols of known packages.  If the mark
> > tree would start at a hons (on a contiguous page), said tree will remain
> > unmarked.
> I think I understand this point very well, even intuitively.  Marking has got
> to start from known places, such as symbols.
> > While gcl never directly modifies data stored in contiguous
> > pages during the mark phase
> This remark of yours makes my head spin with certainty that I don't know what
> I am doing.  Consider the following transcript, in which the contents of
> location 0 of the array foo, located in contiguous space, because of the
> :static t declaration, is obviously marked by the explicitly invoked gc.

Please excuse my last gibberish post on this subject -- what I said
here was completely wrong.  GCL, as I originally stated, never
modifies contiguous data during marking *deliberately*, i.e. when any
of its conventionally allocated objects point to such data.  For
example, the pointers in static object arrays are marked via the mark
table, and then the object pointed to by said pointers (on
non-contiguous pages) are then marked.  This last part is omitted
moreover if the array is a fixnum or other such array as it is here.

Pointers to contiguous data are never exposed to the user in GCL, but
are rather hidden within the object structure -- the GBC algorithm
relies on this hiddenness in that no provision is made to unmark
contiguous data in any event, which would be necessary if conventional
object reference hierarchies could reach contiguous data (i.e. the car
or cdr of a cons was on a contiguous page).  The concept is opaque
unmovable data.

So what you are doing is exposing such pointers for use in
conventional lisp objects.  I.e., the gbc example below creates a cons
object (cdr (si::nani (+ 12 (si::address foo)))) when eval'ed and
assigns it to the variable '**.  Recall that the toplevel holds the
last few commands in '+, '++, ... '-, '--, and so on with '* and '/.
If you precede the gc call with a bunch of other commands to the repl
to clean '** and the like, then the gc will not modify your data as it
no longer reach this "cons".

So in sum the only way this data will get marked in place as a cons is
via conventional objects referring to it in the place conventional
objects are supposed to store other object pointers, (e.g. the cdr of
a cons).  While this might explain a few unnecessary marks your hook
would have to revert, it does not (yet) explain the absence of marks
you would expect leading to a segfault later.

Take care,

> Bob
> -------------------------------------------------------------------------------
> GCL (GNU Common Lisp)  2.7.0 ANSI    Nov 29 2005 17:37:12
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> Use (help) to get some basic information on how to use GCL.
> >(setq foo (make-array 2 :element-type 'fixnum :static t))
> #(0 0)
> >(setf (aref foo 0) (si::address t))
> 149959512
> > 
> (setf (aref foo 1) (si::address nil))
> 151272920
> (si::nani (si::address (cdr (si::nani (+ 12 (si::address foo))))))
> (NIL . T)
> >(si::gbc t)
> T
> >(aref foo 0)
> 149959514               <= here, the value has magically increased by 2 
> because of marking, no?
> >

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]