Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of mike.fursov@gmail.com
 designates 66.249.92.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=K2yFPwkQChcvXtWaACzn++OrmgxIuLzyBWSYZLNj1SFeIpWLl8ak7tZP63FzjwtbA/V07QQ6yQ+/T0fP6vNV/LL+wyMIuE1fL8MG3JHcIha8EiFvpltQgGWlb5TCzlwgz6rwVmGLAUUT4iAP1xE2qukZxU/MgMllYzylj/NO5qU=
Message-ID: <bc79dd600609210754k58e2c53fka63bc2f784cff3fb@mail.gmail.com>
Date: Thu, 21 Sep 2006 21:54:41 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT
 compiler
In-Reply-To: <4511DD57.9060405@anu.edu.au>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_913_17454387.1158850481450"
References: <bc79dd600609180815r3c33d9f4je85c192e730c9940@mail.gmail.com>
	 <4dd1f3f00609180856i5d5beb62wbee23aeb5789163d@mail.gmail.com>
	 <bc79dd600609200705l16da8876tef54828291ac64a6@mail.gmail.com>
	 <4dd1f3f00609200845i6a5f500cw48bc6d9df0c296c6@mail.gmail.com>
	 <4511DD57.9060405@anu.edu.au>

------=_Part_913_17454387.1158850481450
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_913_17454387.1158850481450--