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

Hi Shaping,

On May 19, 2:33 am, Shaping <[email protected]> wrote:
> On May 18, 6:53 pm, talksmall <[email protected]> wrote:
>
> > On May 18, 11:29 pm, Shaping <[email protected]> wrote:
>
> > > On May 18, 10:27 am, "Gilad Bracha" <[email protected]> wrote:
> > >  Does Strongtalk use a
> > > direct-pointer model?
>
> > Yes, additionally both compiled and interpreted methods cache
> > references to classes.
>
> What are the differences in the implementations compiled and
> interpreted methods?  Are the Interpreted methods fully reified?

When I referred to compiled methods I meant "interpreted methods that
have been recompiled into native code by the recompiler". I'm not sure
what you mean when you refer to interpreted methods being "fully
reified". Do you mean the methods, or context objects for the stack
frames? Each interpreted method has it's own stack frame, however,
compiled methods are a different matter. Compiled methods are subject
to inlining, so a single physical frame on the stack may represent
multiple logical frames, however the source code structure of the
inlined frames is preserved to allow deoptimization of the frames for
debugging. The StackTraceInspector is an almost-complete UI debugger,
that works with the deoptimized frames. In this tool the frames are
represented by Activation instances somewhat similar to the
homeContexts from Squeak. Is this what you meant?

> If you are swapping pointers during a #become:, you have to be able to
> find all references.  Is doing this reliably the problem?
>

Finding all of the references for become: is not really a problem.
After all, this is exactly what the garbage collector has to do when
moving objects around. The code is specific to the garbage collector
though, so it will need to be extracted to allow its reuse for
become:. As Gilad mentioned, it's not that it's hard, it's just work
that has to be done, and no-one's done it yet.

> > > > A correct implementation of  doesNotUnderstand: is necessary as well.  I
> > > > understand some people on the list are looking at these issues.
>
> > > What's wrong with Strongtalk's #doesNotUnderstand:?
>
> > It is broken ;)
>
> > Basically, method lookups get cached in inline caches. When the class
> > of the receiver doesn't match the class of the cached method a method
> > lookup is performed. If a matching method is not found
> > doesNotUnderstand: gets called, however overriding the implementation
> > in Object doesn't work quite as expected. Any result returned by the
> > method is discarded and the lookup just repeats until the stack
> > overflows.
>
> Do we actually know where this code for the looping on the method-
> lookup lives?
>
>

The generated bytecode primitives and the recompiled native methods.
It is not helped by the fact that this is assembler, however, the
assembly is done dynamically on image startup using the same built-in
macro assembler used by the re-compiler and since the assembler code
for the send bytecodes of the interpreter is generated by a single
parameterised method, fixing the interpreted case shouldn't be too
hard. I haven't looked at the equivalent code in the re-compiler,
though I imagine that it will be similar.

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.

>
> > 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.

Actually I have ANSI exception handling almost completed. A few things
need finishing off, then we should be able to plug it into (for
example) doesNotUnderstand: and be able to catch MNU.

> Normally, without a handler in place, you would get the usual
> walkback.  Do you just want this to work in the usual way, where you
> get the walkback, or do you have a specific kind of handler in mind
> for this situation in which the cached class doesn't match that of the
> reciever?
>

In Strongtalk, the equivalent of a walkback would be the
StackTraceInspector mentioned above. This allows individual objects
from the stack to be inspected and modified like a normal debugger. It
has limited restart capabilities though.

>
> > > I poked around in Strongtalk-commit.  Most of the recent submissions
> > > seem to relate to the gcc build process or to linux.  Is anyone
> > > developing with the latest version of Visual Studio?.  I'm just asking.
> > > I don't really want to use it because the VS IDE seems to be broken is
> > > basic ways, anyway.  What is the most common, least problematic C++
> > > tool set being used to edit and build Strongtalk C++ code?
>
> > Actually, although the commits have been on the Linux branch, the code
> > on that branch builds under both Linux and Windows. The shared image
> > used by both has no Linux UI support as yet, but scripted Smalltalk
> > code can be executed.
>
> > Most of the recent work I have been doing has been in Windows using VC+
> > + 2008 Express. What problems have you had?
>
> One of the newer versions (I think 2008) of VS, a fresh install,
> reportedly (and I verified it) cannot successfully search for and find
> referenced member functions, when they are clearly present.  This must
> be a setup/config problem, but it's very bad one to experience on a
> fresh install.   I'm considering using Eclipse.
>

OK I lied, I have seen that one. I get by with text-based searches
instead. Works nearly as well, but it is slightly more clunky. I use
Eclipse when developing on Linux, but I think it only works with GCC.
Which platform are planning on focussing on Linux or Windows. I don't
think anyone has done much work with GCC in Windows since last year
when prunedtree did some of the initial work to the VM to build under
GCC. Also, I'm not wild about it's disassembly support. Typically it
only shows you context going forward from the correct execution point,
which is not great when you are trying to debug a piece of generated
code. Another alternative you might like to look at is Codeblocks,
though I only took a brief look at it last year, so I can't give much
of an impression.

>  I haven't seen any
>
> > problems with the environment, only with my code ;)
>
> > I'm just about to start looking into some of the issues Gilad is
> > interested in. In particular, doesNotUnderstand:, automatic garbage
> > collection and become: Wanna help?
>
> Yes.
>
> I don't have much choice.  Smalltalk is not enough anymore and I need
> a better language and VM.  Specifically, if there is a bottleneck, I
> need to be able to write a primitive myself, compile it in statically
> as part of the VM or place it in a DLL and link to it.  I also need
> callbacks, and I understand from Gilad that this is doable.
>

Yes, both callouts and callbacks work for stdcall and cdecl calling
conventions. FFI calls are the one area where an element of
concurrency is available in Strongtalk today. It is possible to call
out to DLL functions asynchronously and continue running Smalltalk
code while the function is executing. Of course, if the call out in
turn results in a call back, then it will pause until the Processor
schedule's it's Process again. The DLL functions do not typically gain
access to Smalltalk objects though. Instead, any data passed to these
functions is copied to the heap via ExternalProxy objects. It is
important not to pass object references outside Smalltalk space, since
these references will not be updated by the garbage collector.

One of the big advantages of Strongtalk is that this may very well not
be necessary, depending on the type of code that you are working with.
The Recompiler can progressively recompile hotspot methods to speed up
bottlenecks. The more frequently the bottleneck is run, the more it is
likely to speed up.

Additionally, DLL calls are subject to the impedance mismatch problem.
Having to copy the data to the heap adds significantly more overhead
than a message send, so if you are frequently crossing the boundary
between Smalltalk and C (or whatever) then this will probably dominate
your performance measurements and you won't see much saving. If you
write additional primitives statically linked into the VM, you will
need to be careful that any object references you store are available
to the garbage collector, or problems will occur when objects get
moved.

> I am working with an old machine--somewhat slow, but tolerable if I
> don't do to much at once.  I'm getting into a new machine soon, but
> will be two to three weeks doing that.  I can look at C++ source in
> the meantime, ask some questions, and get oriented.
>
> Shaping

My Linux porting stuff was done on a five year old Acer laptop, which
isn't exactly state of the art. Strongtalk performs very well with
limited resources, since most of the technology dates from more than
10 years ago, when machine weren't so generously decked out as they
are today. Building the VM under those environments is another matter
though. The faster the better when you're talking about C++ compiles
and links.

Ask away. I will do my best to provide answers where I can, but I'm
still learning the ins and outs myself. Hopefully Gilad will be able
help out with some other details, and Dave G. occasionally lurks on
the group.

I know some parts better than others (interpreter, memory management,
stack unwinding after ifCurtailed, linux porting details), but I
haven't done much investigation into the Recompiler which is what does
the work of dynamic recompilation of interpreted methods into native
code. Unfortunately, this is also where a lot of the stability issues
seem to occur.

Welcome!

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
-~----------~----~----~----~------~----~------~--~---