harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Date Thu, 21 Sep 2006 19:59:11 GMT
On 9/21/06, Mikhail Fursov <mike.fursov@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?
>
>
>
>
> On 9/21/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> >
> > Weldon Washburn wrote:
> > > On 9/20/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >>
> > >> I put the update into JIRA. This update still has a lot of bugs, but
> is
> > >> significantly more stable then the initial one.
> > >> My plan is to work on lock prefix support in Jitrino.OPTCG  tomorrow,
> > so
> > >> if
> > >> somebody is interested to enhance the current implementation there
> > >> will no
> > >> conflicts in our work.
> > >>
> > >> + There are several issues to discuss that are not clear to me:
> > >>
> > >> 1) Do we allow to save magic class into object fields? If yes, GC
> must
> > be
> > >> aware about magics and do not enumerate magic fields.
> > >
> > >
> > > Actually, the GC issues are taken care of at a higher level.  The
> > developer
> > > who is using vmmagics must extend the "Uninterruptible" class.
> >
> > That's not actually strictly true, there's also the
> > UninterruptiblePragma exception.  More generally, the burden is on the
> > programmer to ensure that objects that you hold an Address of don't move
> > while you hold the reference, and these pragmas are one method of doing
> > that.  You could also use locks etc (in theory at least).
> >
> > >
> > Another
> > > issue is that storing an unboxed object from vmmagic into an arbitrary
> > > object field has to be thought through very carefully by the
> > developer.  Or
> > > else there will be stale pointers running around that will cause hard
> > > crashes.  In any case it is not a JIT responsibility.  If the
> developer
> > > puts
> > > an object of type vmmagic Address in the heap then later retrieves a
> > stale
> > > pointer, disaster will hit.  I know because I have done this
> > accidentally.
> >
> > Magic loads and stores also don't trigger read/write barriers, so the
> > programmer needs to manually insert barriers if they would have been
> > called.
> >
> > > 4) Why do we need all of these types: Word, Offset, Extent if they are
> > all
> > >> just platform dependent unsigned integers? I understand that code of
> > >> garbage
> > >> collectors already uses these types and we must support them all, but
> > >> what
> > >> was the initial reason to introduce all of them?
> > >
> > >
> > > I thought the same thing when I first started working on MMTk
> port.  Now
> > I
> > > see there is benefit in the different types because it makes the code
> > > easier
> > > to read and also allows java type system to catch dumb errors that
> > > otherwise
> > > would be left to debugging stage.
> >
> > Once upon a time, magic fields were all just ints, and the present
> > variety evolved over time, precisely for this reason.
> >
> > An ObjectReference may seem mysterious to the casual observer (why don't
> > we just use Object ?).  This is present so that MMTk can support
> > languages other than Java (Haskell was my original target, and we have
> > done C#), and also so because the object model of the VM that executes
> > MMTk code may not necessarily be the same as the system that MMTk is
> > managing.
> >
> > So an ObjectReference is the 'moral equivalent' of an object.
> >
> > > Thats all for today. Will provide an update in a day or two.
> > >>
> > >>
> > >>
> > >> On 9/18/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > >> >
> > >> > On 9/18/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >> > >
> > >> > > All,
> > >> > > I'm working on the implementation of MMTk's
> > >> > > "org.vmmagic.unboxed<org/vmmagic/unboxed/package-frame.html>"
> > >> > > package functionality in Jitrino.OPT compiler.
> > >> > > If you are interested to participate in the development, I
> propose
> > to
> > >> > > discuss all details in this mail thread.
> > >> > >
> > >> > > The current state:
> > >> > > Part of the functionality of vmmagic package is done in the
> > >> magic1.patch
> > >> > .
> > >> > > See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489)
> > >> > >
> > >> > > Tasks that are not finished:
> > >> > > 1) Support of unsigned types.
> > >> > > 2) Support of atomic prepare/attempt operations
> > >> > > 3) Testing suit for vmmagic package.
> > >> > > 4) EM64T support
> > >> > >
> > >> > >
> > >> > > I hope items 1) and 2) will be finished in a week or even sooner
> if
> > >> > > someone
> > >> > > helps. After it's done the item 4) won't be a problem.
> > >> > > I think that the problem (at least for me) is item 3): we need
a
> > test
> > >> > > suite
> > >> > > for vmmagic package. I saw several tests in Weldon's
> > >> drlvm/trunk/vm/MMTk
> > >> > > folder, but this is not sufficient to cover the whole vmmagic
> > >> package.
> > >> > > Does
> > >> > > anyone know/can_write a reliability test suite for vmmagic we
can
> > use
> > >> in
> > >> > > Harmony?
> > >> >
> > >> >
> > >> >
> > >> > A regression test for vmmagic exists.  I have been trying to get it
> > >> > donated
> > >> > and posted to MMTk repository.  Its been a couple of months and no
> > >> > response.  I will find out if it can be donated to Apache.
> > >> >
> > >> > --
> > >> > > Mikhail Fursov
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Weldon Washburn
> > >> > Intel Middleware Products Division
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Mikhail Fursov
> > >>
> > >>
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message