_gst_mem.numWeakOOPs can be wrong?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

_gst_mem.numWeakOOPs can be wrong?

Holger Freyther
Hi Paolo,

I'm reading the oop.c file right now and I noticed a minor issue when it
comes to count the numWeakOOPs. The _gst_make_oop_weak method is doing
this:

1.) add F_WEAK to the OOP flags
2.) Increment _gst_mem.numWeakOOPs by one
3.) Find the right place in the RB tree to add a child..
3.a) If a leaf was reached.. stop
3.b) If the OOP is present return.

In case of 3.b) the numWeakOOPs will be wrong. Now I obviously don't
know when this case might occur but maybe we should either move the
increment to after the allocation or add an abort() instead of a return?

holger


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: _gst_mem.numWeakOOPs can be wrong?

Paolo Bonzini-2
Il 28/10/2012 10:04, Holger Hans Peter Freyther ha scritto:

> I'm reading the oop.c file right now and I noticed a minor issue when it
> comes to count the numWeakOOPs. The _gst_make_oop_weak method is doing
> this:
>
> 1.) add F_WEAK to the OOP flags
> 2.) Increment _gst_mem.numWeakOOPs by one
> 3.) Find the right place in the RB tree to add a child..
> 3.a) If a leaf was reached.. stop
> 3.b) If the OOP is present return.
>
> In case of 3.b) the numWeakOOPs will be wrong. Now I obviously don't
> know when this case might occur but maybe we should either move the
> increment to after the allocation or add an abort() instead of a return?

No, it cannot happen.  The problem is that _gst_make_oop_weak is used
both in prims.def:

  if (!IS_OOP_WEAK (oop1))
    _gst_make_oop_weak (oop1);

and when loading images to bring _gst_mem.weak_areas in sync with the flags:

      if (flags & F_WEAK)
        _gst_make_oop_weak (oop);

so you cannot just return if F_WEAK is already set in the OOP.  But
making it an abort would be a good idea indeed.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk