RFR (XL) 8031320: Use Intel RTM instructions for locks

[Daniel D. Daugherty]

On 3/19/14 11:26 PM, Vladimir Kozlov wrote:
> Thank you, Dan
>
> I updated webrev.01 with your and last Igor's suggestions. See my 
> other mail with description of changes in it (mostly refactoring in 
> macroAssembler_x86.cpp).
>
> http://cr.openjdk.java.net/~kvn/8031320_9/webrev.01/
>

src/share/vm/runtime/rtmLocking.hpp
     line 88: static uintx* rtm_calculation_flag_adr() { return 
&_calculation_flag; }
         Typo: 'rtm_calculation_flag_adr' -> 'rtm_calculation_flag_addr'

src/cpu/x86/vm/rtmLocking.cpp
     No comments.

src/share/vm/utilities/globalDefinitions.hpp
     No comments.

src/share/vm/runtime/arguments.cpp
     No comments.

src/share/vm/runtime/deoptimization.hpp
     No comments.

src/share/vm/runtime/deoptimization.cpp
     No comments.

src/share/vm/runtime/java.cpp
     No comments.

src/share/vm/runtime/task.cpp
     No comments.

src/share/vm/runtime/thread.cpp
     No comments.

src/cpu/x86/vm/globals_x86.hpp
     No comments.

src/cpu/x86/vm/vm_version_x86.hpp
     No comments.

src/cpu/x86/vm/vm_version_x86.cpp
     No comments.

src/cpu/x86/vm/assembler_x86.hpp
     No comments.

src/cpu/x86/vm/assembler_x86.cpp
     line 3040: void Assembler::xend() {
         nit: Looks like these functions are in alpha order so xend()
         should be before xgetbv(). Sorry I missed this in the previous
         round.

src/cpu/x86/vm/macroAssembler_x86.hpp
     No comments.

src/cpu/x86/vm/macroAssembler_x86.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_32.cpp
     Like the new xabort() comments. Thanks!

src/cpu/x86/vm/sharedRuntime_x86_64.cpp
     Like the new xabort() comments. Thanks!

src/cpu/x86/vm/x86_32.ad
     No comments.

src/cpu/x86/vm/x86_64.ad
     No comments.

src/share/vm/adlc/output_c.cpp
     No comments.

src/share/vm/ci/ciEnv.hpp
     No comments.

src/share/vm/ci/ciMethodData.hpp
     No comments.

src/share/vm/ci/ciEnv.cpp
     No comments.

src/share/vm/code/nmethod.hpp
     No comments.

src/share/vm/code/nmethod.cpp
     No comments.

src/share/vm/oops/methodData.hpp
     No comments.

src/share/vm/oops/methodData.cpp
     No comments.

src/share/vm/oops/method.cpp
     Not RTM related, but an improved error mesg. OK.

src/share/vm/opto/c2_globals.hpp
     No comments.

src/share/vm/opto/classes.hpp
     No comments.

src/share/vm/opto/compile.hpp
     No comments.

src/share/vm/opto/compile.cpp
     No comments.

src/share/vm/opto/connode.hpp
     No comments.

src/share/vm/opto/graphKit.cpp
     line 3154: if (UseBiasedLocking && 
PrintPreciseBiasedLockingStatistics) {
         This looks like another more general fix that should be
         backported.

     line 3160: flock->create_rtm_lock_counter(sync_jvms()); // 
sync_jvms used to get current bci
         Why are the counters always created?

src/share/vm/opto/locknode.hpp
     No comments.

src/share/vm/opto/locknode.cpp
     No comments.

src/share/vm/opto/loopTransform.cpp
     No comments.

src/share/vm/opto/machnode.hpp
     No comments.

src/share/vm/opto/macro.hpp
     The placement of the new _has_locks field seems strange.
     Other fields are above the functions.

src/share/vm/opto/macro.cpp
     No comments.

src/share/vm/opto/parse.hpp
     No comments.

src/share/vm/opto/parse1.cpp
     No comments.

src/share/vm/opto/runtime.hpp
     line 90: assert(_next == NULL || next == NULL, "already set");
         This looks like another more general fix that should be
         backported.

src/share/vm/opto/runtime.cpp
     line 1360   } else if (tag == NamedCounter::RTMLockingCounter) {
     line 1361     c = new RTMLockingNamedCounter(strdup(st.as_string()));
         Previous new code is in #if INCLUDE_RTM_OPT ... #endif
         Is there some reason for the difference?

     line 1370:  c->set_next(NULL);
         This looks like another more general fix that should be
         backported.

src/share/vm/opto/type.cpp
     line 4383: return make(ptr, _metadata, offset);
         This does not seem to be RTM related and I don't see that
         file modified in the original webrev. Is this an unrelated
         change that managed to sneak in?

Dan