Re: Problem in Thread.c
"Sébastien Adam" <[email protected]> Mon, 17 Apr 2006 15:16:01 +0000
| Newsgroups | gmane.comp.java.vm.sablevm.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0598242394== Content-Type: multipart/alternative; boundary="----=_Part_13796_25562066.1145286961605" ------=_Part_13796_25562066.1145286961605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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 the 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. > 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 move= d 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. 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 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 think this i= s > 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 i= s > > > still an issue with garbage collection and the GC trigger point is > > > what causes the variation. This is a guess based on my own experienc= e > > > writing a generational collector for SableVM. Missing a single write > > > barrier location caused a host of bizarre problems to manifest in > > > various parts of the VM. Changing the heap size would allow some run= s > > > 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 good 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_SIZE * 1024 > > > > > with: > > > > > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE * 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 > ------=_Part_13796_25562066.1145286961605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > I am curious. What type of generational collector are you w= riting?<br> Have you looked at the one included with SableVM currently? If s= o,<br> what are the major differences?<br> <br> 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 the 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.<br> <br> I am writing a report. Maybe I will publish it as soon as possible.<b= r> <br> > If putting your larger objects into the nursery fixed your problem, it= <br> sounds like you may have a write barrier leak. What large object= <br> threshold size were you using? Sounds like the problem goes away= <br> because of recursive tracing 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 write barrier. <br> <br> 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. <br> <br> 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.<br> <br> 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. <br> <br> > You change may not have actually fixed the problem, but simply hidden = it in your current test case.<br> <br>I know... but for now... I have a report and some results to produce...= I will fix the problem this week...<br> <br> Thanks for your help...<br> <br> Seb<br> <br><div><span class=3D"gmail_quote">On 4/17/06, <b class=3D"gmail_senderna= me">Carl Lebsack</b> <<a href=3D"mailto:[email protected]">lebsack@ias= tate.edu</a>> wrote:</span><blockquote class=3D"gmail_quote" style=3D"bo= rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding= -left: 1ex;"> I am curious. What type of generational collector are you writin= g?<br>Have you looked at the one included with SableVM currently? &nbs= p;If so,<br>what are the major differences?<br><br>If putting your larger o= bjects into the nursery fixed your problem, it <br>sounds like you may have a write barrier leak. What large ob= ject<br>threshold size were you using? Sounds like the problem g= oes away<br>because of recursive tracing of the fields when placed in the n= ursery.<br> If large objects are allocated directly in the old generation, = then <br>updates to their fields need to be tracked by a write barrier. &nb= sp;You<br>change may not have actually fixed the problem, but simply hidden= it<br>in your current test case.<br><br>Carl Lebsack<br><br>On 4/17/06, S= =E9bastien Adam < <a href=3D"mailto:[email protected]">[email protected]</a>>= ; wrote:<br>> > This doesn't imply the bug is in SableVM.<br>><br>= > I agree with you... It's why I said "maybe".<br>><br>> <br>> > If a single reference isn't updated correctly, or a reference= is updated<br>> incorrectly the VM can crash.<br>><br>> Right....= I met this problem a couple days ago.<br>><br>><br>> > Changin= g the heap size would allow some runs to complete successfully <br>> while others would crash.<br>><br>> I allocated the larger o= bjects in the oldest generation. I think this is the<br>> source of the = problem. Since I allocate these objects in the nursery,<br>> everything = works perfectly... and for all heap size... <br>><br>><br>><br>><br>> On 4/17/06, Carl Lebsack <<a hr= ef=3D"mailto:[email protected]">[email protected]</a>> wrote:<br>>= ; > This doesn't imply the bug is in SableVM. Garbage collect= ors are<br> > > extremely sensitive to correctness. If a single refere= nce isn't<br>> > updated correctly, or a reference is updated incorre= ctly the VM can<br>> > crash. However, the crash (segfault= etc.) does not have to appear at <br>> > the source of the problem, but at some point after the proble= m. The<br>> > fact that changing the heap size has an effe= ct probably means there is<br>> > still an issue with garbage collect= ion and the GC trigger point is <br>> > what causes the variation. This is a guess based o= n my own experience<br>> > writing a generational collector for Sable= VM. Missing a single write<br>> > barrier location caused = a host of bizarre problems to manifest in <br>> > various parts of the VM. Changing the heap size wo= uld allow some runs<br>> > to complete successfully while others woul= d crash.<br>> ><br>> > Good luck.<br>> ><br>> > Car= l Lebsack <br>> ><br>> > On 4/16/06, S=E9bastien Adam <<a href=3D"mail= to:[email protected]">[email protected]</a>> wrote:<br>>= ; > > Finally, maybe the bug is in sablevm. When I set my heap size w= ith the <br>> > > following value:<br>> > ><br>> > > #de= fine SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE * 1536<br>> >= ><br>> > > Everything works perfectly...<br>> > > <br>> > > So, depending of the heap size sablevm will produce the = good result or<br>> > > not...<br>> > ><br>> > >= <br>> > ><br>> > > On 4/16/06, Etienne Gagnon <<a href= =3D"mailto:[email protected]"> [email protected]</a>> wrote:<br>> > > ><br>> > >= Actually, the bug is possibly in sablevm... Look at:<br>> &g= t; > <a href=3D"http://sablevm.org/bugs/172">http://sablevm.org/bugs/172= </a><br> > > ><br>> > > Also, note that you should be able to chan= ge such value using a runtime<br>> > > system property, like<br>&g= t; > ><br>> > > sablevm --preperty=3D sablevm.heap.increment= =3D1024 <br>> > > or<br>> > > sablevm<br>> --preperty=3Dsablev= m.heap.default.generation.size=3D...<br>> > ><br>> > > lo= ok in vm_args.m4.c<br>> > ><br>> > > Etienne<br>> >= > <br>> > > S=E9bastien Adam wrote:<br>> > > > Last news= ...<br>> > > ><br>> > > > When I change the heap si= ze... for example:<br>> > > ><br>> > > > In gc_genc= opy.c, <br>> > > ><br>> > > > we replace:<br>> > >= ; > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE * 1024<br= >> > > > with:<br>> > > > #define SVM_DEFAULT_GENER= ATION_SIZE SVM_DEFAULT_FRAME_SIZE * 512 <br>> > > ><br>> > > > I got the following error:<b= r>> > > > sablevm: gc_gencopy.c:455: _svmf_copy_object: Asserti= on `((void *)<br>> > > > obj->lockword) >=3D heap->to_= generation-> space.start && ((void *)<br>> > > > obj->lockword) &= lt; heap->to_generation-> alloc.start' failed.<br>> > > >= <br>> > > > hummmm... this is really bad... It seems to be a pr= oblem in my gc :( <br>> > ><br>> > > --<br>> > > Etienne M. Gagnon= , Ph.D.<br>> > > <a href=3D"http://www.info2.uqam.ca/~egagnon/">ht= tp://www.info2.uqam.ca/~egagnon/</a><br>> > > SableVM:<br>> >= ; >=20 <a href=3D"http://www.sablevm.org/">http://www.sablevm.org/</a><br>> >= ; > SableCC:<br>> > > <a href=3D"http://www.sablecc.org/">http:= //www.sablecc.org/</a><br>> > ><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>> &g= t; > <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_13796_25562066.1145286961605-- --===============0598242394== 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 --===============0598242394==--