This bug describes a problem that arises when users profile Java code using
Java 9 on x86 and Linux using the Oracle Studio Performance Analyzer's
profiling capabilities from the debugger dbx.

The dbx debugger has a breakpoint on syscall(2) because a user application
might make a system call to exit or fork using syscall() and dbx needs to be
able to catch such events. (Ivan Soleimanipour might be a useful resource
for describing what dbx does.)

In recent Java 9 builds, the number of syscall() calls has been increasing.
The repercussions are that users who profile their applications using the
Oracle Studio Performance Analyzer by collecting performance profiling data
via the dbx interface end up with very many
dbx: internal warning: LwpPtrace::stop(): Got stray SIGPROF or SIGIO 1 for l@
messages. Further, at some point, their performance will be impacted.

Here is my simple test case:

$ cat mytest.java
class mytest
{
    public static void main (String [] args)
    {
        int i;
        double x = 0;
        long t = System.nanoTime();
        for (i = 1000000000; i > 0; i--) x = 0.2 * x + 0.3;
        t = System.nanoTime() - t;
        System.out.println("got " + x + " in " + (1.e-9 * t));
    }
}

I make sure the Oracle Studio bin directory is on my path for tools such as
the dbx debugger. Then I do something like this (csh syntax):


foreach J ( 7.0 8.0 9.0_9-ea-b89 9.0_9-ea+128 9.0_9-ea+129 9.0_9-ea+130
9.0_9-ea+135 )

/ws/set/mt/integration/Tools/JDK/intel-Linux/jdk1.$J/bin/javac mytest.java

dbx /ws/set/mt/integration/Tools/JDK/amd64-Linux/jdk1.$J/bin/java << EOF |&
grep -c "dbx: internal warning: LwpPtrace::stop(): Got stray SIGPROF or SIGIO
1 for l@"
collector enable
run -d64 mytest
quit
EOF

end

Here, the J are different JDK versions I have in
/ws/set/mt/integration/Tools/JDK. I compile the test code and then profile
it using the dbx debugger (and the 64-bit java). I count how many of the
warning lines are generated.

Here are the number of syscall() calls that were detected for runs with
different Java 9 builds we had available:

                        r u n
    Java build #1 #2 #3 #4 #5

    7.0 0 0 0 0 0
    8.0 0 0 0 0 0
    9.0_9-ea-b89 4 9 5 4 4
    9.0_9-ea+128 31 47 47 62 40
    9.0_9-ea+129 30 65 66 64 27
    9.0_9-ea+130 93 121 126 149 107
    9.0_9-ea+135 71 105 99 122 95

I ran on this system:

$ uname -a
Linux alvarez 2.6.32-220.el6.x86_64 #1 SMP Wed Dec 7 10:41:06 EST 2011 x86_64

but I think probably any x86 Linux system will do the job.

Note that the number of perturbative syscall() calls was 0 in Java 7 and 8
but then started increasing in Java 9. I don't know exactly why these calls
started appearing but I'm attaching a log file of many call stacks ending up
in syscall(). The immediate parent function tends to be
    os::current_thread_id(), line 230 in "os_linux.cpp"
and it looks like dynamic compilation is involved.