Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003298 [Croquet] Hedgehog major always 03-13-06 19:09 01-28-07 21:25
Reporter howardstearns View Status public  
Assigned To
Priority high Resolution open  
Status confirmed  
Summary 0003298: futureSend futures never go away
Description 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.
Additional Information 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.
Attached Files  CompactNameMap.2.cs.gz [^] (954 bytes) 01-28-07 21:25

- Relationships

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

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.

- Notes
(0004436 - 64 - 64 - 64 - 64 - 64 - 64)
howardstearns
03-13-06 19:10

 Oops. Should be severity Major, not Crash. How do I change that?
 
(0004460 - 998 - 1066 - 1066 - 1066 - 1066 - 1066)
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 - 713 - 773 - 773 - 773 - 773 - 773)
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 - 393 - 393 - 393 - 393 - 393 - 393)
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
 

- Issue History
Date Modified Username Field Change
03-13-06 19:09 howardstearns New Issue
03-13-06 19:10 howardstearns Note Added: 0004436
03-13-06 19:11 howardstearns Relationship added child of 0003297
03-13-06 19:11 howardstearns Relationship added related to 0003292
03-13-06 19:17 howardstearns Severity crash => major
03-13-06 19:18 howardstearns Relationship added parent of 0003299
03-13-06 19:22 howardstearns Relationship added parent of 0003300
03-14-06 02:42 andreas Note Added: 0004460
03-15-06 23:00 andreas Note Added: 0004494
03-15-06 23:00 andreas Status new => confirmed
01-07-07 21:17 howardstearns Relationship added parent of 0005708
01-19-07 05:41 howardstearns Relationship added parent of 0005695
01-28-07 21:25 howardstearns File Added: CompactNameMap.2.cs.gz
01-28-07 21:25 howardstearns Note Added: 0009234

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
73 total queries executed.
47 unique queries executed.
Powered by Mantis Bugtracker