harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM] MMTK porting issues, take one
Date Thu, 15 Jun 2006 07:11:39 GMT
Rodrigo Kumpera wrote:
> 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.
Not just the allocation fast path, but that's the idea.  The pragmas are 
probably most important in the write barriers, where both the 
InlinePragma and NoInlinePragma are important (see "In or Out? Putting 
write barriers in their place.", Blackburn & McKinley, ISMM '02). 
>> 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?
I think the comment is actually incorrect.


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

View raw message