We should think about that and identify a good solution. Thanks for the information and discussion. Stef
The inspector is currently used to view the object log in the development vm...for large object logs it makes sense to filter the log before viewing.
For external viewing I have a Seaside Component that allows one to filter and sort the object log entries as well as delete entries from the ObjectLog ...
Since GemStone runs with multiple vms, you can use a separate vm to look at the shared object log ... ..
The RCQueue (and OrderedCollections for that matter) in GemStone don't incur performance hits as the collection grows over time (unlike growing OrderedCollections in a normal client Smalltalk), but then GemStone was designed with very large collections in mind:)...
GemStone was designed to handle collections and object graphs that can be larger than available memory, so you can forget about the object log until start running out of repository space (basically disk space) ...
For the Pharo, I would think that the fact that an Object log could accumulate a whole lot of stuff is real limiting factor...there'd need to be a process that continuously pruned objects from the object log over time .... so a thread safe linked list might be a better choice for the Object log collection ...
Dale