Hi Max,

On Sun, May 7, 2017 at 4:24 AM, Max Leske <maxleske at gmail.com> wrote:

> Hi,
>
> I'm trying to store an image segment with the latest pharo.cog.spur VM (32
> bits) but keep failing. The segment should produce a file of around 60 MB.
> With an old V3 VM this is no problem at all. There, the WordArrayForSegment
> instance has a size of 4094179 but with the new VM I always run out of
> space because the primitive returns nil and, therefore, the word array size
> is constantly being increased.
>

It's been a while since I wrote this code so my understanding has been
coming back in fits and starts.  The limitation on the use of the hash bits
field is in referring to "out pointers", objects that the saved segment
refers to, not on objects internal to the segment.  So I think it's fixable.

The hash field is used to map from an object in the heap to its object in
the segment.  Right now the mapping is from hash (22 bits) to location in
the segment / 8, and so limits the size of the segment to 500kb.  If an
extra level of indirection was added so that hash maps to index in an array
of oops, then the segment could contain up to 4m objects and I think
that'll be large enough for your use.

If that's still not enough then the al;goriqhm will have to be rewritten to
use the first field of the object in the heap to point to its location in
the segment, and the first field saved alongside.

So let me know.  Would you be happy with a fix that provides up to 4m
objects per segment or would you want to wait for something with a much
higher limit?


> I've built a debug VM and am stepping through the code but I don't have a
> clear understanding of everything that's happening. The failure happens on
> line 46626 of gcc3x-cointerp.c:
>
> newOop = (copy - segStart) / 8;
> if (newOop > (identityHashHalfWordMask())) {
>         return PrimErrLimitExceeded;  // <--------------- failure
> }
>
> What I don't understand, for example, is why "newOop" is checked against
> "identityHashHalfWordMask()" and not against the segment end ("endSeg").
> Here's a list of the current values of the variables upon failure:
>
> objOop  sqInt   180812096
> segAddr sqInt   494731288
> segStart        sqInt   461176856
> endSeg  sqInt   815841432
> bodySize        usqInt  64
> contextSize     sqInt   335672448
> copy    sqInt   494731288
> hash    sqInt   0
> hash1   sqInt   4194302
> i       sqInt   833574680
> iLimiT  sqInt   833574688
> methodHeader    sqInt   1193471
> newOop  sqInt   4194304
> numMediatedSlots        sqInt   833574688
> numSlots        usqInt  14
> oop     sqInt   142640272
>
> As you can see, "endSeg" would be more than large enough to hold the
> object. Is it possible that there's an error here?
>
> Cheers,
> Max
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170508/f28072fe/attachment.html>