Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Weldon, Warning: unknown flag - jet::wb4j This warning means that the code for 'wb4j' switch processing is not on its place. Either the patch failed to apply, or jitrino.dll was not rebuild properly. Will rebuild help ? E.g. to remove build\win_ia32_msvc_debug\semis\vm\jitrino and then run build.bat -DCOMPONENTS=vm.jitrino ? -- Thanks, Alex Weldon Washburn wrote: On 7/10/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Weldon, I just commited http://issues.apache.org/jira/browse/HARMONY-816 into JIRA. It contains the changes for Jitrino.JET: - magics support for MMTk - write barriers for Java for MMTk - a simple test to check the things are alive I followed the instructions in HARMONY-816. It runs hello world OK but errors out when I try the following: build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xem jet: -Xjit jet::wb4j test Warning: unknown flag - jet::wb4j java.lang.NullPointerException at test.test0(test.java:37) at test.main(test.java:26) Any suggestions would be appreciated. I will dig into the details tomorrow morning. By the way, I am using windows laptop for development. Perhaps the \: needs to be replaced with \; Thanks Weldon - 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/mmtk] jitrino.jet write barrier initial implementaion
On 7/10/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Weldon, I just commited http://issues.apache.org/jira/browse/HARMONY-816 into JIRA. It contains the changes for Jitrino.JET: - magics support for MMTk - write barriers for Java for MMTk - a simple test to check the things are alive I followed the instructions in HARMONY-816. It runs hello world OK but errors out when I try the following: build\win_ia32_msvc_debug\deploy\jre\bin\ij.exe -Xem jet: -Xjit jet::wb4j test Warning: unknown flag - jet::wb4j java.lang.NullPointerException at test.test0(test.java:37) at test.main(test.java:26) Any suggestions would be appreciated. I will dig into the details tomorrow morning. By the way, I am using windows laptop for development. Perhaps the \: needs to be replaced with \; Thanks Weldon - 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] jitrino.jet write barrier initial implementaion
Weldon Washburn wrote: On 7/10/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/10/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 7/10/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: One question, why do we need write barriers for 'putstatic' bytecode? This fields appear in root set and does not represent heap to heap references. There is no need to add write barriers to this entities. Good question. The short answer is because MMTk makes zero assumptions about the VM automatically enumerating all the static locations holding ref ptrs. DRLVM makes the assumption that statics will be part of the root set. We really don't have hard data at this point to show us the best approach yet. I vote for leaving it in for now. This is really the kind of GC/VM integration issue I expect the MMTk port force us to deal with. I think nothing is done without the reason. Looks like the static fields in Jikes live somewhere in java heap. The code will make sense if DRLVM will do the same, otherwise the write barriers will possibly confuse implementation of MMTk, as the changed values are reside outside the heap. Its not clear what you are trying to say. In any case, it should be straight forward to sort out putstatic ref ptrs once we get to the debug stage. Static fields in JikesRVM live in the JTOC and are enumerated as roots, just like in drlvm. MMTk simply requires all pointers from outside the heap into it to be enumerated as roots. If statics were part of 'class' objects in the heap, or as an Object array, then the existing write barrier should function correctly. In fact MMTk has no notion of 'static' fields, as it aims to be (target) language independent. cheers, Robin - 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] jitrino.jet write barrier initial implementaion
Weldon Washburn wrote: On 7/10/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Weldon, I just commited http://issues.apache.org/jira/browse/HARMONY-816 into JIRA. Thanks. I will look at it today. It contains the changes for Jitrino.JET: - magics support for MMTk - write barriers for Java for MMTk - a simple test to check the things are alive I also have few questions on unboxed package and some MMTk internals, that I was unable to resolve myself (I used javadocs from http://jikesrvm.sourceforge.net/api/) and I would appreciate a help on resolving them. The main obstacle is that writeBarrier method in PlanLocal is instance method. I failed to find a way how to get the proper instance during runtime - and this is the first question - how to get the proper instance of PlanLocal ? Yes. We will need to add APIs for the jit to get the ref ptrs to a few MMTk java objects. My guess is that MMTk can allocate these objects in immortal space which is never moved, never collected thus the ref pointer is always valid. The latest CVS head for MMTk clarifies/complicates this even more:) Steve has refactored the PlanLocal into a 'MutatorContext' and a 'CollectorContext' object. The Mutator Context is a per-thread data structure, and the collector context is per-GC-thread (MMTk collectors are parallel). Currently, I've made a presumption that there must be some static method to get it. We need to discuss the approaches. The API could be a static java method but this requires the JIT to call out to java code while jitting which might not be a good idea. Another approach is to use the existing class loader API to return the address of a java static variable. Its a proven/tested existing interface. Thoughts? What about a pointer off the per-thread data structure ? I used a simple fake stub to test the implementation (it's in PlanLocal.java attached to the JIRA). Also, there are few questions on unboxed package: - Address::max() - what is 'maximul allowable Address' ? I think its 2**32 or 2**32-1 or something like that. 2**Address-width A highest valid addres in heap ? Or simply ~(void*)0 ? The above seems reasonable. The rest of your questions I will think about and get back to you. Address::min() should be 0. - What's the diff between diff() and sub() ? diff()=='abs(sub())' ? (sub has actually been replaced by minus in the past few weeks) Diff() returns an Offset (a signed quantity) that represents the distance between two addresses. sub() (or minus() now) subtracts an offset from an address returning an address. The difference is in the types they take and return, and interpretation of arguments as signed or unsigned. - Word::one() - what's this ? (Object)1 ? Almost (modulo types). It's the value 1, as type Word. - what is AddressArray::getBacking() ? No idea. Current MMTk CVS head doesn't have it. - rshl, rshr, rsha - they shift, but what and how exactly they're shifting ? Right-shift arithmetic (ie with sign extension) and right-shift logical (no sign extend). Never heard of rshr. - what are exact values for mode argument in writeBarrier ? Currently, I'm simply using 0/1/2. these are the *_BARRIER constants in org.mmtk.utility.Constants. cheers, Robin - 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] jitrino.jet write barrier initial implementaion
Weldon, I just commited http://issues.apache.org/jira/browse/HARMONY-816 into JIRA. It contains the changes for Jitrino.JET: - magics support for MMTk - write barriers for Java for MMTk - a simple test to check the things are alive I also have few questions on unboxed package and some MMTk internals, that I was unable to resolve myself (I used javadocs from http://jikesrvm.sourceforge.net/api/) and I would appreciate a help on resolving them. The main obstacle is that writeBarrier method in PlanLocal is instance method. I failed to find a way how to get the proper instance during runtime - and this is the first question - how to get the proper instance of PlanLocal ? Currently, I've made a presumption that there must be some static method to get it. I used a simple fake stub to test the implementation (it's in PlanLocal.java attached to the JIRA). Also, there are few questions on unboxed package: - Address::max() - what is 'maximul allowable Address' ? A highest valid addres in heap ? Or simply ~(void*)0 ? - What's the diff between diff() and sub() ? diff()=='abs(sub())' ? - Word::one() - what's this ? (Object)1 ? - what is AddressArray::getBacking() ? - rshl, rshr, rsha - they shift, but what and how exactly they're shifting ? - what are exact values for mode argument in writeBarrier ? Currently, I'm simply using 0/1/2. -- Thanks, Alex Weldon Washburn wrote: Alex, Sorry for taking so long to answer your questions below. Please see the response inline. Weldon On 6/27/06, Alex Astapchuk [EMAIL PROTECTED] wrote: AFAIR from the recent thread, to implement WB for MMTk support, I have to emit calls of org.mmtk.plan.PlanLocal.writeBarrier( ObjectReference src, Address slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int mode) on every PUTSTATIC/PUTFIELD/AASTORE. I can guess what 'src' is - this is the object being written, right ? But could you please point me what all other args are ? A quick description of what all the writeBarrier() fields are: src Reference pointer to the object that's getting modified via putfied/putstatic/aastore slot The machine address into which the new reference will be stored tgt The reference pointer that will get written into the slot metaDataA The difference between the machine address of the slot and src metaDataB I think its intended to be used as some sort of an index into VM internal (class loader) array struct that holds info on which fields of a given object are ref ptrs. mode Mode is either PUTASTATIC, PUTFIELD, AASTORE Can't we go without all the stuff and have only 2 args - an object being written and the destination class/array/instance ? :-) If we did this, ultimately we would end up making some ugly hacks on MMTK's writeBarrier(). I'd like to avoid this approach until a real compelling reason surfaces. For initial bring up, the only write barrier GC I worry about is mmtk.plan.generational. The generational GC only uses slot for the actual write barrier. Since it is a substituting write barrier, writeBarrier() calls the code that is responsible for actually scribbling the ref ptr on the Java heap. The code that scribbles on the heap is intended to be developed during MMTK port. Most likely I will write this code. The only parameters needed (I think) is slot and tgt. In other words, you can fill in a zero for src, metaDataA, metaDataB and mode for initial bring up. But ultimately they have to have legitimate values to satisfy MMTK writeBarrier() interface. -- Thanks, Alex - 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] jitrino.jet write barrier initial implementaion
One question, why do we need write barriers for 'putstatic' bytecode? This fields appear in root set and does not represent heap to heap references. There is no need to add write barriers to this entities. This is good that the patch doesn't conflict with HARMONY-581. I can continue my experiments with C garbage collector. -- Ivan On 7/10/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Weldon, I just commited http://issues.apache.org/jira/browse/HARMONY-816 into JIRA. It contains the changes for Jitrino.JET: - magics support for MMTk - write barriers for Java for MMTk - a simple test to check the things are alive I also have few questions on unboxed package and some MMTk internals, that I was unable to resolve myself (I used javadocs from http://jikesrvm.sourceforge.net/api/) and I would appreciate a help on resolving them. The main obstacle is that writeBarrier method in PlanLocal is instance method. I failed to find a way how to get the proper instance during runtime - and this is the first question - how to get the proper instance of PlanLocal ? Currently, I've made a presumption that there must be some static method to get it. I used a simple fake stub to test the implementation (it's in PlanLocal.java attached to the JIRA). Also, there are few questions on unboxed package: - Address::max() - what is 'maximul allowable Address' ? A highest valid addres in heap ? Or simply ~(void*)0 ? - What's the diff between diff() and sub() ? diff()=='abs(sub())' ? - Word::one() - what's this ? (Object)1 ? - what is AddressArray::getBacking() ? - rshl, rshr, rsha - they shift, but what and how exactly they're shifting ? - what are exact values for mode argument in writeBarrier ? Currently, I'm simply using 0/1/2. -- Thanks, Alex -- Ivan 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] jitrino.jet write barrier initial implementaion
On 7/10/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: One question, why do we need write barriers for 'putstatic' bytecode? This fields appear in root set and does not represent heap to heap references. There is no need to add write barriers to this entities. Good question. The short answer is because MMTk makes zero assumptions about the VM automatically enumerating all the static locations holding ref ptrs. DRLVM makes the assumption that statics will be part of the root set. We really don't have hard data at this point to show us the best approach yet. I vote for leaving it in for now. This is really the kind of GC/VM integration issue I expect the MMTk port force us to deal with. This is good that the patch doesn't conflict with HARMONY-581. I can continue my experiments with C garbage collector. -- Ivan - 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] jitrino.jet write barrier initial implementaion
On 7/10/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 7/10/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: One question, why do we need write barriers for 'putstatic' bytecode? This fields appear in root set and does not represent heap to heap references. There is no need to add write barriers to this entities. Good question. The short answer is because MMTk makes zero assumptions about the VM automatically enumerating all the static locations holding ref ptrs. DRLVM makes the assumption that statics will be part of the root set. We really don't have hard data at this point to show us the best approach yet. I vote for leaving it in for now. This is really the kind of GC/VM integration issue I expect the MMTk port force us to deal with. I think nothing is done without the reason. Looks like the static fields in Jikes live somewhere in java heap. The code will make sense if DRLVM will do the same, otherwise the write barriers will possibly confuse implementation of MMTk, as the changed values are reside outside the heap. Regards, -- Ivan 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] jitrino.jet write barrier initial implementaion
On 7/10/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/10/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 7/10/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: One question, why do we need write barriers for 'putstatic' bytecode? This fields appear in root set and does not represent heap to heap references. There is no need to add write barriers to this entities. Good question. The short answer is because MMTk makes zero assumptions about the VM automatically enumerating all the static locations holding ref ptrs. DRLVM makes the assumption that statics will be part of the root set. We really don't have hard data at this point to show us the best approach yet. I vote for leaving it in for now. This is really the kind of GC/VM integration issue I expect the MMTk port force us to deal with. I think nothing is done without the reason. Looks like the static fields in Jikes live somewhere in java heap. The code will make sense if DRLVM will do the same, otherwise the write barriers will possibly confuse implementation of MMTk, as the changed values are reside outside the heap. Its not clear what you are trying to say. In any case, it should be straight forward to sort out putstatic ref ptrs once we get to the debug stage. Regards, -- Ivan 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] -- 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]
