Salikh Zakirov wrote: > Technically, it should not be too difficult to add an additional field to the > VTable > structure, and require GC to write 1 there during object scanning. > However, if the VTable mark is located in the same cache line as gcmap, > it may severely hit parallel GC performance on a multiprocessor due to false > sharing, > as writing VTable mark will invalidate the gcmap pointers loaded to caches of > other > processors. > > object VTable gcmap > +--------+ +-----------+ +------------------+ > | VT ptr |------->| gcmap ptr |----------->| offset of ref #1 | > | ... | | ... | | offset of ref #2 | > +--------+ +-----------+ | ... | > | 0 | > +------------------+
If you go that far for every scanned object (!), then you could simply
place the class unloading bit in the gc map, at index -1) to minimize
disruption of current code...
object VTable gcmap
+------------------+
+--------+ +-----------+ | cl.un. mark bit |
| VT ptr |------->| gcmap ptr |----------->| offset of ref #1 |
| ... | | ... | | offset of ref #2 |
+--------+ +-----------+ | ... |
| 0 |
+------------------+
This gets rid of the cache line hazard...
Why don't you also investigate using SableVM's bidirectional object
layout? Dayong Gu (a Ph.D. student tha I co-supervise) found that it
was quite simple to implement in JikesRVM. I don't see why it should be
harder to implement in drlvm... It would save you this nasty
indirection for scanning objects! [See my Ph.D. thesis for an
explanation of the layout. You can get in touch with Dayong through the
coordinates at http://www.sable.mcgill.ca/people/ ].
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
