Re: Problem in Thread.c

I am curious.  What type of generational collector are you writing?=20
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 update=
d
> 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 =
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 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 th=
e
> > > 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 o=
r
> > > 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 runti=
me
> > > 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
>
>
>