Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 8 May 1999 03:50:49 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenetSPAMCAKE.com>
|
Viewed:
|
1284 times
|
| |
|
|
On Fri, 7 May 1999, stephen p spackman wrote:
> 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.
Java is not particularly space efficient (in typical implementations) for
several reasons:
1) value stacks are stored as a union of all the types you can store in
a variable, so you eat up at least 32 bits (64 on an implementation
supporting long/double). Arrays don't waste space that way, however.
2) late binding requires keeping the names of the methods around in RAM,
so a typical implementation has lots of memory devoted to constant
strings.
3) JVM keeps a fair amount of data about each class and object. If most
objects are small, the overhead can become a significant part of the
overall storage.
Hashing is nothing more than a single method, which is typically inherited
from java.lang.Object and thus consumes no space on most objects. The
extra pointer indirection is an implementation detail in Sun's JVM (so they
can relocate objects during GC without having to update all the pointers),
and even so only applies to arrays and object references which are typically
much larger than the object so the cost is relatively small.
> 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).
There are many ways to do GC. All involve a trade-off between time and
space. Typical algorithms add at least 2 bits for each cell (many GC
schemes are built on Dykstra's 3-color scheme developed 27 years ago),
or dividing the available memory in half and only allocating new cells in
the active half. Either approach has space overhead, and they have varying
effects on runtime efficiency.
> 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.
You are not counting the time to compute the reference graph, which can
be quite substantial for a large number of small objects. GC has its place,
and in general I agree that reducing programmer complexity for increasing
resource requirements is a good tradeoff. However, on a small system it is
harder to make that tradeoff, and I would prefer to have explicit storage
management. Of course, changing that would completely eliminate the benefits
of using JVM in the first place.
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 1 Reply:
 | | Re: Some comments (long)
|
| (...) Sure: one aspect of the "expanded" issue. (...) Well, dynamic loading, not late binding; this stuff would not be on the RCX - presumably almost all of the class loader remains on the host machine, with downloaded code pre-linked and (...) (25 years ago, 8-May-99, to lugnet.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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
