Problem in Thread.c

[Sébastien Adam]

Hi,

I developed a new generational gc in SableVM release 1.13.

I get a segmentation fault at the last instruction in the following code. This instruction is found at line 1364 in the method _svmf_enter_object_monitor of Thread.c.

++++++++++++
...
  else
    {
      /* it is a fat lock */

      _svmt_word fat_index = _svmf_lockword_get_fatlock_index (old_lockword);
      _svmt_fat_lock *fat_lock = vm->fat_locks.array[fat_index];
      jint status = JNI_OK;
      jobject obj;

      if (_svmm_new_native_local (env, obj) != JNI_OK)
    {
      return JNI_ERR;
    }

      /* save reference in case GC happens */
      *obj = instance;

      _svmm_stopping_java (env);

      /* IMPORTANT: From now on, we MUST NOT read or write any
         value which can be changed by GC or any other "stop the
         word" dependent operation. */

      _svmm_mutex_lock (fat_lock->mutex);
++++++++++++

When I print the lockword, I get the following:

1 011011100000000 011101 010010 00 0 0

This lockword don't change in the method _svmf_enter_object_monitor.

The least significant bit is 0 which means that it is a reference. My gc uses a forward reference when an object is copied (it replaces the header of the original object with a reference to the copied object). So, what I get is probably a forward reference. My segmentation fault happens immediately after a call to the gc.

I don't work a lot with the Thread code but I don't think the problem is in _svmf_enter_object_monitor. Is there somebody that can help me to resolve this problem? Where should I look?

thanks,
Seb

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Etienne Gagnon]

Hi Sebastien,

Can you reproduce this problem in a plain version of SableVM 1.13 (i.e.
without your new GC stuff)?  If yes, can you submit a bug report at
http://sablevm.org/bugs.html with the instructions (and any required
code example) to reproduce the problem?

If not, then you should probably create a "personal tag"[*] by copying
the version of your sandbox that exhibits the problem, and send us
another message with the instructions to reproduce the problem.

[*] e.g.
$ export $SVN=svn+ssh://svn.sablevm.org/public/developers/sadam
$ svn cp [-r????]\
  $SVN/sandbox/[???] $SVN/tags/lock_gc_bug

This will create the following tag for others to see:

 svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug

The idea is that you can then continue changing your sandbox without
worrying, as others will fetch the "frozen snapshot" of your sandbox
represented by the tag.

Hints for finding the problem:  You could scan the heap, at the start of
every GC, before copying any object, and verify that all lockwords do
have their least significant bit set.  You should also scan the heap at
the end of GC, and do the same check.  This would reveal whether the
problem is in GC or elsewhere.

Have fun!

Etienne

Sébastien Adam wrote:
> I developed a new generational gc in SableVM release 1.13.
>
> I get a segmentation fault at the last instruction in the following
> code. This instruction is found at line 1364 in the method
> _svmf_enter_object_monitor of Thread.c.
>...
> I don't work a lot with the Thread code but I don't think the problem is
> in _svmf_enter_object_monitor. Is there somebody that can help me to
> resolve this problem? Where should I look?

--
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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Sébastien Adam]

> Hints for finding the problem:  You could scan the heap, at the start of every GC, before copying any object, and verify that all lockwords do have their least significant bit set.  You should also scan the heap at the end of GC, and do the same check.  This would reveal whether the problem is in GC or elsewhere.

It is already done...  Everything is ok in the gc.

> If not, then you should probably create a "personal tag"[*] by copying
the version of your sandbox that exhibits the problem, and send us
another message with the instructions to reproduce the problem.

The following tag has been created.

svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug

To get the segmentation fault, you can use the following:

./autogen.sh    
./configure --prefix=/usr/ --enable-debugging-features --with-gc=gc   
make install
java -jar sablecc.jar j14.scc 

Where sablecc.jar is at the version 2.18 and j14.scc is the java 1.4 grammar.  Both are found on sablecc.org.

Seb

On 4/16/06, Etienne Gagnon <egagnon@...> wrote:

Hi Sebastien,

Can you reproduce this problem in a plain version of SableVM 1.13 (i.e.
without your new GC stuff)?  If yes, can you submit a bug report at
http://sablevm.org/bugs.html with the instructions (and any required
code example) to reproduce the problem?

If not, then you should probably create a "personal tag"[*] by copying
the version of your sandbox that exhibits the problem, and send us
another message with the instructions to reproduce the problem.

[*] e.g.
$ export $SVN=svn+ssh://svn.sablevm.org/public/developers/sadam
$ svn cp [-r????]\
  $SVN/sandbox/[???] $SVN/tags/lock_gc_bug

This will create the following tag for others to see:

svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug

The idea is that you can then continue changing your sandbox without
worrying, as others will fetch the "frozen snapshot" of your sandbox
represented by the tag.

Hints for finding the problem:  You could scan the heap, at the start of
every GC, before copying any object, and verify that all lockwords do
have their least significant bit set.  You should also scan the heap at
the end of GC, and do the same check.  This would reveal whether the
problem is in GC or elsewhere.

Have fun!

Etienne

Sébastien Adam wrote:
> I developed a new generational gc in SableVM release 1.13.
>
> I get a segmentation fault at the last instruction in the following
> code. This instruction is found at line 1364 in the method
> _svmf_enter_object_monitor of Thread.c.
>...
> I don't work a lot with the Thread code but I don't think the problem is
> in _svmf_enter_object_monitor. Is there somebody that can help me to
> resolve this problem? Where should I look?

--
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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Sébastien Adam]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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) >= 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 :(

On 4/16/06, Sébastien Adam <sebastien.adam@...> wrote:

> Hints for finding the problem:  You could scan the heap, at the start of every GC, before copying any object, and verify that all lockwords do have their least significant bit set.  You should also scan the heap at the end of GC, and do the same check.  This would reveal whether the problem is in GC or elsewhere.

It is already done...  Everything is ok in the gc.

> If not, then you should probably create a "personal tag"[*] by copying
the version of your sandbox that exhibits the problem, and send us
another message with the instructions to reproduce the problem.

The following tag has been created.

svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug

To get the segmentation fault, you can use the following:

./autogen.sh    
./configure --prefix=/usr/ --enable-debugging-features --with-gc=gc   
make install
java -jar sablecc.jar j14.scc 

Where sablecc.jar is at the version 2.18 and j14.scc is the java 1.4 grammar.  Both are found on sablecc.org.

Seb

On 4/16/06, Etienne Gagnon <egagnon@...> wrote:

Hi Sebastien,

Can you reproduce this problem in a plain version of SableVM 1.13 (i.e.
without your new GC stuff)?  If yes, can you submit a bug report at
http://sablevm.org/bugs.html with the instructions (and any required
code example) to reproduce the problem?

If not, then you should probably create a "personal tag"[*] by copying
the version of your sandbox that exhibits the problem, and send us
another message with the instructions to reproduce the problem.

[*] e.g.
$ export $SVN=svn+ssh://svn.sablevm.org/public/developers/sadam
$ svn cp [-r????]\
  $SVN/sandbox/[???] $SVN/tags/lock_gc_bug

This will create the following tag for others to see:

svn://svn.sablevm.org/developers/sadam/tags/lock_gc_bug

The idea is that you can then continue changing your sandbox without
worrying, as others will fetch the "frozen snapshot" of your sandbox
represented by the tag.

Hints for finding the problem:  You could scan the heap, at the start of
every GC, before copying any object, and verify that all lockwords do
have their least significant bit set.  You should also scan the heap at
the end of GC, and do the same check.  This would reveal whether the
problem is in GC or elsewhere.

Have fun!

Etienne

Sébastien Adam wrote:
> I developed a new generational gc in SableVM release 1.13.
>
> I get a segmentation fault at the last instruction in the following
> code. This instruction is found at line 1364 in the method
> _svmf_enter_object_monitor of Thread.c.
>...
> I don't work a lot with the Thread code but I don't think the problem is
> in _svmf_enter_object_monitor. Is there somebody that can help me to
> resolve this problem? Where should I look?

--
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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Etienne Gagnon]

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=sablevm.heap.increment=1024
or
 sablevm --preperty=sablevm.heap.default.generation.size=...

look in vm_args.m4.c

Etienne

Sébastien 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) >= 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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Sébastien Adam]

> Also, note that you should be able to change such value using a runtime
system property, like

I plan to do that change soon!

Thanks
Seb

On 4/16/06, Etienne Gagnon <egagnon@...> 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=sablevm.heap.increment=1024
or
sablevm --preperty=sablevm.heap.default.generation.size=...

look in vm_args.m4.c

Etienne

Sébastien 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) >= 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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Sébastien Adam]

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 <egagnon@...> 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=sablevm.heap.increment=1024
or
sablevm --preperty=sablevm.heap.default.generation.size=...

look in vm_args.m4.c

Etienne

Sébastien 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) >= 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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Carl Lebsack]

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ébastien Adam <sebastien.adam@...> 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 <egagnon@...> 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=sablevm.heap.increment=1024
> or
> sablevm --preperty=sablevm.heap.default.generation.size=...
>
> look in vm_args.m4.c
>
> Etienne
>
> Sébastien 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) >= 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
> SableVM-devel@...
> http://sablevm.org/lists/control/listinfo/sablevm-devel
>
>
>
>
>
>
> _______________________________________________
> SableVM-devel mailing list
> SableVM-devel@...
> http://sablevm.org/lists/control/listinfo/sablevm-devel
>
>
>

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Sébastien Adam]

> 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 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 <lebsack@...> 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ébastien Adam <sebastien.adam@...> 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 <egagnon@...> 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= sablevm.heap.increment=1024
> or
> sablevm --preperty=sablevm.heap.default.generation.size=...
>
> look in vm_args.m4.c
>
> Etienne
>
> Sébastien 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) >= 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
> SableVM-devel@...
> http://sablevm.org/lists/control/listinfo/sablevm-devel
>
>
>
>
>
>
> _______________________________________________
> SableVM-devel mailing list
> SableVM-devel@...
> http://sablevm.org/lists/control/listinfo/sablevm-devel
>
>
>

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Etienne Gagnon]

Hi Sebastien,

I definitely think that the framework outlined in

 http://sablevm.org/lists/sablevm-devel/2006-April/000672.html

is needed.  It will be useful now and later, for developing, debugging,
testing and maintaining any complex GC algorithm we include in SableVM.

Etienne

Sébastien Adam wrote:
> 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...

--
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
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Carl Lebsack]

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ébastien Adam <sebastien.adam@...> 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 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 <lebsack@...> 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ébastien Adam <sebastien.adam@...> 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 <egagnon@...> 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= sablevm.heap.increment=1024
> > > or
> > > sablevm
> --preperty=sablevm.heap.default.generation.size=...
> > >
> > > look in vm_args.m4.c
> > >
> > > Etienne
> > >
> > > Sébastien 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) >= 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
> > > SableVM-devel@...
> > > http://sablevm.org/lists/control/listinfo/sablevm-devel
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > SableVM-devel mailing list
> > > SableVM-devel@...
> > > http://sablevm.org/lists/control/listinfo/sablevm-devel
> > >
> > >
> > >
> >
> > _______________________________________________
> > SableVM-devel mailing list
> > SableVM-devel@...
> > http://sablevm.org/lists/control/listinfo/sablevm-devel
> >
>
>
> _______________________________________________
> SableVM-devel mailing list
> SableVM-devel@...
> http://sablevm.org/lists/control/listinfo/sablevm-devel
>
>
>

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

[Sébastien Adam]

> 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 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 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 <lebsack@...> 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ébastien Adam < sebastien.adam@...> 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 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 <lebsack@...> 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ébastien Adam <sebastien.adam@...> 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 <egagnon@...> 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= sablevm.heap.increment=1024
> > > or
> > > sablevm
> --preperty=sablevm.heap.default.generation.size=...
> > >
> > > look in vm_args.m4.c
> > >
> > > Etienne
> > >
> > > Sébastien 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) >= 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
> > > SableVM-devel@...

> > > http://sablevm.org/lists/control/listinfo/sablevm-devel
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > SableVM-devel mailing list
> > > SableVM-devel@...
> > > http://sablevm.org/lists/control/listinfo/sablevm-devel

> > >
> > >
> > >
> >
> > _______________________________________________
> > SableVM-devel mailing list
> > SableVM-devel@...
> > http://sablevm.org/lists/control/listinfo/sablevm-devel
> >
>
>
> _______________________________________________
> SableVM-devel mailing list
> SableVM-devel@...
> http://sablevm.org/lists/control/listinfo/sablevm-devel
>
>
>

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel

_______________________________________________
SableVM-devel mailing list
SableVM-devel@...
http://sablevm.org/lists/control/listinfo/sablevm-devel