[Vm-dev] VM Maker: VMMaker.oscog-rmacnak.1595.mcz

Ryan Macnak rmacnak at gmail.com
Wed Dec 16 02:43:30 UTC 2015


On Tue, Dec 15, 2015 at 10:50 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Ryan,
>
> On Mon, Dec 14, 2015 at 7:32 PM, <commits at source.squeak.org> wrote:
>
>>
>> Ryan Macnak uploaded a new version of VMMaker to project VM Maker:
>> http://source.squeak.org/VMMaker/VMMaker.oscog-rmacnak.1595.mcz
>>
>> ==================== Summary ====================
>>
>> Name: VMMaker.oscog-rmacnak.1595
>> Author: rmacnak
>> Time: 14 December 2015, 7:29:18.283 pm
>> UUID: 3aac3671-b1ff-45b9-8ed0-f3ecc5bca0b3
>> Ancestors: VMMaker.oscog-eem.1594
>>
>> MIPS: Complete simulation of the Newspeak test suite! (~30 billion
>> instructions) (Modulo Aliens, which don't work under the IA32 simulation
>> either.)
>>
>
> Can you say a little bit more about this?  How long did the simulation
> take?  What machine(s) did you run it on?  I *love* that you caught the MNU
> in followForwardingPointersInScheduler. I want to set this up for Squeak
> but never had the patience/.resources before.
>

This was a Newspeak image setup to run the test suite at startup and
display the results on the Transcript, running the normal VM simulation
setup on my Mac. I think the process had ~19 hours of CPU time when it was
finished, but this is an overestimate because the simulation stopped for
each of those bugs in the last commit. The IA32 simulation is an order of
magnitude faster, Bochs being written in C and my MIPS simulator being
written in Smalltalk with gratuitous asserts. Of course the MIPS one is
much easier to add a jump buffer to and get a limited form of back-in-time
debugging...

I don't think this process is well-suited to automatic testing. Both the VM
simulator and the Squeak-based system it's running have too many
assumptions that they are running interactively. In the simulator I had to
disable prompts that trigger on code compaction, primitiveExecuteMethod,
etc. The test harness being run had to be altered to report to the
Transcript. And if an unhandled exception had occurred in the simulated
image that simulator wouldn't have known to stop. This is tolerable as a
one-off to bring a new backend up, but not a productive way to test that
the system stays working.

What would be more helpful is if the VM build was fixed to work with a
cross compiler, so it would compile fast enough to test ARM and MIPS on
Travis CI alongside IA32 and X64. It would also help if the top-of-tree
Intel VMs were always kept working so we'd know which change broke
something. Moving the Subversion repository to a more reliable host (which
likely means migrating to Git) would also cut down on the false positives
Travis reports because the Subversion server has a habit of dropping
connections.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151215/bb3c93a2/attachment.htm


More information about the Vm-dev mailing list