[aarch64-port-dev ] AARCH64: Changes to HotSpot shared code

[Lindenmaier, Goetz]

Hi Andrew,

the change does not build as the file 
   sun.jvm.hotspot.debugger.MachineDescriptionAArch64.java
is missing.

If I add that file, I get                                                                                                   
   cc1plus: error: unrecognized command line option "-Wno-error=cpp"
We are using g++ 4.1.2.

Then I get 
  os_linux.cpp:1927: error: EM_AARCH64 was not declared in this scope
A few lines above it's dealt with a missing EM_486 definition.
I guess this should be fixed similarly.

After these fixes the change builds and runs on PPC nicely.

Considering the change in metaspace: I just proposed a similar change
for the java heap, see 
http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/

Don't you want to use 4*G << narrow_klass_shift() for alignment and
the test for zerobased compressed klasses?  That's what we enforce for
the heap. I think the shift is superior to movk, as it preserves 0
(which is rare for klass pointers, I admit).

And, could you add #if !defined(AARCH64) && !defined(PPC64) at this place?  We'll 
implement the optimized klass compression, too. ;)

In ci_LIR.hpp|cpp please use AARCH64 in #ifs.  

I would propose to add aarch stuff in alphabetical order
(or maybe establish alphabetical order where absent) whenever all cpus are 
listed (makefiles, os_linux, vm_version, ...)

Also, should we sort the cpu includes alphabetically at some point?

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
Sent: Dienstag, 11. November 2014 20:02
To: hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net
Subject: RFR: AARCH64: Changes to HotSpot shared code

http://cr.openjdk.java.net/~aph/aarch64-JDK-8064611/hotspot.patch

Everything except cpu/ and os_cpu/.

Most of this is obvious and trivial, with a few exceptions.

In memory/metaspace.cpp, we allocated the memory for metadata in a
different way.  This is because we want to be able to decode and
encode compressed metadata pointers with a single instruction, and we
can always do that iff the base address is of a particular form.

In opto/, we have made some changes in order to be able to use AArch64
store release instructions for volatile field stores.  These don't
require leading or trailing barriers.  We have tried several times to
do this without changing shared code, but it is impossible with the
current back-end interface.

In several places a release store is used where the AArch64 memory
model makes it unnecessary.  From earlier emails on this list we
discovered that the only architecture which requires this release
store is IA64, and OpenJDK does not support it anyway.  We should
perhaps look at re-engineering the way that memory barriers and memory
accesses are handled in HotSpot with a view to pushing all these
architecture-dependent assumptions out to the back ends.

Andrew.