Re: Problem in Thread.c

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 hesit=
ate
> to let me know...
>
> Actually, you can see a big difference in the gc time when you allocate t=
he
> large object in the oldest generation.  With SableCC 2.18, many big objec=
ts
> die young. If these objects are allocated in the oldest generation, they =
are
> collected only when a full gc happens.  This increase significantly the g=
c
> time. Maybe I can increase the threshold between large and small objects
> (1024 -> 8096 or even more). But the problem happens when the threshold i=
s
> 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 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 everythin=
g
> 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 th=
e
> 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 remembere=
d
> set.
> > > Since the oldest generation is never traced (we use the remembered se=
t),
> > > 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 t=
he
> > > 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 hidd=
en
> 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 nurse=
ry.
> > > > 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 i=
t
> > > > 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 i=
s
> > > 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
> > > 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 a=
re
> > > > > > 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 app=
ear
> 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 so=
me
> 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=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
> > > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
>