At 2:46 PM -0500 1/25/02, [EMAIL PROTECTED] wrote:
> > 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 you're getting confused a bit here--I apologize for not
jumping in earlier.
As far as Parrot's concerned, Garbage Collection is just the
reclamation of unused memory and unused interpreter structures. This
will happen when the interpreter deems it necessary, and you can
force or block a GC run if you need to. The heap may be compacted
when this happens, but variables can be marked as non-moveable if
this is necessary. (for those cases when absolute memory addresses
are referenced outside of the interpreter as well)
Dead Object Detection is the phase where the interpreter determines
which objects are reachable from the root set, and which aren't. Any
objects that aren't reachable *and* are marked as having an active
destructor (and most won't, there's no need in 90% of the cases) will
have their destructor called and the objects can clean up as need be.
Once again this happens when the interpreter deems it necessary and
you may also force or block a DOD run.
In neither case do you have any control over the order that memory is
compacted, or dead objects with destructors have their destructors
called. If you must force some sort of order you need to do so within
the objects destructor. Alternately if your program knows what order
objects should be destroyed in your may explicitly call objects
destructors. This is outside the GC/DOD system however as it happens
from within your mainline code. (When the DOD later runs it won't do
anything with those objects as you've already destroyed them and thus
left nothing for the DOD sweep to do)
> "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]
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
