Projects

Tue May 9 12:32:00 GMT 2000

On 2000年5月09日, Tom Tromey wrote:
So if I understand right, you're using the second word of the vtable
to store a bitmap of the words within an object that contain pointers?
Cool idea, but how about we get around the 32 word restriction by
making the high-order bit significant. Note that the first word
of a Java object shouldn't be significant for GC, since it's always
the vtable. If the high-order bit is zero, the bitmask contains a bit
pattern of all pointers in the object; if the high-order bit is non-zero,
it contains a negative offset to a location containing a counted bitmask.
For large objects, the compiler would emit something like:
	.word	2		// 2 words of pointer mask
	.word	firstmask	// first word of pointer mask
	.word	secondmask	// second word of pointer mask
__vt_Foo:
	.word	__CL_Foo
	.word	-4		// -4 words to the pointer mask
	blah blah blah
>>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
>>Hans> It hasn't, though it changes to about 500 bytes with a 64 bit
>Hans> machine. Larger objects can be handled with a custom mark
>Hans> procedure that interprets longer bitmaps.
>>Are there unused bit patterns for the low bits of the mark descriptor
>we could use? If so we could encode a pointer to a longer bitmap
>there.
>>Or we could do something like what Corey does: encode a pointer to an
>index list, which we'd use in the existing mark function -- and which
>we'd lazily compute the first time into that function. This could be
>done immediately without any compiler change.
>>Hans> My theory is that the added overhead will be amortized over the
>Hans> larger object, and won't be noticable. Whether this is correct
>Hans> remains to be seen.
>>It would also be interesting to know how often these large objects
>occur. My guess is that they rarely occur.
>>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