Re: Problem in Thread.c
"Sébastien Adam" <[email protected]> Tue, 18 Apr 2006 11:30:23 +0000
| Newsgroups | gmane.comp.java.vm.sablevm.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0287351918== Content-Type: multipart/alternative; boundary="----=_Part_26918_8107470.1145359823699" ------=_Part_26918_8107470.1145359823699 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline For now, its a research work. I have implemented some garbage collectors bu= t I need to do some tests before publishing them. This summer I will write my master thesis and I will publish both my thesis and my GCs. So, you need to be patient a little bit :) I will happily share my work... very soon! Seb On 4/18/06, Carl Lebsack <[email protected]> wrote: > > So you didn't try the gencopy option? I believe it should be > functional. I periodically have been working on enhancements but > haven't had a lot of time lately. I'd be interested in the > differences you are implementing. The large object threshold I chose > was 2kB, but is easily alterable. > > I have been considering modifying my implementation to include an > Appel style generational collector. You mentioned you are doing > things "differently". Are you at liberty to share what you mean, or > is this research work? > > Carl Lebsack > > On 4/17/06, S=E9bastien Adam <[email protected]> wrote: > > > ./configure --with-gc=3Dgencopy > > > > ./configure --with-gc=3Dgc > > > > > > > You shouldn't need to "trace" anything in the older generation if the > > write barrier is set up correctly. A correct write barrier is > > necessary regardless of where large objects are initially allocated. > > The remembered set needs to be updated with any potential > > intergenerational references. When a large object is first allocated, > > none of its fields will have valid references (all zero/NULL). They > > will only be updated through later mutator actions that should be > > caught by a write barrier. > > > > Right... my mistake... I need to take a break to think about that > problem... > > for now... I don't have time... But if you have some hints... don't > hesitate > > to let me know... > > > > Actually, you can see a big difference in the gc time when you allocate > the > > large object in the oldest generation. With SableCC 2.18, many big > objects > > die young. If these objects are allocated in the oldest generation, the= y > are > > collected only when a full gc happens. This increase significantly the > gc > > time. Maybe I can increase the threshold between large and small object= s > > (1024 -> 8096 or even more). But the problem happens when the threshold > is > > 1024 bytes. > > > > > > > > > > > > > > > > On 4/17/06, Carl Lebsack <[email protected]> wrote: > > > On 4/17/06, S=E9bastien Adam <[email protected]> wrote: > > > > > I am curious. What type of generational collector are you > writing? > > > > Have you looked at the one included with SableVM currently? If so, > > > > what are the major differences? > > > > > > > > Yes... I have looked at the one included with SableVM but it doesn'= t > > work. I > > > > build my generational gc from scrash. It is quite different from th= e > > other. > > > > The write barrier is not the same, the algorithm to select the > > collection > > > > (minor, major, full) is not the same... In fact, pratically > everything > > is > > > > different. > > > > > > > > I am writing a report. Maybe I will publish it as soon as possible= . > > > > > > > > > > > > > > ./configure --with-gc=3Dgencopy > > > > > > This doesn't work? How so? I built the SDK just last week and ran i= t > > > on several benchmarks. What problem do you see, and do you have a > > > test case that produces a problem? > > > > > > > > If putting your larger objects into the nursery fixed your > problem, it > > > > sounds like you may have a write barrier leak. What large object > > > > threshold size were you using? Sounds like the problem goes away > > > > because of recursive tracing of the fields when placed in the > nursery. > > > > If large objects are allocated directly in the old generation, then > > > > updates to their fields need to be tracked by a write barrier. > > > > > > > > No... I don't recursively trace the heap but I trace the fields of > the > > moved > > > > object. I use a modified write barrier to update these fields. > > > > > > > > Actually, I have found the problem. My large object fields may > > reference > > > > the younger generations and these references are not in the > remembered > > set. > > > > Since the oldest generation is never traced (we use the remembered > set), > > > > some objects die prematuraly. > > > > > > This is what I meant. If the objects are allocated in the nursery > > > they will get traced. > > > > > > > > > > > I must trace the fields of my large objects when I allocate them in > the > > > > oldest generation (only when the first gc after the creation > happens). I > > > > don't do that by now... there is the problem. > > > > > > You shouldn't need to "trace" anything in the older generation if the > > > write barrier is set up correctly. A correct write barrier is > > > necessary regardless of where large objects are initially allocated. > > > The remembered set needs to be updated with any potential > > > intergenerational references. When a large object is first allocated= , > > > none of its fields will have valid references (all zero/NULL). They > > > will only be updated through later mutator actions that should be > > > caught by a write barrier. > > > > > > Carl Lebsack > > > > > > > > > > > > > > > > You change may not have actually fixed the problem, but simply > hidden > > it > > > > in your current test case. > > > > > > > > I know... but for now... I have a report and some results to > produce... > > I > > > > will fix the problem this week... > > > > > > > > Thanks for your help... > > > > > > > > Seb > > > > > > > > > > > > On 4/17/06, Carl Lebsack <[email protected]> wrote: > > > > > I am curious. What type of generational collector are you > writing? > > > > > Have you looked at the one included with SableVM currently? If > so, > > > > > what are the major differences? > > > > > > > > > > If putting your larger objects into the nursery fixed your > problem, it > > > > > sounds like you may have a write barrier leak. What large object > > > > > threshold size were you using? Sounds like the problem goes away > > > > > because of recursive tracing of the fields when placed in the > nursery. > > > > > If large objects are allocated directly in the old generation, > then > > > > > updates to their fields need to be tracked by a write > barrier. You > > > > > change may not have actually fixed the problem, but simply hidden > it > > > > > in your current test case. > > > > > > > > > > Carl Lebsack > > > > > > > > > > On 4/17/06, S=E9bastien Adam < [email protected]> wrote: > > > > > > > This doesn't imply the bug is in SableVM. > > > > > > > > > > > > I agree with you... It's why I said "maybe". > > > > > > > > > > > > > > > > > > > If a single reference isn't updated correctly, or a reference > is > > > > updated > > > > > > incorrectly the VM can crash. > > > > > > > > > > > > Right.... I met this problem a couple days ago. > > > > > > > > > > > > > > > > > > > Changing the heap size would allow some runs to complete > > successfully > > > > > > while others would crash. > > > > > > > > > > > > I allocated the larger objects in the oldest generation. I thin= k > > this is > > > > the > > > > > > source of the problem. Since I allocate these objects in the > > nursery, > > > > > > everything works perfectly... and for all heap size... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/17/06, Carl Lebsack <[email protected]> wrote: > > > > > > > This doesn't imply the bug is in SableVM. Garbage collectors > are > > > > > > > extremely sensitive to correctness. If a single reference > isn't > > > > > > > updated correctly, or a reference is updated incorrectly the > VM > > can > > > > > > > crash. However, the crash (segfault etc.) does not have to > appear > > at > > > > > > > the source of the problem, but at some point after the > problem. > > The > > > > > > > fact that changing the heap size has an effect probably means > > there is > > > > > > > still an issue with garbage collection and the GC trigger > point is > > > > > > > what causes the variation. This is a guess based on my own > > experience > > > > > > > writing a generational collector for SableVM. Missing a > single > > write > > > > > > > barrier location caused a host of bizarre problems to manifes= t > in > > > > > > > various parts of the VM. Changing the heap size would allow > some > > runs > > > > > > > to complete successfully while others would crash. > > > > > > > > > > > > > > Good luck. > > > > > > > > > > > > > > Carl Lebsack > > > > > > > > > > > > > > On 4/16/06, S=E9bastien Adam <[email protected]> wrote= : > > > > > > > > Finally, maybe the bug is in sablevm. When I set my heap > size > > with > > > > the > > > > > > > > following value: > > > > > > > > > > > > > > > > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE = * > > 1536 > > > > > > > > > > > > > > > > Everything works perfectly... > > > > > > > > > > > > > > > > So, depending of the heap size sablevm will produce the goo= d > > result > > > > or > > > > > > > > not... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/06, Etienne Gagnon < [email protected] > wrote: > > > > > > > > > > > > > > > > > Actually, the bug is possibly in sablevm... Look at: > > > > > > > > http://sablevm.org/bugs/172 > > > > > > > > > > > > > > > > Also, note that you should be able to change such value > using a > > > > runtime > > > > > > > > system property, like > > > > > > > > > > > > > > > > sablevm --preperty=3D sablevm.heap.increment=3D1024 > > > > > > > > or > > > > > > > > sablevm > > > > > > --preperty=3Dsablevm.heap.default.generation.size=3D... > > > > > > > > > > > > > > > > look in vm_args.m4.c > > > > > > > > > > > > > > > > Etienne > > > > > > > > > > > > > > > > S=E9bastien Adam wrote: > > > > > > > > > Last news... > > > > > > > > > > > > > > > > > > When I change the heap size... for example: > > > > > > > > > > > > > > > > > > In gc_gencopy.c, > > > > > > > > > > > > > > > > > > we replace: > > > > > > > > > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZ= E > * > > 1024 > > > > > > > > > with: > > > > > > > > > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZ= E > * > > 512 > > > > > > > > > > > > > > > > > > I got the following error: > > > > > > > > > sablevm: gc_gencopy.c:455: _svmf_copy_object: Assertion > > `((void *) > > > > > > > > > obj->lockword) >=3D heap->to_generation-> space.start && > ((void > > *) > > > > > > > > > obj->lockword) < heap->to_generation-> alloc.start' > failed. > > > > > > > > > > > > > > > > > > hummmm... this is really bad... It seems to be a problem > in my > > gc > > > > :( > > > > > > > > > > > > > > > > -- > > > > > > > > Etienne M. Gagnon, Ph.D. > > > > > > > > http://www.info2.uqam.ca/~egagnon/ > > > > > > > > SableVM: > > > > > > > > http://www.sablevm.org/ > > > > > > > > SableCC: > > > > > > > > http://www.sablecc.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > SableVM-devel mailing list > > > > > > > > [email protected] > > > > > > > > > > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > SableVM-devel mailing list > > > > > > > > [email protected] > > > > > > > > > > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SableVM-devel mailing list > > > > > > > [email protected] > > > > > > > > > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SableVM-devel mailing list > > > > > > [email protected] > > > > > > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SableVM-devel mailing list > > > > > [email protected] > > > > > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SableVM-devel mailing list > > > > [email protected] > > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > SableVM-devel mailing list > > > [email protected] > > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > > _______________________________________________ > > SableVM-devel mailing list > > [email protected] > > http://sablevm.org/lists/control/listinfo/sablevm-devel > > > > > > > > _______________________________________________ > SableVM-devel mailing list > [email protected] > http://sablevm.org/lists/control/listinfo/sablevm-devel > ------=_Part_26918_8107470.1145359823699 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline For now, its a research work. I have implemented some garbage collectors but I need to do some tests before publishing them. This summer I will write my master thesis and I will publish both my thesis and my GCs.<br> <br> So, you need to be patient a little bit :) I will happily share my wo= rk... very soon!<br> <br> Seb<br><br><div><span class=3D"gmail_quote">On 4/18/06, <b class=3D"gmail_s= endername">Carl Lebsack</b> <<a href=3D"mailto:[email protected]">lebs= [email protected]</a>> wrote:</span><blockquote class=3D"gmail_quote" styl= e=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; = padding-left: 1ex;"> So you didn't try the gencopy option? I believe it should be<br>= functional. I periodically have been working on enhancements but= <br>haven't had a lot of time lately. I'd be interested in the<b= r>differences you are implementing. The large object threshold I= chose <br>was 2kB, but is easily alterable.<br><br>I have been considering modify= ing my implementation to include an<br>Appel style generational collector.&= nbsp; You mentioned you are doing<br>things "differently".&n= bsp; Are you at liberty to share what you mean, or <br>is this research work?<br><br>Carl Lebsack<br><br>On 4/17/06, S=E9basti= en Adam <<a href=3D"mailto:[email protected]">sebastien.adam@gmai= l.com</a>> wrote:<br>> > ./configure --with-gc=3Dgencopy<br>><b= r> > ./configure --with-gc=3Dgc<br>><br>><br>> > You shouldn't = need to "trace" anything in the older generation if the<br>> w= rite barrier is set up correctly. A correct write barrier is<br>= > necessary regardless of where large objects are initially allocated. <br>> The remembered set needs to be updated with any potential<br>> = intergenerational references. When a large object is first alloc= ated,<br>> none of its fields will have valid references (all zero/NULL)= . They <br>> will only be updated through later mutator actions that should be<= br>> caught by a write barrier.<br>><br>> Right... my mistake... I= need to take a break to think about that problem...<br>> for now... I d= on't have time... But if you have some hints... don't hesitate <br>> to let me know...<br>><br>> Actually, you can see a big diff= erence in the gc time when you allocate the<br>> large object in the old= est generation. With SableCC 2.18, many big objects<br>> die = young. If these objects are allocated in the oldest generation, they are <br>> collected only when a full gc happens. This increase si= gnificantly the gc<br>> time. Maybe I can increase the threshold between= large and small objects<br>> (1024 -> 8096 or even more). But the pr= oblem happens when the threshold is <br>> 1024 bytes.<br>><br>><br>><br>><br>><br>><br>>= ;<br>> On 4/17/06, Carl Lebsack <<a href=3D"mailto:[email protected]= u">[email protected]</a>> wrote:<br>> > On 4/17/06, S=E9bastien = Adam < <a href=3D"mailto:[email protected]">[email protected]</a>>= ; wrote:<br>> > > > I am curious. What type of gener= ational collector are you writing?<br>> > > Have you looked at the= one included with SableVM currently? If so, <br>> > > what are the major differences?<br>> > ><br>>= ; > > Yes... I have looked at the one included with SableVM but it do= esn't<br>> work. I<br>> > > build my generational gc from scras= h. It is quite different from the <br>> other.<br>> > > The write barrier is not the same, the al= gorithm to select the<br>> collection<br>> > > (minor, major, f= ull) is not the same... In fact, pratically everything<br>> is<br>> &= gt; > different. <br>> > ><br>> > > I am writing a report. Mayb= e I will publish it as soon as possible.<br>> > ><br>> > >= ;<br>> ><br>> > ./configure --with-gc=3Dgencopy<br>> ><br= >> > This doesn't work? How so? I built the SDK= just last week and ran it <br>> > on several benchmarks. What problem do you see, an= d do you have a<br>> > test case that produces a problem?<br>> >= ;<br>> > > > If putting your larger objects into the nursery fi= xed your problem, it <br>> > > sounds like you may have a write barrier leak. &nbs= p;What large object<br>> > > threshold size were you using? &= nbsp;Sounds like the problem goes away<br>> > > because of recursi= ve tracing of the fields when placed in the nursery. <br>> > > If large objects are allocated directly in the old gener= ation, then<br>> > > updates to their fields need to be tracked by= a write barrier.<br>> > ><br>> > > No... I don't recursi= vely trace the heap but I trace the fields of the <br>> moved<br>> > > object. I use a modified write barrier to = update these fields.<br>> > ><br>> > > Actually, I have f= ound the problem. My large object fields may<br>> reference<b= r>> > > the younger generations and these references are not in th= e remembered <br>> set.<br>> > > Since the oldest generation is never traced= (we use the remembered set),<br>> > > some objects die prematural= y.<br>> ><br>> > This is what I meant. If the object= s are allocated in the nursery <br>> > they will get traced.<br>> ><br>> > ><br>> = > > I must trace the fields of my large objects when I allocate them = in the<br>> > > oldest generation (only when the first gc after th= e creation happens). I <br>> > > don't do that by now... there is the problem.<br>> &g= t;<br>> > You shouldn't need to "trace" anything in the old= er generation if the<br>> > write barrier is set up correctly. &= nbsp;A correct write barrier is <br>> > necessary regardless of where large objects are initially all= ocated.<br>> > The remembered set needs to be updated with any potent= ial<br>> > intergenerational references. When a large obje= ct is first allocated, <br>> > none of its fields will have valid references (all zero/NULL)= . They<br>> > will only be updated through later mutator a= ctions that should be<br>> > caught by a write barrier.<br>> ><= br>> > Carl Lebsack <br>> ><br>> > ><br>> > ><br>> > > > Yo= u change may not have actually fixed the problem, but simply hidden<br>>= it<br>> > > in your current test case.<br>> > ><br>> = > > I know... but for now... I have a report and some results to prod= uce... <br>> I<br>> > > will fix the problem this week...<br>> >= ><br>> > > Thanks for your help...<br>> > ><br>> &= gt; > Seb<br>> > ><br>> > ><br>> > > On 4/17/= 06, Carl Lebsack < <a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<b= r>> > > > I am curious. What type of generational co= llector are you writing?<br>> > > > Have you looked at the one = included with SableVM currently? If so, <br>> > > > what are the major differences?<br>> > > &= gt;<br>> > > > If putting your larger objects into the nursery = fixed your problem, it<br>> > > > sounds like you may have a wr= ite barrier leak. What large object <br>> > > > threshold size were you using? Sounds li= ke the problem goes away<br>> > > > because of recursive tracin= g of the fields when placed in the nursery.<br>> > > > If large= objects are allocated directly in the old generation, then <br>> > > > updates to their fields need to be tracked by a wri= te barrier. You<br>> > > > change may not have actua= lly fixed the problem, but simply hidden it<br>> > > > in your = current test case. <br>> > > ><br>> > > > Carl Lebsack<br>> > &g= t; ><br>> > > > On 4/17/06, S=E9bastien Adam < <a href=3D= "mailto:[email protected]">[email protected]</a>> wrote:<b= r> > > > > > > This doesn't imply the bug is in SableVM.<br>= > > > > ><br>> > > > > I agree with you... It= 's why I said "maybe".<br>> > > > ><br>> > &= gt; > > <br>> > > > > > If a single reference isn't updated corre= ctly, or a reference is<br>> > > updated<br>> > > > &g= t; incorrectly the VM can crash.<br>> > > > ><br>> > &= gt; > > Right.... I met this problem a couple days ago. <br>> > > > ><br>> > > > ><br>> > > = > > > Changing the heap size would allow some runs to complete<br>= > successfully<br>> > > > > while others would crash. <br>> > > > ><br>> > > > > I allocated the la= rger objects in the oldest generation. I think<br>> this is<br>> >= > the<br>> > > > > source of the problem. Since I alloca= te these objects in the <br>> nursery,<br>> > > > > everything works perfectly...= and for all heap size...<br>> > > > ><br>> > > >= ; ><br>> > > > ><br>> > > > ><br>> >= > > > On 4/17/06, Carl Lebsack < <a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<b= r>> > > > > > This doesn't imply the bug is in SableVM.&n= bsp; Garbage collectors are<br>> > > > > > extremely= sensitive to correctness. If a single reference isn't <br>> > > > > > updated correctly, or a reference is upda= ted incorrectly the VM<br>> can<br>> > > > > > crash.&= nbsp; However, the crash (segfault etc.) does not have to appear<br>&g= t; at<br> > > > > > > the source of the problem, but at some point = after the problem.<br>> The<br>> > > > > > fact that c= hanging the heap size has an effect probably means<br>> there is<br> > > > > > > still an issue with garbage collection and th= e GC trigger point is<br>> > > > > > what causes the vari= ation. This is a guess based on my own<br>> experience<br>>= ; > > > > > writing a generational collector for SableVM.&nb= sp; Missing a single <br>> write<br>> > > > > > barrier location caused a h= ost of bizarre problems to manifest in<br>> > > > > > var= ious parts of the VM. Changing the heap size would allow some<br= >> runs <br>> > > > > > to complete successfully while others wou= ld crash.<br>> > > > > ><br>> > > > > >= Good luck.<br>> > > > > ><br>> > > > > &g= t; Carl Lebsack <br>> > > > > ><br>> > > > > > On 4/16/= 06, S=E9bastien Adam <<a href=3D"mailto:[email protected]">sebast= [email protected]</a>> wrote:<br>> > > > > > > Fin= ally, maybe the bug is in sablevm. When I set my heap size <br>> with<br>> > > the<br>> > > > > > > f= ollowing value:<br>> > > > > > ><br>> > > >= ; > > > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE= * <br>> 1536<br>> > > > > > ><br>> > > > = > > > Everything works perfectly...<br>> > > > > &g= t; ><br>> > > > > > > So, depending of the heap siz= e sablevm will produce the good <br>> result<br>> > > or<br>> > > > > > > = not...<br>> > > > > > ><br>> > > > > &g= t; ><br>> > > > > > ><br>> > > > > &= gt; > On 4/16/06, Etienne Gagnon <=20 <a href=3D"mailto:[email protected]">[email protected]</a> > wrote:<= br>> > > > > > > ><br>> > > > > >= > Actually, the bug is possibly in sablevm... Look at:<br>&g= t; > > > > > >=20 <a href=3D"http://sablevm.org/bugs/172">http://sablevm.org/bugs/172</a><br>= > > > > > > ><br>> > > > > > > Al= so, note that you should be able to change such value using a<br>> > = > runtime <br>> > > > > > > system property, like<br>> > &= gt; > > > ><br>> > > > > > > sablevm --pre= perty=3D sablevm.heap.increment=3D1024<br>> > > > > > >= ; or <br>> > > > > > > sablevm<br>> > > > > = --preperty=3Dsablevm.heap.default.generation.size=3D...<br>> > > &= gt; > > ><br>> > > > > > > look in vm_args.m4= .c <br>> > > > > > ><br>> > > > > > >= ; Etienne<br>> > > > > > ><br>> > > > >= > > S=E9bastien Adam wrote:<br>> > > > > > > &g= t; Last news... <br>> > > > > > > ><br>> > > > > >= ; > > When I change the heap size... for example:<br>> > > &= gt; > > > ><br>> > > > > > > > In gc_ge= ncopy.c, <br>> > > > > > > ><br>> > > > > >= ; > > we replace:<br>> > > > > > > > #define = SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE *<br>> 1024<br>> &= gt; > > > > > > with: <br>> > > > > > > > #define SVM_DEFAULT_GENERATION_= SIZE SVM_DEFAULT_FRAME_SIZE *<br>> 512<br>> > > > > > = > ><br>> > > > > > > > I got the following er= ror: <br>> > > > > > > > sablevm: gc_gencopy.c:455: _svm= f_copy_object: Assertion<br>> `((void *)<br>> > > > > >= ; > > obj->lockword) >=3D heap->to_generation-> space.sta= rt && ((void<br>> *)<br>> > > > > > > > ob= j->lockword) < heap->to_generation-> alloc.start' failed.<br>&g= t; > > > > > > ><br>> > > > > > >= > hummmm... this is really bad... It seems to be a problem in my <br>> gc<br>> > > :(<br>> > > > > > ><br>&= gt; > > > > > > --<br>> > > > > > > = Etienne M. Gagnon, Ph.D.<br>> > > > > > > <a href=3D"h= ttp://www.info2.uqam.ca/~egagnon/"> http://www.info2.uqam.ca/~egagnon/</a><br>> > > > > > >= ; SableVM:<br>> > > > > > > <a href=3D"http://www.sabl= evm.org/">http://www.sablevm.org/</a><br>> > > > > > >= SableCC: <br>> > > > > > > <a href=3D"http://www.sablecc.org/">= http://www.sablecc.org/</a><br>> > > > > > ><br>> &= gt; > > > > ><br>> > > > > > ><br>> = > > > > > > _____________________________________________= __ <br>> > > > > > ><br>> > > > > > >= ; SableVM-devel mailing list<br>> > > > > > > <a href= =3D"mailto:[email protected]">[email protected]</a><br>>= > > > > > > <br>> > > <a href=3D"http://sablevm.org/lists/control/listinfo/sab= levm-devel">http://sablevm.org/lists/control/listinfo/sablevm-devel</a><br>= > > > > > > ><br>> > > > > > ><br= > > > > > > > ><br>> > > > > > ><br= >> > > > > > ><br>> > > > > > ><b= r>> > > > > > > ______________________________________= _________ <br>> > > > > > > SableVM-devel mailing list<br>> &= gt; > > > > > <a href=3D"mailto:[email protected]">S= [email protected]</a><br>> > > > > > ><br>> = > >=20 <a href=3D"http://sablevm.org/lists/control/listinfo/sablevm-devel">http://= sablevm.org/lists/control/listinfo/sablevm-devel</a><br>> > > >= > > ><br>> > > > > > ><br>> > > >= ; > > > <br>> > > > > ><br>> > > > > > ________= _______________________________________<br>> > > > > > Sa= bleVM-devel mailing list<br>> > > > > > <a href=3D"mailto= :[email protected]"> [email protected]</a><br>> > > > > ><br>> >= > <a href=3D"http://sablevm.org/lists/control/listinfo/sablevm-devel">h= ttp://sablevm.org/lists/control/listinfo/sablevm-devel</a><br>> > >= ; > > > <br>> > > > ><br>> > > > ><br>> > > = > > _______________________________________________<br>> > >= > > SableVM-devel mailing list<br>> > > > > <a href= =3D"mailto:[email protected]"> [email protected]</a><br>> > > > ><br>> <a href= =3D"http://sablevm.org/lists/control/listinfo/sablevm-devel">http://sablevm= .org/lists/control/listinfo/sablevm-devel</a><br>> > > > ><b= r> > > > > ><br>> > > > ><br>> > > >= <br>> > > > _______________________________________________<br>= > > > > SableVM-devel mailing list<br>> > > > <a hr= ef=3D"mailto:[email protected]"> [email protected]</a><br>> > > ><br>> <a href=3D"htt= p://sablevm.org/lists/control/listinfo/sablevm-devel">http://sablevm.org/li= sts/control/listinfo/sablevm-devel</a><br>> > > ><br>> > = > <br>> > ><br>> > > ______________________________________= _________<br>> > > SableVM-devel mailing list<br>> > > <a= href=3D"mailto:[email protected]">[email protected]</a><br= > > > > <a href=3D"http://sablevm.org/lists/control/listinfo/sablevm= -devel">http://sablevm.org/lists/control/listinfo/sablevm-devel</a><br>>= > ><br>> > ><br>> > ><br>> ><br>> > __= _____________________________________________ <br>> > SableVM-devel mailing list<br>> > <a href=3D"mailto:Sab= [email protected]">[email protected]</a><br>> > <a href= =3D"http://sablevm.org/lists/control/listinfo/sablevm-devel">http://sablevm= .org/lists/control/listinfo/sablevm-devel </a><br>> ><br>><br>><br>> _________________________________= ______________<br>> SableVM-devel mailing list<br>> <a href=3D"mailto= :[email protected]">[email protected]</a><br>> <a href= =3D"http://sablevm.org/lists/control/listinfo/sablevm-devel"> http://sablevm.org/lists/control/listinfo/sablevm-devel</a><br>><br>>= <br>><br><br>_______________________________________________<br>SableVM-= devel mailing list<br><a href=3D"mailto:[email protected]">SableVM-= [email protected] </a><br><a href=3D"http://sablevm.org/lists/control/listinfo/sablevm-devel"= >http://sablevm.org/lists/control/listinfo/sablevm-devel</a><br></blockquot= e></div><br> ------=_Part_26918_8107470.1145359823699-- --===============0287351918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SableVM-devel mailing list [email protected] http://sablevm.org/lists/control/listinfo/sablevm-devel --===============0287351918==--