<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 9/8/2013 1:34 PM, Eliot Miranda
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAC20JE00DsmYhRVg71ZHiAVf4We+d7Q0oWrxOswPzk-9kR4HaA@mail.gmail.com"
      type="cite">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <div dir="ltr"><br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Well, VW's permSpace is a bit less than &nbsp;a dedicated
              class space. &nbsp;It is merely a 3rd generation of the oldest
              objects which just happens to contain classes and methods
              (and method dictionaries and Smalltalk and globals et al.
              &nbsp;Yes this could be a good idea and yes this is potentially
              doable in Spur. &nbsp;*But* it doesn't have to be done now.
              &nbsp;The most important thing is to get a version of Spur that
              is much faster than the current system asap. &nbsp;Don't let
              the perfect be the enemy of the good etc.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Sure, no pressure :)<br>
    I certainly did not mean it as in let's try to make it perfect from
    the start, but only as in, if it might influence design
    considerations, let's keep it in mind.<br>
    <br>
    <blockquote
cite="mid:CAC20JE00DsmYhRVg71ZHiAVf4We+d7Q0oWrxOswPzk-9kR4HaA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <pre>I also assume that a dedicated space for pinned memory might also simplify the garbage collector and even help performance a bit.</pre>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Indeed. &nbsp;But... what do you think of this idea (again
              from the SpurMemoryManager class comment):</div>
            <div>"A segmented oldSpace is useful. &nbsp;It allows growing
              oldSpace incrementally, adding a segment at a time, and
              freeing empty segments. &nbsp;But such a scheme is likely to
              introduces complexity in object enumeration, and
              compaction (enumeration would apear to require visiting
              each segment, compaction must be wthin a segment, etc).
              One idea that might fly to allow a segmented old space
              that appears to be a single contiguous spece is to use
              fake pinned objects to bridge the gaps between segments.
              &nbsp;The last two words of each segment can be used to hold
              the header of a pinned object whose size is the distance
              to the next segment. &nbsp;The pinned object's classIndex can
              be one of the puns so that it doesn't show up in
              allInstances; this can perhaps also indicate to the
              incremental collector that it is not to reclaim the
              object, etc. &nbsp;However, free objects would need a large
              enough size field to stretch across large gaps in the
              address space. &nbsp;The current design limits the overflow
              size field to a 32-bit slot count, which wouldn't be large
              enough in a 64-bit implementation. &nbsp;The overflow size
              field is at most 7 bytes since the overflow size word also
              contains a maxed-out 8-bit slot count (for object
              parsing). &nbsp;A byte can be stolen from e.g. the identityHash
              field to beef up the size to a full 64-bits."</div>
            <div><br>
            </div>
            <div>So while the system might &nbsp;indeed keep a segment that
              it puts pinned objects in preferentially, this wouldn't be
              visible to the image level. &nbsp;It would only be an
              optimization in the VM. &nbsp;Does that make sense?</div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <pre>To me it appears that this kind of specialization of memory (splitting it into dedicated spaces) would almost always be a win.
While it increases the complexity by increasing the number of components to manage, it also simplifies the components, since they need to handle fewer special cases.
But I have never implemented a vm :)</pre>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Yes it makes sense. &nbsp;But supporting it at the image
              level is work. &nbsp;VW's ObjectMemory/MemoryPolicy is quite
              sophisticated and I don't want to make implementing
              something similar for Squeak/Pharo a gating issue for the
              release of Cog+Spur. &nbsp;Again, don't let the perfect be the
              enemy of the good. &nbsp;The first cut of the design,. the
              first release of the design, is not the final release.
              &nbsp;Evolution is a constant.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I did not mean supporting it at the image level. This is also in
    response to not having the pinned objects segment visible at the
    image level, which I think is perfectly fine. <br>
    Tempting as image level support may sound, I think the image should
    offer as high a level of abstraction of the machine as possible,
    only breaking it when a specific and compelling reason is
    identified. In this case, pinning itself breaks the abstraction, but
    it is justified by the need to inter-operate with the rest of the
    world.<br>
    <br>
    I think exposing low-level details is a losing battle because the
    hosts are becoming more and more complex. If one really wanted to be
    in control, one would have to interact with the OS' paging/swapping,
    even caches and scheduling/processor affinity, let alone the fact
    that the OS itself might be virtualized. Or even the hardware. So
    where do we stop? These external aspects can dominate actual
    performance so much as to render our knobs useless. We should count
    us lucky if the VM/garbage collector can keep up with all these
    mechanisms and cooperate with them themselves - speaking of which:
    would it be possible for the vm/garbage collector to handle its own
    paging/swapping, so that the OS (which has much less specific
    information) does not interfere? <br>
    This is also in response to Tim's reminiscences of the good old
    days. I did have a lot of fun in my youth counting processor cycles
    of the individual instructions to make sure my interrupt routines,
    running directly on the metal, with no OS, could be serviced in the
    allotted time. It was a great feeling to be in such full control. I
    think those days are gone.<br>
    <br>
    <div bgcolor="#FFFFFF" text="#000000">
      <pre>You only mentioned in your blog tagging for the 32-bit world (I think).
Can you please add some comments about 64-bit tagging?</pre>
    </div>
    <blockquote
cite="mid:CAC20JE00DsmYhRVg71ZHiAVf4We+d7Q0oWrxOswPzk-9kR4HaA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Sure, I'll add stuff to the design sketch soon. &nbsp;But
              the idea is to provide immediate 60-bit, or 61-bit floats
              to the 64-bit system that implement a subset of 64-bit
              IEEE double precision in the centre of the range (actually
              with the same range as single-precision 32-bit floats),
              the same as in 64-bit VW.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Thank you,<br>
    Florin<br>
  </body>
</html>