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

Tony Hosking hosking at cs.purdue.edu
Wed Mar 12 16:12:57 CET 2008


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>

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


More information about the M3devel mailing list