Re: why can't we destroy() objects

Discussion in 'Java' started by Joona I Palaste, Aug 3, 2003.

  1. S. Balk <0spam.nl> scribbled the following:
    > I was wondering why we could not destroy objects ourselves while the
    > garbage-collector still does it's job. What are the disadvantages of having
    > such low-level memory-access. In real-time / graphics applications I see
    > only advantages, because you will always have stop-the-world gc() on a
    > single cpu.


    > What are you thoughts?


    If you used references referring to destroy()ed objects, the JVM would
    get confused. You'd have destroyed (pun not intended) one of Java's
    strongest selling points: references are guaranteed to be valid or
    explicitly null.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "Shh! The maestro is decomposing!"
    - Gary Larson
    Joona I Palaste, Aug 3, 2003
    #1
    1. Advertising

  2. Joona I Palaste

    S. Balk Guest

    > > I was wondering why we could not destroy objects ourselves while the
    > > garbage-collector still does it's job. What are the disadvantages of

    having
    > > such low-level memory-access. In real-time / graphics applications I see
    > > only advantages, because you will always have stop-the-world gc() on a
    > > single cpu.

    >
    > > What are you thoughts?

    >
    > If you used references referring to destroy()ed objects, the JVM would
    > get confused. You'd have destroyed (pun not intended) one of Java's
    > strongest selling points: references are guaranteed to be valid or
    > explicitly null.


    By destroying an object, it is explicitly null, isn't it?
    S. Balk, Aug 3, 2003
    #2
    1. Advertising

  3. "S. Balk" <0spam.nl> wrote in message news:bgk1th$oq3$...
    > > If you used references referring to destroy()ed objects, the JVM would
    > > get confused. You'd have destroyed (pun not intended) one of Java's
    > > strongest selling points: references are guaranteed to be valid or
    > > explicitly null.

    >
    > By destroying an object, it is explicitly null, isn't it?


    Objects are never null. References to objects may be null.
    That is, if you have a reference variable, it may contain null
    or it may contain a *valid* reference to an object. This is an
    important property of Java and a significant advantage over
    C++.

    If a destroy() method existed, what would it do? It could only
    be invoked on a reference. Let's say it destroyed the object
    and nulled the reference. This makes sense if that reference
    was the only one, but what if there were many? What if
    the reference to the object appeared in ten different lists?
    Would it null all of them? What about threading issues?
    Could it interrupt every thread, pause it, remove the reference,
    and resume? That would be as much overhead as gc is currently
    anyway. And this would destroy any guarantee that threads
    might want to make about their own datastructures. Ouch.

    And what is the advantage of an explicit destroy() operation?
    You want to manage object lifecycle yourself? It's a step backwards.

    If your *real* concern is about gc pauses, then you might want
    to talk about issues in concurrent garbage collection.


    Marshall
    Marshall Spight, Aug 4, 2003
    #3
  4. Joona I Palaste

    S. Balk Guest

    > If a destroy() method existed, what would it do? It could only
    > be invoked on a reference. Let's say it destroyed the object
    > and nulled the reference. This makes sense if that reference
    > was the only one, but what if there were many? What if
    > the reference to the object appeared in ten different lists?
    > Would it null all of them? What about threading issues?
    > Could it interrupt every thread, pause it, remove the reference,
    > and resume?


    I thought a null-reference was a reference to 'empty' part of memory. So by
    destroying the object itself, all references to it would be null. But by
    reading your comments, I see it's more complicated than that.

    > And what is the advantage of an explicit destroy() operation?
    > You want to manage object lifecycle yourself? It's a step backwards.


    Depends on your needs I guess, if you can't allow a stop-the-time gc() on a
    single-cpu machine, what are the possibilities? You can't expect a stable
    framerate in games with the stop-the-time approach, a *quick (not full)*
    gc() always causes a noticable pause when rendering: java.awt.Graphics
    leaves too much garbage.

    > If your *real* concern is about gc pauses, then you might want
    > to talk about issues in concurrent garbage collection.


    On a single cpu? I read some articles about that a few months ago, that said
    this was only available on multi-cpu-systems.
    S. Balk, Aug 4, 2003
    #4
  5. Joona I Palaste

    Roedy Green Guest

    On Sun, 03 Aug 2003 23:31:04 GMT, "Marshall Spight" <>
    wrote or quoted :

    >Objects are never null. References to objects may be null.


    I could envision a language when you could destroy objects. the
    reference is a handle, a indirect pointer to the object. You zero out
    the handle. If any live reference still exist, as soon as they come
    after the object they get a DestroyedObjectException.

    You are unlikely to see such as language unless it is for very small
    devices. Garbage collection is such a convenience. It is almost
    impossible to get perfect. There are just too many execution paths to
    think about with Exceptions.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Aug 4, 2003
    #5
  6. "S. Balk" <0spam.nl> wrote in message
    news:bgk7ha$55i$...
    >
    > Depends on your needs I guess, if you can't allow a stop-the-time gc() on

    a
    > single-cpu machine, what are the possibilities? You can't expect a stable
    > framerate in games with the stop-the-time approach, a *quick (not full)*
    > gc() always causes a noticable pause when rendering: java.awt.Graphics
    > leaves too much garbage.
    >
    > > If your *real* concern is about gc pauses, then you might want
    > > to talk about issues in concurrent garbage collection.

    >
    > On a single cpu? I read some articles about that a few months ago, that

    said
    > this was only available on multi-cpu-systems.


    Most popular Java VMs have had concurrent GC for several years now,
    regardless of the number of CPUs.
    A Bag Of Memes, Aug 4, 2003
    #6
  7. Joona I Palaste

    Tim Tyler Guest

    S. Balk <0spam.nl> wrote:

    : I thought a null-reference was a reference to 'empty' part of memory.

    Typically a null pointer is implemented as a reference to the
    "zero" location.

    : So by destroying the object itself, all references to it would be
    : null.

    That would involve a different sort of null - a pointer to an object
    which was marked as nulled.

    All object access would need to check for this state of affairs.

    That would be slower than the existing check for zero.

    It isn't worth slowing everything down just for this.

    An alternative implementation might seek out all the references
    and null them. That would not be very speedy - and would result
    in unpleasant "live one minute, dead the next" behaviour.

    In all, it's best to just let the GC do its thing.
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Aug 4, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?dnZlbms=?=

    Should I explicitly destroy objects

    =?Utf-8?B?dnZlbms=?=, Nov 9, 2005, in forum: ASP .Net
    Replies:
    8
    Views:
    2,905
    Chris Botha
    Nov 10, 2005
  2. Minkyu Kim
    Replies:
    1
    Views:
    270
    Terry Reedy
    Feb 19, 2004
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,733
    Smokey Grindel
    Dec 2, 2006
  4. Ook
    Replies:
    2
    Views:
    311
  5. David Espada
    Replies:
    0
    Views:
    110
    David Espada
    Dec 27, 2004
Loading...

Share This Page