JDK-5003419 : empty blocks sometimes produce unnecessary jumps
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2004-02-25
  • Updated: 2005-07-13
  • Resolved: 2005-07-13
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.
6 b43Fixed
Related Reports
Relates :  
Relates :  
Relates :  
While looking at another bug I was reading the PrintOptoAssembly from the test case and noticed quite a few empty blocks which ended up only containing jumps.  This resulted in a quite a few cases where the code jumped away and then jumped back for no purpose.  The blocks apparently contains at least some memory merge state so they aren't trivially removeable but they should be removeable somehow, even by simply fixing the block layout to avoid the jump.  I don't know what impact these extra blocks have on real programs but they seem to occur fairly often so it's worth investigating more closely.  The following awk script will detect them in opto assembly output.

/::/ && $NF ~ /bytes\)/ {
  method = $(NF-2);

$2 ~ "B[0-9][0-9]*:" {
  block = $0;
  if ($3 == "BA") {
    branch = $0;
    if (NF == 1) {
      if (method != lastmethod) {
        print "found " count;
        print "";
        print method;
        lastmethod = method;
        count = 0;
      print block;
      print branch;
  print jtoj " jump to jumps found in total";

For a specjvm98 -Xmixed run with -m1 -M1 it found 1634 of these jump to jump blocks.

The top 20 method in terms of empty blocks found are:

spec.benchmarks._228_jack.Jack_the_Parser_Generator::_Jack3regular_expression found 118
spec.benchmarks._228_jack.Jack_the_Parser_Generator::_Jack3complex_regular_expression_unit found 100
spec.benchmarks._228_jack.Jack_the_Parser_Generator::_Jack3expansion_unit found 80
spec.benchmarks._228_jack.ParseGen::buildPhase3Routine found 43
spec.benchmarks._228_jack.ParseGen::phase1ExpansionGen found 34
spec.benchmarks._228_jack.NfaState::GenerateCode found 34
spec.benchmarks._213_javac.Parser::parseExpression found 31
spec.benchmarks._213_javac.Parser::parseStatement found 30
spec.benchmarks._228_jack.Jack_the_Parser_Generator::_Jack3character_list found 27
spec.benchmarks._213_javac.Parser::parseTerm found 27
spec.benchmarks._213_javac.ConvertExpression::simplify found 26
spec.benchmarks._213_javac.Parser::parseTerm found 25
spec.benchmarks._213_javac.Parser::parseStatement found 25
spec.benchmarks._213_javac.Instruction::balance found 25
spec.benchmarks._213_javac.Instruction::balance found 25
spec.benchmarks._213_javac.Parser::parseTerm found 23
spec.benchmarks._213_javac.SourceClass::compileClass found 21
spec.benchmarks._213_javac.Expression::codeConversion found 21
spec.benchmarks._213_javac.MethodExpression::checkValue found 19
spec.benchmarks._202_jess.jess.Node2::CallNode found 16

SUGGESTED FIX See PRT webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050608072857.rasbold.c2_baseline/workspace/webrevs/webrev-2005.06.08/index.html ###@###.### 2005-06-08 19:18:16 GMT

EVALUATION In the examples I looked at, PhaseCFG::RemoveEmpty() was failing to remove blocks because they contained a MergeMemNode. We should attempt to move such nodes to other blocks, similar to what RemoveEmpty does for Phi nodes. ###@###.### 2004-02-26