[squeak-dev] [ANN] CorruptVM preview

2008/7/1 Eliot Miranda <[hidden email]>:

> Hi Igor,
>     this looks cool.  It is related to David Ungar's Klein which was an
> attempt at a self-hosted Self system, and to Exupery and Typed Smalltalk,
> and Ian's Cola.  Whenever I've thought about this style VM I've always been
> put off by a bug issue.  How are you going to deal with hard crashes?
> One needs some form of symbolic debugging at the machine code level.  If one
> is debugging the Squeak VM (or any other Smalltalk VM I've worked on) one
> can compile a version with debug symbols, use the platform's debugger (e.g.
> gdb) and write debugging functions in C to be called from that debugger.
> If one has a self-hosted Smalltalk system with no symbolic information that
> can be read by a platform's debugger because the system, being Smalltalk,
> has is own fully reflective self-description, then it seems to me one really
> is fishing about in a vast hex dump of the entire system, and that doesn't
> seem workable.  Note that in the presence of a hard crash one doesnt have
> the system to debug itselr because it has just crashed.

I have some thoughts about using properly set exception handling mechanism.
In Windows its a Structured Exception Handling (SEH) , provided by OS,
in unixes there is need to set up a signal handlers.
So, if properly set up, it is possible to debug most of errors without
using external debugger process, and you don't have to generate any
symbolic info for them.
There are vast possible options and solutions. As Ralph mentioned, it
can keep 2 object memories - one for running image, second for
controlling it.

> So are you going to export symbolic information that a platform debugger can
> consume (and if so, how?) or are you going to do something else (e.g.
> mirrors)?
>

Good question, i need to think about it. I don't think it would be
easy to bind such info with platform debugger (because they all are
C-centric and its unlikely that they will be able to find any info in
freely movable code ;) ), what i think is more realistic, that we can
run an image containing debugger, and provide enough interface in
running image, so debugger can extract all required info from process
being debugged.

--

Best regards,
Igor Stasenko AKA sig.

2008/7/2 Eliot Miranda <[hidden email]>:

>
>
> This is the "mirrors" approach I alluded to.  The right approach is to
> implement the debugger with a mirror between it and the system it looks at.
>  There is a mirror for local debugging taht is fairly transparent.  then
> there is a mirror for the renoter system which is much more involved because
> it has to use peek and poke to examine the memory space of the target
> process and it has to extract meta information   from it (and in the
> presence of errors, e.g. the hard crash could have corrupted memory).
>

I have some ideas about it.
First: nobody prevents me to have image containing separate object
memories. Its only a question how to load and bootstrap it :)

Or, more specific: i think i will introduce the island model (or vats)
from the start.
So there will be a multiple islands (which can be possibly run in
parallel native threads), which don't share anything, or sharing a
protected memory region, writing to which is guarded by a lot of
checks and rules :)

Since there is nothing outside, which dictates me to have: single
heap, single GC, single object memory; it is possible to implement a
system, which could have different memory regions governed by
different memory managers and garbage collectors.

Then debugging looks much less scary than comparing to system crippled
by VM written in C :)

> Let me encourage you to think about this soon and work on it asap because it
> is a really important issue.  If you don't have a good debugging environment
> up front your progress will be slow.  No one has succeeded in bringing such
> a system for a Smalltalk-like language into production use yet (neither
> Klein nor TypedSmalltalk nor Exupery has made it to production use).  Making
> it happen would be fantastic.  You have the Spoon system to build upon.
>

Absolutely, a system without good means of debugging can't progress
fast (and its mainly just a useless artifact for serious deployment).
I'm concerned that amount of debug information to be added to method
would hit hard the memory consumption.

> You have to both provide a Smalltalk-level debugger and a machine code
> debugger which can display machine instructions, registers and memory.  It
> would be nice to be able to reuse disassemblers et al from other components
> but you might find that Smalltalk implementations are quicker to write and
> easier to understand and use.  But you will need them.
>

Heh.. right, but it would take ages :)
A teamwork is what is needed. I looking for a people who may want to
join crusade for the ultimate smalltalk self-sustaining system
implementation :)

2008/7/2 Eliot Miranda <[hidden email]>:
>
>
> On Tue, Jul 1, 2008 at 5:05 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> 2008/7/2 Eliot Miranda <[hidden email]>:
>> >
>> >
>> > This is the "mirrors" approach I alluded to.  The right approach is to
>> > implement the debugger with a mirror between it and the system it looks
>> > at.
>> >  There is a mirror for local debugging taht is fairly transparent.  then
>> > there is a mirror for the renoter system which is much more involved
>> > because
>> > it has to use peek and poke to examine the memory space of the target
>> > process and it has to extract meta information   from it (and in the
>> > presence of errors, e.g. the hard crash could have corrupted memory).
>> >
>>
>> I have some ideas about it.
>> First: nobody prevents me to have image containing separate object
>> memories. Its only a question how to load and bootstrap it :)
>>
>> Or, more specific: i think i will introduce the island model (or vats)
>> from the start.
>> So there will be a multiple islands (which can be possibly run in
>> parallel native threads), which don't share anything, or sharing a
>> protected memory region, writing to which is guarded by a lot of
>> checks and rules :)
>>
>> Since there is nothing outside, which dictates me to have: single
>> heap, single GC, single object memory; it is possible to implement a
>> system, which could have different memory regions governed by
>> different memory managers and garbage collectors.
>
> This assumes that an error in one island can't corrupt the heap of another
> island, not a safe assumption.  You really need to use separate address
> spaces for isolation.  If the mirrors are done right the tool side of things
> is the same anyway.
>

Then its coming closer to a point, when without speaking directly with
hardware (without being restricted by OS) is the only reliable option.
It would be much painless if things could operate on zero ring (kernel mode).
But without it.. we have to live in user-mode memory model, provided
by OS. And hence, should heed what OS dictates: use separate process
to debug another process.

Things are really, can be a lot easier, if it could manage physical
memory itself.. For instance, i feel headache each time when i
thinking how to make Processes cheap. A straightforward approach is to
use separate native thread for each Process instance, and let OS
manage the stack. But this is far from cheap. A single native thread
reserving at least two/three pages of physical memory for stack.
I could make own stack, and use separate stack (not provided by OS by
default), and can make own checks for stack space left. But then in
case when you do foreign calls, things makes the whole idea not so
attractive - foreign functions have no idea how large my stack is, and
can't check it in same way is my code does.