...
As the VM the PPC port is derived from is targeted to long running server applications, it utilizes the optimizing C2 compiler, assuming most code is compiled at some point making interpreter performance irrelevant. To simplify porting it uses the C interpreter. Still, to get maximal performance, it supports many optimizations implemented in HotSpot, as compressed oops and biased locking. Therefore we extended the C interpreter to support these.
...
To support G1 garbage collection, we call obj_at_put() in the aastore bytecode, instead of doing the store and barrier operations locally. This This takes care of the different GC requirements.
http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/rev/684e6ea70669
...
We follow two different strategies with releasing of store operations. On IA64 we user use releasing store operations for all stores into the Java Heap. This guarantees that everybody using a reference sees a fully initialized object. This performs better than executing memory barriers.
...
HotSpot can compile a method that is stuck in a hot loop, and switch to the compiled method while the method is interpreted. This This technique is called on stack replacement (OSR).
...
We implemented the profiling calls in a separate file bytecodeInterpreterProfiling.hpp. It's incorporated in the interpreter via Macros, so that the functionality can be disabled by a simple preprocessor flag. For VMs using the interpreter without the C2 compiler it's essential to remove the profiling code, as it costs considerable interpreter runtime. Currently Currently we guard this by #ifdef PPC64, it might be better to use COMPILER2.
...
Overview
Content Tools
ThemeBuilder