Re: Problem in Thread.c
"Sébastien Adam" <[email protected]> Mon, 17 Apr 2006 12:14:22 +0000
| Newsgroups | gmane.comp.java.vm.sablevm.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1824487673== Content-Type: multipart/alternative; boundary="----=_Part_11372_14894152.1145276062093" ------=_Part_11372_14894152.1145276062093 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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 is th= e 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 manifest 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 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=3Dsablevm.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 > ------=_Part_11372_14894152.1145276062093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > This doesn't imply the bug is in SableVM.<br> <br> I agree with you... It's why I said "maybe".<br> <br> > If a single reference isn't updated correctly, or a reference is updat= ed incorrectly the VM can crash.<br><br> Right.... I met this problem a couple days ago.<br> <br> > Changing the heap size would allow some runs to complete successfully = while others would crash.<br> <br> I allocated the larger objects in the oldest generation. I think this is the source of the problem. Since I allocate these objects in the nursery, everything works perfectly... and for all heap size...<br> <br> <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;"> This doesn't imply the bug is in SableVM. Garbage collectors are= <br>extremely sensitive to correctness. If a single reference is= n't<br>updated correctly, or a reference is updated incorrectly the VM can<= br>crash. However, the crash (segfault etc.) does not have to ap= pear at <br>the source of the problem, but at some point after the problem. &n= bsp;The<br>fact that changing the heap size has an effect probably means th= ere is<br>still an issue with garbage collection and the GC trigger point i= s<br>what causes the variation. This is a guess based on my own = experience <br>writing a generational collector for SableVM. Missing a sing= le write<br>barrier location caused a host of bizarre problems to manifest = in<br>various parts of the VM. Changing the heap size would allo= w some runs<br>to complete successfully while others would crash. <br><br>Good luck.<br><br>Carl Lebsack<br><br>On 4/16/06, S=E9bastien Adam = <<a href=3D"mailto:[email protected]">[email protected]</a= >> wrote:<br>> Finally, maybe the bug is in sablevm. When I set my he= ap size with the <br>> following value:<br>><br>> #define SVM_DEFAULT_GENERATION_SI= ZE 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>> wrot= e:<br>> ><br>> Actually, the bug is possibly in sablevm... &n= bsp;Look at: <br>> <a href=3D"http://sablevm.org/bugs/172">http://sablevm.org/bugs/17= 2</a><br>><br>> Also, note that you should be able to change such val= ue using a runtime<br>> system property, like<br>><br>> sablevm --= preperty=3D sablevm.heap.increment=3D1024<br>> or<br>> sablevm --preperty=3Dsable= vm.heap.default.generation.size=3D...<br>><br>> look in vm_args.m4.c<= br>><br>> Etienne<br>><br>> S=E9bastien Adam wrote:<br>> >= ; Last news... <br>> ><br>> > When I change the heap size... for example:<br>&= gt; ><br>> > In gc_gencopy.c,<br>> ><br>> > we replace= :<br>> > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE *= 1024 <br>> > with:<br>> > #define SVM_DEFAULT_GENERATION_SIZE SVM_DE= FAULT_FRAME_SIZE * 512<br>> ><br>> > I got the following error:= <br>> > sablevm: gc_gencopy.c:455: _svmf_copy_object: Assertion `((vo= id *) <br>> > obj->lockword) >=3D heap->to_generation->space.st= art && ((void *)<br>> > obj->lockword) < heap->to_ge= neration-> alloc.start' failed.<br>> ><br>> > hummmm... this= is really bad... It seems to be a problem in my gc :( <br>><br>> --<br>> Etienne M. Gagnon, Ph.D.<br>> <a href=3D"htt= p://www.info2.uqam.ca/~egagnon/">http://www.info2.uqam.ca/~egagnon/</a><br>= > SableVM:<br>> <a href=3D"http://www.sablevm.org/">http://www.sablev= m.org/ </a><br>> SableCC:<br>> <a href=3D"http://www.sablecc.org/">http://ww= w.sablecc.org/</a><br>><br>><br>><br>> ________________________= _______________________<br>><br>> SableVM-devel mailing list<br>>= =20 <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>><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_11372_14894152.1145276062093-- --===============1824487673== 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 --===============1824487673==--