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

On May 18, 10:18 pm, talksmall <[email protected]> wrote:

> > What are the differences in the implementations of 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".

Right.

 I'm not sure
> what you mean when you refer to interpreted methods being "fully
> reified".

Both are modeled as first-class objects in Smalltalk?  Seems that way.

 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:

 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.

So the CompiledMethod instance that models a compiled method is still
retained for use in debugging, even if the compiled method's machine
code has been inlined in another method being called from an actual
frame on the stack.

 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?

Yes, I  was referring to this and the models used for the two kinds of
methods.

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

That is what I supposed and was wondering why the traversal from the
roots of the world hadn't been factored-out for use in #become:

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

"Recompiling" is the iterative compiling of bottlenecked regions of
code?

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

All of that seems reasonable.

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


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

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

So then we do intend to use exceptions in the usual way, once you get
the new ANSI exception handling code finished?

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

OK.

> > 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 prefer not to have to get by.  I want VS to work correctly in the
simplest use-case, and it doesn't.  Does anyone have a fix for this?
I guess not.  I don't understand why a basic bug like this persists in
a dev environ.  I expect MS to be incompetent when they make an OS.
But VS is their development environment, and basic referential
integrity is not present, seemingly, unless I've missed something.

> I use
> Eclipse when developing on Linux, but I think it only works with GCC.

I could use Eclipse for editing code, and then jump out to a command
prompt to run a nmake, but I don't relish the idea.

> Which platform are planning on focussing on Linux or Windows.

I'm focusing on WinXP Pro (no Vista, not ever).  I will do Linux
later.

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

I recall that.

 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.

That's sounds very frustrating.


> 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 did some reading on this.  It looks interesting.  I will try it
with MinGW.


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

This is similar to what we do in VW with CDatum objects on the foreign
heap.  These C structures can be managed manually if allocated with
malloc, or automatically by the GC if allocated with gcMalloc.


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

Yes, I recall reading about this, and am excited about the potential
efficiencies achievable.


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

This is my main concern.

Also, I am still collecting opinions on the best C++ environs on
Windows.

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

Thanks.


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