Both vw7.8 32bits and vw8.3 64bits return 1 to this test:

    | superStruct meta struct weak |
    superStruct := Object.
    meta := Metaclass new.
    meta hash.
    meta setSuperclass: superStruct class.
    meta methodDictionary: MethodDictionary new.
    meta setInstanceFormat: (Behavior formatFromType: #none super:
superStruct class instVars: Array new).
    struct := meta new.
    struct hash.
    struct setSuperclass: superStruct.
    struct methodDictionary: MethodDictionary new.
    struct setInstanceFormat: (Behavior formatFromType: #none super:
superStruct instVars: Array new).
    struct instanceVariables: Array new.
    struct setName: 'TestStickyWeak'.
    weak := WeakArray with: struct.
    meta := struct := nil. "break references"
    3 timesRepeat: [ObjectMemory garbageCollect].
    weak count: #notNil.



2018-03-27 21:20 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Hi Eliot,
> Let me check...
>
> 2018-03-27 21:14 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>> HI Nicolas,
>>
>> On Tue, Mar 27, 2018 at 3:33 AM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>> Hi Bob,
>>> yes, you force me to rethink. The way mark and sweep GC works, cycles in
>>> object graphs do not matter.
>>> As long as the objects in the cycles are only pointed to weakly from
>>> roots,
>>>
>>> | value weak array2 |
>>> value := Array new.
>>> weak := WeakArray with: value.
>>> 3 timesRepeat: [Smalltalk garbageCollect].
>>> self assert: (weak count: #notNil) = 1. "Not yet reclaimed, thisContext
>>> points to it thru value variable"
>>> value := nil.
>>> 3 timesRepeat: [Smalltalk garbageCollect].
>>> self assert: (weak count: #notNil) = 0. "This time, it is reclaimed"
>>>
>>> "Example of cycle"
>>> value := Array new: 1.
>>> array2 := Array with: value.
>>> value at: 1 put: array2.
>>> weak := WeakArray with: value.
>>> array2 := nil.
>>> value := nil.
>>> 3 timesRepeat: [Smalltalk garbageCollect].
>>> self assert: (weak count: #notNil) = 0. "The value is reclaimed despite
>>> the cycle"
>>>
>>> It's then VW that behaves strangely: I did not find any pointer to the
>>> class nor its metaclass apart themselves
>>> (I took care to not add the metaclass to metaclass superclass
>>> subclasses, because those are not weak).
>>> This has obscured my mind.
>>> Sorry for the noise.
>>>
>>
>> Is there difference between 32-bit and 64-bit VisualWorks?  Like Spur,
>> 64-bit VW uses a class table, whereas 32-bit VW has class pointers in
>> object headers.  So if you see the behavior in one but not the other that
>> could point to a bug in tracing the class table (and its likely my bug).
>>
>> 2018-03-26 23:15 GMT+02:00 Bob Arning <arning315 at comcast.net>:
>>>
>>>> Other that the WeakValueDictionary, is there anything referencing
>>>> either the class or metaclass? If not, then they would be collected.
>>>> Perhaps VW is saving a reference elsewhere?
>>>>
>>>> On 3/26/18 3:07 PM, Nicolas Cellier wrote:
>>>>
>>>> Hi all,
>>>> while porting MatFileReader to Squeak, I encountered this questionable
>>>> behaviour:
>>>>
>>>> I create classes on the fly for holding Matlab struct().
>>>> I want those classes to be garbage collected when no more used.
>>>>
>>>> If I store the classes in a WeakArray, then this should normally not
>>>> work:
>>>> I mean that the classes should not be reclaimed.
>>>> Why?
>>>> Because the metaclass points strongly to the class (via thisClass
>>>> variable).
>>>> And the metaclass can't be reclaimed either, because it still has an
>>>> instance.
>>>> That's what happens in Visualworks, classes put in a WeakArray are
>>>> never reclaimed.
>>>> Fortunately, there is some Ephemeron support in VW to work around this
>>>> (such loop are detected by ephemerons, and strong references by some object
>>>> ephemerely pointed to does not count).
>>>>
>>>> In Squeak, I used a WeakValueDictionary, and to my surprise, discovered
>>>> that the classes were reclaimed.
>>>> Is this a bug?
>>>>
>>>> Nicolas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180327/50e46a35/attachment-0001.html>