From petar@ida.liu.se Sat Nov 13 15:36:14 2004
Date: Thu, 25 Sep 2003 08:31:55 +0200 (MEST)
From: Peter Aronsson <petar@ida.liu.se>
To: adrpo@ida.liu.se
Cc: petfr@ida.liu.se
Subject: Re: RML vec-setnth

Hi.

Here is a reply from Mikael regarding sideeffects in RML when implementing a
set element operation on a vector.

Apparently the GC of RML does not support this. Have you much experience in this 
part of RML? Could you implement this?

/Peter

------------- Börja Vidarebefordrat meddelande -------------

X-Authentication-Warning: harpo.it.uu.se: mikpe set sender to mikpe@harpo using 
-f
MIME-Version: 1.0
Date: Wed, 24 Sep 2003 21:34:22 +0200
From: Mikael Pettersson <mikpe@csd.uu.se>
To: Peter Aronsson <petar@ida.liu.se>
Subject: Re: RML vec-setnth
X-Virus-Scanned: clamdscan / ClamAV version 0.60
X-Spam-Status: No, hits=-29.9 required=5.0 
tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, 
USER_AGENT_VM,X_AUTH_WARNING version=2.53-ida_0.5
X-Spam-Checker-Version: SpamAssassin 2.53-ida_0.5 (1.174.2.15-2003-03-30-exp)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by portofix.ida.liu.se id 
h8OJYQXW016469

Peter Aronsson writes:
 > Hejsan.
 > 
 > Av prestandaskäl vill jag implementera vec-setnth, dvs sätta ett element 
 > i en vector.
 > relation vector_setnth: ('a vector,int,'a) => ('a vector)
 > 
 > Här är min implementation:
 > 
 > RML_BEGIN_LABEL(System__vector_5fsetnth)
 > {
 >     rml_uint_t nelts = 0;
 >     void *vec = rmlA0;
 >     void *data;
 >     rml_uint_t i = (rml_uint_t)RML_UNTAGFIXNUM(rmlA1);
 >     if( i >= RML_HDRSLOTS(RML_GETHDR(vec)) ) {
 >       RML_TAILCALLK(rmlFC);
 >     } else {
 >       RML_STRUCTDATA(vec)[i] = rmlA2;     
 >       RML_TAILCALLK(rmlSC);
 >     }
 > }
 > RML_END_LABEL
 > 
 > När jag använder denna implemetation får jag segmenteringsfel.
 > Är det gc:n som ej registrerar det nya värdet, eller har du någon annan 
 > ide om vad som kan vara fel?

Felet är väntat. Generationsbaserade garbage collectors klarar
bara av sidoeffekter på heap-allokerat data om de också har s.k.
skrivbarriärer. Problemet är att sidoeffekter skapar wrong-way
pointers som invaliderar generationsstrukturen, med påföljd att
levande data kan frigöras eller att objekt kan flyttas utan att
alla referenser uppdateras. Skrivbarriären "registrerar" alla
celler innehållandes wrong-way pointers och ser till att dessa
tas hänsyn till vid garbningar.

RML har inga sådana muterbara data, och implementationen har
därför heller ingen skrivbarriär.

Det går självklart att implementera en sådan, men det får du
eller någon annan i Linköping i så fall göra. Jones och Lins
bok "Garbage Collection" publicerad av Wiley bör ha en Ok
beskrivning av problemet och olika lösningar.

/Mikael


------------- Avsluta Vidarebefordrat meddelande -------------


 _________________________________________________________________
/ Peter Aronsson, Phd Student at PELAB (Programming Environments  \ 
| Laboratory ) Department for Computer & Information Science      | 
| Linköping University, Sweden                                    | 
|=================================================================|
| petar@ida.liu.se , phone +46 (0)13-28 1737 Room 3B:490          |
\_________________________________________________________________/