Re: Problem in Thread.c

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 the othe=
r.
> 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 it
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 mo=
ved
> 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 se=
t.
> 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.=20
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 i=
t
> 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 successful=
ly
> > > 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.  Th=
e
> > > > 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 experie=
nce
> > > > writing a generational collector for SableVM.  Missing a single wri=
te
> > > > barrier location caused a host of bizarre problems to manifest in
> > > > various parts of the VM.  Changing the heap size would allow some r=
uns
> > > > 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 wit=
h
> 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 resu=
lt
> 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 * 10=
24
> > > > > > with:
> > > > > > #define SVM_DEFAULT_GENERATION_SIZE SVM_DEFAULT_FRAME_SIZE * 51=
2
> > > > > >
> > > > > > 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
>
>
>