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.... Sent from the Squeak VM mailing list archive at Nabble.com.