At 3:48 PM -0500 1/25/02, [EMAIL PROTECTED] wrote:
> > 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)
>
>If I know what I want to destroy and when, can I just turn off Parrot's
>automatic garbage collector/memory compactor and send it instructons on
>what I want deleted?
You don't even have to go that far. Just explicitly call the object's
destruction code and you're fine. (You do *not* want to turn off
Parrot's GC, though, or you'll leak like a sieve)
Something like:
destroy P4
or whatever. You'll need to make sure your cleanup code properly sets
the PMC internals to make itself undef so Bad Things don't happen,
but that's about it.
>
>
>
> Dan
>Sugalski
>
> <[EMAIL PROTECTED] To:
>[EMAIL PROTECTED], [EMAIL PROTECTED]
> > cc:
>[EMAIL PROTECTED]
> Subject: Re: How
>Powerful Is Parrot? (A Few More Questions)
> 01/25/02
>03:43
>
>PM
>
>
>
>
>
>
>
>
>
>
>
>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
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
