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 Wed, 20 Sep 2006 15:45:08 GMT
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.  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.

2) Do we allow to a method to return a magic class?


Yes.  We also allow vmmagic parameters.  You might want to take a look at
Jitrino.JET to see what needs to be supported.

3) Do we allow to a method to accept a magic class as a parameter? If yes,
> we need some modifications in VM code.


I know.  I stumbled on this the hard way.  I have patches for this in JIRA
Harmony-1260.  I have not committed this code yet.  Its a very heavily used
code path  and I want someone else to try it to make sure it won't disrupt
anything before I commit it.



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.

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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

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