Re: Recognising pointers during garbage collection?

nmm1@cus.cam.ac.uk (Nick Maclaren)
4 Sep 2003 22:49:24 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: Recognising pointers during garbage collection? cymric73@hotmail.com (Maarten D. de Jong) (2003-07-25)
Re: Recognising pointers during garbage collection? basile@starynkevitch.net (Basile STARYNKEVITCH) (2003-07-31)
Re: Recognising pointers during garbage collection? basile@starynkevitch.net (Basile STARYNKEVITCH) (2003-07-31)
Re: Recognising pointers during garbage collection? gneuner2@comcast.net (George Neuner) (2003-07-31)
Re: Recognising pointers during garbage collection? fjh@cs.mu.oz.au (Fergus Henderson) (2003-08-04)
Re: Recognising pointers during garbage collection? basile@starynkevitch.net (Basile STARYNKEVITCH) (2003-09-04)
Re: Recognising pointers during garbage collection? nmm1@cus.cam.ac.uk (2003-09-04)
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 4 Sep 2003 22:49:24 -0400
Organization: University of Cambridge, England
References: 03-07-149 03-07-186 03-07-204 03-09-010
Keywords: GC
Posted-Date: 04 Sep 2003 22:49:24 EDT

Basile STARYNKEVITCH <basile@starynkevitch.net> wrote:
>In an older article, I (Basile) wrote previously:
>
>Basile>> For example, Qish is a precise, generational copying, garbage
>Basile>> collector for (and in) C.
>
>but Fergus Henderson added (on 2003-08-03 21:23:01 PST)
>
>Fergus> That is not a particularly good example, IMHO, since Qish is
>Fergus> not written in standard C; it relies on undefined behaviour.
>
>I don't believe it is true (at least for the latest Qish version 0.9,
>which was released around february 23rd 2003).


I haven't looked at it, but Fergus's point will remain true. Even if
it does not rely on undefined behaviour DIRECTLY, it will do so by
relying on implementation-defined, implementation dependent and
unspecified behaviour to do what it wants.


And later, as you point out, it is not for C anyway. It is for a
subset of C.


>Qish does rely on volatile pointers, but it does not need the
>-fvolatile flag (or any particular compilation flag) - even if I did
>claimed incorrectly in previous releases that Qish needs such flags. I
>checked with ths ISO90 C spec lately.


See below.


>I apologise for having wrongly stated in previous releases that some
>particular compilation flags are needed. I do think that every correct
>C compiler can compile Qish code (provided the compiler does follow
>the volatile keyword correctly...)


See below.


>So the correct use of Qish is to:
>
>1. have all GC pointers declared as volatile;
>
>2. have all local GC pointers put into a volatile struct named
>_locals_
>
>3. more generally follow appropriately the [restrictive] Qish coding
> style (which includes the above 2 rules), in particular avoid
> imbricated functions calls like f(g(h(x),y),z) and call appropriate
> prologue & epilogue macros.


Very much a subset of C.


>Could Fergus (or others) please examine the latest (0.9) version of
>Qish and tell exactly what is undefined behavior in Qish. Please read
>and discuss the code, which is more correct than the (poor)
>documentation.


If I get a moment, I may take a look, but you won't like my comments.
Most of them will refer to insuperable obstacles, where there is NO
way to do something in a defined fashion.


>Actually, I think that the previous versions of Qish did not need any
>particular compiler flag neither, but I failed to understand that when
>releasing it. It is a matter of precisely understand the meaning of
>volatile.


Well, considering that the committee that specified the standard
disagree about its meaning, and every implementation I have looked
at differs, that is a trifle hard to achieve ....


If you read the standard CAREFULLY, with knowledge of the discussions
on the reflector, you will discover that volatile has no portable
meaning. It implies saome constraints, but its meaning and use are
entirely implementation dependent (NOT implementation-defined).


Sorry.




Regards,
Nick Maclaren.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.