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

[David T. Lewis]

Hi Tim,

I just added you to the repository at
http://www.squeaksource.com/SystemTracing. Please commit your updates
there.

Thanks a lot for doing this!

Dave


>
> 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 :)
>
> 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.
>
> cheers,
> Tim
>
>
> Eliot Miranda-2 wrote
>> Hi Tim,
>>
>>> On Feb 26, 2016, at 7:59 AM, timfelgentreff <
>
>> 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
>>> 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.
>