JDK-6445745 : TransformerManagementThreadAddTests.java fails an assertion
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u18,5.0u18-rev,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris,solaris_9
  • CPU: generic,sparc
  • Submitted: 2006-06-30
  • Updated: 2012-02-01
  • Resolved: 2006-07-20
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.
Other Other Other JDK 6
5.0u19-revFixed 5.0u20-revFixed 5.0u21Fixed 6 b92Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
TransformerManagementThreadAddTests.java failed in the 2006.06.29 nightly.
Here is the entry from my usual analysis report:

New INSTRUMENT_REGRESSION failures (from 2006.06.29)
   java/lang/instrument/TransformerManagementThreadAddTests.java
        This test failed the following assertion:

            Internal Error (src/share/vm/opto/parse1.cpp, 1579)
            Error: assert(n != top() || r->in(pnum) == top(),
                "live value must not be garbage")

        on Solaris X86 Server VM (machine vm-v20z-9), Solaris SPARC
        Server VM (machine jtg-s130), Solaris SPARC-64 Server VM
        (machine jtg-s130), and Solaris AMD64 Server VM (machine
        vm-v20z-10). This is a client-centric day so these are the
        only Server VM configs to be run today.

        This failure did not occur in the 2006.06.28 run. PRT job
        20060629094817.dcubed.service_hs_b91_merge was a merge of
        20060629071936.nips.compiler_b91_merge from main/baseline.
        There were no other putbacks to service_hs_baseline. It
        looks like we picked up a regression for the c2_baseline
        push for Mustang-B91.

        This test is covered by the following bug:

            6239043 4/4 test/java/lang/instrument/
                        TransformerManagementThreadAddTests.java failed 

        However, this is not the same failure mode.
To reproduce this bug you need a JDK/SDK workspace. Actually you
just need the test portion of it, possibly even just the
test/java/lang/instrument portion of it, but I haven't tested
that.

I've attached a do-sdk-jli.ksh script that runs just the
TransformerManagementThreadAddTests.java test. Drop this
script at the top of the JDK/SDK workspace and run as
follows:

% ksh do-sdk-jli.ksh $JAVA_HOME -server
runregress: Version 01/14/06
runregress: Using jtreg 2.1.6 from /java/svc/jct-tools2.1.6
runregress: Using this jdk for JavaTest: /java/svc/sqeweb/UNIFIED-DTF/stable-jdk/solaris-sparc
runregress: Testing this jdk: /net/gtee/export/nightly/mustang/JDK/service_hs_baseline/jdk1.6/solaris-sparc

-- NOTE:  Will run jtreg with  -server -showversion
          jtreg might not like some/all of these!
          Run ..../jtreg -help for more info

Starting run:  Fri Jun 30 14:44:54 PDT 2006
Directory "/home/dcubed/sdk-test-mustang/sdk-jli.solaris-sparc/JTwork/scratch" not found: Creating
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)

test results: failed: 1
Report written to /home/dcubed/sdk-test-mustang/sdk-jli.solaris-sparc/JTreport/report.html
Results written to /home/dcubed/sdk-test-mustang/sdk-jli.solaris-sparc/JTwork
Error: some tests failed or other problems occurred

real     1:34.4
user     1:02.0
sys         9.1

The summary report is in:
   /home/dcubed/sdk-test-mustang/sdk-jli.solaris-sparc/jjsummary.html

Failed tests are:
runner finished: java/lang/instrument/TransformerManagementThreadAddTests.java: Failed. Unexpected exit from test [exit code: 6]

cat /home/dcubed/sdk-test-mustang/sdk-jli.solaris-sparc/JTwork/java/lang/instrument/TransformerManagementThreadAddTests.jtr


% tail -25 sdk-jli.solaris-sparc/JTwork/java/lang/instrument/TransformerManagementThreadAddTests.jtr
----------System.out:(19/931)----------
InstrumentationHandoff JPLIS agent initialized
Reading test class from /home/dcubed/sdk-test-mustang/sdk-jli.solaris-sparc/JTwo
rk/classes/java/lang/instrument/DummyClass.class
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/parse1.cpp:1579]
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/net/prt-solsparc-q1-18/tmp/PrtBuildDir/workspace/src/share/v
m/opto/parse1.cpp, 1579 [ Patched ]), pid=22468, tid=7
#
# Java VM: Java HotSpot(TM) Server VM (20060629094817.dcubed.service_hs_b91_merg
e-debug mixed mode)
#
# Error: assert(n != top() || r->in(pnum) == top(),"live value must not be garba
ge")
# An error report file with more information is saved as hs_err_pid22468.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 7
Dumping core ...
----------System.err:(0/0)----------
result: Failed. Unexpected exit from test [exit code: 6]


test result: Failed. Unexpected exit from test [exit code: 6]

Feel free to use ~dcubed/sdk-test-mustang and the do-sdk-jli.ksh
file that I left there.

Comments
SUGGESTED FIX There are few possible solutions for this problem. One is to modify liveness of locals to reflect the Interpreter's state of locals. It is expensive since it requires to call into VM for each block. Another is to ask Interpreter each time we are creating a phi in a block. It is even more expensive. John and Tom suggested to use NULL_PTR value instead of TOP for dead locals and skip their type check at the OSR entry. These changes is very small and helps both cases. Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2006/20060713123833.kvn.6445745/workspace/webrevs/webrev-2006.07.13/index.html
13-07-2006

EVALUATION Steve G. fix for 6403625 exposed an additional case of the disagreement between Interpreter and ciTypeFlow when an oop is defined inside a loop. In this case Interpreter says the oop's local value is dead (uninitialized) at the beginning of the loop (OSR entry) and alive at the loop's end. The Steve's fix catch this disagreement and set the local value to TOP on the OSR entry. This cause the assert when Parser creates Phi to merge the backbranch (alive) value with the entry (dead) top value.
13-07-2006