NativeMethodPrefixAgent.java times out intermittently in nightly testing. 
Below is my analysis report entry:

New INSTRUMENT_REGRESSION failures (from 2006.07.26)
    java/lang/instrument/NativeMethodPrefixAgent.java
        This test failed due to timeout on Win32 Server VM (machine
        vmnightly2).

        Also, this failure showed up in the "New Failures" section even
        though both bugs associated with it are in state "integrated".
        I think the failure should have been in the "Unknowns" section.

        Robert and Dan originally believed this failure was related to
        the following bug:

            6447640 2/2 methodOopDesc::jmethod_id() can deadlock when
                        used by the VMThread

        The fix for 6447640 was putback to service_hs_baseline on
        2006.07.17 so it looks like this timeout is a different issue.

        Update: We have not had Win32 results for this subsuite since
            the 2006.07.26 failure (as of 2006.08.01).

        Update: This test passed in the 2006.08. customer  run on Win32 Server
            VM (machine robocop). The CHD entry for test machine
            vmnightly2 says it is an 800 MHz PIII. The CHD entry for
            machine robocop doesn't include any CPU info.

        Update: This test failed due to timeout in the 2006.09.06 run
            on Solaris X86 Client VM (machine vm-v20z-3). This machine
            is a 2 x 2.3GHz machine. I no longer think this is a test
            machine issue.

        Update: The "Unknowns" classification issue should be resolved
            when GTEE deploys.

        Update: "Unknowns" support appears to be working with GTEE.

        Last failure on 2007. customer .24 run with Solaris X86 Client VM.
        Previous failure on 2007. customer .22 run with Solaris X86 Server VM.

The "Unknowns" support issue is unrelated to this timeout.
Posted Date : 2007-02-26 18:59:29.0

Sometimes also known as:

    closed/java/lang/instrument/NativeMethodPrefixAgent.java
Posted Date : 2007-03-01 22:07:03.0

This bug is going to be used to modify the the following tests:

    java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh
    java/lang/instrument/appendToClassLoaderSearch/run_tests.sh
    java/lang/instrument/BootClassPath/BootClassPathTest.sh
    java/lang/instrument/NativeMethodPrefixAgent.java
    java/lang/instrument/RetransformAgent.java
Posted Date : 2008-02-16 00:07:39.0

N/A

The "shell MakeJAR2.sh" task has timed out in nightly using a
network mounted JDK. That task takes 13+ seconds on my 4-way
Ultra-80 with all local resources using the following JDK config:

    JDK under test: (/work/jdk/1.7.0/solaris-sparc)
    java version "1.7.0-ea"
    Java(TM) SE Runtime Environment (build 1.7.0-ea-b24)
    Java HotSpot(TM) Client VM (build 12.0-b01, mixed mode, sharing)

To hit the 120 second timeout requires that task to take 9X as long.
However, the machines on which the failure has been seen are not
equivalent to my 4-way Ultra-80 so we're comparing apples to
oranges.

What I'm going to do with this bug is:

- run all the INSTRUMENT_REGRESSION tests with "-client"
- look for all tasks that take > 10 seconds
- change the timeout for the task from the default of 120
  seconds to 240 seconds

So I'm going to double the timeout for these tasks and we'll see
where that takes us.
Posted Date : 2008-02-15 23:34:21.0