You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alex Astapchuk <al...@gmail.com> on 2006/07/10 14:41:24 UTC
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 <al...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn wrote:
> On 7/10/06, Alex Astapchuk <al...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Weldon Washburn <we...@gmail.com>.
On 7/10/06, Alex Astapchuk <al...@gmail.com> 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.
>
> 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?
> 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.
> 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.
> - 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
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn wrote:
> On 7/10/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>> On 7/10/06, Weldon Washburn <we...@gmail.com> wrote:
>> > On 7/10/06, Ivan Volosyuk <iv...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Weldon Washburn <we...@gmail.com>.
On 7/10/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> On 7/10/06, Weldon Washburn <we...@gmail.com> wrote:
> > On 7/10/06, Ivan Volosyuk <iv...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 7/10/06, Weldon Washburn <we...@gmail.com> wrote:
> On 7/10/06, Ivan Volosyuk <iv...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Weldon Washburn <we...@gmail.com>.
On 7/10/06, Ivan Volosyuk <iv...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Ivan Volosyuk <iv...@gmail.com>.
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 <al...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Alex Astapchuk <al...@gmail.com>.
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 <al...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Weldon Washburn <we...@gmail.com>.
On 7/10/06, Alex Astapchuk <al...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org