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
11 matches
Mail list logo
