Re: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger

On May 21, 6:20 am, Shaping <[email protected]> wrote:
> > > Both are modeled as first-class objects in Smalltalk?  Seems that way.
>
> > No. Only the interpreted version is visible to Smalltalk. The compiled
> > version appears as an nmethod in the VM, but I don't believe there is
> > a Smalltalk level equivalent. When Activation objects are created for
> > the StackTraceInspector the stack has already been deoptimised to
> > leave on interpreted frames (and therefore interpreted methods).
>
> > >  Do you mean the methods, or context objects for the stack
>
> > > > frames?
>
> > > Both.  I'm asking how we model compiled and interpreted forms of a
> > > method, specifically, so that I can determine how to track-down all
> > > references that may need to participate in a #become:
>
> > In the VM a (re)compiled method is represented as an nmethod. An
> > interpreted method is represented as a methodOopDesc usually referred
> > to be a methodOop pointer. The core of the code necessary for a
> > become: is in phase 1 of the mark and sweep garbage collection in
> > markSweep.cpp. This illustrates iteration over all places where the VM
> > may store references to Smalltalk objects.
>
> > At the moment this code uses a function pointer passed to a series of
> > iterator functions (such as Universe::oops_do()). Continuing with this
> > means that we would need to put the state in global variables, an idea
> > I'm really not keen on, but may be better than the alternatives.
>
> Why not maintain needed global state in a single instance of class
> Universe (the most global scope in Strongtalk, presumably), where the
> iterators also live?

Effectively, that is what happens now, except that Universe is
AllStatic (which means what it sounds like). wrt become: I think this
is nasty, because the stored values aren't really part of the state of
Universe, that is just a convenient temporary place to store the two
values (or to sets of values, in the
elementsForwardIdentityTo:copyHash: case) to allow a stateless
function pointer to be used in the iterator method.

>
> > > "Recompiling" is the iterative compiling of bottlenecked regions of
> > > code?
>
> > It's not iterative exactly, but it may happen repeatedly if a method
> > is heavily used. Note that tight loops inside a single method
> > activation that never ends (the typical case being event loops) are
> > not optimized by the recompiler. Recompilation is typically triggered
> > on send sites, but the new version of the method is only used for a
> > new activation of the method, not for existing activations.
>
> I see.
>
>
>
> > > > The way that the interpreted code works at the moment is to identify
> > > > that the IC is stale (ie. the receiver class doesn't match) and fall
> > > > through to the lookup code which is supposed to patch the method and
> > > > class in the IC. The code then jumps back to the start IC test again
> > > > and falls through again. Actually why this causes the stack overflow I
> > > > saw when I tried earlier, I'm not sure. I was actually expecting it to
> > > > go into a spin loop around the send.
>
> > > Seems that that once the patch in the IC is done correctly, the test
> > > for stale will not longer fall through to the lookup code.  Perhaps
> > > the patch itself is the problem.
>
> > No. You can only patch the IC with a method that matches the signature
> > of the message send. doesNotUnderstand: doesn't meet this criteria. In
> > particular, it expects an instance of Message as an argument, rather
> > than a list of arguments for the original message send. To work in the
> > way you suggest the lookup routine would need to pop the arguments off
> > the stack, construct a Message with those arguments and push it back
> > in their place, then patch the IC, keeping in mind that this is all
> > occurring in a different frame of the stack - that of the method
> > containing the IC, rather than that of the lookup function.
>
> > In addition, and somewhat more problematically, the next time you hit
> > that IC it will contain a reference to doesNotUnderstand:. That's not
> > so bad if the receiver class has changed, because the lookup gets
> > called to updated the IC, but if it is the same class, you have a
> > problem, because there is now no hook to pop the arguments from the
> > stack and create a Message with them.
>
> Agreed.
>
>
>
> > All round, I think it is easier to change the send code to invoke
> > doesNotUnderstand: rather than trying to do it in the lookup function.
>
> Agreed.  I need to know more about the structure of the IC and how it
> is used in the course of a send.  I'm following the gist of this but
> some of the details are unclear.  I should be looking at code soon
> with CodeBlocks.
>
>
>
> > > > > > To fix this, message sends in compiled and interpreted methods need to
> > > > > > allow for a failed lookup followed by an invocation of
> > > > > > doesNotUnderstand: that pops the arguments from the stack and pushes
> > > > > > the result returned by the method.
>
> > > > > Are you saying that you want the exception handling following the
> > > > > raising of the MNU expection to work correctly?  Apparently the
> > > > > exception itself is not being raised at all.  Is this the problem?
>
> > > > Actually the current doesNotUnderstand: doesn't signal a MNU.
> > > > Strongtalk doesn't have ANSI standard exceptions. Instead it calls
>
> > > > Processor stopWithError: (ProcessDoesNotUnderstandError new message:
> > > > m)
>
> > > > which is a bit like an exception, without quite being one.
> > > > Specifically, there is no mechanism to catch this error other than the
> > > > ProcessorScheduler's stopHandler.
>
> > > So what magic do we do inside this special handler?
>
> > Typically the stopHandler starts a StackTraceInspector on the stopped
> > process. Take a look at Launcher. This is the main Transcript window.
> > When the programming environment starts it sets the stopHandler on the
> > Processor (a ProcessorScheduler instance). The code is in
> > Launcher>>startProgEnv. Of course, the stop handler could be set to
> > something else using stopHandler: on the Processor, but there's
> > effectively only one chance to catch the error, not a nested set of
> > exception handlers. This is what my exception handling implementation
> > provides using the ANSI Smalltalk description.
>
> Do we have a standard set of test-scripts in Smalltalk (SUnit tests or
> even an agreed upon DoIt or set of them) that drill the VM for various
> basic functions, as well as new ones being tested for the first time,
> like your ANSI exception handling?  In each test cycle I want to know
> that I'm fixing my own stuff and not breaking someone else's.
>
> Shaping

There are some Smalltalk-side tests, but very little at the level of
the VM itself. If you look at Bootstrap>>deterministicallyTestSystem,
this is the closest to a SUnit test suite. Actually, now that my
exception handling stuff is nearly complete, I managed to port across
SUnit from the Squeak version, so we could port these across to a
separate set of test classes, as well as adding our own, as they are a
bit skimpy. I have never liked the idea of having the test code for a
class within the class itself.

There is a handy little test script that can be used to run this
automatically from the command line within starting the UI. You will
find it in tools/test.dlt. To run this use something like
strongtalk_debug.exe -f tools\strongtalkrc-forInterpretedTests -script
tools\test.dlt from the strongtalk directory.

BTW once you manage to build strongtalk, and assuming that you are
using the gcc-linux branch, you will need a compatible image and
sources. You can find a zip containing these on the downloads page of
the wiki. You should unzip them in the strongtalk directory.

Regards, Steve
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---