Discussion:
[ANN] CorruptVM preview
(too old to reply)
Igor Stasenko
2012-01-28 12:19:02 UTC
Permalink
Since lately there a some interest in C/C++ compiling and some people
mentioned how it would be cool to make everything to be dynamically
compiled,
i decided to make a preview announce of a research which i done during
last few months.

A project name is a weird, and definitely it require more appropriate
name to not scare off a potential users/developers, but this is not an
issue right now :)

Let me describe a little the key features of project and what goals it pursuing:

- the main goal is to create a smalltalk language environment (similar
to other smalltalks), but i avoid to call it VM, because its not
really a VM, because there is no VM at all.
- everything is written in smalltalk
- system is completely self sustaining: smalltalk code compiled down
to native code (no initial need in having bytecodes). Of course no-one
prevents you from implementing a bytecode interpreter on top of it.
But this is beyond the scope of current project. :)
- there is no primitives nor need in writing external code in C (or in
any other statically typed language). A primitives replaced by native
methods (methods with <native> pragma), by using which you can
implement any low-level behavior.

- everything (by a 99.9% ;) in system is up to implementor. There is
a few 'glue' semantics used by compiler, but compiler itself
extensively using static inlining (inlining native methods from
well-known classes such as CompiledMethod/ProtoObject or
StackContext). Memory management/relocation, FFI , a diverse set of
what we currently know as 'privitives' will be implemented in a
system. This opens a potentially huge playground, how system would
look like :)

- avoid using global state. All state which code can potentially refer
to is placed in literals. There is no difference between native
methods and smalltalk methods in compiled method format. The
difference only how they are compiled. Of course there will be some
global state , i think it would be a single 'lobby' object, which
contains a symbols table (required to support symbols uniqueness
thoughout all system). But anyway, references to it will be possible
only from method literals.
- generated native code are location independent. Since all jumps will
be relative, and all location-dependent stuff are either held in
literals or computed. Therefore a CompiledMethod instances can be
relocated freely in memory (by GC and friends) without any change that
it will cause any harm.

- compiler translates smalltalk code to a lambda representation. Then
using different transformations it generates a low-level lambdas,
which represent a virtual machine CPU instructions. No AST nor bunch
of different classes to represent semantic elements of code used.
Lambdas all the way down.

- an object memory model is initially based on Ian's minimal object
system. With some changes.

You can download a snapshot of project at squeaksource:
http://www.squeaksource.com/CorruptVM

What is currently should work:

CVMachineSimulator bootstrap -- bootstrap a object memory for simulation
CVSimulationTests run -- run different tests on boostrapped object memory

There are also an initial implementation of translating to native code
using Exupery (you need to load Exupery for that).
Do it:
CVExuperyCompiler test inspect


I am currently open for suggestions and advices or discussion in how
is better to implement system based on such design.
Would be glad to read your comments.

There is also a wiki page of project:
http://wiki.squeak.org/squeak/6041
--
Best regards,
Igor Stasenko AKA sig.
Dietmar Schielke
2012-01-28 12:19:02 UTC
Permalink
Sounds like a good idea! This reminds me on Forth and its cross compilers
and recently factor.



"Igor Stasenko" <***@gmail.com>
Gesendet von: squeak-dev-***@lists.squeakfoundation.org
01.07.2008 08:07
Bitte antworten an
The general-purpose Squeak developers list
<squeak-***@lists.squeakfoundation.org>


An
"The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Kopie

Thema
[squeak-dev] [ANN] CorruptVM preview






Since lately there a some interest in C/C++ compiling and some people
mentioned how it would be cool to make everything to be dynamically
compiled,
i decided to make a preview announce of a research which i done during
last few months.

A project name is a weird, and definitely it require more appropriate
name to not scare off a potential users/developers, but this is not an
issue right now :)

Let me describe a little the key features of project and what goals it
pursuing:

- the main goal is to create a smalltalk language environment (similar
to other smalltalks), but i avoid to call it VM, because its not
really a VM, because there is no VM at all.
- everything is written in smalltalk
- system is completely self sustaining: smalltalk code compiled down
to native code (no initial need in having bytecodes). Of course no-one
prevents you from implementing a bytecode interpreter on top of it.
But this is beyond the scope of current project. :)
- there is no primitives nor need in writing external code in C (or in
any other statically typed language). A primitives replaced by native
methods (methods with <native> pragma), by using which you can
implement any low-level behavior.

- everything (by a 99.9% ;) in system is up to implementor. There is
a few 'glue' semantics used by compiler, but compiler itself
extensively using static inlining (inlining native methods from
well-known classes such as CompiledMethod/ProtoObject or
StackContext). Memory management/relocation, FFI , a diverse set of
what we currently know as 'privitives' will be implemented in a
system. This opens a potentially huge playground, how system would
look like :)

- avoid using global state. All state which code can potentially refer
to is placed in literals. There is no difference between native
methods and smalltalk methods in compiled method format. The
difference only how they are compiled. Of course there will be some
global state , i think it would be a single 'lobby' object, which
contains a symbols table (required to support symbols uniqueness
thoughout all system). But anyway, references to it will be possible
only from method literals.
- generated native code are location independent. Since all jumps will
be relative, and all location-dependent stuff are either held in
literals or computed. Therefore a CompiledMethod instances can be
relocated freely in memory (by GC and friends) without any change that
it will cause any harm.

- compiler translates smalltalk code to a lambda representation. Then
using different transformations it generates a low-level lambdas,
which represent a virtual machine CPU instructions. No AST nor bunch
of different classes to represent semantic elements of code used.
Lambdas all the way down.

- an object memory model is initially based on Ian's minimal object
system. With some changes.

You can download a snapshot of project at squeaksource:
http://www.squeaksource.com/CorruptVM

What is currently should work:

CVMachineSimulator bootstrap -- bootstrap a object memory for simulation
CVSimulationTests run -- run different tests on boostrapped object memory

There are also an initial implementation of translating to native code
using Exupery (you need to load Exupery for that).
Do it:
CVExuperyCompiler test inspect


I am currently open for suggestions and advices or discussion in how
is better to implement system based on such design.
Would be glad to read your comments.

There is also a wiki page of project:
http://wiki.squeak.org/squeak/6041
--
Best regards,
Igor Stasenko AKA sig.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/06e9cb19/attachment.htm
Eliot Miranda
2012-01-28 12:19:03 UTC
Permalink
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.

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)?
Post by Igor Stasenko
Since lately there a some interest in C/C++ compiling and some people
mentioned how it would be cool to make everything to be dynamically
compiled,
i decided to make a preview announce of a research which i done during
last few months.
A project name is a weird, and definitely it require more appropriate
name to not scare off a potential users/developers, but this is not an
issue right now :)
- the main goal is to create a smalltalk language environment (similar
to other smalltalks), but i avoid to call it VM, because its not
really a VM, because there is no VM at all.
- everything is written in smalltalk
- system is completely self sustaining: smalltalk code compiled down
to native code (no initial need in having bytecodes). Of course no-one
prevents you from implementing a bytecode interpreter on top of it.
But this is beyond the scope of current project. :)
- there is no primitives nor need in writing external code in C (or in
any other statically typed language). A primitives replaced by native
methods (methods with <native> pragma), by using which you can
implement any low-level behavior.
- everything (by a 99.9% ;) in system is up to implementor. There is
a few 'glue' semantics used by compiler, but compiler itself
extensively using static inlining (inlining native methods from
well-known classes such as CompiledMethod/ProtoObject or
StackContext). Memory management/relocation, FFI , a diverse set of
what we currently know as 'privitives' will be implemented in a
system. This opens a potentially huge playground, how system would
look like :)
- avoid using global state. All state which code can potentially refer
to is placed in literals. There is no difference between native
methods and smalltalk methods in compiled method format. The
difference only how they are compiled. Of course there will be some
global state , i think it would be a single 'lobby' object, which
contains a symbols table (required to support symbols uniqueness
thoughout all system). But anyway, references to it will be possible
only from method literals.
- generated native code are location independent. Since all jumps will
be relative, and all location-dependent stuff are either held in
literals or computed. Therefore a CompiledMethod instances can be
relocated freely in memory (by GC and friends) without any change that
it will cause any harm.
- compiler translates smalltalk code to a lambda representation. Then
using different transformations it generates a low-level lambdas,
which represent a virtual machine CPU instructions. No AST nor bunch
of different classes to represent semantic elements of code used.
Lambdas all the way down.
- an object memory model is initially based on Ian's minimal object
system. With some changes.
http://www.squeaksource.com/CorruptVM
CVMachineSimulator bootstrap -- bootstrap a object memory for simulation
CVSimulationTests run -- run different tests on boostrapped object memory
There are also an initial implementation of translating to native code
using Exupery (you need to load Exupery for that).
CVExuperyCompiler test inspect
I am currently open for suggestions and advices or discussion in how
is better to implement system based on such design.
Would be glad to read your comments.
http://wiki.squeak.org/squeak/6041
--
Best regards,
Igor Stasenko AKA sig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/20a742ce/attachment.htm
Ralph Johnson
2012-01-28 12:19:03 UTC
Permalink
Post by Eliot Miranda
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.
One way to fix this is to make debuggers work differently. One image
should be able to inspect and control another, as in Spoon. In
general, the debugger for image X runs in the controller of X, not in
X itself. Of course, the compiler should probably be in the
controller, as well. This would make a lot of things easier, such as
parallelism, security, and fault tolerance.

-Ralph
Igor Stasenko
2012-01-28 12:19:04 UTC
Permalink
Post by Eliot Miranda
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.
Post by Eliot Miranda
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.
Eliot Miranda
2012-01-28 12:19:04 UTC
Permalink
Post by Igor Stasenko
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Post by Eliot Miranda
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.
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Post by Eliot Miranda
is fishing about in a vast hex dump of the entire system, and that
doesn't
Post by Eliot Miranda
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.
Post by Eliot Miranda
So are you going to export symbolic information that a platform debugger
can
Post by Eliot Miranda
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.
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).

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.

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.

Best
Eliot
Post by Igor Stasenko
--
Best regards,
Igor Stasenko AKA sig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080701/65ee6554/attachment.htm
Igor Stasenko
2012-01-28 12:19:04 UTC
Permalink
Post by Eliot Miranda
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 :)
Post by Eliot Miranda
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.
Post by Eliot Miranda
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 :)
--
Best regards,
Igor Stasenko AKA sig.
Eliot Miranda
2012-01-28 12:19:04 UTC
Permalink
Post by Igor Stasenko
Post by Eliot Miranda
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.
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Post by Igor Stasenko
by VM written in C :)
Post by Eliot Miranda
Let me encourage you to think about this soon and work on it asap because
it
Post by Eliot Miranda
is a really important issue. If you don't have a good debugging
environment
Post by Eliot Miranda
up front your progress will be slow. No one has succeeded in bringing
such
Post by Eliot Miranda
a system for a Smalltalk-like language into production use yet (neither
Klein nor TypedSmalltalk nor Exupery has made it to production use).
Making
Post by Eliot Miranda
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.
Post by Eliot Miranda
You have to both provide a Smalltalk-level debugger and a machine code
debugger which can display machine instructions, registers and memory.
It
Post by Eliot Miranda
would be nice to be able to reuse disassemblers et al from other
components
Post by Eliot Miranda
but you might find that Smalltalk implementations are quicker to write
and
Post by Eliot Miranda
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
Igor Stasenko
2012-01-28 12:19:04 UTC
Permalink
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
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.

So without hard hacking OS internals, the idea of using zeons of
Processes scheduled between a limited numbers of native threads is
barely possible.

Its shows, how inflexible and rigid operating systems can be, if you
want to write in any other language than C :)
Post by Eliot Miranda
Post by Igor Stasenko
Then debugging looks much less scary than comparing to system crippled
by VM written in C :)
Post by Eliot Miranda
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.
Post by Eliot Miranda
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
--
Best regards,
Igor Stasenko AKA sig.
Eliot Miranda
2012-01-28 12:19:04 UTC
Permalink
Hi Igor,
Post by Ralph Johnson
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
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
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
at.
There is a mirror for local debugging taht is fairly transparent.
then
Post by Eliot Miranda
Post by Igor Stasenko
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Post by Eliot Miranda
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
Igor Stasenko
2012-01-28 12:19:05 UTC
Permalink
Post by Eliot Miranda
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).
yeah, yeah, boring stuff just to make two environments live together
without much conflicts.
However it adds complexity in managing running machine state. And
against nature of simplicity and flexibility. But there is not much
choices...
I just asking myself, why OS designers didn't thought a bit, about
enabling user process to provide control on own stack?
Why there is no option to provide a buffer for initial stack, when
creating new native thread? Or if not a buffer, then at least a
reserved address space.
Post by Eliot Miranda
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. :) )
It seems the only viable way on modern OSes.
Since i don't have to care about primitives (they not exists), the
only what i should care of is when it does foreign calls.
And since foreign calls are up to implementor - it has nothing to do
with compiler. Its only a matter of writing a correct callout code and
correctly handling return from it an returned value(s), if any.
Post by Eliot Miranda
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.
--
Best regards,
Igor Stasenko AKA sig.
Loading...