Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sun, 9 May 1999 18:36:14 GMT
|
Original-From:
|
Paul Speed <pspeed@augustschell.comIHATESPAM>
|
Viewed:
|
1302 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" (...) (25 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
|
|
|
|
