RFR: 143072: [JVMCI] Port JVMCI to AArch64

[Christian Thalinger]

> On Dec 20, 2015, at 11:14 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 21/12/15 06:42, Christian Thalinger wrote:
>> Alright, here is what I would like to integrate:
>> 
>> http://cr.openjdk.java.net/~twisti/8143072/webrev.01/
>> 
>> There are not many source changes but I wanted to send a webrev
>> anyway.
>> 
>> You will notice that the test changes are gone.  That’s because of
>> the unfortunate situation with the open and closed AArch64 port.
>> Before I haven’t found a way to reuse the open AArch64 JVMCI changes
>> with our closed port I can’t enable the tests on AArch64 because we
>> would see all of them fail.  And I really want to avoid to copy the
>> files verbatim into our closed port.
> 
> Needs must, I guess.  It's a silly situation, but we are where we are.
> :-)
> 
> I kinda assumed that the proprietary AArch64 port had a different name
> internally, ARM64 or something.  We are going to have to fix this
> somehow.

It does have a different name in the build system but not in jtreg.

Anyway, I think I found a solution we can use for now.  I sorted out the build issues and since all existing tests (except the ones from 8144704 which do not run on AArch64, yet) only need the Java part of JVMCI we are good.  Also, I noticed you pulled the CodeInstaller changes in your latest webrev.

Here is my webrev:

http://cr.openjdk.java.net/~twisti/8143072/webrev.02/

While doing all these changes I realized it would be better to move the _features/_cpuFeatures fields up into the parent class Abstract_VM_Version:

http://cr.openjdk.java.net/~twisti/8143072/webrev.02/src/share/vm/runtime/vm_version.hpp.udiff.html

and use that on all platforms.  Internally we discussed if the name should contain “cpu” and we ended up deciding to not do it but instead file an Enhancement to move the CPU features logic into a separate class:

https://bugs.openjdk.java.net/browse/JDK-8145956

A JPRT job is running right now to verify I didn’t break anything.

> 
> Andrew.
> 
>