[Vm-dev] Re: Tracing a Spur Image from Smalltalk

Eliot Miranda 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:
> 
> 
> Hi,
> 
> 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...?


> cheers,
> Tim
> 
> 
> Eliot Miranda-2 wrote
>> Hi Tim,
>> 
>>> On Feb 26, 2016, at 7:59 AM, timfelgentreff &lt;
> 
>> timfelgentreff@
> 
>> &gt; 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
>>> the
>>> header produced by the VM and the objects written also look good. I can
>>> also
>>> 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
>>> ok,
>>> 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
>>> up.
>>> 
>>> So my question is, what assumptions could there be, and where could I
>>> start
>>> looking.
>> 
>> 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.
>> 
>> 
>>> 
>>> Cheers,
>>> Tim
>>> 
>>> (If you're wondering why I'm using the Smalltalk-level tracing at all -
>>> in
>>> our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code
>>> fast
>>> 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
>>> the
>>> 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:
>>> http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224.html
>>> 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 mailing list