If I look at the serializers I know the mechanics are simple:
1. take an object and look it up in a table.
2. if the object is in the table it has already been serialized. We take a reference from the table and write it down
3. if it isn't in the table it means the object has not been serialized and the contents need to be written. After that the object with a reference representation is written to the table
4. while writing the content of an object (inst vars) I encounter simple objects (direct string representation) or complex objects (composite). In the latter case we start over from 1.
If the object graph is well interconnected than the odds are high that a stack will grow high until the first reference can be written. With a small pier kernel I already matched a stack size of 1000.
In Fuel we� traverse the graph but instead of using a recursion we use our own simple stack implementation where we push and pop objects.
But Martin may explaint better than me.
I'm interested in details how it works and if it avoids the deep stack. Is there additional information about that?
In 4. you said "while writing the content of an object (inst vars) I encounter simple
objects (direct string representation) or complex objects (composite).
In the latter case we start over from 1.".
So... Imagine object X with two instVars Y and Z. Imagine the method of the traverse is called #analye:.� So you do #analize: X.� Then, in such method you check whether X has regular pointers to regular objects, and if true, you analize them. So in this case you would send #analyze: Y and #analize: Z, generating the recursion. Right ?
Ok, instead of sending #analyze: Y and #analize: Z� what we do is just to do a push on a stack:�� #push: Y� and #push: Z. And then we are done with X, so we pop from the stack and we continue with the next object (at some point in the future we will pop Y and Z) When there are no more objects in the stack it means we are done.
For performance (I think) we did FLSimpleStack. You can check also FLSimpleStackTest. Both are in Fuel repo.
Would something like that help for the stack in GemStone?
Cheers
�
Norbert�
One solution I can think of is to collect and order objects in the graph that cover smaller segments from the overall graph. This way I would construct a sorted collection that is sorted by stack depth (lowest first). The collection will then be serialized leading to a much smaller possible stack sizes. It might be there are cases it can't work but I think for most cases it will do its job. And it will be slow of course.
Does anybody know if such a tool exists?
Norbert
--
Mariano
http://marianopeck.wordpress.com