Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Robin Garner wrote: Weldon Washburn wrote: Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to "own" the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving object hash one or two or even 12 header bits. Absolutely. +1 Why is it necessary to piggyback on hashCode() for this? Just to keep he GC from having the GC place requirements on object layout? (In which case I'd argue that you are doing practically the same thing if you just takeover hashCode()) > It all becomes a local problem of GC implementation. No need for negotiating with the rest of the VM :) From a top-level how about giving the GC one byte of object header to do hash plus whatever it wants? I realize it would be nice to have an "expando" object model in Harmony that would allow arbitrary number of header bits for a) tib ptr, b) default hash code, c) lock info and d) GC info. I worry that this would be too disruptive to the code base right now. Can we make do with the above proposal? We can definitely make do with it. Are you agreeing that the GC should own hashCode() or that some header bits are allowed? From a generalist POV, I liked the header bits idea, but I know nothing about how GCs are done.. 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon Washburn wrote: Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to "own" the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving object hash one or two or even 12 header bits. Absolutely. +1 > It all becomes a local problem of GC implementation. No need for negotiating with the rest of the VM :) From a top-level how about giving the GC one byte of object header to do hash plus whatever it wants? I realize it would be nice to have an "expando" object model in Harmony that would allow arbitrary number of header bits for a) tib ptr, b) default hash code, c) lock info and d) GC info. I worry that this would be too disruptive to the code base right now. Can we make do with the above proposal? We can definitely make do with it. Just to be clear, the two-bit Object.hashCode() scheme I refer to is the one in section 3.3 of, "Space- and Time-Efficient Implemention of the Java Object Model" by David Bacon, et al. I think this is also the scheme Ivan Volosyuk is refering to and has an implementation of. And as implemented in JikesRVM. Yep, that's the one I'm talking about too. So where you say >> > I think the hashCode can be >> > reduced to one bit plus the object's current address at first >> > HashCode() invocation. I'd put this hash bit in the GC byte. And >> > make the GC byte the lowest byte in the header word. The remaining >> > 3bytes could be used for fat/thin locks. I'm guessing you're assuming a copying nursery and a non-moving mature space ? In a more general setting I'm not sure how you could get away with one bit. cheers - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
+1, for GC to own Object.hashCode(). That's exactly, what I propose. Slightly outdated patch with the changes included can be found in HARMONY-1269. I can update it to reflect recent TM changes or you can redo this work by yourself. -- Thanks, Ivan On 8/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to "own" the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving object hash one or two or even 12 header bits. It all becomes a local problem of GC implementation. No need for negotiating with the rest of the VM :) From a top-level how about giving the GC one byte of object header to do hash plus whatever it wants? I realize it would be nice to have an "expando" object model in Harmony that would allow arbitrary number of header bits for a) tib ptr, b) default hash code, c) lock info and d) GC info. I worry that this would be too disruptive to the code base right now. Can we make do with the above proposal? Just to be clear, the two-bit Object.hashCode() scheme I refer to is the one in section 3.3 of, "Space- and Time-Efficient Implemention of the Java Object Model" by David Bacon, et al. I think this is also the scheme Ivan Volosyuk is refering to and has an implementation of. On 8/28/06, Robin Garner <[EMAIL PROTECTED]> wrote: > > From talking to > > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte > > of object header for private use. Its unclear to me if this will be a > > performance problem for a product JVM. > > Yep. We found a nice mark-sweep implementation technique that greatly > reduces the cost of sweeping if we have several mark bits available, but > after 4 or so bits the advantage tails off, so there is room for > compromise with the VM's need. On the other hand I'm currently looking at > other ways we could speed up GC if there were a few extra header bits > available, so the more bits available to GC, the better - and these will > generally be tunable parameters that can be traded against the VM's other > needs. > > > I think the hashCode can be > > reduced to one bit plus the object's current address at first > > HashCode() invocation. I'd put this hash bit in the GC byte. And > > make the GC byte the lowest byte in the header word. The remaining > > 3bytes could be used for fat/thin locks. > > In GenMS, where there is a copying nursery and a non-moving mature space, > you could indeed get away with 1 bit for hashcode, with a different > meeaning in each space. In a heap where objects could move more than > once, I think you might still need 2 bits. - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Robin, Good points. Given that Object.hashCode() implementation sortof, kindof depends on a copying mature space, does it make sense for the GC to "own" the Object.hashCode() implementation? That way, we eliminate the vm-wide debate about giving object hash one or two or even 12 header bits. It all becomes a local problem of GC implementation. No need for negotiating with the rest of the VM :) From a top-level how about giving the GC one byte of object header to do hash plus whatever it wants? I realize it would be nice to have an "expando" object model in Harmony that would allow arbitrary number of header bits for a) tib ptr, b) default hash code, c) lock info and d) GC info. I worry that this would be too disruptive to the code base right now. Can we make do with the above proposal? Just to be clear, the two-bit Object.hashCode() scheme I refer to is the one in section 3.3 of, "Space- and Time-Efficient Implemention of the Java Object Model" by David Bacon, et al. I think this is also the scheme Ivan Volosyuk is refering to and has an implementation of. On 8/28/06, Robin Garner <[EMAIL PROTECTED]> wrote: > From talking to > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte > of object header for private use. Its unclear to me if this will be a > performance problem for a product JVM. Yep. We found a nice mark-sweep implementation technique that greatly reduces the cost of sweeping if we have several mark bits available, but after 4 or so bits the advantage tails off, so there is room for compromise with the VM's need. On the other hand I'm currently looking at other ways we could speed up GC if there were a few extra header bits available, so the more bits available to GC, the better - and these will generally be tunable parameters that can be traded against the VM's other needs. > I think the hashCode can be > reduced to one bit plus the object's current address at first > HashCode() invocation. I'd put this hash bit in the GC byte. And > make the GC byte the lowest byte in the header word. The remaining > 3bytes could be used for fat/thin locks. In GenMS, where there is a copying nursery and a non-moving mature space, you could indeed get away with 1 bit for hashcode, with a different meeaning in each space. In a heap where objects could move more than once, I think you might still need 2 bits. cheers - 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 - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
> From talking to > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte > of object header for private use. Its unclear to me if this will be a > performance problem for a product JVM. Yep. We found a nice mark-sweep implementation technique that greatly reduces the cost of sweeping if we have several mark bits available, but after 4 or so bits the advantage tails off, so there is room for compromise with the VM's need. On the other hand I'm currently looking at other ways we could speed up GC if there were a few extra header bits available, so the more bits available to GC, the better - and these will generally be tunable parameters that can be traded against the VM's other needs. > I think the hashCode can be > reduced to one bit plus the object's current address at first > HashCode() invocation. I'd put this hash bit in the GC byte. And > make the GC byte the lowest byte in the header word. The remaining > 3bytes could be used for fat/thin locks. In GenMS, where there is a copying nursery and a non-moving mature space, you could indeed get away with 1 bit for hashcode, with a different meeaning in each space. In a heap where objects could move more than once, I think you might still need 2 bits. cheers - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/25/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote: On 8/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > On 8/24/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > > In any way, currently there is no single header file in the system, > > which would describe the object structure. Rather, DRLVM uses some > > static assumptions about object header, which are not enforced by any > > common include file. This would be a nice thing to solve... > > Good point. There needs to be a discussion on harmony-dev regarding > how the object header bits are "sliced and diced". From talking to > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte > of object header for private use. Its unclear to me if this will be a > performance problem for a product JVM. I think the hashCode can be > reduced to one bit plus the object's current address at first > HashCode() invocation. I'd put this hash bit in the GC byte. And OK, then what this one bit will be used for? Where do we keep the hash code after the object is moved and it's address is changed? Perhaps I'm not getting the idea... Hashcode for the moved object can be allocated just after the end of the object. This is done in GC v4.1 (HARMONY-1269). For more details how it can be done, look at my previous posting in this thread. The problem is, that changes required for existing algorithms to use this approach. E.g. it is not so easy to do this in Gc_v4. So, use of GC interface function gc_get_hashcode() can help. Some of algorithm may store hashcode in object info bits, others can use more advanced approaches. > make the GC byte the lowest byte in the header word. The remaining > 3bytes could be used for fat/thin locks. Are there any remaining I think this is a good idea to use the different bytes for GC and Object's monitor purposes. It can help monitor's and GC's algorithms to work independently and avoid extensive atomic operations whenever it is possible. Thanks, Andrey. - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: On 8/24/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > In any way, currently there is no single header file in the system, > which would describe the object structure. Rather, DRLVM uses some > static assumptions about object header, which are not enforced by any > common include file. This would be a nice thing to solve... Good point. There needs to be a discussion on harmony-dev regarding how the object header bits are "sliced and diced". From talking to the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte of object header for private use. Its unclear to me if this will be a performance problem for a product JVM. I think the hashCode can be reduced to one bit plus the object's current address at first HashCode() invocation. I'd put this hash bit in the GC byte. And OK, then what this one bit will be used for? Where do we keep the hash code after the object is moved and it's address is changed? Perhaps I'm not getting the idea... make the GC byte the lowest byte in the header word. The remaining 3bytes could be used for fat/thin locks. Are there any remaining I think this is a good idea to use the different bytes for GC and Object's monitor purposes. It can help monitor's and GC's algorithms to work independently and avoid extensive atomic operations whenever it is possible. Thanks, Andrey. fields unaccounted for? Thoughts? -- 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] -- Andrey Chernyshev 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, look at the patch in http://issues.apache.org/jira/browse/HARMONY-1269. I have already done this work. After the patch you have whole lowest byte + 2 bits in the second byte for GC use; in expense of implementing hashcode by GC. In my understanding the hashcode can be reduced to 2 status bits in object info: 00. hashcode is not set 01. hashcode is set (hashcode is the address of object) 11. hashcode is set and object is moved (hashcode is no longer the address of object) This layout require assistance from GC (which is missing in GC_V4). I suggest using interface function: gc_get_hashcode() in GC-to-VM interface which will know exactly the layout of bits in the lowest byte of hashcode and will do all the needed actions depending on the GC implementation. -- Regards, Ivan On 8/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: On 8/24/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > In any way, currently there is no single header file in the system, > which would describe the object structure. Rather, DRLVM uses some > static assumptions about object header, which are not enforced by any > common include file. This would be a nice thing to solve... Good point. There needs to be a discussion on harmony-dev regarding how the object header bits are "sliced and diced". From talking to the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte of object header for private use. Its unclear to me if this will be a performance problem for a product JVM. I think the hashCode can be reduced to one bit plus the object's current address at first HashCode() invocation. I'd put this hash bit in the GC byte. And make the GC byte the lowest byte in the header word. The remaining 3bytes could be used for fat/thin locks. Are there any remaining fields unaccounted for? Thoughts? -- 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][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/24/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: In any way, currently there is no single header file in the system, which would describe the object structure. Rather, DRLVM uses some static assumptions about object header, which are not enforced by any common include file. This would be a nice thing to solve... Good point. There needs to be a discussion on harmony-dev regarding how the object header bits are "sliced and diced". From talking to the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte of object header for private use. Its unclear to me if this will be a performance problem for a product JVM. I think the hashCode can be reduced to one bit plus the object's current address at first HashCode() invocation. I'd put this hash bit in the GC byte. And make the GC byte the lowest byte in the header word. The remaining 3bytes could be used for fat/thin locks. Are there any remaining fields unaccounted for? Thoughts? -- 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon Washburn wrote:
> Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h
> defines the use of *(ref_ptr +4) for 32-bit environment. Just
> guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell
> the GC that it can use the least significant bit out of these four
> bytes. Is this correct?
Yes. This is correct for the current GC (aka v4), see vm/gc/src/gc_header.h
48 //
49 // Use the contention bit of object header to lock stuff for now... Is
this OKAY???
50 //
51 #define GC_OBJECT_MARK_BIT_MASK 0x0080
52 #define FORWARDING_BIT_MASK 0x1
The comment is outdated. Bit 0x80 of the lockword has not been
used as a contention for quite some time.
GC v4 uses bit 0x80 for verification purpose.
> I would like to use this bit as an MMTk mark
> bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is
> probably not the best...)
In any way, currently there is no single header file in the system,
which would describe the object structure. Rather, DRLVM uses some
static assumptions about object header, which are not enforced by any
common include file. This would be a nice thing to solve...
> There is also a gc/src/gc_header.h file that contains, "#define
> GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of
> sync_bits.h use of this area???Can I assume gc_header.h is
> incorrect?
No.
gc_header.h is correct in stating that GC v4 uses bit 0x80.
However, other GC implementation have other assumptions, and Ivan
recently submitted a patch (along with GC v4.1) that abstracts hashcode,
and makes all lower 10 bits available for GC use, provided that GC
serves the hashcode.
RESUME: If a GC provides function gc_get_hashcode(),
GC has 10 lower bits of lockword at its disposal.
Otherwise, it can only use bits 0,7,8,9 (bits 1-6 are used by default hash
implementation).
One more thing to take into account, that current thread manager
may access lockword in another thread (e.g. using 32 bit compare-and-swap
operation
to unreserve a lock), so atomic operation needs to be used
when updating lockword while java threads are running.
For example, see how default hashcode is implemented in
vm/vmcore/src/thread/object_generic.cpp:
57 void set_hash_bits(ManagedObject *p_obj)
58 {
59 uint8 hb = (uint8) (((POINTER_SIZE_INT)p_obj >> 3) & HASH_MASK) ;
60 // lowest 3 bits are not random enough so get rid of them
61
62 if (hb == 0)
63 hb = (23 & HASH_MASK); // NO hash = zero allowed, thus hard
map hb = 0 to a fixed prime number
64
65 // don't care if the cmpxchg fails -- just means someone else
already set the hash
*** 66 port_atomic_cas8(P_HASH_CONTENTION_BYTE(p_obj),hb, 0);
67 }
-
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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, > There bit layout was the following before new thread manager integration: > object info word contains: > 0 bit - available for GC > 1-6 bits - object hashcode > 7 bit - contention bit unused by TM, but used by GC_V4 > 8-31 bits - other thread manager's data The new Thread Manager use only 10-31 bit for its own data. So you could also use 8-9 bits for GC purpose. These bits could be read any time, but modified only at GC stop the world phase, because they share a byte with a monitor recursion count and other bits. This byte is updated without a lock Thanks Artem - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/24/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: Weldon, I have some information for this case. There bit layout was the following before new thread manager integration: object info word contains: 0 bit - available for GC 1-6 bits - object hashcode 7 bit - contention bit unused by TM, but used by GC_V4 8-31 bits - other thread manager's data I have some changes for this layout in the GC v4.1 patch. Patch introduces new GC interface function: gc_get_hashcode() If garbage collector exports that function it hash full management of all bits in the lowest byte of object info word, but it should provide implementation of identity hashcode for heap objects. If garbage collector doesn't have this function, the previous (described above) layout of bits will be used. -- Ivan On 8/24/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > Weldon, the bits your mentioned are for obj_info. Vtable can't have > its bits overloaded simply without special handling. > > Thanks, > xiaofeng > > On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > On 8/23/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > Weldon, I experimented with last two bits for marking and forwarding > > > without problem. > > > > I assume you are referring to the 2 lowest bits in the vtable pointer. > > The two lowest bits will step on the recursion mask in sync_bits.h... > > won't it? I am confused. > > > > It turns out that MMTk keeps the mark bits around even between GCs. > > Leaving an LSB of the vtable ptr set and then resuming application > > execution will surely cause a failure. Thus there needs to be a full > > time dedicated mark bit in the object header. This is in addition to > > the need for a forwarding bit. > > > > > > > > > > The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( > > > So far as I experimented, it's only used for heap verification). > > > > > > Thanks, > > > xiaofeng > > > > > > On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h > > > > defines the use of *(ref_ptr +4) for 32-bit environment. Just > > > > guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell > > > > the GC that it can use the least significant bit out of these four > > > > bytes. Is this correct? I would like to use this bit as an MMTk mark > > > > bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is > > > > probably not the best...) > > > > > > > > There is also a gc/src/gc_header.h file that contains, "#define > > > > GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of > > > > sync_bits.h use of this area???Can I assume gc_header.h is > > > > incorrect? > > > > > > > > -- > > > > 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] - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, I have some information for this case. There bit layout was the following before new thread manager integration: object info word contains: 0 bit - available for GC 1-6 bits - object hashcode 7 bit - contention bit unused by TM, but used by GC_V4 8-31 bits - other thread manager's data I have some changes for this layout in the GC v4.1 patch. Patch introduces new GC interface function: gc_get_hashcode() If garbage collector exports that function it hash full management of all bits in the lowest byte of object info word, but it should provide implementation of identity hashcode for heap objects. If garbage collector doesn't have this function, the previous (described above) layout of bits will be used. -- Ivan On 8/24/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: Weldon, the bits your mentioned are for obj_info. Vtable can't have its bits overloaded simply without special handling. Thanks, xiaofeng On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > On 8/23/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > Weldon, I experimented with last two bits for marking and forwarding > > without problem. > > I assume you are referring to the 2 lowest bits in the vtable pointer. > The two lowest bits will step on the recursion mask in sync_bits.h... > won't it? I am confused. > > It turns out that MMTk keeps the mark bits around even between GCs. > Leaving an LSB of the vtable ptr set and then resuming application > execution will surely cause a failure. Thus there needs to be a full > time dedicated mark bit in the object header. This is in addition to > the need for a forwarding bit. > > > > > > The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( > > So far as I experimented, it's only used for heap verification). > > > > Thanks, > > xiaofeng > > > > On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h > > > defines the use of *(ref_ptr +4) for 32-bit environment. Just > > > guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell > > > the GC that it can use the least significant bit out of these four > > > bytes. Is this correct? I would like to use this bit as an MMTk mark > > > bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is > > > probably not the best...) > > > > > > There is also a gc/src/gc_header.h file that contains, "#define > > > GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of > > > sync_bits.h use of this area???Can I assume gc_header.h is > > > incorrect? > > > > > > -- > > > 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, the bits your mentioned are for obj_info. Vtable can't have its bits overloaded simply without special handling. Thanks, xiaofeng On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: On 8/23/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > Weldon, I experimented with last two bits for marking and forwarding > without problem. I assume you are referring to the 2 lowest bits in the vtable pointer. The two lowest bits will step on the recursion mask in sync_bits.h... won't it? I am confused. It turns out that MMTk keeps the mark bits around even between GCs. Leaving an LSB of the vtable ptr set and then resuming application execution will surely cause a failure. Thus there needs to be a full time dedicated mark bit in the object header. This is in addition to the need for a forwarding bit. > > The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( > So far as I experimented, it's only used for heap verification). > > Thanks, > xiaofeng > > On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h > > defines the use of *(ref_ptr +4) for 32-bit environment. Just > > guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell > > the GC that it can use the least significant bit out of these four > > bytes. Is this correct? I would like to use this bit as an MMTk mark > > bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is > > probably not the best...) > > > > There is also a gc/src/gc_header.h file that contains, "#define > > GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of > > sync_bits.h use of this area???Can I assume gc_header.h is > > incorrect? > > > > -- > > 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] > > > > > > - > 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 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/23/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: Weldon, I experimented with last two bits for marking and forwarding without problem. I assume you are referring to the 2 lowest bits in the vtable pointer. The two lowest bits will step on the recursion mask in sync_bits.h... won't it? I am confused. It turns out that MMTk keeps the mark bits around even between GCs. Leaving an LSB of the vtable ptr set and then resuming application execution will surely cause a failure. Thus there needs to be a full time dedicated mark bit in the object header. This is in addition to the need for a forwarding bit. The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( So far as I experimented, it's only used for heap verification). Thanks, xiaofeng On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h > defines the use of *(ref_ptr +4) for 32-bit environment. Just > guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell > the GC that it can use the least significant bit out of these four > bytes. Is this correct? I would like to use this bit as an MMTk mark > bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is > probably not the best...) > > There is also a gc/src/gc_header.h file that contains, "#define > GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of > sync_bits.h use of this area???Can I assume gc_header.h is > incorrect? > > -- > 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] > > - 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 - 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][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, I experimented with last two bits for marking and forwarding without problem. The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( So far as I experimented, it's only used for heap verification). Thanks, xiaofeng On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h defines the use of *(ref_ptr +4) for 32-bit environment. Just guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell the GC that it can use the least significant bit out of these four bytes. Is this correct? I would like to use this bit as an MMTk mark bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is probably not the best...) There is also a gc/src/gc_header.h file that contains, "#define GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of sync_bits.h use of this area???Can I assume gc_header.h is incorrect? -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h defines the use of *(ref_ptr +4) for 32-bit environment. Just guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell the GC that it can use the least significant bit out of these four bytes. Is this correct? I would like to use this bit as an MMTk mark bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is probably not the best...) There is also a gc/src/gc_header.h file that contains, "#define GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of sync_bits.h use of this area???Can I assume gc_header.h is incorrect? -- 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]
