On Mon, Jan 9, 2012 at 1:16 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
Ok guys....what about the following:
stronglyPointsTo: anObject
"Answers true if the garbage collector would fail to collect anObject because I hold a reference to it, or false otherwise"
(self instVarsInclude: anObject) ifTrue: [ self class isWeak ifFalse: [ ^true ]. 1 to: self class instSize do: [ :i | (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. ^false ] ifFalse: [ ^self class == anObject and: [ self class isCompact not ] ]
Named inst vars in weak arrays are strong references. So the above looks wrong to me. Its more like this: 1 to: self class instSize do: [:i| (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. self class isWeak ifFalse: [1 to: self basicSize do: [:i| (se;f basicAt: i) == anObject ifTrue: [ ^true ] ]. ^false This should be a primitive. I believe Levente's primitive is even more useful and equivalent to 1 to: self class instSize do: [:i| (self instVarAt: i) == anObject ifTrue: [ ^i ] ]. self class isWeak ifFalse: [1 to: self basicSize do: [:i| (se;f basicAt: i) == anObject ifTrue: [ ^i + self class instSize ] ]. ^0
pointsTo: anObject "Answers true if I hold a reference to anObject, or false otherwise"
^ (self instVarsInclude: anObject) or: [ ^self class == anObject and: [ self class isCompact not ] ]
And then, from the the tracing pointer stuff (such as #pointersToExcept:) we use #stronglyPointsTo
do you agree?
On Mon, Jan 9, 2012 at 9:55 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Mon, Jan 9, 2012 at 12:47 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Mon, Jan 9, 2012 at 12:38 PM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On Jan 9, 2012, at 8:46 06PM, Levente Uzonyi wrote:
On Mon, 9 Jan 2012, Mariano Martinez Peck wrote:
So..I am puzzle again. I said "In which scenario can (self
instVarsInclude: anObject) answer true, but the loop false? " you answered: "The scenario happens when the receiver has weak
slots and
the argument is referenced from one of those weak slots, but not from the other slots." Imagine the receiver has a weak slot XXX that points to anObject. So (self instVarsInclude: anObject) answers true. How can the loop answer false without a GC? why would XXX stop pointing to anObject if there is not GC in the middle ?
The loop doesn't iterate over the indexable slots, only named ones.
grrr you are right!
Ok, so I finally got it. So previously pointersTo: would answer true even if the slots were weak. Now it would answer false, and that's why you have changed the method comment. Now I am thinking if this should be the default behavior of #pointsTo:. If I just read the selector #pointsTo: I would guess weak references are also taken into account. So that's why I am not completely sure. Aren't there any other impact of the system because of this change? what about having #stronglyPointsTo: with this new version and have another one #pointsTo: which considers weak also? does it make sense? or it is better to directly avoid weak by defualt in #pointsTo?
I wasn't sure about this, that's why it's not in Squeak yet. Ignoring weak references is okay as long as these methods are only used for pointer tracing.
Levente
Even with a good comment, the naming starts to make little sense, imho⦠Does an object having weak slots mean it no longer pointsTo: the objects in those slots?
Sadly, I have no better succinct suggestions. :/
Also, what happens when an object holds its (non-compact) class in a weak slot?
In other words, is:
wa := WeakArray new: 1. wa at: 1 put: WeakArray. self assert: (wa pointsTo: WeakArray).
a valid test?
It is vacuous, since WeakArray is referred to indirectly from the roots via Smalltalk and so will not go away. The following is not a valid test because there could be a GC in between the at:put: and the assert:.
| o oh | wa := WeakArray new: 1. o := Object new. oh := o hash. wa at: 1 put: o. o := nil. self assert: (wa at: 1) hash = oh
but 99 times out of a hundred it'll pass :)
and it can better be written
| oh | wa := WeakArray new: 1. oh := (wa at: 1 put: Object new) hash. self assert: (wa at: 1) hash = oh
Weak arrays are tricky beasts. To me, it doesn't matter that when used on WeakArray pointsTo: or instVarsIncludes: or whatever produce results that may be invalid at some subsequent time. The same is true for e.g. a normal Array that could be updated in some other thread. It does mater that at the point when an inst var is queried these methods/primitives answer the right answer. Writing valid tests that verify these answers is another matter entirely. Don't let the perfect be the enemy of the good.
Cheers, Henry
-- best, Eliot
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot