JDK-8013036 : vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-04-23
  • Updated: 2014-10-09
  • Resolved: 2013-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8010862 - The Method counter fields used for profiling can be allocated lazily
Description
many tests trigger assert in Comp_Baseline-Tiered-2013-04-22 on solaris-sparc:

;; Using jvm: "/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/comp_baseline/solaris-sparc/jre/lib/sparc/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/172708.amurillo/s/src/share/vm/runtime/simpleThresholdPolicy.cpp:157), pid=3172, tid=2
#  assert(mcs != NULL) failed: 
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b85) (build 1.8.0-ea-fastdebug-b85)
# Java VM: Java HotSpot(TM) Server VM (25.0-b30-internal-201304191727.amurillo.hs25-b30-comp-sync-fastdebug mixed mode solaris-sparc )
# Core dump written. Default location: /export/local/aurora/sandbox/results/ResultDir/tc01x002_copy_1/core or core.3172
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Stack: [0xfd370000,0xfd3f0000],  sp=0xfd3eedf8,  free space=507k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x100a530]  void VMError::report_and_die()+0x7d4;;  __1cHVMErrorOreport_and_die6M_v_+0x7d4
V  [libjvm.so+0x65689c]  void report_vm_error(const char*,int,const char*,const char*)+0x74;;  __1cPreport_vm_error6Fpkci11_v_+0x74
V  [libjvm.so+0xe897c4]  void SimpleThresholdPolicy::handle_counter_overflow(Method*)+0x40;;  __1cVSimpleThresholdPolicyXhandle_counter_overflow6MpnGMethod__v_+0x40
V  [libjvm.so+0xe87824]  nmethod*SimpleThresholdPolicy::event(methodHandle,methodHandle,int,int,CompLevel,nmethod*,JavaThread*)+0x84;;  __1cVSimpleThresholdPolicyFevent6MnMmethodHandle_1iinJCompLevel_pnHnmethod_pnKJavaThread__4_+0x84
V  [libjvm.so+0x8adf60]  nmethod*InterpreterRuntime::frequency_counter_overflow_inner(JavaThread*,unsigned char*)+0x524;;  __1cSInterpreterRuntimebGfrequency_counter_overflow_inner6FpnKJavaThread_pC_pnHnmethod__+0x524
V  [libjvm.so+0x8ad840]  nmethod*InterpreterRuntime::frequency_counter_overflow(JavaThread*,unsigned char*)+0x28;;  __1cSInterpreterRuntimebAfrequency_counter_overflow6FpnKJavaThread_pC_pnHnmethod__+0x28
Comments
When TieredCompilation is enabled, in InterpreterGenerator::generate_counter_incr() (templateInterpreter_sparc.cpp, line 300~315), it increments the MethodData::invocation_counter only and done. The invocation_counter originally in Method, now in MethodCounters is never updated if MethodData already exists, hence the MethodCounters object is never created. The MethodCounters is only created when one of the counter fields is updated the first time in order to save memory. In that case the MethodCounters can be NULL when SimpleThresholdPolicy::handle_counter_overflow is called under TieredCompilation.
26-04-2013
issue affects a lot of test on all platfroms => P1
26-04-2013
The assert(!m->was_never_executed()) looks very strange. It seems to be an unrelated issue. The NonTieredCompPolicy::reset_counter_for_invocation_event() sets the invocation_counter carry bit before the !m->was_never_executed() check. The check should always succeed as the carry bit is set. Looking at the InvocationCounter code, the 'count', 'carry' and 'state' are encoded using single 32-bit integer. The operations on the 'count', 'carry' and 'state' do not look thread safe. Looks like the same issue has been reported by JDK-7115356.
25-04-2013
Reproduced on sparcv9. Debugging the core dump, I see the MethodData::invocation_counter limit has reached for the method on method entry, hence it jumped to frequency_counter_overflow. %g is 1025ULL. At this time, the methodCounters is not yet created. 0xffffffff6a025700: ldsw [ %g4 + 0x6c ], %g3 0xffffffff6a025704: add %g3, 8, %g3 0xffffffff6a025708: btst 0x3f8, %g3 0xffffffff6a02570c: be,pn %icc, 0xffffffff6a02615c 0xffffffff6a025710: st %g3, [ %g4 + 0x6c ] 0xffffffff6a025714: b %icc, 0xffffffff6a0259e8 0xffffffff6a025718: nop Checking the method data also confirms that. So when SimpleThresholdPolicy::handle_counter_overflow() is called, it's possible that the methodCounters is NULL. (dbx) print *method *method = { _constMethod = 0xffffffff7a08c860 _method_data = 0xffffffff7a2808e0 _method_counters = (nil) _access_flags = { _flags = 1 } _vtable_index = -2 _method_size = 12U _intrinsic_id = '���' _jfr_towrite = '\0' _caller_sensitive = '\0' _force_inline = '\0' _hidden = '\0' _dont_inline = '\0' _compiled_invocation_count = 0 _i2i_entry = 0xffffffff6a0254c0 "��A`(\x80\x88��" _adapter = 0x1003f1778 _from_compiled_entry = 0xffffffff6a0db34c "��Y`P^B����^V^A" _code = (nil) _from_interpreted_entry = 0xffffffff6a0254c0 "��A`(\x80\x88��" } (dbx) print *(method->_method_data) *method->_method_data = { _method = 0xffffffff7a08c8c0 _size = 192 _hint_di = 0 _nof_decompiles = 0 _nof_overflow_recompiles = 0 _nof_overflow_traps = 0 _trap_hist = { _align = 0 _array = "" } _eflags = 0 _arg_local = 0 _arg_stack = 0 _arg_returned = 0 _creation_mileage = 0 _invocation_counter = { _counter = 1025U InterpreterInvocationLimit = 80000 InterpreterBackwardBranchLimit = 10700 InterpreterProfileLimit = 26400 _init = (0, 0) _action = (0xffffffff7e0ffb60 = &`libjvm.so`invocationCounter.cpp`do_nothing(methodHandle,Thread*), 0xffffffff7e0ffc50 = &`libjvm.so`invocationCounter.cpp`do_decay(methodHandle,Thread*)) } _backedge_counter = { _counter = 1U InterpreterInvocationLimit = 80000 InterpreterBackwardBranchLimit = 10700 InterpreterProfileLimit = 26400 _init = (0, 0) _action = (0xffffffff7e0ffb60 = &`libjvm.so`invocationCounter.cpp`do_nothing(methodHandle,Thread*), 0xffffffff7e0ffc50 = &`libjvm.so`invocationCounter.cpp`do_decay(methodHandle,Thread*)) } _invocation_counter_start = 0 _backedge_counter_start = 0 _num_loops = 0 _num_blocks = 0 _highest_comp_level = '\0' _highest_osr_comp_level = '\0' _would_profile = true _data_size = 16 _data = (144115196665790464)
25-04-2013
Hi Vlad, I'm looking at this issue currently. I have some suspects but not confirmed. I'll keep you updated. Thanks.
24-04-2013
Jiangli, any progress on this? Any suggested fix. I can't run nashorn with Tiered and we get Nightly failures.
24-04-2013