Review Request: 6896043: Zero fixes

[Vladimir Kozlov]

Gary,

 >   hotspot/src/cpu/zero/vm/entry_zero.hpp:

To be clear. You did it to inline methods in debug VM version, right?
They will be optimized for optimized builds anyway.

 >   hotspot/src/cpu/zero/vm/frame_zero.hpp,
 >   hotspot/src/cpu/zero/vm/frame_zero.cpp:

Can you add at least an assert into sender_for_nonentry_frame() to
verify expected frame types?

 >
 >   hotspot/src/share/vm/runtime/os.hpp:

Can you explain why your changes is not the same as the comment says?:
((_mem_serialize_page ^ addr) & -pagesize) == 0

Thanks,
Vladimir

Gary Benson wrote:
> Hi all,
> 
> This last week I've spent some time going through all the patches
> in IcedTea and picking out the ones that affect Zero.  This webrev
> contains those, along with a fix for a build failure and a little
> bit of new code that's required for the latest Shark.
> 
>   http://cr.openjdk.java.net/~gbenson/zero-update-01-hs/
> 
> I've bundled them into one webrev, since each change is small, but
> if separate webrevs would be easier or better for you then let me
> know and I'll split it accordingly.
> 
> The changes are as follows:
> 
>   hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:
>     Add code to update the invocation counter for non-synchronized
>     native methods.  This causes Shark to generate wrappers for
>     hot methods, instead of using the interpreter entry.
> 
>   hotspot/src/cpu/zero/vm/entry_zero.hpp:
>     Inline a couple of methods.  This saves a frame every time the
>     interpreter calls a new Java method, and makes stack traces look
>     nicer in gdb.
> 
>   hotspot/src/cpu/zero/vm/frame_zero.hpp,
>   hotspot/src/cpu/zero/vm/frame_zero.cpp:
>     Zero has the same various frame::sender_for_${type}_frame methods
>     as the architecture-specific ports, but in Zero all frames are
>     handled identically except for entry frames.  This change replaces
>     most of the sender_for_${type}_frame with sender_for_entry_frame
>     and sender_for_nonentry_frame, simplifying the marshalling.  Adding
>     compiled native methods in Shark was going to introduce another
>     type of frame and so yet another sender_for_${type}_frame method
>     and I decided enough was enough :)
> 
>   hotspot/src/cpu/zero/vm/globals_zero.hpp:
>     Fix a build breakage introduced by 6887571.
> 
>   hotspot/src/cpu/zero/vm/sharedRuntime_zero.cpp:
>     Implemented SharedRuntime::generate_native_wrapper using Shark.
> 
>   hotspot/src/cpu/zero/vm/sharkFrame_zero.hpp:
>     Updated a friend declaration to match the latest version of Shark.
> 
>   hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
>     Fixed a bug where the invocation counter would be incremented
>     twice for backedges when not using Shark.  Fixed a bug where
>     SharedRuntime::OSR_migration_begin was incorrectly invoked
>     using CALL_VM.  Removed an old workaround that was causing
>     build failures on IA64.
> 
>   hotspot/src/share/vm/prims/jni.cpp:
>     Added an assertion to ensure Atomic::xchg and Atomic::xchg_ptr
>     are working correctly.  On most Zero platforms these are
>     implemented using a GCC intrinsic which *should* work as we
>     expect, but is allowed to only work for the values of 0 and 1
>     if that's all the platform can manage.
> 
>   hotspot/src/share/vm/prims/jvmtiManageCapabilities.cpp:
>     The C++ interpreter doesn't currently support JVMTI pop frame
>     or force early return messages.  This changes the capabilities
>     the VM reports to reflect that.
> 
>   hotspot/src/share/vm/runtime/os.hpp:
>     S390 rounds the addresses of segmentation faults to the nearest
>     page.  This changes os::is_memory_serialize_page to cope with
>     that.
> 
> Cheers,
> Gary
>