Re: [drlvm] Re: [design] Class unloading: false sharing of vtable marks

2006-11-14 Thread Rana Dasgupta
On 11/14/06, Robin Garner <[EMAIL PROTECTED]> wrote: >Whether this helps performance depends on the cache policy of the >multiprocessor. I'm not sufficiently versed in cache architectures to >say, but I would expect that machines with sufficiently weak memory >models will make this cheap, thos

[drlvm] Re: [design] Class unloading: false sharing of vtable marks

2006-11-14 Thread Robin Garner
Salikh Zakirov wrote: As we discussed before, the VTable marks approach [1] has a "false sharing" problem on a multiprocessor: when one thread is writing to vtable mark, it is invalidating respective cache line in other processor caches. Meanwhile, since gcmaps, located near vtable marks, are

Re: [drlvm] Re: [design] Class unloading: false sharing of vtable marks

2006-11-14 Thread Weldon Washburn
On 11/14/06, Robin Garner <[EMAIL PROTECTED]> wrote: Salikh Zakirov wrote: > As we discussed before, the VTable marks approach [1] has a "false sharing" problem > on a multiprocessor: > > when one thread is writing to vtable mark, it is invalidating respective cache line > in other processor cac

[design] Class unloading: false sharing of vtable marks

2006-11-14 Thread Salikh Zakirov
As we discussed before, the VTable marks approach [1] has a "false sharing" problem on a multiprocessor: when one thread is writing to vtable mark, it is invalidating respective cache line in other processor caches. Meanwhile, since gcmaps, located near vtable marks, are loaded frequently during