Hi Igor,

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

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


A foreign call is a perfect time to do a stack switch.  One has to marshall
arguments from one language to another so it doesn't add asny overhead to
marshall objects one one stack into values passed out on another stack.  You
pay a little bit extra on the return path where you do have to change
stacks, but its not a huge cost (system calls are not that expensive
anymore).

If you take this approach (which is taken by the VisualWorks VM for all
primitives written in C, everything except a subset of the core language
primitives) you can easily manage your own stack.  (It is even easy to
allocate the small amount of stack you use on the thread's C stack using
alloca. :) )

The native Cog will do this.  The StackInterpreter Cog (that today executes
325k bytecodes before hitting incomplete simulation code in BitBltSimulator,
sob - I wanted to see some pixels) also does this but only interprets in the
stack rather than running natively on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/2d3e0446/attachment.htm