Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 8 May 1999 11:25:43 GMT
|
Original-From:
|
stephen p spackman <stephen@*nomorespam*acm.org>
|
Viewed:
|
1660 times
|
| |
|
|
John A. Tamplin wrote:
>
> 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.
Sure: one aspect of the "expanded" issue.
> 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.
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 pre-verified. You'd be
truly silly not to split the symbol table - I don't think introspection
will be heavily used in this environment :-).
> 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.
Yep.
> 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.
Am I wrong? Most systems that provide hashing of mutable objects either
go to great lengths to ensure that objects never relocate, or actually
CHOOSE a hash code at object creation and STORE it in the object. Either
approach requires space overhead: either a pointer somewhere or a hash
value.
So it looks to me that the minimum size of java.lang.Object is three
pointers (the pointer to the object, the vtable, the hash mechanism),
and measurements suggest it is actually much bigger.
> > 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.
Actually I would have said that "typical" algorithms were now at least
ephemeral and require very little overhead of any kind. But those work
best in large virtual memories, so they aren't the ones we're discussing
here.
> > 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,
Nono, that was a space analysis; recall that I was replying to an
objection that there was no *room* for a gc on the RCX. Of *course*
there is time overhead in this situation; a time overhead which I
calculate to be comparable to that of using an interpreter rather than
compiled code (that is, a small few instructions per "useful"
instruction).
> 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.
Which was the conclusion I too had come to, though garbage collection
was not on my own list of features to omit.
stephen
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 1 Reply:
 | | Re: Some comments (long)
|
| Let's move this discussion to lego-robotics-rcx, since that group was created for discussions like these. (...) Late binding requires the symbol table or some representation of the same thing. For example, you have C inheriting from B inheriting (...) (26 years ago, 10-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Some comments (long)
|
| (...) 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 (...) (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
