[Vm-dev] Re: Cog Rump Xen unikernel (spur mmap)

Eliot Miranda eliot.miranda at gmail.com
Thu Dec 17 08:57:00 UTC 2015


On Wed, Dec 16, 2015 at 10:34 PM, Ryan Macnak <rmacnak at gmail.com> wrote:

>
> On Wed, Dec 16, 2015 at 3:20 PM, Ben Coman <btc at openinworld.com> wrote:
>
>>
>> On Thu, Dec 17, 2015 at 4:13 AM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>> >
>> > There are constraints here.  The VM assumes the following memory order:
>> >
>> > Low addresses:
>> >     machine code zone
>> >     new space
>> >     first heap segment
>> >
>> > High addresses
>> >     subsequent heap segments
>
>
> I know new space < old space is relied on for store buffer checks. Is the
> relative order of the code zone and the heap ever used?
>

Rather than used, it is coped with.  See SpurMemoryManager>>isYoungObject:
& isReallyYoungObject: &
Spur[32|64]BitCoMemoryManager>>isReallyYoungObject:.  The code zone can go
anywhere, but if it goes below new space (as it does currently) then the
scavenger needs to use isReallyYoungObject: so as not to be confused by the
CogMethod references in cogged CompiledMethods.

Thinking long term, this reliance on ordering is bad for address space
> randomization or having multiple heaps in the same process (e.g., having
> concurrent actors with fast messaging). The Dart VM uses object alignment
> to distinguish object age, though it doesn't have immediate characters or
> floats contending for that bit.
>

Agreed.  But it is nice to be able to use a single bounds check.  I'm happy
to maintain two versions when address randomisation and/ior unikernels
force two checks.

The alignment issue is trickier than that.  Right now Spur has an 8 byte
alignment, so bit 1 << 3 can vary.  Aligning object headers on a 16 byte
boundary, thereby allowing bit 1 << 3 to be used to mark age, would involve
padding half of the objects with another 8 byte word, and that's of the
order of a 7% hit on memory usage in 64-bits and 6% in 32-bits (*).  So
while the alignment trick is fast to test I don't think it pays for itself.

(*) surprised me, but that's what I measured.  Since Spur rounds object up
to 8 bytes, a 1 inst var 32-bit obj takes the same size as a 2 inst var
32-bit obj.  So I guess that this rounding has the effect of ending up with
more 32-bit objects aligned on a 16-byte boundary than 64-bit ones.  That
seems to be the case; in my reader image 141871 32-bit objects need
rounding up whereas 232742 64-bit ones do.  In my reader image there
are 384388 64-bit objects and 413845 32-bit ones.  I guess that means 29457
fewer objects due to the larger immediate range and immediate floating
point.  Not too shabby :-)  [but it's late; take these numbers with a grain
of salt]

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151217/61200946/attachment-0001.htm


More information about the Vm-dev mailing list