<br><br><div class="gmail_quote">On Tue, Jul 1, 2008 at 5:05 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2008/7/2 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div class="Ih2E3d">><br>
><br>
> This is the "mirrors" approach I alluded to. The right approach is to<br>
> implement the debugger with a mirror between it and the system it looks at.<br>
> There is a mirror for local debugging taht is fairly transparent. then<br>
> there is a mirror for the renoter system which is much more involved because<br>
> it has to use peek and poke to examine the memory space of the target<br>
> process and it has to extract meta information from it (and in the<br>
> presence of errors, e.g. the hard crash could have corrupted memory).<br>
><br>
<br>
</div>I have some ideas about it.<br>
First: nobody prevents me to have image containing separate object<br>
memories. Its only a question how to load and bootstrap it :)<br>
<br>
Or, more specific: i think i will introduce the island model (or vats)<br>
from the start.<br>
So there will be a multiple islands (which can be possibly run in<br>
parallel native threads), which don't share anything, or sharing a<br>
protected memory region, writing to which is guarded by a lot of<br>
checks and rules :)<br>
<br>
Since there is nothing outside, which dictates me to have: single<br>
heap, single GC, single object memory; it is possible to implement a<br>
system, which could have different memory regions governed by<br>
different memory managers and garbage collectors.</blockquote><div><br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Then debugging looks much less scary than comparing to system crippled<br>
by VM written in C :)<br>
<div class="Ih2E3d"><br>
> Let me encourage you to think about this soon and work on it asap because it<br>
> is a really important issue. If you don't have a good debugging environment<br>
> up front your progress will be slow. No one has succeeded in bringing such<br>
> a system for a Smalltalk-like language into production use yet (neither<br>
> Klein nor TypedSmalltalk nor Exupery has made it to production use). Making<br>
> it happen would be fantastic. You have the Spoon system to build upon.<br>
><br>
<br>
</div>Absolutely, a system without good means of debugging can't progress<br>
fast (and its mainly just a useless artifact for serious deployment).<br>
I'm concerned that amount of debug information to be added to method<br>
would hit hard the memory consumption.<br>
<div class="Ih2E3d"><br>
> You have to both provide a Smalltalk-level debugger and a machine code<br>
> debugger which can display machine instructions, registers and memory. It<br>
> would be nice to be able to reuse disassemblers et al from other components<br>
> but you might find that Smalltalk implementations are quicker to write and<br>
> easier to understand and use. But you will need them.<br>
><br>
<br>
</div>Heh.. right, but it would take ages :)<br>
A teamwork is what is needed. I looking for a people who may want to<br>
join crusade for the ultimate smalltalk self-sustaining system<br>
implementation :)</blockquote><div><br>I hear you. But for me, first things first :)<br><br>best<br>Eliot</div></div>