SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Croquet
Viewing Issue Advanced Details
3298 Hedgehog major always 03-13-06 19:09 01-28-07 21:25
howardstearns  
 
high  
confirmed  
open  
none    
none  
0003298: futureSend futures never go away
TFarRef>>futureSend:at:args: calls TIsland>>register:name:, which puts stuff in TIsland's nameMap (a strong Dictionary).

Later on, TIsland>>execute: sees that the message is named and puts the future for the result in exports. (exports may be weak, but the nameMap reference keeps it around).

Neither of these entries ever gets removed from the two tables.

In other words, someone wants the result of the futureSend for at least a little while, but the farRef for it never goes away.
Possible solution: make nameMap be weak, but keep reference until they get round-tripped and decoded?

There are two other issues (which I'll report as child tickets) that aggrevate this. It may be sufficient for a time to just fix these contributing tickets.
related to 0003292closed andreas Island 'exports' filling up with TFarRefs to BlockContexts 
parent of 0003299confirmed  future messages compile as futureSend instead of futureDo 
parent of 0003300closed andreas unnecessary futureSend for avatar head transform 
parent of 0005708new  makePointer creates uncollectable garbage memory leak 
parent of 0005695new  future in tail-position of block - core packages 
child of 0003297confirmed  island export and nameMap tables filling up 
Not all the children of this issue are yet resolved or closed.
 CompactNameMap.2.cs.gz [^] (954 bytes) 01-28-07 21:25

Notes
(0004436)
howardstearns   
03-13-06 19:10   
Oops. Should be severity Major, not Crash. How do I change that?
(0004460)
andreas   
03-14-06 02:42   
The reason why this can't work as easily as making the name map a weak dictionary is that in a replicated environment, only a single machine may hold onto a FarRef strongly. For example, consider something like:

  obj := island future new: SomeObject.

In this case, only the invoking machine will (via obj) hold strongly onto the FarRef for the object created. However, some time later we will want to send a message to the object (farRef) and if, by then, the object has been GCed, we're screwed (on the remote participants).

In the long-term we will want to look at ways of automating the management in a way that determines a "primary owner" for a reference (e.g., the machine that invoked the future send) and that then deterministally releases the objects in the replicated environment. This should be handled in a regular cleanup interval (say every other second or so?) to mimic the normal GC behavior.

In the short term we will need a workaround (which I am still unsure about).
(0004494)
andreas   
03-15-06 23:00   
On a related note (just so I don't forget it): It is really important that any solution for the problem described here is capable of dealing with object references that are effectively "in transit". For example, consider this:

  obj := island future new: Object.
  island future add: obj.

In this case obj is the only life reference to the object ever and may cause us to mark that object eligible for garbage collection before the #add: message (to which obj is one of the args) has completed its roundtrip. Put differently, it looks as if the machine sending a message needs to keep references to all its args up until the point where the message has completed its roundtrip (or is known to have failed).
(0009234)
howardstearns   
01-28-07 21:25   
I have a crude/simple #compactNameMap: method in the Wisconsin package that clears the nameMap and registering everything accessible from globals. This is only useful when we know that no one is holding a an off-island reference. Fortunately, we know that's the case when we resurrect an island from a disk cache, so that's what I do. Attached as just the relevant stuff as CompactNameMap.2.cs