United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6445745 TransformerManagementThreadAddTests.java fails an assertion
6445745 : TransformerManagementThreadAddTests.java fails an assertion

Details
Type:
Bug
Submit Date:
2006-06-30
Status:
Resolved
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2006-07-20
Component:
hotspot
OS:
solaris_9,solaris,generic
Sub-Component:
compiler
CPU:
sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u18,5.0u18-rev,6
Fixed Versions:
6

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:

Sub Tasks

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
                                     
2006-07-13
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.
                                     
2006-07-13



Hardware and Software, Engineered to Work Together