JDK-8226287 : Make process_users_of_allocation handle gc barriers
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2019-06-18
  • Updated: 2019-08-15
  • Resolved: 2019-07-01
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 13 JDK 14
13 b28Fixed 14Fixed
Related Reports
Duplicate :  
Relates :  
Description
vmTestbase/metaspace/stressHierarchy/stressHierarchy005/TestDescription.java crashed:

hierarchyType = MIXED
attemptsLimit = 50
unloadingPause = 1000
pausesLimit = 5
treeDepth=70, minLevelSize=10, maxLevelSize=100, hierarchyType=MIXED, triggerUnloadingHelper.getClass().getName()=vm.share.gc.TriggerUnloadingWithWhiteBox
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007feca4a6e2b0, pid=29347, tid=29370
#
# JRE version: Java(TM) SE Runtime Environment (14.0+2) (build 14-ea+2-12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14-ea+2-12, mixed mode, tiered, z gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xc152b0]  PhaseIterGVN::remove_globally_dead_node(Node*)+0xb0
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
Unsupported internal testing APIs have been used.

# An error report file with more information is saved as:
# testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_vm_metaspace/scratch/0/hs_err_pid29347.log
#
# Compiler replay data is saved as:
# testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_vm_metaspace/scratch/0/replay_pid29347.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
http://cr.openjdk.java.net/~neliasso/8226287/webrev.02/
28-06-2019

http://cr.openjdk.java.net/~neliasso/8226287/webrev.01/
19-06-2019

The problem is that we've passing NULL to PhaseIterGVN::remove_globally_dead_node(), via igvn.remove_dead_node(). It looks like that can happen here: void ZBarrierSetC2::expand_loadbarrier_node(PhaseMacroExpand* phase, LoadBarrierNode* barrier) const { ... Node* out_ctrl = barrier->proj_out_or_null(LoadBarrierNode::Control); ... if (out_ctrl != NULL) { igvn.replace_node(out_ctrl, result_region); } .... igvn.remove_dead_node(out_ctrl); ... } We have a NULL check on the call to igvn.replace_node() but _not_ on the call to igvn.remove_dead_node(). I.e. we should do: if (out_ctrl != NULL) { igvn.remove_dead_node(out_ctrl); }
18-06-2019

Probably related to JDK-8224675. Nils, could you please have a look?
18-06-2019