You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/06/02 07:41:22 UTC
[DRLVM] MMTK porting issues, take one
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?
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?
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.
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
Re: [DRLVM] MMTK porting issues, take one
Posted by Robin Garner <ro...@anu.edu.au>.
Rodrigo Kumpera wrote:
> On 6/2/06, Weldon Washburn <we...@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?
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.
cheers
---------------------------------------------------------------------
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
Re: [DRLVM] MMTK porting issues, take one
Posted by Rodrigo Kumpera <ku...@gmail.com>.
On 6/2/06, Weldon Washburn <we...@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