AArch64: Status

[Christian Thalinger]

> On Feb 26, 2016, at 11:56 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 26/02/16 23:03, Christian Thalinger wrote:
> 
>> The assert suggests there is some code missing in the
>> DeoptimizationBlob.  Another way would be to implement
>> PreferGraalStubs=true and use these by default on AArch64.  That
>> would be my preferred way, actually, because the reason I introduced
>> DeoptimizationStub and UncommonTrapStub was to make porting to a new
>> architecture easier.  And this is one of these rare cases!
> 
> That solution makes sense to me.
> 
>> Also, I’m seeing issues with biased locking and method flushing very
>> likely related to stack walking.  Although garbage collections
>> seemingly do work.
>> 
>> Oh, and I haven’t implemented compressed oops yet (that’s the
>> low-hanging fruit!).
>> 
>> Anyway, I have to go off and work on something else for a while so
>> it would be great if other people could pick up some of the open
>> issues.
> 
> Sure.  My biggest problem with Graal has always been figuring out how
> to run and test it.  I have it all built, but it's very hard to get my
> head around what it's doing.  If you have a recipe with the right
> instructions about how to run the tests and reproduce the problems
> that would help a lot.

It’s basically the command at the end of my post:

$ mx unittest -XX:-UseCompressedOops bytecode.BC

Turn compressed oops on, run it and you will see a lot of exceptions.  Mostly the same, I would guess.

Some can be fixed locally on an x86 machine by doing:

$ mx unittest -Dos.arch=aarch64 -XX:-UseCompressedOops bytecode.BC

It will fail once it hits the code installer or a foreign call which needs some architecture specific information but for most missing LIR implementations this approach works.

The next big group is:

$ mx unittest -XX:-UseCompressedOops except.BC

(The last command line option is basically a substring match on all JUnit tests.  Check out the package com.oracle.graal.jtt.except)