Re: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Weldon Washburn wrote: Robin, I did a diff of the mmtk/vm directory. It looks like nothing really changed in the vm interface code which is good. Am I understanding this right?? That sounds about right. And (famous last words) I think the interface will probably remain stable for a while now. I did notice a change in utility/scan/mmtype.java. getSlot(ObjectReference, int) returns addr.plus(VM.ARRAY_BASE_OFFSET) instead of ...plus(arrayOffset)... I actually stumbled on this bug during bringup. I replaced ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it looks like I simply set ARRAY_BASE_OFFSET to 12 during clinit. Does this seem right?? That's the intent, yes. Each VM provides its array base offset as a constant. 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: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Weldon Washburn wrote: I actually stumbled on this bug during bringup. I replaced ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it looks like I simply set ARRAY_BASE_OFFSET to 12 during clinit. Does this seem right?? By the way, the array base offset may differ depending on the platform and array type. As as I know, currently on 32 bit platform (ia32) the array base offset is 12 for types of size = 4. Double[] and long[] arrays have array base offset 16. on 64 bit platforms, if the vtable pointers are compressed (they are now), the array base offset is the same as on 32 bit platforms. Should someone disable vtable reference compression, the array base offset will be always 16 (8 bytes vptr + 4 bytes flags + 4 bytes array size). - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote: By the way, the array base offset may differ depending on the platform and array type. As as I know, currently on 32 bit platform (ia32) the array base offset is 12 for types of size = 4. Double[] and long[] arrays have array base offset 16. Thank you Salikh, the information is really useful! on 64 bit platforms, if the vtable pointers are compressed (they are now), the array base offset is the same as on 32 bit platforms. AFAIK the current inter component interface uses only 32bit allocation handle values (e.g. gc_alloc) To support 64bit allocation handles we have to modify VM-GC interfaces in DRLVM. -- Mikhail Fursov
Re: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Urgh. In that case the array base offset should be specified in the constructor of an MMType - JikesRVM doesn't have this problem, because the object pointer always points to element 0 of an array irrespective of header sizes and alignment issues (and hence the align and offset parameters to 'alloc'). I was brought up to believe that a fixed offset to the first data field was a performance win - has it been measured ? I'll have a look at doing this in MMTk, but probably not until after OOPSLA. cheers Weldon Washburn wrote: I actually stumbled on this bug during bringup. I replaced ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it looks like I simply set ARRAY_BASE_OFFSET to 12 during clinit. Does this seem right?? By the way, the array base offset may differ depending on the platform and array type. As as I know, currently on 32 bit platform (ia32) the array base offset is 12 for types of size = 4. Double[] and long[] arrays have array base offset 16. on 64 bit platforms, if the vtable pointers are compressed (they are now), the array base offset is the same as on 32 bit platforms. Should someone disable vtable reference compression, the array base offset will be always 16 (8 bytes vptr + 4 bytes flags + 4 bytes array size). - 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: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Salikh, Good catch! You just saved the MMTk port 20 hours of debugging. Thank you :) On 10/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Weldon Washburn wrote: I actually stumbled on this bug during bringup. I replaced ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it looks like I simply set ARRAY_BASE_OFFSET to 12 during clinit. Does this seem right?? By the way, the array base offset may differ depending on the platform and array type. As as I know, currently on 32 bit platform (ia32) the array base offset is 12 for types of size = 4. Double[] and long[] arrays have array base offset 16. on 64 bit platforms, if the vtable pointers are compressed (they are now), the array base offset is the same as on 32 bit platforms. Should someone disable vtable reference compression, the array base offset will be always 16 (8 bytes vptr + 4 bytes flags + 4 bytes array size). - 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: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Robin, This helps a bunch. Thanks! I have downloded http://cs.anu.edu.au/people/Robin.Garner/mmtk-20061012.jar and will move to it now. On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: Original Message Subject: Re: [DRLVM][JET] write barrier for Java (mmtk) Date: Thu, 12 Oct 2006 11:36:33 +1000 From: Robin Garner [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Weldon Washburn wrote: Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. I don't know when it will be suggested we move to a more recent version of MMTk. I suspect a major part of the confusion has been because of working with a code base where the Plan interface is in transition. My impression was that Steve's advance release to you included the refactoring into MutatorContext and CollectorContext. It's been pretty stable (wrt major refactorings) since then. My recollection is that writeBarrier hasn't been a method of Plan since mid 2005 when Daniel Frampton and I refactored and created PlanLocal. Could you double check ?? In any case, please confirm that each java thread needs to put an instance of Plan in its thread-local storage and that writeBarrier() and alloc() virtual method entry points need to be materialized from thread-local Plan object. No. Each java thread needs a MutatorContext (or more precisely the correct sub-type for the given plan) for each thread, and a CollectorContext for each GC thread. Logically, the objects Plan, MutatorContext, CollectorContaxt, Trace and TraceLocal comprise a plan. Also, please confirm (or deny) that we should never call VM.barriers.performWriteInBarrier(). It only should be called by internal MMTk methods (I think). Confirmed. Well you could call it, but it just does a store without invoking a write barrier. Rarely what you want outside of MMTk internals. On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper
Re: [Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Robin, I did a diff of the mmtk/vm directory. It looks like nothing really changed in the vm interface code which is good. Am I understanding this right?? I did notice a change in utility/scan/mmtype.java. getSlot(ObjectReference, int) returns addr.plus(VM.ARRAY_BASE_OFFSET) instead of ...plus(arrayOffset)... I actually stumbled on this bug during bringup. I replaced ...plus(arrayOffset)... with ...plus(12)... Its a hack. But now it looks like I simply set ARRAY_BASE_OFFSET to 12 during clinit. Does this seem right?? On 10/12/06, Weldon Washburn [EMAIL PROTECTED] wrote: Robin, This helps a bunch. Thanks! I have downloded http://cs.anu.edu.au/people/Robin.Garner/mmtk-20061012.jar and will move to it now. On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: Original Message Subject: Re: [DRLVM][JET] write barrier for Java (mmtk) Date: Thu, 12 Oct 2006 11:36:33 +1000 From: Robin Garner [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Weldon Washburn wrote: Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. I don't know when it will be suggested we move to a more recent version of MMTk. I suspect a major part of the confusion has been because of working with a code base where the Plan interface is in transition. My impression was that Steve's advance release to you included the refactoring into MutatorContext and CollectorContext. It's been pretty stable (wrt major refactorings) since then. My recollection is that writeBarrier hasn't been a method of Plan since mid 2005 when Daniel Frampton and I refactored and created PlanLocal. Could you double check ?? In any case, please confirm that each java thread needs to put an instance of Plan in its thread-local storage and that writeBarrier() and alloc() virtual method entry points need to be materialized from thread-local Plan object. No. Each java thread needs a MutatorContext (or more precisely the correct sub-type for the given plan) for each thread, and a CollectorContext for each GC thread. Logically, the objects Plan, MutatorContext, CollectorContaxt, Trace and TraceLocal comprise a plan. Also, please confirm (or deny) that we should never call VM.barriers.performWriteInBarrier(). It only should be called by internal MMTk methods (I think). Confirmed. Well you could call it, but it just does a store without invoking a write barrier. Rarely what you want outside of MMTk internals. On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier
Re: [DRLVM][JET] write barrier for Java (mmtk)
Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [DRLVM][JET] write barrier for Java (mmtk)
Weldon, I'm a bit confused what to call finally... The previous WB4J version did a call to org/mmtk/plan/PlanLocal::writeBarrier(). The problem was with getting an instance of PlanLocal. We solved it by adding a stub static method PlanLocal::getPlanLocal() - just for the sake of testing functionality. In the latest version (HARMONY-1806) I'm doing a call to static Barriers::performWriteInBarrier(). However, as long as this method is presented in old MMTk javadoc, I could not find it in the MMTk/ sources from Harmony svn. Also, looking into MMTk/ I could not find a PlanLocal class either. The javadoc says that writeBarrier() is only presented in xxMutator classes. I was about to call org.mmtk.vm::barriers::writeInBarrier() but just saw your post. So, now I'm a in deep thoughts on which method to call and what instance to use. :-) Could please give me a clue? -- Thanks, Alex Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- Mikhail Fursov - 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][JET] write barrier for Java (mmtk)
I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- Mikhail Fursov - 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][JET] write barrier for Java (mmtk)
Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. I don't know when it will be suggested we move to a more recent version of MMTk. I suspect a major part of the confusion has been because of working with a code base where the Plan interface is in transition. In any case, please confirm that each java thread needs to put an instance of Plan in its thread-local storage and that writeBarrier() and alloc() virtual method entry points need to be materialized from thread-local Plan object. Also, please confirm (or deny) that we should never call VM.barriers.performWriteInBarrier(). It only should be called by internal MMTk methods (I think). On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- Mikhail Fursov - 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][JET] write barrier for Java (mmtk)
hmm we may have version skew going on here. Mikhail, Robin can we stay with the July 14 (or there abouts) version that Steve Blackburn posted to his web page? On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/11/06, Weldon Washburn [EMAIL PROTECTED] wrote: Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. Looks like 'unboxed' package from MMTk has been updated recently too. I've found 'Address::prefetchNTA()' op today we do not have in our version. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
[Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Original Message Subject: Re: [DRLVM][JET] write barrier for Java (mmtk) Date: Thu, 12 Oct 2006 11:18:20 +1000 From: Robin Garner [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] My standard practice, at least at this early stage of development, is to try to track SVN head as far as possible. When you get close to release, sure, freeze versions. It's a process choice, and up to you. I realise there might be issues with you accessing svn head directly - I'm happy to cut you a new jar file whenever you like. The current version is at http://cs.anu.edu.au/people/Robin.Garner/mmtk-20061012.jar AFAIK, Steve's private release to you was an *advance* release, that SVN trunk has now overtaken (he didn't want to commit it until after the JikesRVM 2.4.5 release). More in another reply. Weldon Washburn wrote: hmm we may have version skew going on here. Mikhail, Robin can we stay with the July 14 (or there abouts) version that Steve Blackburn posted to his web page? On 10/11/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 10/11/06, Weldon Washburn [EMAIL PROTECTED] wrote: Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. Looks like 'unboxed' package from MMTk has been updated recently too. I've found 'Address::prefetchNTA()' op today we do not have in our version. On ia62/x64 systems, prefetch and prefetchNTA should be synonymous. -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [DRLVM][JET] write barrier for Java (mmtk)]
Original Message Subject: Re: [DRLVM][JET] write barrier for Java (mmtk) Date: Thu, 12 Oct 2006 11:36:33 +1000 From: Robin Garner [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Weldon Washburn wrote: Robin, Thanks for helping clarify the issues. The MMTk code base we are using is what Steve Blackburn supplied us in mid July. I don't know when it will be suggested we move to a more recent version of MMTk. I suspect a major part of the confusion has been because of working with a code base where the Plan interface is in transition. My impression was that Steve's advance release to you included the refactoring into MutatorContext and CollectorContext. It's been pretty stable (wrt major refactorings) since then. My recollection is that writeBarrier hasn't been a method of Plan since mid 2005 when Daniel Frampton and I refactored and created PlanLocal. Could you double check ?? In any case, please confirm that each java thread needs to put an instance of Plan in its thread-local storage and that writeBarrier() and alloc() virtual method entry points need to be materialized from thread-local Plan object. No. Each java thread needs a MutatorContext (or more precisely the correct sub-type for the given plan) for each thread, and a CollectorContext for each GC thread. Logically, the objects Plan, MutatorContext, CollectorContaxt, Trace and TraceLocal comprise a plan. Also, please confirm (or deny) that we should never call VM.barriers.performWriteInBarrier(). It only should be called by internal MMTk methods (I think). Confirmed. Well you could call it, but it just does a store without invoking a write barrier. Rarely what you want outside of MMTk internals. On 10/11/06, Robin Garner [EMAIL PROTECTED] wrote: I think you must be looking at a fairly old version of MMTk. writeBarrier is an instance method of a MutatorContext (in org.mmtk.plan). MutatorContext exists to hold unsynchronized thread-local data structures. Particularly relevant to the write barrier, each mutator context has its own thread-local remset. All of the mutator context methods of MMTk need fast access to the MMTk thread local data structures, which is why they are instance methods. The other critical instance method of a MutatorContext is 'alloc', which also has it's thread-local chunk of the space(s) it allocates into. As far as the VM is concerned, it will be calling instance methods of a final class. The various classes in org.mmtk.plan.* aren't final, but the VM interface code is expected to wrap the currently selected plan in some final class. JikesRVM wraps the currently selected plan classes in a 'SelectedPlan', 'SelectedMutatorContext' etc. As far as the VM.barriers.performWriteInBarrier() call is concerned, the optimization required to devirtualize a call to a final method of a static final field shouldn't be too hard to implement. MMTk recently moved away from using static methods for this part of the interface, to the current abstract factory, and improved the structure of the software significantly. We don't want to go back! I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. well, it less 'breaks the architecture' than performs a no-op :) -- robin Weldon Washburn wrote: Ooops. I really tangled things up. You are right about how we are supposed to find the Java write barrier method. It is located in Plan.writeBarrier(). Each GC algorithm has a Plan class that overrides the writeBarrier() method. I erroneously thought we could call VM.barriers.performWriteInBarrier() directly. This sort of, kind of breaks MMTk architecture. By design, each GC algorithm in MMTk is supposed to call Plan.writeBarrier() which, in turn, will call VM.barriers.performWriteInBarrier. Sorry for the confusion. On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread
Re: [DRLVM][JET] write barrier for Java (mmtk)
Weldon,
I thought about slightly different approach.
Why not to write fast-path VM helper like was proposed in the thread
[drlvm]Extending...
This helper (a static method) can be inlined by JIT without any
devirtualization and call any method needed from MMTk or native
implementation. So JIT won't know if it works with MMTk or with a native GC:
all you need is just to replace the Java version of the helper.
?
On 10/11/06, Weldon Washburn [EMAIL PROTECTED] wrote:
I am just now getting back to the MMTk port.
Looking at MMTk code base, I see that during bootup MMTk creates an
org.mmtk.vm.VM object. The VM object contains a static field that holds
an
instance of Barriers. It is called org.mmtk.vm.VM.barriers.
The complete VM declaration is:
public static final Barriers barriers;
And, of course, the instance method performWriteInBarrier() can be
devirtualized by an optimizing JIT. There is no need to improve the
performance of the write barrier in JET. Thus there is no need to change
the existing MMTk interface.
I can create something like
class MMTkInitization {
static org.mmtk.vm.VM vmBoot;
void init() {
vmBoot = new org.mmtk.vm.VM();
}
The JIT would use reflection to find vmBoot field and then find
performWriteInBarrier() entry point.
Another approach would be to add a new API to JIT/VM interface that would
return the entry point performWriteInBarrier(). Its certainly not as
clean
and maintainable since its an ugly devirtualization hack that will break
if MMTk even wants to subclass Barriers.java
--
Weldon Washburn
Intel Middleware Products Division
--
Mikhail Fursov
Re: [DRLVM][JET] write barrier for Java (mmtk)
Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ?
Re: [DRLVM][JET] write barrier for Java (mmtk)
Yes, we can run the usual inliner after helpers are inlined. The only problem I want to notice is that once we have different helpers for different GCs it's a bad idea to use virtual method calls in performance sensitive helpers. You are allowed to do it, but the better solution is to teach the helper to use a final implementation of the Barrier and replace the helper once the implementation of the Barrier class is changed. On 10/11/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Makes sense, using a standard barrier invocation fastpath. But I assume that the MMTk WB helper that it will call needs to be inlined too. Thanks On 10/10/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, I thought about slightly different approach. Why not to write fast-path VM helper like was proposed in the thread [drlvm]Extending... This helper (a static method) can be inlined by JIT without any devirtualization and call any method needed from MMTk or native implementation. So JIT won't know if it works with MMTk or with a native GC: all you need is just to replace the Java version of the helper. ? -- Mikhail Fursov
