To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 4960
4959  |  4961
Subject: 
Re: Some comments (long)
Newsgroups: 
lugnet.robotics
Date: 
Sun, 9 May 1999 18:36:14 GMT
Original-From: 
Paul Speed <{pspeed@augustschell.}nospam{com}>
Viewed: 
1710 times
  
stephen p spackman wrote:

Paul Speed wrote:

        For the record, up until recently I agreed with you.
However, after hearing further discussions I think it is possible.
The biggest hurdle is probably garbage collection since this is what
causes Java's propensity to "gobble" memory.

This is FUD.

Hmmm... I guess I have to explain every little word I write
so as not to get flamed.

People fear Java on a small memory platform because when
they run a JVM for any length of time on their Wintel boxes they
see it slowly "gobble" more and more and more memory up to about
70-96 meg depending on internal JVM overhead for the heap that's
been created.  By default, the 1.2 JVM has a max heap set at 64 meg.
The docs say otherwise, but trust me on this one.

The garbage collector won't run unless certain conditions
are met.  One of these conditions is that the amount of free memory
available is very small.... so GC doesn't usually happen until you
are fairly close to max heap size.  The other seems to be based
on idle time.

Combine all of this with immutable objects and gobble
gobble gobble.

And yes, I understand that the current GC is optimized
for a different situation, but it is still a fear that people will
have.  It is important that whatever GC is written take into account
the type of environment it is running on.  It may be best to have
the GC run very often.  It may be better to have it run whenever
new would return an out of memory exception. (It currently doesn't
on real Java.)

In any case, I see it as the single biggest "memory" issue.


What causes Java to gobble memory is more likely (a) the amount of
header overhead it places on objects (more to do with hashing support
than gc, I suspect) and (b), to a lesser extent, the fact that objects
are never "expanded" in place but always pay an additional pointer
overhead.

Header overhead is very small.  Pointer overhead is probably
larger than header overhead in current JVM's because of the indexing,
etc. that goes on.  Besides which, some of this hit happens on every
reference collectively making it relatively expensive.


The space overhead for garbage collection per se is quite small, near
zero if you stop the interpreter during gc and every object has a method
table; even if you do full traversal (obviating all need for type tags
if you are clever) the temp space is proportional only to the square
root of heap size and a couple of marking bits in each pointer (using
technology 25 years out of date; there may be a better bound by now).

But think about it: a garbage collector can release memory *as soon as
is logically possible*. This *must* be no worse than an explicit-release
system. If the gc waits longer, that is a pure - and automatically
managed - time/space tradeoff.

Agreed.  Howver, in a language that encourages the creation
of _many_ throw-away objects a size optimized GC becomes very
important.  It may have to be so agressive as to run after every
scope exit.


stephen (who still isn't sanguine about RCX Java but hates to see a
language attacked for its *good* features)

Ack.  Please don't think that I'm attacking Java.  As far
as I'm concerned it was the language that I've been waiting for
since I first learned of C++.  I only sought to focus the memory
worries where they need to be focused.  After you take the class
loader out of the JVM, the single biggest memory waster you are
going to see is an improperly thought out garbage collector.

-Paul (pspeed@progeeks.com)
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics



Message is in Reply To:
  Re: Some comments (long)
 
(...) This is FUD. What causes Java to gobble memory is more likely (a) the amount of header overhead it places on objects (more to do with hashing support than gc, I suspect) and (b), to a lesser extent, the fact that objects are never "expanded" (...) (26 years ago, 8-May-99, to lugnet.robotics)

42 Messages in This Thread:













Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    
Active threads in Robotics

 
Verified and Trusted Team of Hackers
11 hours ago
Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR