[M3devel] WeakRef mechanism alive and well? cm3-cvshead

[Tony Hosking]

Indeed! Can you devise a testcase?  Note that the generational  
collector will retain old objects for some time until a major  
collection occurs,

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On Mar 13, 2008, at 9:56 AM, Dragiša Durić wrote:

> And not only that, their stackbase is also set to NIL, meaning their
> stack is not regarded in any way during future collections - meaning  
> all
> local variables are forgotten once apply method returns.
>
> That way, "spuriousness"  is not an issue, once thread returns?
>
> dd
>
> On Thu, 2008-03-13 at 09:46 -0400, Tony Hosking wrote:
>> They should get unlinked from the global ring.
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue
>> University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>>
>> On Mar 13, 2008, at 6:16 AM, Dragiša Durić wrote:
>>
>>> What happens to thread stacks once threads are Join-ed?
>>>
>>> dd
>>>
>>> On Wed, 2008-03-12 at 11:12 -0400, Tony Hosking wrote:
>>>> This is probably a result of conservatism for references from
>>>> thread
>>>> stacks which results in spurious retention.  It may be necessary
>>>> to be
>>>> more careful about what references are held on the stack in the
>>>> threads implementation (and elsewhere in your code).  Until we
>>>> diagnose the place where objects are being retained it will be
>>>> hard to
>>>> pinpoint.  You should realize that weak refs are a problem in many
>>>> language implementations, not just Modula-3.  I look forward to
>>>> hearing more definitively from you.
>>>>
>>>> Antony Hosking | Associate Professor | Computer Science | Purdue
>>>> University
>>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 12, 2008, at 4:21 AM, Dragiša Durić wrote:
>>>>
>>>>> Problem in my case can be thoroughness of GC... Because it's
>>>>> linked
>>>>> list of WeakRef-ed objects, it's always first element in list to
>>>>> become
>>>>> unreachable first - all others are reachable at least through
>>>>> previous
>>>>> (in list) WeakRef-ed object. So, behaviour I have observed can
>>>>> be
>>>>> because of some thousands of freeable objects, that one is
>>>>> missed
>>>>> too
>>>>> often.
>>>>>
>>>>> I have other object being cleaned and counted... There also
>>>>> cleanup
>>>>> invocation looks like it's lagging too much. I'll come with
>>>>> numbers
>>>>> after I have more tests.
>>>>>
>>>>> dd
>>>>>
>>>>> On Tue, 2008-03-11 at 09:50 -0400, Tony Hosking wrote:
>>>>>> Sounds like we need some sort of testcase.  Would you be able
>>>>>> to
>>>>>> devise one?  It will be hard to make it deterministic, but at
>>>>>> least we
>>>>>> should see a non-zero cleanup count.
>>>>>>
>>>>>> Antony Hosking | Associate Professor | Computer Science |
>>>>>> Purdue
>>>>>> University
>>>>>> 305 N. University Street | West Lafayette | IN 47907 | USA
>>>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mar 11, 2008, at 4:03 AM, Dragiša Durić wrote:
>>>>>>
>>>>>>> I have single linked list that I use to send messages to
>>>>>>> many
>>>>>>> threads.
>>>>>>> It's end is locked for addition, and current end is given to
>>>>>>> each
>>>>>>> new
>>>>>>> client connecting. This way, all client are going towards
>>>>>>> end of
>>>>>>> the
>>>>>>> list so it's head becomes unreferenced and goes away by GC.
>>>>>>>
>>>>>>> Except it does not.
>>>>>>>
>>>>>>> I've added WeakRef cleanup and sequential id's so I can
>>>>>>> record
>>>>>>> maximum
>>>>>>> freed id for checking. No single cleanup happens.
>>>>>>>
>>>>>>> I'll cross check my code and count my references from
>>>>>>> application
>>>>>>> side,
>>>>>>> but maybe someone else has similar problems?
>>>>>>>
>>>>>>> dd
>>>>>>> -- 
>>>>>>> Dragiša Durić <dragisha at m3w.org>
>>>>>>>
>>>>>>
>>>>> -- 
>>>>> Dragiša Durić <dragisha at m3w.org>
>>>>>
>>>>
>>>>
>>> -- 
>>> Dragiša Durić <dragisha at m3w.org>
>>>
>>
>>
> -- 
> Dragiša Durić <dragisha at m3w.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080313/ea1b9ec2/attachment-0002.html>