On 25 May 2011 02:40, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, May 24, 2011 at 5:34 PM, Igor Stasenko siguctua@gmail.com wrote:
On 25 May 2011 00:51, Craig Latta craig@netjam.org wrote:
Hi Igor--
...now I'm looking forward to ephemeron conflicts. :)
What conflicts?
Please elaborate :)
Oh, none yet, I just suspect there will be some with the stuff I wrote to GC stale methods.
Yes. This could be a problem. Consider a following:
MyClass>>someMethod ^ #( 'abc' 'def' )
ephemeron := Ephemeron new key: self someMethod first value: somethingElse.
So, we created an ephemeron, whose key are object which came from method's literals. And even worse, as it shown above, it could be not a direct literal, but nested object.
Now, if you GC this stale #someMethod , it will apparently turn ephemeron's value to be weakly referenced, and its key will be lost and replaced by nil.
Uh, no. The ephemeron refers to the string 'abc' that happened to be referenced by the method. But that string won't be garbage collected until there are no references to it in the system, including from the ephemeron. i.e. the ephemeron will either need to nil its key or itself be collected before the 'abc' string can be collected.
No. Ephemeron's key held weakly. Right? So, if key points to that 'abc' , and the only strong reference to 'abc' is via such method, then if you remove method from system, the ephemeron's key will be replaced by nil .. and rest of logic which follows, but its not interesting..
Because same will happen if you just use weak objects:
array := WeakArray with: (self someMethod first) "which answers a literal from that method".
now, imagine that you want to temporarily unload such "stale" method from memory, but make sure that system pretends that it is still in memory (if it is intended), and still reachable from roots, you have to do something to make sure that weak ref, held by array are not gone.
So, if you can solve this problem for usual weak refs, then you solve that for ephemerons too.
There is no magic here with references to objects from methods. In Smalltalk, methods are just objects. [and in the Cog VM there is a little bit of chicanery to preserve the illusion that there are no machien code methods involved, but that's what it does; hide the machine code].