--- a/WeakArray.st Tue Apr 05 18:04:53 2016 +0200
+++ b/WeakArray.st Tue Apr 05 20:29:05 2016 +0200
@@ -1,5 +1,3 @@
-"{ Encoding: utf8 }"
-
"
COPYRIGHT (c) 1991 by Claus Gittinger
All Rights Reserved
@@ -43,7 +41,7 @@
WeakArrays can be used to trace disposal of objects; in contrast to other
objects, references by WeakArrays will NOT keep an object from being
garbage collected.
- Instead, whenever an object kept in a WeakArray dies, its entry is zeroed,
+ Instead, whenever an object kept in a WeakArray dies, its entry is set to a SmallInteger,
and the WeakArray is informed by the storage manager. The WeakArray itself
then informs possible dependents via the dependency mechanism.
@@ -52,7 +50,7 @@
file when disposed (otherwise you could run out of OS filedescriptors).
This can be done by keeping the FileStream objects in a weakArray, and
keep a parallel array of filedescriptors. Whenever a fileStream is
- freed, search both arrays for an index where the stream is zero, but the
+ freed, search both arrays for an index where the stream is set to a SmallInteger, but the
filedescriptor is non-nil. Then close that file, and nil the filedescriptor
entry. Notice, that there is a class (Registry) which does exactly this in
a more programmer friendly way.
@@ -76,18 +74,18 @@
A weakArray notifies its dependents via normal dependency notfications.
[hint:]
- WeakArray handling adds small some overhead to the VM
- (each weakarray is scanned after each GC).
- It is uncertain, if the current mechanism works well
- with (say) ten-thousands of weakArrays.
- We had the system running with >2000 weakArrays, some being quite
- big for a while and had a few percent of added gc time.
- The system as delivered creates between 50 and 100 weakArrays,
- but with many dependents, this number may grow.
- If you need the dependency mechanism on a huge number of objects,
- consider adding a (non-weak) dependents field to your class
- - take the implementation of Model as a guide (or subclass them
- from Model).
+ WeakArray handling adds small some overhead to the VM
+ (each weakarray is scanned after each GC).
+ It is uncertain, if the current mechanism works well
+ with (say) ten-thousands of weakArrays.
+ We had the system running with >2000 weakArrays, some being quite
+ big for a while and had a few percent of added gc time.
+ The system as delivered creates between 50 and 100 weakArrays,
+ but with many dependents, this number may grow.
+ If you need the dependency mechanism on a huge number of objects,
+ consider adding a (non-weak) dependents field to your class
+ - take the implementation of Model as a guide (or subclass them
+ from Model).
As a possible option, we could perform the weakArray scanning only in
the oldSpace reclamation code - this would remove most of the overhead,
@@ -96,27 +94,27 @@
[instance variables:]
- dependents get informed via #change notifiction
- that the weakArray has lost pointers.
- Having the dependents here is an optimization.
+ dependents get informed via #change notifiction
+ that the weakArray has lost pointers.
+ Having the dependents here is an optimization.
[class variables:]
- RegistrationFailedSignal raised if a weakArray cannot be
- registered by the VM. This only happens,
- if the VM has to resize its internal tables
- and is running out of malloc-memory.
+ RegistrationFailedSignal raised if a weakArray cannot be
+ registered by the VM. This only happens,
+ if the VM has to resize its internal tables
+ and is running out of malloc-memory.
[memory requirements:]
- OBJ-HEADER + (size * ptr-size) + ptr-size
- + sizeof(dependents-collection)
+ OBJ-HEADER + (size * ptr-size) + ptr-size
+ + sizeof(dependents-collection)
[author:]
- Claus Gittinger
+ Claus Gittinger
[See also:]
- Array WeakIdentitySet WeakIdentityDictionary Registry
- Model
+ Array WeakIdentitySet WeakIdentityDictionary Registry
+ Model
"
! !