develooper Front page | perl.perl6.internals | Postings from February 2001

Re: Garbage collection

Thread Previous | Thread Next
Jan Dubois
February 11, 2001 21:45
Re: Garbage collection
Message ID:
On Sun, 11 Feb 2001 22:30:30 -0500, "Bryan C. Warnock"
<> wrote:

>crossed to -internals

Ok, I removed -language.

>Jan Dubois:
>> Not necessarily; you would have to implement it that way: When you try to
>> open a file and you don't succeed, you run the garbage collector and try
>> again.  But what happens in the case of XS code: some external library
>> tries to open a file and gets a failure.  How would it trigger a GC in the
>> Perl internals?  It wouldn't know a thing that it had been embedded in a
>> Perl app.
>But that would be the point of the API, no?  Even in XS, you'd interface 
>through perl for memory or file management.  So the core would still be 
>able to invoke the GC.  Granted, these are last-ditch efforts anyway - what 
>would really be needed to trigger?  E[MN]FILE? ENOMEM?  Weird cases of 
>ENOSPC?  If you happen to hit one, force a GC pass, and retry whatever the 
>call was.  Even if the GC is unsuccessful (at resource reclamation), 
>wouldn't you still want Perl to panic, vice the XS code anyway?

What about extensions using a statically linked version of libc?  Or one
managing it's own resources?  The XS glue code would then have to insert a
GC call after each external API call that failed.  And the ugly thing is:
Even for a generational GC scheme you would have to GC *all* the memory
because you are not looking for some free memory, but hoping that some
object will free a resource.  You don't know which generation to collect;
it could be anywhere.

Doing full GC in this fashion after failed API calls will probably wipe
out any performance gain mark-and-sweep has over reference counting.

>> This scheme would only work if *all* resources including memory and
>> garbage collection are handled by the OS (or at least by a virtual machine
>> like JVM or .NET runtime).  But this still doesn't solve the destruction
>> order problem.
>Well, no.  My thought would be if A needed to be destroyed before B, then B 
>wouldn't/shouldn't be marked for GC until after A was destroyed.  It might 
>take several sweeps to clean an entire dependency tree, unfortunately.  

But *how* do you implement this dependency in a way that is *cheaper* than
reference counting?  You can save some memory by only reference counting
objects and not simple values, but this increases runtime cost beyond
simply reference counting everything.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About