[aarch64-port-dev ] CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms

[Andrew Haley]

On 10/11/15 10:42, Edward Nevill wrote:
> On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote:
>> On 11/05/2015 01:25 PM, Bob Vandette wrote:
>>> This eliminates the possibility of using the Hotspot JIT (Just-in-
>>> time compiler) but since the Hotspot template interpreter is also
>>> dynamically generated, we can’t use that form of the interpreter.
>>> We have enhanced our closed ARM ports to statically generate the
>>> interpreter for iOS but since these sources are not available in the
>>> open source forest, we’ll use Zero initially to provide a working
>>> solution for the Mobile project.  I welcome the maintainers of the
>>> open aarch64 port to enhance that port to enable static code
>>> generation of your interpreter so that we won’t have to use Zero.
>>> The shared code changes required for static code generation has
>>> already been integrated into the JDK9 master sources.
>>
>> OK, thanks.  It's definitely worth us having a look at that.
> 
> One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to
> compile to some intermediate representation which would be more amenable
> to interpretation.
> 
> I am thinking of an intermediate representation where each
> opcode/operand pair is 128 bits and the dispatch code is simply.
> 
> ldp Ropcode, Roperand, [Rpc], #16
> br Ropcode
> 
> IE. The opecode is simply the address of a static routine to handle that
> opcode.

i.e. direct threaded code.

> I think it would be possible to get quite good performance using this
> technique, especially if you could statically compile longer code
> sequences based on profiling information.

Maybe, but I suspect it would be easier to write a JIT (C1 or C2)
back-end for this machine.  I expect that the real problem
performance-wise would be that you'd blow out the Dcache.

Andrew.