[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