> 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.)
I believe I understand now. I think that what this means to me is that if I
want 100% deterministic destruction, I will have to implement my own
garbage collector. This garbage collector will call object destructors and
free all language-specific resources of the object. Once I've finished
using the object, the Parrot garbage collector will free Parrot resources
associated with the object at some undetermined time in the future.
I think that's acceptable.
Thanks Bryan.
Dave
"Bryan C.
Warnock" To: [EMAIL PROTECTED]
<bwarnock@capi cc: [EMAIL PROTECTED]
ta.com> Subject: Re: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 02:10
PM
Please respond
to bwarnock
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]
