Smalltalk › Squeak › Squeak - Dev

Suspiscious "weak" value reclaimed

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Nicolas Cellier

Suspiscious "weak" value reclaimed

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

Bob Arning-2

Re: Suspiscious "weak" value reclaimed

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

timrowledge

Re: Suspiscious "weak" value reclaimed

> On 26-03-2018, at 2:15 PM, Bob Arning <[hidden email]> wrote:
>
> 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?

Usually a class' superclass would point to it with the subclasses array. If you were to make classes and *not* install them as a child of some superclass then I'd anticipate the class getting collected as soon as there are not instances being held onto. You could probably do interesting things by having the subclass array be weak and maybe having a mechanism that can (re)load a class when actually needed. But wait! That's at least in part what Craig has been doing with Context for some time now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quo signo nata es? = What's your sign?

Nicolas Cellier

Re: Suspiscious "weak" value reclaimed

In reply to this post by Bob Arning-2

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.

2018-03-26 23:15 GMT+02:00 Bob Arning <[hidden email]>:

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

Nicolas Cellier

Re: Suspiscious "weak" value reclaimed

In reply to this post by timrowledge

Hi Tim,

yes, MatFileStructureElement class has an instance variable named weakSubclasses which is a WeakValueDictionary for that purpose.

I used a Dictionary rather than just a WeakArray, because the class also acts as a namespace (an Environment).

Otherwise, I would need to define a specific kind of environment pointing weakly to its binding values, and this would create portability problems for not so much added value (Pharo does not have Environment for example).

2018-03-26 23:25 GMT+02:00 tim Rowledge <[hidden email]>:

> On 26-03-2018, at 2:15 PM, Bob Arning <[hidden email]> wrote:
>
> 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?

Usually a class' superclass would point to it with the subclasses array. If you were to make classes and *not* install them as a child of some superclass then I'd anticipate the class getting collected as soon as there are not instances being held onto. You could probably do interesting things by having the subclass array be weak and maybe having a mechanism that can (re)load a class when actually needed. But wait! That's at least in part what Craig has been doing with Context for some time now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quo signo nata es? = What's your sign?

Bob Arning-2

Re: Suspiscious "weak" value reclaimed

In reply to this post by Nicolas Cellier

I don't *know*, but it does seem possible that a garbage collector could follow the class field of every marked object and mark those classes as well. Maybe VW does that? Not necessary, of course, in ordinary Smalltalk as classes are generally strongly held by the eponymous root.

On 3/27/18 6:33 AM, Nicolas Cellier 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.

2018-03-26 23:15 GMT+02:00 Bob Arning <[hidden email]>:

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

Nicolas Cellier

Re: Suspiscious "weak" value reclaimed

2018-03-27 13:02 GMT+02:00 Bob Arning <[hidden email]>:

I don't *know*, but it does seem possible that a garbage collector could follow the class field of every marked object and mark those classes as well. Maybe VW does that? Not necessary, of course, in ordinary Smalltalk as classes are generally strongly held by the eponymous root.

Yes, the VM cannot rely on image side conventions and should follow the class (for example there are obsolete classes).
There is SpurMemoryManager>>markAndTraceClassOf: for that.

On 3/27/18 6:33 AM, Nicolas Cellier 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.

2018-03-26 23:15 GMT+02:00 Bob Arning <[hidden email]>:

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

timrowledge

Re: Suspiscious "weak" value reclaimed

In reply to this post by Bob Arning-2

> On 27-03-2018, at 4:02 AM, Bob Arning <[hidden email]> wrote:
> strongly held by the eponymous root.

That's my next techno-death-metal-punk band name...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never do at compile-time what you can put off till run-time

Eliot Miranda-2

Re: Suspiscious "weak" value reclaimed

In reply to this post by Nicolas Cellier

HI Nicolas,

On Tue, Mar 27, 2018 at 3:33 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:
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

Nicolas Cellier

Re: Suspiscious "weak" value reclaimed

Hi Eliot,

Let me check...

2018-03-27 21:14 GMT+02:00 Eliot Miranda <[hidden email]>:

HI Nicolas,
On Tue, Mar 27, 2018 at 3:33 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:

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

Nicolas Cellier

Re: Suspiscious "weak" value reclaimed

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 <[hidden email]>:

Hi Eliot,
Let me check...
2018-03-27 21:14 GMT+02:00 Eliot Miranda <[hidden email]>:
HI Nicolas,
On Tue, Mar 27, 2018 at 3:33 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:

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

Nicolas Cellier

Re: Suspiscious "weak" value reclaimed

Err, my bad...
In VW, reclaimed objects are not replaced by nil but by 0 (zero).

The example correctly answer 0 if I replace
^weak count: [:e | e ~= 0].

Cross dialect is a path full of pitfalls

2018-03-27 21:41 GMT+02:00 Nicolas Cellier <[hidden email]>:

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 <[hidden email]>:
Hi Eliot,
Let me check...
2018-03-27 21:14 GMT+02:00 Eliot Miranda <[hidden email]>:
HI Nicolas,
On Tue, Mar 27, 2018 at 3:33 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:

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