[Vm-dev] pixelValueAt: is not robust to hibernation [was: [squeak-dev] The Trunk: MorphicExtras-nice.137.mcz]

[David T. Lewis]

On Fri, Dec 20, 2013 at 04:54:39PM +0100, Nicolas Cellier wrote:
>  
> 2013/12/20 David T. Lewis <lewis at mail.msen.com>
> 
> >
> > Moving this to vm-dev for discussion of the BitBlt primitive.
> >
> >
> > Thanks for opening the bugs.squeak.org issue. Your patch adds this:
> >
> >         bitsSize := interpreterProxy byteSizeOf: bitmap.
> >         ((interpreterProxy isWordsOrBytes: bitmap)
> >                 and: [bitsSize = (stride * height * 4 "bytes per word")])
> >                         ifFalse: [^interpreterProxy primitiveFail].
> >
> > Which translates as:
> >
> >         bitsSize = interpreterProxy->byteSizeOf(bitmap);
> >         if (!((interpreterProxy->isWordsOrBytes(bitmap)) && (bitsSize ==
> > ((stride * height) * 4)))) {
> >                 interpreterProxy->primitiveFail();
> >                 return null;
> >         }
> >
> > This looks like exactly what Bert was suggesting.
> >
> > I think there are two things we should test:
> >
> > 1) Check if the extra computation has an effect on performance.
> >
> 
> I don't think the difference will be measurable, that's very few ops
> overhead...
> Even if it was, it must be compared to in-image protection alternative.
> So I don't think that this is relevant in this case.
> 

You are probably right, although I would not mind checking to be sure. Can
you suggest a simple test that I can run to exercise the primitive heavily?
I will try to follow up later with a timeToRun comparison of a VM before
and after the change.

> 
> >
> > 2) Check to make sure the logic works on the 64 bit image, to make sure
> > that the 4 bytes per word does the right thing (I think that it will work,
> > and I can follow up on this later to be sure).
> >
> > Dave
> >
> >
> The 4 bytes per word is also hardcoded in other BitBlt primitive because
> that's really what the bit blt expect, 32bit words.

I am quite sure that you are right about this, I just like to double check
it whenever I see a "4" entering the code.

> I'm a bit puzzled by 64bits image terminology, is variableWordSubclass:
> composed of 32bits words or 64 bits words (like pointers)?

The terminology is confusing. A "word" for variableWordSubclass: is always
32 bits in size, for all object memory formats (so far). In the 64 bit object
memory, "bytes per word" is 8 rather than 4, which leads to confusion with
the 4 byte "word". Neither of these kinds of word is related in any way to
the C pointer size.

In the 64 bit object memory (image format 68002 or 68003, I'm not sure
about Spur), the 32 bit Smalltalk words are packed into the 64 bit object
memory words. There are two Smalltalk words per object memory word, and
eight bytes per object memory word. An object pointer (oop) is 8 bytes, so
there is one oop per object memory word. This is all independent of C pointer
size, and a 64-bit object memory will run (slowly) on a VM compiled as a
32 bit executable (so there is no reason in principle that you cannot run
a 64-bit object memory on a 32-bit Cog VM, and this is currently possible
with an interpreter VM).

Some of the terminology is explained at http://www.squeakvm.org/squeak64/faq.html

Dave