[squeak-dev] [ANN] CorruptVM preview

Eliot Miranda eliot.miranda at gmail.com
Wed Jul 2 00:20:04 UTC 2008


On Tue, Jul 1, 2008 at 5:05 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > 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 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 :)


I hear you.  But for me, first things first :)

best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/d42a8679/attachment.htm


More information about the Squeak-dev mailing list