== Quote from Bill Baxter (wbaxter@gmail.com)'s article
> On Thu, Aug 7, 2008 at 11:38 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> > "Bill Baxter" wrote
> >> On Thu, Aug 7, 2008 at 8:12 AM, Jason House wrote:
> >>
> >> One possible gotcha that just crossed my mind:  I think the current GC allocates chunks in an all or nothing manner -- hasPointers is just a single bit.  So could it be that the fact that all Objects have a vtable pointer mean that everything in an Object is always treated as having pointers?
> >
> > At least on Tango, this is not the case:
> >
> > import tango.core.Memory;
> >
> > class X
> > {
> >    int x;
> > }
> >
> > class Y
> > {
> >    int *y;
> > }
> >
> > void main()
> > {
> >    auto n = new X;
> >    assert(GC.getAttr(cast(void*)n) & GC.BlkAttr.NO_SCAN);
> >    auto m = new Y;
> >    assert(!(GC.getAttr(cast(void*)m) & GC.BlkAttr.NO_SCAN));
> > }
> Hmm, yeh I also went looking for the previous discussion on this topic
> and found there that someone had already checked that the GC flag on
> the WeakRef class was getting set properly.
> The only other potential problem I can see is the manipulation of the
> member variable that goes on in the destructor of the WeakRef.  It
> makes the assumption that if the referred object has been collected
> then the notification function will have been called, and thus the
> pointer-as-size_t variable will be null.  But that code is very
> similar to what std.signals does in its destructor.  So if that's the
> source of the bug then it's probably a bug that's in std.signal too.

The last time I tested the WeakRef code the unittest was simply broken in that it tried something like this:

    WeakRef!(int) r = new int;
    GC.collect();
    assert( r.get() is null );

Problem being that a register still may have a reference to the int value that the test expected to be collected.  The easiest way around this is to perform a second "dummy" allocation in hopes that the relevant registers will be overwritten.  Once I made this change in the WeakRef code the unittest passed for Tango.


Sean

"Sean Kelly" <sean@invisibleduck.org> wrote in message news:g7fv4t$2bce$1@digitalmars.com...

>
> The last time I tested the WeakRef code the unittest was simply broken in that it tried something like this:
>
>    WeakRef!(int) r = new int;
>    GC.collect();
>    assert( r.get() is null );
>
> Problem being that a register still may have a reference to the int value that the test expected to be collected.  The easiest way around this is to perform a second "dummy" allocation in hopes that the relevant registers will be overwritten.  Once I made this change in the WeakRef code the unittest passed for Tango.

For you.  For me, it still fails.

"Sean Kelly" wrote
> == Quote from Bill Baxter (wbaxter@gmail.com)'s article
>> On Thu, Aug 7, 2008 at 11:38 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> > "Bill Baxter" wrote
>> >> On Thu, Aug 7, 2008 at 8:12 AM, Jason House wrote:
>> >>
>> >> One possible gotcha that just crossed my mind:  I think the current GC allocates chunks in an all or nothing manner -- hasPointers is just a single bit.  So could it be that the fact that all Objects have a vtable pointer mean that everything in an Object is always treated as having pointers?
>> >
>> > At least on Tango, this is not the case:
>> >
>> > import tango.core.Memory;
>> >
>> > class X
>> > {
>> >    int x;
>> > }
>> >
>> > class Y
>> > {
>> >    int *y;
>> > }
>> >
>> > void main()
>> > {
>> >    auto n = new X;
>> >    assert(GC.getAttr(cast(void*)n) & GC.BlkAttr.NO_SCAN);
>> >    auto m = new Y;
>> >    assert(!(GC.getAttr(cast(void*)m) & GC.BlkAttr.NO_SCAN));
>> > }
>> Hmm, yeh I also went looking for the previous discussion on this topic
>> and found there that someone had already checked that the GC flag on
>> the WeakRef class was getting set properly.
>> The only other potential problem I can see is the manipulation of the
>> member variable that goes on in the destructor of the WeakRef.  It
>> makes the assumption that if the referred object has been collected
>> then the notification function will have been called, and thus the
>> pointer-as-size_t variable will be null.  But that code is very
>> similar to what std.signals does in its destructor.  So if that's the
>> source of the bug then it's probably a bug that's in std.signal too.
>
> The last time I tested the WeakRef code the unittest was simply broken in that it tried something like this:
>
>    WeakRef!(int) r = new int;

This is probably just a typo, but the WeakRef class can only point to an Object derivative, because it adds an extra monitor code in a hidden field, which wouldn't be on an int.

>    GC.collect();
>    assert( r.get() is null );
>
> Problem being that a register still may have a reference to the int value that the test expected to be collected.  The easiest way around this is to perform a second "dummy" allocation in hopes that the relevant registers will be overwritten.  Once I made this change in the WeakRef code the unittest passed for Tango.

I don't see this as an issue, except that the unittest needs updating.  The object still functions as designed.  Jarrett has some other issue (which he has yet to share :) )

I'd like to see this get solved, as I can see a benefit to having a WeakRef class in Tango.

-Steve

Bill,

As an aside, I notice you have a dup() function in WeakRef.  When would you ever want to dup the WeakRef?  If anything, dup() should just return 'this'.

-Steve

On Fri, Aug 8, 2008 at 11:09 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Bill,
>
> As an aside, I notice you have a dup() function in WeakRef.  When would you
> ever want to dup the WeakRef?  If anything, dup() should just return 'this'.
>

Hmm, yeh.  You're right.  It doesn't serve any useful purpose there.

--bb

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:g7g9if$10vt$1@digitalmars.com...

> I don't see this as an issue, except that the unittest needs updating. The object still functions as designed.  Jarrett has some other issue (which he has yet to share :) )

http://dsource.org/projects/tango/ticket/1046