[squeak-dev] trunk and new vm etiquette

David T. Lewis lewis at mail.msen.com
Tue Jul 21 20:40:20 UTC 2020


He Eliot,

On Tue, Jul 21, 2020 at 12:29:49PM -0700, Eliot Miranda wrote:
> Hi David,
> 
> On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > About a week's advance notice on the list(s) seems pretty reasonable,
> > possibly with an <ACK> from the CI folks to make sure. Switching VMs
> > might be an inconvenience, but this is trunk after all and that's what
> > it's for.
> >
> > I'm assuming that "broken" means the the user would see some failing
> > tests due to the need for updated VM support, but the image would
> > still run and be somewhat functional on the previous VM.
> >
> > This might also be an opportune time to add
> > primitiveMultipleBytecodeSetsActive
> > if you are so inclined. It requires trunk users to update their VM before
> > the image format number can be updated, so it would be convenient if
> > it could come along with the primitiveAt[Put] changes.
> >
> 
> We still have to discuss this.  I'm sorry, been too busy to do so.  I still
> don't understand the intent here.  The VM already provides a status bit in
> parameter 65 which says whether the VM supports multiple bytecode sets.  If
> the intent is to mark an image when multiple bytecode sets have been used
> then the primitive doesn't appear to me to do what's required.  I'll try
> and answer in the context of the thread soon, because I agree it's
> important.

Thanks :-)

>  Ideally there would be a pair of flags set somewhere that said
> if the current image had ever executed a method in either bytecode set.
> 

Yes, that would be better if it can be done without affecting performance.

Dave

> 
> > Dave
> >
> >
> > On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:
> > > Hi Eliot,
> > >
> > > I only ever upgrade my VM if something breaks or if I am asked to. So
> > > if you'd post a message with something like "Please upgrade your VM"
> > > in the subject line to the list once you push the changes to Trunk,
> > > that would be great for me!
> > >
> > > Concerning the time span: in an ideal world I would say "as soon as
> > > the CI is green", but I have my doubts that this will be enough for
> > > Squeak. Assuming that you use the new VM immediately and frequently
> > > (or anyone else does), I think a day of work up to a week after the VM
> > > changes is fine. Or as soon as you are confident about it, however you
> > > measure that. ;-)
> > >
> > > Kind regards,
> > > Jakob
> > >
> > > Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> > > <eliot.miranda at gmail.com>:
> > > >
> > > > Hi All,
> > > >     I've just found and fixed a VM bug in an as-yet-unpublished pair
> > of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and
> > Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows
> > two methods (at:[put:]) in FloatArray to relace four methods
> > (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times
> > faster than the plugin methods.  The issue is when to publish the
> > corrections to trunk.
> > > >
> > > > Since the existing VM is broken I don't want to simply push to trunk
> > and have people inconvenienced by a sudden emergence of failures in the
> > FoatArrayTests.  However, I do want to push the corrections soon, because
> > they're a substantial improvement.  So the question is how long should I
> > wait?
> > > >
> > > > Is it OK if I push the fixes to FloatArray and subclasses in a week?
> > Do people using trunk keep an eye on the CI builds and upgrade, or would
> > they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask
> > that you upgrade your VM.
> > > > _,,,^..^,,,_
> > > > best, Eliot
> > > >
> > >
> >
> >
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

> 



More information about the Squeak-dev mailing list