You could change the GC scheme (*cough*) to use one similar to Python's (ref-counting + additional GC for cyclic references *double-cough*).
Out-of-this-world-ly yours, Michael On Fri, 14 Jan 2005 14:40:43 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > Hildo Biersma writes: > > If the number of objects that needs this is relatively small, we could > > play a trick somewhat like the following (with small changes to the perl > > compiler): > > > > 1. Break the filehandle object into two: a generic wrapper that uses > > refcounting and forwards all calls, plus the actual filehandle object. > > There seems to be a misconception about refcounting, and it's showing up > here. People seem to think that you can do it to certain objects and > not others. The fact is, right now when we're wiggling around PMCs > we're just changing some pointers. But if there is one object that > likes to be refcounted, then *every* pointer change needs to do the > refcount dance. It's a big, potentially cache-blowing speed hit for the > whole virtual machine. > > You can't do refcounting selectively. It's all or none. > > Of course, in C++, you can, because you tell C++ which pointers are > refcountable pointers at compile time. If, by static analysis, we could > tell Parrot when PMCs need refcounting before it assembled the bytecode, > and also in some other places, we might be able to pull it off. But > that's a halting problem problem if the language from which we're > compiling is untyped. > > What I'd most like is to convince Larry to waive the timely destruction > requirement. However, that doesn't really solve the problem for other > languages that need timely destruction. Are there any? > > Luke >
