Projects

Tue May 9 13:26:00 GMT 2000

On 2000年5月09日, Tom Tromey wrote:
I will definitely be doing this sometime in the not-too-distant
future.
Compressing class metadata accomplishes many things.
 1) Makes the class metadata smaller, position independent, and
 read-only. Because the current design contains so many
 absolute pointers, it must go in the data segment whenever
 you want to make a position independent module. Each pointer
 requires a fixup which adds alot to the metadata cost. Having
 class metadata a serialized byte stream without pointers is a
 big win for making PIC modules smaller and more efficient.
 2) Shrink long Java class name references by tokenizing the
 package names, serializing long Java type names like a/b/c/Foo
 with a string table reference to the package plus a reference to
 the class name. Here it would be useful to have some linker
 support for string atomization! Are there any active projects
 for making gld create string dictionary sections?
 3) Each Java class would initially only contain information
 necessary to support the following:
	a) Object instantiation. For this we only need the size
	 and vtable.
	b) Interface invokation. I haven't yet dug into the new fast
	 interface call mechanism to know how this relates to
	 serializing the class metadata.
 4) All class introspection, including instanceof and checkcast
 instantiate the complete class definition only if they're used.
>>>>>> "Jon" == Jonathan P Olson <olson@mmsi.com> writes:
>>Jon> Considering the 50% overhead I get with Java metadata, lossage
>Jon> from GC seems miniscule.
>>You've mentioned the possibility of compressing this data.
>We're accepting patches :-)
>Or, failing that, if you have a definite plan we could at least add it
>to the projects page.
>>Jon> To be actually useful for precise collection, you really need a
>Jon> separate data structure containing a bit for each pointer in an
>Jon> allocation.
>>I added code to gcc to use the previously unused vtable slot to hold a
>bitmap description of the object. Hans has changed the GC to use this
>information. Bryce has been working on integrating the two.
>>Tom
-- 
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790