<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 03.06.2011 10:38, Norbert Hartl wrote:
    <blockquote
      cite="mid:7718A7DA-5BAA-499F-90EF-57B7674B626A@hartl.name"
      type="cite"><br>
      <div>
        <div>Am 03.06.2011 um 10:20 schrieb Mariano Martinez Peck:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite"><br>
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
              0.8ex; border-left: 1px solid rgb(204, 204, 204);
              padding-left: 1ex;">
              <div style="word-wrap: break-word;">
                <div>
                  <div class="im"><br>
                    <blockquote type="cite">
                      <div class="gmail_quote">
                        <blockquote class="gmail_quote" style="margin:
                          0pt 0pt 0pt 0.8ex; border-left: 1px solid
                          rgb(204, 204, 204); padding-left: 1ex;">
                          If I look at the serializers I know the
                          mechanics are simple:<br>
                          <br>
                          1. take an object and look it up in a table.<br>
                          2. if the object is in the table it has
                          already been serialized. We take a reference
                          from the table and write it down<br>
                          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<br>
                          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.<br>
                          <br>
                          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.<br>
                          <br>
                        </blockquote>
                        <div><br>
                          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.
                          <br>
                          But Martin may explaint better than me. <br>
                        </div>
                      </div>
                    </blockquote>
                    <div><br>
                    </div>
                  </div>
                  I'm interested in details how it works and if it
                  avoids the deep stack. Is there additional information
                  about that?</div>
                <div><br>
                </div>
              </div>
            </blockquote>
            <div><br>
              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.".<br>
              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 ?<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        yes, the time between analyse: Y and analyse: Z is dependent on
        the graph that is attached to Y. Y can have objects that have
        further objects etc. So leaving X aside, Y can be the first
        object to serialize and Z the last.<br>
        <blockquote type="cite">
          <div class="gmail_quote">
            <div>
              <br>
              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. <font
                class="Apple-style-span" color="#000000"><font
                  class="Apple-style-span" color="#144fae"><br>
                </font></font></div>
          </div>
        </blockquote>
        <div><br>
        </div>
        How do you write X? I can see that you turn a recursive trace
        into depth-by-depth trace but the difficult part is to write X.
        In X you need a reference representation of any sort. How do you
        derive that from the stack? </div>
      <div><br>
        <blockquote type="cite">
          <div class="gmail_quote">
            <div>For performance (I think) we did FLSimpleStack. You can
              check also FLSimpleStackTest. Both are in Fuel repo. <br>
              <br>
              Would something like that help for the stack in GemStone?<br>
              <br>
            </div>
          </div>
        </blockquote>
        Yes. With this approach the resulting stack size is much
        smaller. To exceed the stack setting you need a graph containing
        an object which has a shortest route that is larger than the
        stack limit. And I think this is very unlikely :) </div>
      <div>I would need to change Sixx in order to have it work like
        this. I need to think about it.</div>
      <div><br>
      </div>
      <div>Thanks,</div>
      <div><br>
      </div>
      <div>Norbert<br>
      </div>
    </blockquote>
    Yes, using a specific stack in the way Fuel does relies on there
    being a separate analyze-phase before the actual serialization of 
    the objects.<br>
    (Due to wanting to group objects of the same type together when
    serializing)<br>
    <br>
    You could do the same in a "raw" serializer like SIXX:<br>
    1) pop first object from stack<br>
    2) if any of the instvars need to be serialized, and their ids can
    not be found in cache, push self + missing objects<br>
    3) if not, serialize self, then goto 1<br>
    <br>
    The key difference is you can not considering an object "done"
    during an analysis phase, but rather push it back on the stack for
    reevaluation after its dependencies have been handled in the same
    way.<br>
    <br>
    So the resulting stack will be much larger than what you see in
    Fuel, but still kept outside the call stack.<br>
    <br>
    Cheers,<br>
    Henry<br>
    <br>
    <br>
  </body>
</html>