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

Eliot Miranda eliot.miranda at gmail.com
Wed Dec 16 18:14:04 UTC 2015


Hi Ryan,

    I'll just respond to your point about keeping VMs working for now.

On Tue, Dec 15, 2015 at 6:43 PM, Ryan Macnak <rmacnak at gmail.com> wrote:

>
> 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.
>

I very much agree.  Apologies for the current situation.  AFAICT the build
is broken for reasons other than that the basic VM isn't correct.  I'm able
to build and run on macos32x86 and macos64x64 now.  As soon as I've got the
x64 up and running (should be today) I'll fix the builds.  Better, I
promise to attend to the builds tomorrow at the latest.


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.
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151216/6d5c1a6b/attachment.htm


More information about the Vm-dev mailing list