Re: [DRLVM][MMTk GC] marksweep configuration works in "user mode"
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
Re: [DRLVM][MMTk GC] marksweep configuration works in "user mode"
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]
Re: [DRLVM][MMTk GC] marksweep configuration works in "user mode"
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. geir -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][MMTk GC] marksweep configuration works in "user mode"
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? :) geir There were some workarounds in MMTk code itself. It does not make sense to commit these workarounds to drlvm/trunk or to put them in JIRA. Instead, I told Steve Blackburn what the MMTk porting problems are. For the record the MMTk mods are: 1) SegregatedFreeList.java wants to use vmmagic atomic operations even in single java thread app. But vmmagic atomic ops are not fully functional in Jitrino.JET just yet. The workaround is to do a simple write to memory instead of CAS. The mods to SegregatedFreeList.java are: 731a732 atomic = false; //wjw hack around Addresss.attempt bug 2) MMType.getSlot() is hard coded to assume that element zero is an "Offset" of zero from the vtable ptr. While this may indeed be the case for JikesRVM, in DRLVM the offset is 12. The diff to MMType.java is: 83,86c83,86 < if (isReferenceArray) < return addr.plus(arrayOffset).plus(reference << LOG_BYTES_IN_ADDRESS); < else < return addr.plus(offsets[reference]); --- if (isReferenceArray) return addr.plus(12).plus(reference << LOG_BYTES_IN_ADDRESS); // return addr.plus(arrayOffset).plus(reference << LOG_BYTES_IN_ADDRESS); else return addr.plus(offsets[reference]); - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM][MMTk GC] marksweep configuration works in "user mode"
All, I just committed mods that allow MMTk marksweep configuration to run the simple tests in test.java. There were some workarounds in MMTk code itself. It does not make sense to commit these workarounds to drlvm/trunk or to put them in JIRA. Instead, I told Steve Blackburn what the MMTk porting problems are. For the record the MMTk mods are: 1) SegregatedFreeList.java wants to use vmmagic atomic operations even in single java thread app. But vmmagic atomic ops are not fully functional in Jitrino.JET just yet. The workaround is to do a simple write to memory instead of CAS. The mods to SegregatedFreeList.java are: 731a732 atomic = false; //wjw hack around Addresss.attempt bug 2) MMType.getSlot() is hard coded to assume that element zero is an "Offset" of zero from the vtable ptr. While this may indeed be the case for JikesRVM, in DRLVM the offset is 12. The diff to MMType.java is: 83,86c83,86 < if (isReferenceArray) < return addr.plus(arrayOffset).plus(reference << LOG_BYTES_IN_ADDRESS); < else < return addr.plus(offsets[reference]); --- if (isReferenceArray) return addr.plus(12).plus(reference << LOG_BYTES_IN_ADDRESS); // return addr.plus(arrayOffset).plus(reference << LOG_BYTES_IN_ADDRESS); else return addr.plus(offsets[reference]); -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
