This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
RE: Projects
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: Projects
- From: Tom Tromey <tromey at cygnus dot com>
- Date: Tue, 9 May 2000 11:19:02 -0700 (PDT)
- Cc: "'minyard at acm dot org'" <minyard at acm dot org>, "Jonathan P. Olson" <olson at mmsi dot com>, Tom Tromey <tromey at cygnus dot com>, green at cygnus dot com, java-discuss at sourceware dot cygnus dot com
- References: <140D21516EC2D3119EE700902787664456E7EE@hplex1.hpl.hp.com>
>>>>> "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