You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/06/22 01:06:01 UTC
[drlvm/mmtk] jitrino.jet write barrier design questions
It would be really nice if jitrino.jet allowed the write barrier to be
selected at the start of jitting an individual method. Is this
possible?
The selections would be mutually exclusive:
1)
no write barrier (for the existing GCV4)
2)
write barrier written in Java (for MMTk)
3)
write barrier written in C (for the yet to be determined basic generational GC)
Allowing the "java" write barrier to be selected on a method by method
basis would be very useful for MMTk bring up. The concept is to
initially run MMTK sort of like a "user mode linux". That is, startup
the JVM w/o barriers turned on. Run "hello world". Then switch on
MMTK collector/allocator and Java write barriers and compile/run the
following method:
public class InitialMMTkBringup {
public int stressTheMMTkAllocator () {
while(true) {
Object obj = new Object();
Object [] ia = new Object[100];
//at a later stage, add code that causes a write barrier
//at a later stage, add code that will randomly chain Object
arrays together...
}
}
The above would be running while the underlying JVM GC is running. If
not careful this could cause lots of confusion. The intention is to
run MMTk in "user mode" only to the point where MMTk alloc,
collection, write barrier code paths are exercised. Provided we do
not do anything to cause the underlying JVM GC to kick in, we should
be OK.
As a second step actually integrate MMTk into the JVM. Note that
basic garden variety Java debugger should work w/o modification with a
"user mode MMTk".
--
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 design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 6/30/06, Alex Astapchuk <al...@gmail.com> wrote:
> > Actually, the simplest form of write barrier would be one, single
> > parameter -- a ref ptr to the object getting scribbled on. I suspect
>
> Hmmm...
> Seems I have a misunderstanding here - how comes a single ref ?
>
> What I was thinking of, is that the WB of 2 refs is a kind of
> optimization for generational GCs. I recall a thread on this
> in harmony-dev - that having an object being written and the
> target to write into, such GC can easily detect whether or not
> the young 'src' becomes reachable from the old generation.
>
> But what would be a 'single ref' write barrier intended for ?
> Just curious...
Good point. I did some digging. The precursor to DRLVM, ORP, has a
generational collector with the oldest generation using the train
algorithm. The write barrier in ORP has just one argument which is
"slot". The comment in ORP code indicates that filtering out
uninteresting ref ptrs was tried but showed an overall performance
degrade. SableVM has a generational GC that only uses the "slot"
pointer.
OTOH, MMTk generational collector does filter out uninterresting
addresses. It uses both addresses as you suggest above.
---------------------------------------------------------------------
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 design questions
Posted by Alex Astapchuk <al...@gmail.com>.
Weldon,
>> I can guess what 'src' is - this is the object being written, right ?
>> But could you please point me what all other args are ?
>> Can't we go without all the stuff and have only 2 args - an
>> object being written and the destination class/array/instance ? :-)
>
> Actually, the simplest form of write barrier would be one, single
> parameter -- a ref ptr to the object getting scribbled on. I suspect
Hmmm...
Seems I have a misunderstanding here - how comes a single ref ?
What I was thinking of, is that the WB of 2 refs is a kind of
optimization for generational GCs. I recall a thread on this
in harmony-dev - that having an object being written and the
target to write into, such GC can easily detect whether or not
the young 'src' becomes reachable from the old generation.
But what would be a 'single ref' write barrier intended for ?
Just curious...
Anyway, back to the business.
Adding 'Uninterruptible' functionality into Jitrino.JET seems
pretty easy - just avoid generating back branch pooling.
Though my understanding is that this will also require VM-side
support - in a case if 'Uninterruptible' method makes a call to
VM (allocates an object, or performs interface call or whatever).
>before it makes sense to add MMTk write barrier to
> jitrino.JET, we need to add intrinsics to support MMTk vmmagic
> classes.
Seems the first to do are the org.vmmagic.unboxed.* ?
--
Thanks,
Alex
Weldon Washburn wrote:
> Hi Alex,
> Comment inline below.
>
> On 6/27/06, Alex Astapchuk <al...@gmail.com> wrote:
>> Weldon,
>>
>> Weldon Washburn wrote:
>> > It would be really nice if jitrino.jet allowed the write barrier to be
>> > selected at the start of jitting an individual method. Is this
>> > possible?
>> Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
>> flags to instrument the jitted code.
>
> I think you are referring to stuct OpenMethodExecutionParams{...} in
> jit_export.h. I took a look, it seems like the right place to put the
> switches that tell the compiler which write barrier to emit.
>>
>> >
>> > The selections would be mutually exclusive:
>> > 1)
>> > no write barrier (for the existing GCV4)
>> > 2)
>> > write barrier written in Java (for MMTk)
>> > 3)
>> > write barrier written in C (for the yet to be determined basic
>> > generational GC)
>>
>> VM (or ExectionManager) can signal which barrier to implement using
>> the flags passed to JIT_compile_method.
>> The current set of seems incomplete - for instance, it does not cover
>> array manipulations. Also, we can't signal the difference you mention -
>> WB4J or WB4C, but sure we can extend the set.
>
> Yes, extend OpenMethodExecutionParams{...} This seems like a good idea.
>
>>
>> I have a look at the submitted patch for DRLVM (GC write barrier update
>> patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
>> seems it's only for interpreter.
>
> Yes and no. The part that would be interesting to a compiler writer
> targets an interpreter thus this patch is of limited interest.
> However, the part that patches the VM is interesting to VM builders.
> A side note. I looked at the patch for the VM code and can't help but
> comment that the mods which add gc_write_barrier() to vm_arrays() look
> to be redundant as gc_heap_wrote_object() is already called.
>>
>> If no one complains, I would like to implement the WB4J we are
>> discussing here in .jet.
>
> Go for it!
>
>>
>> As we currently don't have C-based GC with WB support (do we?),
>
> Its a long, long story. For all intents and purposes, drlvm does not
> yet have a quality "C" GC that requires a write barrier. I hope this
> changes soon.
>
>> for the first iteration I'm going to instrument code with WB4J in
>> response to OpenMethodExecutionParams:: exe_insert_write_barriers.
>
> Good idea! Write some code and post it to JIRA. Then I can give feedback.
>
>> We can change this later then.
>>
>> Though I'm not familiar with MMTk, could please give me some clues ?
>>
>> 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 agree with the above approach. There is an MMTK api for copying a
> range of ref ptrs to the middle of a Java array object but I think we
> can ignore this api for starts. Its probably used by internal VM when
> it does a clone of an array of references. I iwll look into this
> later.
>
> We need to walk through the handling of all the arguments over the
> next few emails. Briefly, the JIT sees an ObjectReference as a
> standard, ordinary java object. An "Address" is basically a ref ptr
> that the JIT specifically does not enumerate. "Address" is protected
> from GC problems via the "Uninterruptible" interface. Basically any
> method that implements the Uninterruptible interface does not sprinkle
> GC polling back branch/ret code in the emitted stream. "Offset" is an
> integer that expresses the distance between a ref ptr and an interior
> ptr. Both ptrs point to the same object. There might be a hidden
> design constraint that object field layout does not change during
> execution (I have to think about this one).
>
> Real important. Before it makes sense to add MMTk write barrier to
> jitrino.JET, we need to add intrinsics to support MMTk vmmagic
> classes. More on intrinsics in later emails. Before we can run
> multithread java apps on MMTk, we need to get the JIT to emit
> back-branch gc polling code. More on this topic in a separate thread
> if you like.
>
>>
>> I can guess what 'src' is - this is the object being written, right ?
>> But could you please point me what all other args are ?
>> Can't we go without all the stuff and have only 2 args - an
>> object being written and the destination class/array/instance ? :-)
>
> Actually, the simplest form of write barrier would be one, single
> parameter -- a ref ptr to the object getting scribbled on. I suspect
> MMTk has such a wide, elaborate WB interface for two reasons. First,
> MMTk is a framework for developing a wide range of GC algorithms.
> They do not want to keep going back to the interface and tweaking it
> and adding "#ifdef special_case", etc. Second, MMTk is written in
> Java. An optimizing JIT will inline the WB code. Once inlined, an
> optimizing JIT will optimize away the unused parameters
>>
>>
>> --
>> Thanks,
>> Alex
>>
>>
>>
>> >
>> > Allowing the "java" write barrier to be selected on a method by method
>> > basis would be very useful for MMTk bring up. The concept is to
>> > initially run MMTK sort of like a "user mode linux". That is, startup
>> > the JVM w/o barriers turned on. Run "hello world". Then switch on
>> > MMTK collector/allocator and Java write barriers and compile/run the
>> > following method:
>> >
>> > public class InitialMMTkBringup {
>> >
>> > public int stressTheMMTkAllocator () {
>> > while(true) {
>> > Object obj = new Object();
>> > Object [] ia = new Object[100];
>> > //at a later stage, add code that causes a write barrier
>> > //at a later stage, add code that will randomly chain Object
>> > arrays together...
>> > }
>> > }
>> >
>> > The above would be running while the underlying JVM GC is running. If
>> > not careful this could cause lots of confusion. The intention is to
>> > run MMTk in "user mode" only to the point where MMTk alloc,
>> > collection, write barrier code paths are exercised. Provided we do
>> > not do anything to cause the underlying JVM GC to kick in, we should
>> > be OK.
>> >
>> > As a second step actually integrate MMTk into the JVM. Note that
>> > basic garden variety Java debugger should work w/o modification with a
>> > "user mode MMTk".
>> >
>> >
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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 design questions
Posted by Weldon Washburn <we...@gmail.com>.
Hi Alex,
Comment inline below.
On 6/27/06, Alex Astapchuk <al...@gmail.com> wrote:
> Weldon,
>
> Weldon Washburn wrote:
> > It would be really nice if jitrino.jet allowed the write barrier to be
> > selected at the start of jitting an individual method. Is this
> > possible?
> Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
> flags to instrument the jitted code.
I think you are referring to stuct OpenMethodExecutionParams{...} in
jit_export.h. I took a look, it seems like the right place to put the
switches that tell the compiler which write barrier to emit.
>
> >
> > The selections would be mutually exclusive:
> > 1)
> > no write barrier (for the existing GCV4)
> > 2)
> > write barrier written in Java (for MMTk)
> > 3)
> > write barrier written in C (for the yet to be determined basic
> > generational GC)
>
> VM (or ExectionManager) can signal which barrier to implement using
> the flags passed to JIT_compile_method.
> The current set of seems incomplete - for instance, it does not cover
> array manipulations. Also, we can't signal the difference you mention -
> WB4J or WB4C, but sure we can extend the set.
Yes, extend OpenMethodExecutionParams{...} This seems like a good idea.
>
> I have a look at the submitted patch for DRLVM (GC write barrier update
> patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
> seems it's only for interpreter.
Yes and no. The part that would be interesting to a compiler writer
targets an interpreter thus this patch is of limited interest.
However, the part that patches the VM is interesting to VM builders.
A side note. I looked at the patch for the VM code and can't help but
comment that the mods which add gc_write_barrier() to vm_arrays() look
to be redundant as gc_heap_wrote_object() is already called.
>
> If no one complains, I would like to implement the WB4J we are
> discussing here in .jet.
Go for it!
>
> As we currently don't have C-based GC with WB support (do we?),
Its a long, long story. For all intents and purposes, drlvm does not
yet have a quality "C" GC that requires a write barrier. I hope this
changes soon.
> for the first iteration I'm going to instrument code with WB4J in
> response to OpenMethodExecutionParams:: exe_insert_write_barriers.
Good idea! Write some code and post it to JIRA. Then I can give feedback.
> We can change this later then.
>
> Though I'm not familiar with MMTk, could please give me some clues ?
>
> 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 agree with the above approach. There is an MMTK api for copying a
range of ref ptrs to the middle of a Java array object but I think we
can ignore this api for starts. Its probably used by internal VM when
it does a clone of an array of references. I iwll look into this
later.
We need to walk through the handling of all the arguments over the
next few emails. Briefly, the JIT sees an ObjectReference as a
standard, ordinary java object. An "Address" is basically a ref ptr
that the JIT specifically does not enumerate. "Address" is protected
from GC problems via the "Uninterruptible" interface. Basically any
method that implements the Uninterruptible interface does not sprinkle
GC polling back branch/ret code in the emitted stream. "Offset" is an
integer that expresses the distance between a ref ptr and an interior
ptr. Both ptrs point to the same object. There might be a hidden
design constraint that object field layout does not change during
execution (I have to think about this one).
Real important. Before it makes sense to add MMTk write barrier to
jitrino.JET, we need to add intrinsics to support MMTk vmmagic
classes. More on intrinsics in later emails. Before we can run
multithread java apps on MMTk, we need to get the JIT to emit
back-branch gc polling code. More on this topic in a separate thread
if you like.
>
> I can guess what 'src' is - this is the object being written, right ?
> But could you please point me what all other args are ?
> Can't we go without all the stuff and have only 2 args - an
> object being written and the destination class/array/instance ? :-)
Actually, the simplest form of write barrier would be one, single
parameter -- a ref ptr to the object getting scribbled on. I suspect
MMTk has such a wide, elaborate WB interface for two reasons. First,
MMTk is a framework for developing a wide range of GC algorithms.
They do not want to keep going back to the interface and tweaking it
and adding "#ifdef special_case", etc. Second, MMTk is written in
Java. An optimizing JIT will inline the WB code. Once inlined, an
optimizing JIT will optimize away the unused parameters
>
>
> --
> Thanks,
> Alex
>
>
>
> >
> > Allowing the "java" write barrier to be selected on a method by method
> > basis would be very useful for MMTk bring up. The concept is to
> > initially run MMTK sort of like a "user mode linux". That is, startup
> > the JVM w/o barriers turned on. Run "hello world". Then switch on
> > MMTK collector/allocator and Java write barriers and compile/run the
> > following method:
> >
> > public class InitialMMTkBringup {
> >
> > public int stressTheMMTkAllocator () {
> > while(true) {
> > Object obj = new Object();
> > Object [] ia = new Object[100];
> > //at a later stage, add code that causes a write barrier
> > //at a later stage, add code that will randomly chain Object
> > arrays together...
> > }
> > }
> >
> > The above would be running while the underlying JVM GC is running. If
> > not careful this could cause lots of confusion. The intention is to
> > run MMTk in "user mode" only to the point where MMTk alloc,
> > collection, write barrier code paths are exercised. Provided we do
> > not do anything to cause the underlying JVM GC to kick in, we should
> > be OK.
> >
> > As a second step actually integrate MMTk into the JVM. Note that
> > basic garden variety Java debugger should work w/o modification with a
> > "user mode MMTk".
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> 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 design questions
Posted by Ivan Volosyuk <iv...@gmail.com>.
Alex,
The patch in HARMONY-504 works fine for C-based GC, it can have some
problems in Java-based GC. I'm also interested in WB4C support in jet
for experimenting. Currently, I use
http://issues.apache.org/jira/browse/HARMONY-581 to get that support.
--
thanks,
Ivan
On 6/27/06, Alex Astapchuk <al...@gmail.com> wrote:
> Weldon,
>
> Weldon Washburn wrote:
> > It would be really nice if jitrino.jet allowed the write barrier to be
> > selected at the start of jitting an individual method. Is this
> > possible?
> Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
> flags to instrument the jitted code.
>
> >
> > The selections would be mutually exclusive:
> > 1)
> > no write barrier (for the existing GCV4)
> > 2)
> > write barrier written in Java (for MMTk)
> > 3)
> > write barrier written in C (for the yet to be determined basic
> > generational GC)
>
> VM (or ExectionManager) can signal which barrier to implement using
> the flags passed to JIT_compile_method.
> The current set of seems incomplete - for instance, it does not cover
> array manipulations. Also, we can't signal the difference you mention -
> WB4J or WB4C, but sure we can extend the set.
>
> I have a look at the submitted patch for DRLVM (GC write barrier update
> patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
> seems it's only for interpreter.
>
> If no one complains, I would like to implement the WB4J we are
> discussing here in .jet.
>
> As we currently don't have C-based GC with WB support (do we?),
> for the first iteration I'm going to instrument code with WB4J in
> response to OpenMethodExecutionParams:: exe_insert_write_barriers.
> We can change this later then.
>
> Though I'm not familiar with MMTk, could please give me some clues ?
>
> 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 ?
> Can't we go without all the stuff and have only 2 args - an
> object being written and the destination class/array/instance ? :-)
>
>
> --
> Thanks,
> Alex
>
>
>
> >
> > Allowing the "java" write barrier to be selected on a method by method
> > basis would be very useful for MMTk bring up. The concept is to
> > initially run MMTK sort of like a "user mode linux". That is, startup
> > the JVM w/o barriers turned on. Run "hello world". Then switch on
> > MMTK collector/allocator and Java write barriers and compile/run the
> > following method:
> >
> > public class InitialMMTkBringup {
> >
> > public int stressTheMMTkAllocator () {
> > while(true) {
> > Object obj = new Object();
> > Object [] ia = new Object[100];
> > //at a later stage, add code that causes a write barrier
> > //at a later stage, add code that will randomly chain Object
> > arrays together...
> > }
> > }
> >
> > The above would be running while the underlying JVM GC is running. If
> > not careful this could cause lots of confusion. The intention is to
> > run MMTk in "user mode" only to the point where MMTk alloc,
> > collection, write barrier code paths are exercised. Provided we do
> > not do anything to cause the underlying JVM GC to kick in, we should
> > be OK.
> >
> > As a second step actually integrate MMTk into the JVM. Note that
> > basic garden variety Java debugger should work w/o modification with a
> > "user mode MMTk".
---------------------------------------------------------------------
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
Re: [drlvm/mmtk] jitrino.jet write barrier initial implementaion
Posted by Alex Astapchuk <al...@gmail.com>.
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 design questions
Posted by Robin Garner <ro...@anu.edu.au>.
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.
MetadataA and B were introduced to solve a problem in the JikesRVM opt
compiler. While I'm not sure of the details, they allow the compiler to
preserve type information across the write barrier call. Bottom line:
they're there for the compiler: don't need 'em, pass zeros.
>
> 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 ? :-)
>
These parameters support different styles of barrier. Some barriers
remember objects which have been mutated, then scan the object during a
minor GC; others remember the pointer itself, and avoid having to scan
(potentially large) objects - hence the need for the src and slot
parameters.
The mode parameter could potentially allow the two strategies to
coexist, by saving slots for address arrays (expensive to scan if big)
and objects for scalars. I don't think we do it, but it would be a
shame to make it impossible.
> 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".
>
I expect this is probably the approach you're taking, but I would do the
port by targeting the NoGC, MarkSweep, SemiSpace, CopyMS and GenMS
collectors in that order - the write barrier isn't needed then until the
very end.
> 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.
>
We also assume that the compiler will probably optimize all the
parameters away or into registers, so the # parameters shouldn't be a
performance issue.
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 design questions
Posted by Weldon Washburn <we...@gmail.com>.
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
>
>
--
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 design questions
Posted by Alex Astapchuk <al...@gmail.com>.
Weldon,
Weldon Washburn wrote:
> It would be really nice if jitrino.jet allowed the write barrier to be
> selected at the start of jitting an individual method. Is this
> possible?
Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
flags to instrument the jitted code.
>
> The selections would be mutually exclusive:
> 1)
> no write barrier (for the existing GCV4)
> 2)
> write barrier written in Java (for MMTk)
> 3)
> write barrier written in C (for the yet to be determined basic
> generational GC)
VM (or ExectionManager) can signal which barrier to implement using
the flags passed to JIT_compile_method.
The current set of seems incomplete - for instance, it does not cover
array manipulations. Also, we can't signal the difference you mention -
WB4J or WB4C, but sure we can extend the set.
I have a look at the submitted patch for DRLVM (GC write barrier update
patch for DRLVM - http://issues.apache.org/jira/browse/HARMONY-504), but
seems it's only for interpreter.
If no one complains, I would like to implement the WB4J we are
discussing here in .jet.
As we currently don't have C-based GC with WB support (do we?),
for the first iteration I'm going to instrument code with WB4J in
response to OpenMethodExecutionParams:: exe_insert_write_barriers.
We can change this later then.
Though I'm not familiar with MMTk, could please give me some clues ?
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 ?
Can't we go without all the stuff and have only 2 args - an
object being written and the destination class/array/instance ? :-)
--
Thanks,
Alex
>
> Allowing the "java" write barrier to be selected on a method by method
> basis would be very useful for MMTk bring up. The concept is to
> initially run MMTK sort of like a "user mode linux". That is, startup
> the JVM w/o barriers turned on. Run "hello world". Then switch on
> MMTK collector/allocator and Java write barriers and compile/run the
> following method:
>
> public class InitialMMTkBringup {
>
> public int stressTheMMTkAllocator () {
> while(true) {
> Object obj = new Object();
> Object [] ia = new Object[100];
> //at a later stage, add code that causes a write barrier
> //at a later stage, add code that will randomly chain Object
> arrays together...
> }
> }
>
> The above would be running while the underlying JVM GC is running. If
> not careful this could cause lots of confusion. The intention is to
> run MMTk in "user mode" only to the point where MMTk alloc,
> collection, write barrier code paths are exercised. Provided we do
> not do anything to cause the underlying JVM GC to kick in, we should
> be OK.
>
> As a second step actually integrate MMTk into the JVM. Note that
> basic garden variety Java debugger should work w/o modification with a
> "user mode MMTk".
>
>
---------------------------------------------------------------------
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