On Friday 25 January 2002 13:50, [EMAIL PROTECTED] wrote:
> > 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?
GC (at the Parrot level) isn't finalization (at the language level). In
your last several posts, it hasn't been clear at what level you're trying to
address.
Parrot supports deterministic destruction at the language level. If your
language wants 'o' to be destroyed at the exit from f2(), then 'o' will be
destroyed in whatever manner MyClass destruction means to your language.
Resources allocated strictly by the internal representation responsible for
MyClass (e.g. Leeper_Object) may not be collected at that point, but that's
mostly independent of the language. (You could also trigger a GC run
yourself.)
Consider, for a moment, a C++ object that is dependent on some kernel
resource. C++ makes the determination of when and how that object is
destroyed and finalized, releasing both program memory, user-space
resources, and the attached kernel resources. It shouldn't then matter to
the program if, when, or how the kernel goes about collecting those
resources. (Overcommitting memory is a good example of how some modern
kernels lie to their programs for exactly that reason.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
