> Thanks for the nice example, except I understand the issue you
> are speaking of, I was basically asking what parts of it do you think
> are more "difficult" to implement than any other major construct?
I believe the main difficulty comes from heading into uncharted waters. For
example, once you've decided to make garbage collection optional, what does
the following line of code mean?
delete x;
Does it mean anything at all? Is it even a legal statement? Is garbage
collection optional for all variables, or simply not used for stack
variables, but always used for heap variables?
Or, for example, are the side effects of the following two functions
different?
void f1()
{
// On the stack
MyClass o;
}
void f2()
{
// On the heap
MyClass o = new MyClass();
}
If garbage collection is not 100% deterministic, these two functions could
produce very different results because we do not know when or if the
destructor for MyClass will execute in the case of f2(). The same would be
true when exceptions are thrown from a function. If garbage collection is
not 100% deterministic (and Mark and Sweep is not), we need extra language
features, such as Java's "finally" block, to ensure things can be cleaned
up, and extra training to ensure programmers are smart enough to know how
to use "finally" blocks correctly.
So, as I see it, the choice of garbage collections schemes ripples
throughout the entire language. It effects what statements are legal and
the semantics of even the simplest pieces of code.
The point to all my questions is this: I'm thinking about basing my
language on the Parrot VM. If I do that, what does the call to f2() mean?
What happens to my language when I use the Parrot VM?
Dave
"Melvin Smith"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m.com> cc: [EMAIL PROTECTED], Simon
Cozens <[EMAIL PROTECTED]>
Subject: Re: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 01:13
PM
Thanks for the nice example, except I understand the issue you
are speaking of, I was basically asking what parts of it do you think
are more "difficult" to implement than any other major construct?
There are several ways to address the example you just gave (my computer
science is getting rusty here) but let me think...
> a.b_member = b; // Stack variable a now references heap variable
b.
I see no problem here.
> b.a_member = a; // Heap variable b now references stack variable
a.
> global_b.a_member = a; // Stack variable global_b now references
stack variable a.
> global_b2 = b; // Stack variable global_b2 now references heap
variable b.
> // What happens to the six objects we've created when we leave the
scope of f()?
One approach is
stack = stack (reference)
stack = heap (reference)
heap = heap (reference)
heap = stack (copy)
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
David.Leeper@bisy
s.com To: Melvin
Smith/ATLANTA/Contr/IBM@IBMUS
cc:
[EMAIL PROTECTED], Simon Cozens <[EMAIL PROTECTED]>
01/25/2002 12:45 Subject: Re: How Powerful
Is Parrot? (A Few More Questions)
PM
> >From what I've seen, supporting both garbage collection and true stack
> >variables is a difficult task.
> Why is that?
Because stack variables can refer to heap variables and heap variables can
refer to stack variables. The garbage collector needs to be smart enough to
handle all cases correctly. For example, let's say we have the following
two classes...
class A
{
public B b_member;
}
class B
{
public A a_member;
}
.....and the following declarations and function...
B global_b; // Creates an instance of B with an A member, both
on the stack.
B global_b2; // Creates an instance of B with an A member, both on
the stack.
void f()
{
A a; // Creates an instance of A with a B member, both on
the stack.
B b = new B(); // Creates an instance of B with an A member, both on
the heap.
// 4 objects have now been created in this function, an A and B on the
stack, and an A and B on the heap.
a.b_member = b; // Stack variable a now references heap variable
b.
b.a_member = a; // Heap variable b now references stack variable
a.
global_b.a_member = a; // Stack variable global_b now references
stack variable a.
global_b2 = b; // Stack variable global_b2 now references heap
variable b.
// What happens to the six objects we've created when we leave the
scope of f()?
}
This implies several things.
1) Garbage collection is optional because stack variables are not garbage
collected.
2) Garbage collection knows every object created, how every object was
created (stack or heap), and how every object is referenced by other
objects.
3) The stack interacts seemlessly with garbage collection. When we leave f
() in the above example, referencing global_b.a_member needs to produce an
error or exception.
4) Garbage collection interacts seemlessly with the stack. In the above
example, b can never be garbage collected for the life of the program
because the stack variable global_b2 references it and global_b2 never goes
out of scope.
It's not impossible to write a garbage collector that can handle this, I've
done it myself. This is why I've been asking these questions about Parrot.
I want to know if I can use Parrot as a VM for a language I've designed.
I'm currently generating C++ code. I'd like to use Parot, but I need true
stack variables and 100% deterministic garbage collection.
I don't know of any language that has these features. Java doesn't. C++
doesn't (unless you roll your own and restrict what programmers can do), C#
doesn't.
Dave
"Melvin Smith"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
m.com> cc: [EMAIL PROTECTED],
Simon Cozens <[EMAIL PROTECTED]>
Subject: Re: How Powerful Is
Parrot? (A Few More Questions)
01/25/02 12:00
PM
>From what I've seen, supporting both garbage collection and true stack
>variables is a difficult task.
Why is that?
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
