harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Date Thu, 21 Sep 2006 14:54:41 GMT
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?


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.OPT CG  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

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