Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: why can't we destroy() objects

Reply
Thread Tools

Re: why can't we destroy() objects

 
 
Joona I Palaste
Guest
Posts: n/a
 
      08-03-2003
S. Balk <(E-Mail Removed)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 ((E-Mail Removed)) ---------------------------\
| 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
 
Reply With Quote
 
 
 
 
S. Balk
Guest
Posts: n/a
 
      08-03-2003
> > 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?


 
Reply With Quote
 
 
 
 
Marshall Spight
Guest
Posts: n/a
 
      08-03-2003
"S. Balk" <(E-Mail Removed)0spam.nl> wrote in message news:bgk1th$oq3$(E-Mail Removed)...
> > 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


 
Reply With Quote
 
S. Balk
Guest
Posts: n/a
 
      08-03-2003
> 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.


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-04-2003
On Sun, 03 Aug 2003 23:31:04 GMT, "Marshall Spight" <(E-Mail Removed)>
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.
 
Reply With Quote
 
A Bag Of Memes
Guest
Posts: n/a
 
      08-04-2003

"S. Balk" <(E-Mail Removed)0spam.nl> wrote in message
news:bgk7ha$55i$(E-Mail Removed)...
>
> 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.


 
Reply With Quote
 
Tim Tyler
Guest
Posts: n/a
 
      08-04-2003
S. Balk <(E-Mail Removed)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/ http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
class objects, method objects, function objects 7stud Python 11 03-20-2007 06:05 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Unable to serialize the session state. Please note that non-serializable objects or MarshalByRef objects are not permitted when session state mode is 'StateServer' or 'SQLServer'. Mike Larkin ASP .Net 1 05-23-2005 12:33 PM
objects of objects, vectors and sessions bigbinc Java 3 11-18-2003 09:26 AM



Advertisments