On Fri, Feb 26, 2016 at 11:27 AM, David T. Lewis <lewis@mail.msen.com> wrote:

That is very good news! The Cuis folks will be happy to hear about this
also, as there has been recent discussion on the Cuis list about how to do
a transition to Spur format.

Alas the tracer is unlikely to work as one needs to add extra methods.  I have been remiss in helping the Cuis folks transition.  I have been distracted with 64-bit work.  The situation right now is that a script that installs the revised Float (SmallFloat64 & BoxedFloat64) hierarchy needs rewriting for Cuis and I haven't got round to it.  Forgive me.




If I recall right, the issue with tracing and resuming on Cog had to do
with resuming in the middle of a method of a jitted method. I don't think
that I ever positively confirmed that theory, but things worked fine under
an interpreter and it was a trivial step to re-save from Cog.

At least from the image level the difference in e.g. pc in the active context shouldn't be visible.  If it is then there's a bug in Cog.
 

Dave

>
> I've updated the SystemTracer package to trace a Spur-format image.
>
> 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).
>
> 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.
>
> 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.)
>
>
>
> --
> 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.
>





--
_,,,^..^,,,_
best, Eliot