<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 a dedicated
class space. 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.
Yes this could be a good idea and yes this is potentially
doable in Spur. *But* it doesn't have to be done now.
The most important thing is to get a version of Spur that
is much faster than the current system asap. 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. But... what do you think of this idea (again
from the SpurMemoryManager class comment):</div>
<div>"A segmented oldSpace is useful. It allows growing
oldSpace incrementally, adding a segment at a time, and
freeing empty segments. 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.
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. 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. However, free objects would need a large
enough size field to stretch across large gaps in the
address space. 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. 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). 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 indeed keep a segment that
it puts pinned objects in preferentially, this wouldn't be
visible to the image level. It would only be an
optimization in the VM. 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. But supporting it at the image
level is work. 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. Again, don't let the perfect be the
enemy of the good. The first cut of the design,. the
first release of the design, is not the final release.
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. 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>