The selection of header bits for object hash is controlled by HASH_MASK located in mon_enter_exit.h. By happy coincidence, there was an unused bit in the header. The old version:
#define HASH_MASK 0x7e The hacked on version for MMTk: #define HASH_MASK 0xfc A question for those who know the thread manager code. Will the above cause a problem today? Will it cause a problem with what the thread manager wants to do with header bits tomorrow? Now the semispace collector definitely goes further before it falls down. I had a long IM session with Steve Blackburn (MMTk expert) last night to figure out the next debug steps. We realized a few important items but, of course, none of this is recorded in harmony-dev email. I will start a second mmtk thread to record the current state of MMTk debugging. On 8/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote: > On 8/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> Weldon Washburn wrote: >> > All, >> > >> > I just committed mods that allow MMTk marksweep configuration to run >> > the simple tests in test.java. >> > >> >> That's cool - what do we do with it next? :) > > The next step is to get MMTk semispace collector running. I am > working on it right now. It turns out MMTk needs the mark bit and the > forwarding bit adjacent to each other in the same byte of the object > header. This may mean shoving around the bits in DRLVM object header > to get the required space. In neither case is it configurable via a mask or something? > >> >> geir > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
