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

[Nicolas Cellier]

2013/12/20 David T. Lewis <lewis at mail.msen.com>

>
> 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.
>
>
most heavy use are probably Form>>floodFill2:at: and
PNMReadWriter>>nextPutRGB:

For example:

AndreasSystemProfiler spyOn: [| prw |
    prw := PNMReadWriter new.
    prw stream: (ByteArray new: 1e5) writeStream.
    [prw nextPutImage: PaintBoxMorph paletteImage] bench].


>
> > >
> > > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131220/40e90fdb/attachment-0001.htm