Subject:
|
Re: Some comments (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 10 May 1999 12:42:37 GMT
|
Original-From:
|
John A. Tamplin <JAT@LIVEONTHENET.COMspamless>
|
Viewed:
|
1348 times
|
| |
|
|
Let's move this discussion to lego-robotics-rcx, since that group was
created for discussions like these.
On Sat, 8 May 1999, stephen p spackman wrote:
> 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 :-).
Late binding requires the symbol table or some representation of the same
thing. For example, you have C inheriting from B inheriting from A. A
defines f(), but B and C do not. A method in C calling f() must use A.f().
Then B is recompiled and now implements f(). The same code used in C
must now call B.f() without recompiling C.
I am planning on giving up late binding by requiring that all derived
classes be relinked when a parent class is modified.
> 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.
Sun's reference implementation uses a pointer indirection so that objects
can be relocated during GC. That pointer's location never changes, so
they use that as the hash code. If you create your own hashCode() method,
it is a method entry in the class which takes no space in each instance.
If you generate the hash value from the contents of the object rather than
its address, there is no space overhead per instance.
> 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.
Don't forget the monitor used for synchronization, the pointer to
instance variables, the pointer to the class, etc.
> 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).
If you mean only efficiency of when the space can be reused, then GC is still
not best. Explicit freeing of memory can happen at the instant the memory
is no longer required. GC can take place no sooner than that, and generally
will be much later.
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:
Message is in Reply To:
 | | 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)
|
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
|
|
|
|
