[Vm-dev] Re: Tracing a Spur Image from Smalltalk
eliot.miranda at gmail.com
Fri Feb 26 22:17:52 UTC 2016
> On Feb 26, 2016, at 1:25 PM, timfelgentreff <timfelgentreff at gmail.com> wrote:
> by parallel-stepping through the simulator on the traced image and a normal
> one I found two issues, the first relating to the size of the hidden roots
> object (was 4096 in my code, apparently needs a few extra slots) and the
> size of the free lists object (which I left empty, because we're ignoring it
> in RSqueakVM). After fixing those things and adding an ugly workaround for a
> file-prim failure post startup, I now get working Spur images out of the
> tracing process :)
Congratulations Tim, and thanks!
> Would it make sense to move the SystemTracing package into the VMMaker repo?
> If not, David, can you give me access to the SystemTracing repo so I can
> push my version there? I did everything in a new subclass of SystemTracer2
> (minus some method extraction refactorings), so the old code for tracing
> pre-Spur images and the even older version without BlockContexts also works.
Nice! Do you select the right tracer based on a vmParameterAt: invocation, or...?
> Eliot Miranda-2 wrote
>> Hi Tim,
>>> On Feb 26, 2016, at 7:59 AM, timfelgentreff <
>> > wrote:
>>> I've updated the SystemTracer package to trace a Spur-format image.
>> Woo hoo!
>>> This works as far as I can tell, producing a header that looks just like
>>> header produced by the VM and the objects written also look good. I can
>>> open the image in RSqueak, but not on Spur. It crashes immediately and
>>> produces a Smalltalk backtrace that looks like it never manages to return
>>> from the image-saving method (but the names in the Stack-trace all look
>>> leading me to believe that enough objects got written ok to figure out
>>> classes, method names, find the right Process to run and so forth).
>> Have you tried opening it in the simulator? Also you can use the leak
>> checker in both the simulator and in an assert VM. But that you can run
>> the traced image in RSqueak argues against it being a mist raced heap.
>>> Curiously, the old SystemTracer2 class that writes Cog-format images also
>>> produces images that cannot be opened by Cog VMs, only Interpreter VMs.
>>> So I
>>> assume there are other assumptions that maybe the JIT makes when starting
>>> So my question is, what assumptions could there be, and where could I
>> The things to do are to use the simulator and an assert VM because many of
>> the invariants upon which the VMs depend are checked by asserts. Likely
>> you'll find an assert failure that will point to any issues immediately.
>> Tim, if your image is available I'd love to download it.
>>> (If you're wondering why I'm using the Smalltalk-level tracing at all -
>>> our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code
>>> enough that we no longer have to rely on C code from plugins or optional
>>> primitives, we're trying to see how far we can push this, and e.g. write
>>> image from within itself, too.)
>> And I hope that Sista will help you get there.
>> BTW, if you have spare muscle in your team Sour could really do with a new
>> compactor. Clément has a design in his head but, like me, no time. I
>> guess you're in the same state but I thought I'd ask just in case.
>>> View this message in context:
>>> Sent from the Squeak VM mailing list archive at Nabble.com.
> View this message in context: http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224p4881300.html
> Sent from the Squeak VM mailing list archive at Nabble.com.
More information about the Vm-dev