harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rodrigo Kumpera" <kump...@gmail.com>
Subject Re: [DRLVM] MMTK porting issues, take one
Date Fri, 02 Jun 2006 14:00:04 GMT
On 6/2/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> All,
>
> Perhaps the following is already covered in documentation.  If this is
> the case, please tell me where to find it.  Below are some initial
> questions regarding porting MMTK to DRLVM.
>
> A question about org.vmmagic.pragma.InlinePragma class.  The comments
> in the code says, "This pragma indicates that a particular method
> should always be inlined by the optimizing compiler."  Just to be
> clear, will there be any correctness issues if a non-optimizing
> compiler does not do any inlining?

AFAIK the inline pragmas are used to clearly define the alocation fast
path for the optimizing compiler.

> It looks like we have to get Jitrino.JET to generate "funny" binaries
> for all the classes in the org.vmmagic.unboxed package.  Is this
> correct?  Are there any other packages that bend the type safety rules
> we need to worry about?

The magic types are how the MMTK does pointer operations and unsigned
math, the compiler must emit special code for the methods and statics
of these classes. Actually it's pretty easy to emit such code from a
non-optimizing compiler.

> It looks like org.vmmagic.unboxed.Extent needs the JIT to specifically
> emit instructions that do unsigned arithmetic.  Is this correct?
>
> A question on org.vmmagic.unboxed.ObjectReference class --- there is a
> comment that says, "Note: this is a JikesRVM specific extension to
> vmmagic."  But a grep of MMTK source shows hundreds of uses of this
> class.  Does the comment mean that MMTK should not use ObjectReference
> class?  Or maybe in the future MMTK will not use ObjectReference
> class?
>
> Should I ignore
> /rvm/src/vm/arch/intel/compilers/baseline/writeBarrier/VM_Barriers.java?
>  Just guessing that this code is intended to be called by a
> not-so-optimizing compiler.  This class has a method called
> compilePutfieldBarrier that emits binary code that calls a vm entry
> point that apparently does the write barrier.

This is JikesRVM specific code.

> Thanks
> --
> Weldon Washburn
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> 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
>
>

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


Mime
View raw message