Am Dienstag, 1. August 2006 23:21 schrieb Kevin Tew:
> Syntax:
>
> END '{' expr.. '}'
>
> Registers finalize routine. The block followed after |END| is evaluated
> just before the interpreter termination. Unlike |BEGIN|, |END| blocks
> shares their local variables, just like blocks.
I've p
e the solution is two stacks of subs in the interpreter structure.
One for initialization and one for finalization which are traversable
and modifiable using opcodes or a specialized pmc.
My take is that he initialization stack gets executed just before :main
and the finalization stack gets exe
such
objects from a special PMC pool, so that we don't have to sweep over all
PMCs.
There is of course still the problem of ordered finalization and
destruction.
leo
t;
> BUT, a nifty thing would be to actually delay finalization until an
> object is about to be re-used off of the free list. That is, treat ecru
> items as only-maybe free, and as they are pulled off of the free list
> for re-use, check to see if a finalizer needed to be called and if so,
quire another sweep
over the items newly resident on the free list (the left-over items in
the from-space), which would (unfortunately) take time proportional to
the number of freed object.
BUT, a nifty thing would be to actually delay finalization until an
object is about to be re-used off o
r. I wonder how fast it is when it's halfway under water and out of
> file descriptors.
GC has nothing to do with finalization. Many people want it to, and seem
to conflate the two, but they're separate. Dead object detection and
cleanup doesn't have to be tied to memory
eone thought they
> could still do
> something inside a finalizer during global destruction and
> you still need
> to finalize every other object on your heap :).
As I said, the finalization should be discouraged. It is application's
problem if it uses extensive finalization, jus
On Tue, 28 Aug 2001 19:04:20 -0700, Hong Zhang <[EMAIL PROTECTED]>
wrote:
>Normally, GC is more efficient than ref count, since you will have many
>advanced gc algorith to choose and don't have to pay malloc overhead.
You still need to malloc() your memory; however I realize that the
allocator c
On Tue, 28 Aug 2001 18:35:34 -0700, Damien Neil <[EMAIL PROTECTED]> wrote:
>On Tue, Aug 28, 2001 at 09:07:03PM -0400, Sam Tregar wrote:
>> Well, there's the Perl 5 reference counting solution. In normal cases
>> DESTROY is called as soon as it can be. Of course we're all anxious to
>> get into
> I don't think speed is where the interest is coming from. GC should fix
> common memory problems, such as the nasty circular references issue that
has
> caught all of us at some time.
Normally, GC is more efficient than ref count, since you will have many
advanced gc algorith to choose and don'
Sam Tregar wrote:
> On Wed, 29 Aug 2001, Jeremy Howard wrote:
>
> > The answer used in .NET is to have a dispose() method (which is not a
> > special name--just an informal standard) that the class user calls
manually
> > to clean up resources. It's not an ideal solution but there doesn't seem
to
On Tue, Aug 28, 2001 at 09:07:03PM -0400, Sam Tregar wrote:
> Well, there's the Perl 5 reference counting solution. In normal cases
> DESTROY is called as soon as it can be. Of course we're all anxious to
> get into the leaky GC boat with Java and C# because we've heard it's
> faster. I wonder
On Tue, 28 Aug 2001 21:07:03 -0400 (EDT), Sam Tregar <[EMAIL PROTECTED]>
wrote:
>On Wed, 29 Aug 2001, Jeremy Howard wrote:
>
>> The answer used in .NET is to have a dispose() method (which is not a
>> special name--just an informal standard) that the class user calls manually
>> to clean up resou
On Wed, 29 Aug 2001, Jeremy Howard wrote:
> The answer used in .NET is to have a dispose() method (which is not a
> special name--just an informal standard) that the class user calls manually
> to clean up resources. It's not an ideal solution but there doesn't seem to
> be many other practical o
Hong Zhang wrote:
> Most of finalization is used to deal with external resource, such as open
> file, socket, window. You don't really want to depend on finalization,
> since it is very likely run out of default file descriptor limit before
> the finalization kicks in. The rule o
much identical to Perl's
> DESTROY. (Except that Java's non-refcounting GC doesn't provide the
> same guarantees on when an object whill be finalized.) (And
> the problem
> that all too many JVMs have had buggy implementations of finalizers...
> that's an im
16 matches
Mail list logo
