You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Robin Garner <ro...@anu.edu.au> on 2006/09/22 01:28:36 UTC
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT
compiler
> On 9/21/06, Mikhail Fursov <mi...@gmail.com> wrote:
>>
>> Weldon, Robin
>> thank you for the comments.
>> There are just a few steps left to do before Jitrino.OPT will have
>> usable
>> "unboxed" package implementation.
>>
>> Right now I'm working on atomic operations (prepare/attempt pair), and I
>> do
>> not completely understand the semantic of the 'prepare' method.
>> The "prepareXYZ" method looks like a simple load and is not an atomic
>> operation by itself. Are there any examples that describe these
>> operations
>> in details?
>
>
>
> Robin will correct me if I am wrong.
>
> I think the idea is that this is a generic API intended to be used for
> accessing "compare and swap" facilities on a bunch of different hardware.
> And the actual hardware has different memory models, different CAS
> semantics, etc.
>
> Basically the generic facility needed is to first read the CAS target
> memory
> location (this is the "prepare"). If the memory is sitting at a specific
> value (this is the "do something"), then do an "attempt" as follows:
>
> old_contents = CAS(expected_specfic_value_that_I_just_read,
> some_new_value,
> target_memory_location)
>
> If the old_contents are identical to
> expected_specific_value_that_I_just_read, we know that the CAS succeeded.
> In other words, you won the competition. Otherwise you lost.
>
> I imagine the following situation in user's code:
>>
>> prepareXYZ()
>> do something
>> attempt()
>>
>> Is this code correct?
>>
You're correct.
The prepare/attempt was designed to match architectures (PPC, Alpha ...)
with a load-locked/store-conditional instruction pair.
The standard code fragment for a synchronized update is
do {
oldVal = x.prepare();
newVal = f(oldVal);
} while (!x.attempt(oldVal,newVal));
As an aside, vmmagic should probably have CAS as a primitive rather than
prepare/attempt, but I don't think that's going to happen in the immediate
future.
cheers
---------------------------------------------------------------------
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][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Posted by Weldon Washburn <we...@gmail.com>.
Mikhail,
I just now committed magic5.diff, H1489. Let me know when the next JIRA is
ready. I want your mods committed so that I can resume MMTk integration.
Thanks
Weldon
On 10/2/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> I forgot to test the last patch on Linux.
> Now the build is fixed for Linux too and I attached to the H1489 the new
> patch: 'magic5.diff'
>
> On 10/2/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >
> > On 9/30/06, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > Good! I look forward to seeing vm helpers written in vmmagic.
> > >
> > > Yes, this is the final goal and I hope we will start the
> implementation
> > of VM helpers using magics package this week. The only item left to do
> is to
> > restore JET support for your experiments with GC. I'm going to commit
> the
> > patch in a day.
> >
> > Weldon,
> > I finished vmmagic implementation in OPT compiler and there are no known
> > bugs left.
> > I tested the code with Eclipse and several benchmarks - nothing is
> broken,
> > all applications work OK.
> > Could I ask you to add the 'magics' support code into the trunk? The
> patch
> > name is ' magic4.diff' in H1489
> >
> > --
> > Mikhail Fursov
>
>
>
>
> --
> Mikhail Fursov
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Posted by Mikhail Fursov <mi...@gmail.com>.
I forgot to test the last patch on Linux.
Now the build is fixed for Linux too and I attached to the H1489 the new
patch: 'magic5.diff'
On 10/2/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 9/30/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Good! I look forward to seeing vm helpers written in vmmagic.
> >
> > Yes, this is the final goal and I hope we will start the implementation
> of VM helpers using magics package this week. The only item left to do is to
> restore JET support for your experiments with GC. I'm going to commit the
> patch in a day.
>
> Weldon,
> I finished vmmagic implementation in OPT compiler and there are no known
> bugs left.
> I tested the code with Eclipse and several benchmarks - nothing is broken,
> all applications work OK.
> Could I ask you to add the 'magics' support code into the trunk? The patch
> name is ' magic4.diff' in H1489
>
> --
> Mikhail Fursov
--
Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Posted by Mikhail Fursov <mi...@gmail.com>.
On 9/30/06, Weldon Washburn <we...@gmail.com> wrote:
>
> Good! I look forward to seeing vm helpers written in vmmagic.
>
> Yes, this is the final goal and I hope we will start the implementation of
VM helpers using magics package this week. The only item left to do is to
restore JET support for your experiments with GC. I'm going to commit the
patch in a day.
Weldon,
I finished vmmagic implementation in OPT compiler and there are no known
bugs left.
I tested the code with Eclipse and several benchmarks - nothing is broken,
all applications work OK.
Could I ask you to add the 'magics' support code into the trunk? The patch
name is 'magic4.diff' in H1489
--
Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Posted by Weldon Washburn <we...@gmail.com>.
On 9/29/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> All,
> I finished 'unboxed' package implementation in Jitrino.OPT. The patch is
> in
> JIRA 1489
> The potential problems:
> 1) We still do not have a test suite.
Hmmm... I fixed up the vmmagic test suite and gave it back to the owners .
It should be donated to open source soon.
2) Two bugs in Jitrino.OPT CG prevents us from use load/store by offset
> operations sometimes. I going to fix both of these bugs on Monday.
>
> Anyway, I think we will be ready to write helpers with 'magics' next week.
Good! I look forward to seeing vm helpers written in vmmagic.
On 9/22/06, Robin Garner <ro...@anu.edu.au> wrote:
> >
> > > On 9/21/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > >>
> > >> Weldon, Robin
> > >> thank you for the comments.
> > >> There are just a few steps left to do before Jitrino.OPT will have
> > >> usable
> > >> "unboxed" package implementation.
> > >>
> > >> Right now I'm working on atomic operations (prepare/attempt pair),
> and
> > I
> > >> do
> > >> not completely understand the semantic of the 'prepare' method.
> > >> The "prepareXYZ" method looks like a simple load and is not an atomic
> > >> operation by itself. Are there any examples that describe these
> > >> operations
> > >> in details?
> > >
> > >
> > >
> > > Robin will correct me if I am wrong.
> > >
> > > I think the idea is that this is a generic API intended to be used for
> > > accessing "compare and swap" facilities on a bunch of different
> > hardware.
> > > And the actual hardware has different memory models, different CAS
> > > semantics, etc.
> > >
> > > Basically the generic facility needed is to first read the CAS target
> > > memory
> > > location (this is the "prepare"). If the memory is sitting at a
> > specific
> > > value (this is the "do something"), then do an "attempt" as follows:
> > >
> > > old_contents = CAS(expected_specfic_value_that_I_just_read,
> > > some_new_value,
> > > target_memory_location)
> > >
> > > If the old_contents are identical to
> > > expected_specific_value_that_I_just_read, we know that the CAS
> > succeeded.
> > > In other words, you won the competition. Otherwise you lost.
> > >
> > > I imagine the following situation in user's code:
> > >>
> > >> prepareXYZ()
> > >> do something
> > >> attempt()
> > >>
> > >> Is this code correct?
> > >>
> >
> > You're correct.
> >
> > The prepare/attempt was designed to match architectures (PPC, Alpha ...)
> > with a load-locked/store-conditional instruction pair.
> >
> > The standard code fragment for a synchronized update is
> >
> > do {
> > oldVal = x.prepare();
> > newVal = f(oldVal);
> > } while (!x.attempt(oldVal,newVal));
> >
> > As an aside, vmmagic should probably have CAS as a primitive rather than
> > prepare/attempt, but I don't think that's going to happen in the
> immediate
> > future.
> >
> > cheers
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Mikhail Fursov
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Posted by Mikhail Fursov <mi...@gmail.com>.
All,
I finished 'unboxed' package implementation in Jitrino.OPT. The patch is in
JIRA 1489
The potential problems:
1) We still do not have a test suite.
2) Two bugs in Jitrino.OPT CG prevents us from use load/store by offset
operations sometimes. I going to fix both of these bugs on Monday.
Anyway, I think we will be ready to write helpers with 'magics' next week.
On 9/22/06, Robin Garner <ro...@anu.edu.au> wrote:
>
> > On 9/21/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >>
> >> Weldon, Robin
> >> thank you for the comments.
> >> There are just a few steps left to do before Jitrino.OPT will have
> >> usable
> >> "unboxed" package implementation.
> >>
> >> Right now I'm working on atomic operations (prepare/attempt pair), and
> I
> >> do
> >> not completely understand the semantic of the 'prepare' method.
> >> The "prepareXYZ" method looks like a simple load and is not an atomic
> >> operation by itself. Are there any examples that describe these
> >> operations
> >> in details?
> >
> >
> >
> > Robin will correct me if I am wrong.
> >
> > I think the idea is that this is a generic API intended to be used for
> > accessing "compare and swap" facilities on a bunch of different
> hardware.
> > And the actual hardware has different memory models, different CAS
> > semantics, etc.
> >
> > Basically the generic facility needed is to first read the CAS target
> > memory
> > location (this is the "prepare"). If the memory is sitting at a
> specific
> > value (this is the "do something"), then do an "attempt" as follows:
> >
> > old_contents = CAS(expected_specfic_value_that_I_just_read,
> > some_new_value,
> > target_memory_location)
> >
> > If the old_contents are identical to
> > expected_specific_value_that_I_just_read, we know that the CAS
> succeeded.
> > In other words, you won the competition. Otherwise you lost.
> >
> > I imagine the following situation in user's code:
> >>
> >> prepareXYZ()
> >> do something
> >> attempt()
> >>
> >> Is this code correct?
> >>
>
> You're correct.
>
> The prepare/attempt was designed to match architectures (PPC, Alpha ...)
> with a load-locked/store-conditional instruction pair.
>
> The standard code fragment for a synchronized update is
>
> do {
> oldVal = x.prepare();
> newVal = f(oldVal);
> } while (!x.attempt(oldVal,newVal));
>
> As an aside, vmmagic should probably have CAS as a primitive rather than
> prepare/attempt, but I don't think that's going to happen in the immediate
> future.
>
> cheers
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Mikhail Fursov