From david.holmes at oracle.com Tue Jul 1 02:29:36 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Jul 2014 12:29:36 +1000 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53B199A8.7040003@oracle.com> References: <53AD9949.9030601@oracle.com> <53B0F6A9.1060109@oracle.com> <53B0FB78.6060506@oracle.com> <53B199A8.7040003@oracle.com> Message-ID: <53B21D10.5090501@oracle.com> Hi Dan, I disagree on a few points but lets wait to see what Markus' work shows. Though I would be surprised if it detects the indirect safepoint blocking caused by submitting a synchronous, safepoint-needing, VM op. David On 1/07/2014 3:08 AM, Daniel D. Daugherty wrote: > David, > > Thanks for the review. Obviously I can't list you as a reviewer > since I already pushed the changeset... > > > On 6/29/14 11:54 PM, David Holmes wrote: >> Correction ... >> >> On 30/06/2014 3:33 PM, David Holmes wrote: >>> Hi Dan, >>> >>> I see this has already gone in but I think it is worth looking closer at >>> this. >>> >>> On 28/06/2014 2:18 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a fix ready for the following bug: >>>> >>>> 8047720 Xprof hangs on Solaris >>>> https://bugs.openjdk.java.net/browse/JDK-8047720 >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ >>>> >>>> This deadlock occurred between the following threads: >>>> >>>> Main thread - Trying to stop the WatcherThread as part of >>>> shutting down the VM; this thread is blocked >>>> on the PeriodicTask_lock which keeps it from >>>> reaching a safepoint. >>>> WatcherThread - Requested a VM_ForceSafepoint to complete >>>> a JavaThread::java_suspend() call as part >>>> of a FlatProfiler record_thread_ticks() >>>> call; this thread owns the PeriodicTask_lock >>>> since it is processing a periodic task. >>>> VMThread - Trying to start a safepoint; this thread is >>>> blocked waiting for the Main thread to reach >>>> a safepoint. >>>> >>>> The PeriodicTask_lock is one of the VM internal locks and is >>>> typically managed using Mutex::_no_safepoint_check_flag to >>>> avoid deadlocks. Yes, the irony is dripping on the floor... :-) >>> >>> What was overlooked here is that the holder of a lock that is acquired >>> without safepoint checks, must never block at a safepoint whilst holding >>> that lock. > > I'm not sure about the above rule when you're talking about > internal VM threads that are really JavaThreads. JavaThreads > can run into all kinds of our special logic when doing thread > state transitions and the like. JavaThreads can also post JVM/TI > events which can lead to blocking at safepoints or blocking on > JVM/TI raw monitors in event handlers, etc... > > > >>> In this case the blocking is indirect, caused by the >>> synchronous nature of the VM_Operation, rather than a direct result of >>> "blocking for the safepoint" (which the WatcherThread does not >>> participate in). > > Right. The WatcherThread intentionally does not participate in > safepoints when using the PeriodicTask_lock. To me, that means > that other threads using that lock should not participate in > the safepoint protocol. > > I believe we're trying to be consistent about how we use locks > with respect to honoring the safepoint protocol or not. Markus G > has a bug fix in process where he's trying to add sanity checks > that detect inconsistent use of locks. In this particular case, > I believe that the Main thread's use of the PeriodicTask_lock > with the safepoint protocol enabled would be seen as inconsistent. > However, I may not have all the details for what Markus is doing. > > >>> I wonder if the WatcherThread should really be using >>> the async variant of VM_ForceSafepoint here? > > The WatcherThread is trying to do a JavaThread::java_suspend() > call. JavaThread::java_suspend() cannot return to the caller > until it is sure that the target thread will not execute any > more bytecodes. Switching to an async VM_ForceSafepoint would > break that invariant and cause subtle deadlocks because a target > JavaThread could acquire a Java monitor when the suspend > requesting thread thinks it is suspended. Been down that road > before and it is not pretty. > > > >>> >>>> The interesting part of this deadlock is that I think that it >>>> is possible for other periodic tasks to hit it. Anything that >>>> causes the WatcherThread to start a safepoint while processing >>>> a periodic task should be susceptible to this race. Think about >>>> the -XX:+DeoptimizeALot option and how it causes VM_Deopt >>>> requests on thread state transitions... Interesting... >>> >>> I don't think so. You need three threads involved to get the deadlock. >> >> But that isn't the point. As you state this deadlock, at VM shutdown, >> could impact any synchronous safepoint operations executed by the >> WatcherThread. > > Right. The problem is that the WatcherThread holds the > PeriodicTask_lock across the potential for VM operations > so we have to be very, very careful with non-WatcherThread > uses of that lock to avoid deadlocks. > > > >> >> That aside ... >> >>> In the current case the main thread's locking of the PeriodicTask_lock >>> without a safepoint check is what causes the problem - that violates the >>> rules surrounding use of "no safepoint checks". The other methods that a >>> JavaThread might call that acquire the PeriodicTask_lock do perform the >>> safepoint checks, so they wouldn't deadlock. Hence it seems to me that >>> only WatcherThread::stop can lead to this problem. And as >>> WatcherThread::stop is only called from before_exit, and that can only >>> be called once, it seems to me that we could/should actually acquire the >>> lock with a safepoint check. > > Agreed that only the WatcherThread::stop() call can lead to this deadlock > because it is that call that catches the PeriodicTask_lock being held > across a VM operation. That's the heart of this deadlock and we're only > differing on how to solve that deadlock. > > The primary purpose of WatcherThread::stop() is setting the > _should_terminate > flag so that the WatcherThread knows that it should stop dispatching > periodic > tasks. _should_terminate is already volatile and the existing code does an > OrderAccess::fence() just to be sure the update is seen. The secondary > purpose of WatcherThread::stop() is waking up the WatcherThread so that it > stops in a more timely fashion. The WatcherThread waits for a fixed > amount of > time so it will eventually wake up and see the new _should_terminate value. > > If caller of WatcherThread::stop() cannot get the PeriodicTask_lock, then > that means the WatcherThread is active so WatcherThread::stop() only has > to set the flag. It is possible for the WatcherThread::stop() call to race > with the WatcherThread dropping the PeriodicTask_lock and waiting. In that > case, the WatcherThread waits for a fixed amount of time so it will > eventually wake up and see the new _should_terminate value. > > I intentionally don't want WatcherThread::stop() to honor the safepoint > protocol when accessing the PeriodicTask_lock so that we remain consistent > with our use of that lock. See my comments above about Markus' work in this > area. > > WatcherThread::stop() will honor the safepoint protocol a couple of lines > down from my changes: > > 1380 // it is ok to take late safepoints here, if needed > 1381 MutexLocker mu(Terminator_lock); > > The subsequent wait() loop also honors the safepoint protocol. > > Dan > > >> >> David >> ----- >> >>> Cheers, >>> David >>> >>>> >>>> Testing: >>>> - I found a way to add delays to the right spots in the >>>> VM to make the deadlock reproduce in just about every >>>> run of the test associated with the bug. The new >>>> os::naked_short_sleep() function is your friend. Thanks >>>> to Fred for adding that! See the bug report for the >>>> debugging diffs. >>>> - 72 hours of running the test in the bug report with >>>> delays enabled for product, fastdebug and jvmg bits >>>> in parallel on my Solaris X86 server. >>>> - JPRT test run >>>> - Aurora Adhoc results are in process; we're having issues >>>> with both a broken testbase build and infra problems >>>> with results not being uploaded. >>>> > From staffan.larsen at oracle.com Tue Jul 1 06:17:06 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 08:17:06 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: <53B193A7.2020109@oracle.com> References: <53B193A7.2020109@oracle.com> Message-ID: <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> Jaroslav, Great cleanup! How about using Process.destroyForcibly() instead of sending the ?shutdown? message? Maybe not as ?nice?, but much less code. test/sun/tools/jstatd/JstatdTest.java: 323 port = Integer.toString(31111); //Utils.getFreePort()); Looks like a mistake? /Staffan On 30 jun 2014, at 18:43, Jaroslav Bachorik wrote: > Please, review the following test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 > Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 > > Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. > > Thanks, > > -JB- From erik.gahlin at oracle.com Tue Jul 1 07:37:57 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 01 Jul 2014 09:37:57 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> Message-ID: <53B26555.5090203@oracle.com> Updated webrev: http://cr.openjdk.java.net/~egahlin/8028474_5/ See comments inline. Staffan Larsen skrev 2014-06-26 13:22: > Indentation around JavaProcess.getId() is weird. > Fixed > JavaProcess.getPid/setPid/pid do not appear to be used. > Fixed > JavaProcess.waitForRemoval: How about using timestamps > (currentTimeMillis()) before the loop and for each ite > ration to determine if the timeout has expired (instead of "time+=100?)? > The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log. I also cleaned up the log for releaseStarted/releaseTerminated > nit: missing empty line before line 139, method releaseStarted(). > Fixed Thanks Erik > /Staffan > > > On 26 jun 2014, at 00:56, Erik Gahlin > wrote: > >> It didn't work. >> >> There's no termination notification, if I use >> Process#destroyForcibly(). I believe the hsperfdata file is left >> behind so it will not be able to detect that the process has died. >> >> Here is an updated version that renames some variable/methods. >> >> http://cr.openjdk.java.net/~egahlin/8028474_3/ >> >> Thanks >> Erik >> >> Erik Gahlin skrev 2014-06-18 09:37: >>> Didn't know about destroyForcibly(). I could try that. >>> >>> Erik >>> >>> Staffan Larsen skrev 18/06/14 09:26: >>>> Erik, >>>> >>>> How about using Process.destroyForcibly() as a means to terminate >>>> the process instead of using files for signaling? >>>> >>>> /Staffan >>>> >>>> On 17 jun 2014, at 23:13, Erik Gahlin >>> > wrote: >>>> >>>>> Yes, very weird >>>>> >>>>> Could have been that I needed the tools.jar in the child >>>>> processes, or it could have been something else. If I remember >>>>> correctly, I got a CNF that I didn't get with the shell script, >>>>> but it was few months back. >>>>> >>>>> Anyway, I retried with JPRT and now it works without the shell script. >>>>> >>>>> http://cr.openjdk.java.net/~egahlin/8028474_2/ >>>>> >>>>> Erik >>>>> >>>>> Staffan Larsen skrev 2014-06-16 13:49: >>>>>> >>>>>> On 16 jun 2014, at 12:32, Erik Gahlin >>>>> > wrote: >>>>>> >>>>>>> Yekaterina Kantserova skrev 13/06/14 12:59: >>>>>>>> Erik, >>>>>>>> >>>>>>>> is there some reason why we need to keep >>>>>>>> MonitorVmStartTerminate.sh? I've moved the JTreg header to >>>>>>>> MonitorVmStartTerminate.java >>>>>>> Hi Katja, >>>>>>> >>>>>>> That's how I did the test initially, and it works locally, but I >>>>>>> could never get it to work in JPRT without the shell script. I >>>>>>> believe the tools.jar is not on the class path. >>>>>> >>>>>> That is weird. I see other tests that depend in tools.jar and >>>>>> they work fine. >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> >>>>>>> Erik >>>>>>>> >>>>>>>> /* >>>>>>>> * @test >>>>>>>> * @bug 4990825 >>>>>>>> * @summary attach to external but local JVM processes >>>>>>>> * @library /lib/testlibrary >>>>>>>> * @build jdk.testlibrary.* >>>>>>>> * @run main MonitorVmStartTerminate >>>>>>>> */ >>>>>>>> >>>>>>>> and the test works just fine. >>>>>>>> >>>>>>>> The JTreg run contains all pathes and system properties >>>>>>>> MonitorVmStartTerminate.sh tries to construct: >>>>>>>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} >>>>>>>> -Dtest.classes=${TESTCLASSES} -classpath ${CP} >>>>>>>> MonitorVmStartTerminate >>>>>>>> >>>>>>>> See the log attached. >>>>>>>> >>>>>>>> Note *@build jdk.testlibrary.** instead of *@build >>>>>>>> jdk.testlibrary.ProcessTools* to make sure all testlibrary >>>>>>>> classes are compiled >>>>>>>> to the right place when running tests concurrently. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Katja (Not a Reviewer) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could I have a review of a test that has been failing >>>>>>>>> intermittently. The test now uses files for synchronization >>>>>>>>> instead of waiting for a process that sleeps. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>>>>>>> >>>>>>>>> Description: >>>>>>>>> >>>>>>>>> The test starts ten Java processes, each with a unique id. >>>>>>>>> >>>>>>>>> Each process creates a file named after the id and then it >>>>>>>>> waits for >>>>>>>>> the test to remove the file, at which the Java process exits. >>>>>>>>> >>>>>>>>> The processes are monitored by the test to make sure >>>>>>>>> notifications >>>>>>>>> are sent when processes are started/terminated. >>>>>>>>> >>>>>>>>> To avoid Java processes being left behind, in case of an >>>>>>>>> unexpected >>>>>>>>> failure, shutdown hooks are registered that remove files when >>>>>>>>> the test >>>>>>>>> exits. If files are not removed, i.e. due to a JVM crash, >>>>>>>>> the Java processes will exit themselves after 1000 s. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Erik >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jul 1 07:38:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 09:38:57 +0200 Subject: RFR: 8048687 [TESTBUG] com/sun/jdi/ExclusiveBind.java "Could not find or load main class" Message-ID: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> Please review this test fix. webrev: http://cr.openjdk.java.net/~sla/8048687/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8048687 The test tries to start a process but fails with: ----------System.out:(35/1961)---------- vmOpts: javaOpts: -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M Command line: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/macosx-amd64/bin/java -classpath /export/local/aurora/sandbox/results/workDir/classes/1/com/sun/jdi -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=61682 HelloWorld ] ... ----------System.err:(16/856)---------- [process1] Error: Could not find or load main class Failed to start a process (thread dump follows) At first glance the command line looks ok, but what I missed here is that there are two spaces before "-Xmixed". Two spaces in a command line is ok, but in this case it means that the String[] argument to ProcessBuilder has one empty String element. That is not ok since that would turn into an actual empty argument to the process. We can actually see this in the output from the process, too: [process1] Error: Could not find or load main class If it was the HelloWorld class that could not be found it should have said: [process1] Error: Could not find or load main class HelloWorld But now it is the empty string class that we can't find. The fix makes sure there are no empty Strings in the process arguments. Thanks, /Staffan From staffan.larsen at oracle.com Tue Jul 1 07:41:08 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 09:41:08 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B26555.5090203@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> Message-ID: <0D4CB7C8-764A-41B1-8F44-118F96D1AFAE@oracle.com> Looks good! Thanks, /Staffan On 1 jul 2014, at 09:37, Erik Gahlin wrote: > Updated webrev: > http://cr.openjdk.java.net/~egahlin/8028474_5/ > > See comments inline. > > Staffan Larsen skrev 2014-06-26 13:22: >> Indentation around JavaProcess.getId() is weird. >> > Fixed >> JavaProcess.getPid/setPid/pid do not appear to be used. >> > Fixed > >> JavaProcess.waitForRemoval: How about using timestamps (currentTimeMillis()) before the loop and for each ite >> ration to determine if the timeout has expired (instead of "time+=100?)? >> > The code now uses currentTimeMillis(). Premature timeouts due to clock changes can be deduced from the log. > > I also cleaned up the log for releaseStarted/releaseTerminated > >> nit: missing empty line before line 139, method releaseStarted(). >> > Fixed > > Thanks > Erik > >> /Staffan >> >> >> On 26 jun 2014, at 00:56, Erik Gahlin wrote: >> >>> It didn't work. >>> >>> There's no termination notification, if I use Process#destroyForcibly(). I believe the hsperfdata file is left behind so it will not be able to detect that the process has died. >>> >>> Here is an updated version that renames some variable/methods. >>> >>> http://cr.openjdk.java.net/~egahlin/8028474_3/ >>> >>> Thanks >>> Erik >>> >>> Erik Gahlin skrev 2014-06-18 09:37: >>>> Didn't know about destroyForcibly(). I could try that. >>>> >>>> Erik >>>> >>>> Staffan Larsen skrev 18/06/14 09:26: >>>>> Erik, >>>>> >>>>> How about using Process.destroyForcibly() as a means to terminate the process instead of using files for signaling? >>>>> >>>>> /Staffan >>>>> >>>>> On 17 jun 2014, at 23:13, Erik Gahlin wrote: >>>>> >>>>>> Yes, very weird >>>>>> >>>>>> Could have been that I needed the tools.jar in the child processes, or it could have been something else. If I remember correctly, I got a CNF that I didn't get with the shell script, but it was few months back. >>>>>> >>>>>> Anyway, I retried with JPRT and now it works without the shell script. >>>>>> >>>>>> http://cr.openjdk.java.net/~egahlin/8028474_2/ >>>>>> >>>>>> Erik >>>>>> >>>>>> Staffan Larsen skrev 2014-06-16 13:49: >>>>>>> >>>>>>> On 16 jun 2014, at 12:32, Erik Gahlin wrote: >>>>>>> >>>>>>>> Yekaterina Kantserova skrev 13/06/14 12:59: >>>>>>>>> Erik, >>>>>>>>> >>>>>>>>> is there some reason why we need to keep MonitorVmStartTerminate.sh? I've moved the JTreg header to MonitorVmStartTerminate.java >>>>>>>> Hi Katja, >>>>>>>> >>>>>>>> That's how I did the test initially, and it works locally, but I could never get it to work in JPRT without the shell script. I believe the tools.jar is not on the class path. >>>>>>> >>>>>>> That is weird. I see other tests that depend in tools.jar and they work fine. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Erik >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * @test >>>>>>>>> * @bug 4990825 >>>>>>>>> * @summary attach to external but local JVM processes >>>>>>>>> * @library /lib/testlibrary >>>>>>>>> * @build jdk.testlibrary.* >>>>>>>>> * @run main MonitorVmStartTerminate >>>>>>>>> */ >>>>>>>>> >>>>>>>>> and the test works just fine. >>>>>>>>> >>>>>>>>> The JTreg run contains all pathes and system properties MonitorVmStartTerminate.sh tries to construct: >>>>>>>>> ${JAVA} ${TESTVMOPTS} -Dtest.jdk=${TESTJAVA} -Dtest.classes=${TESTCLASSES} -classpath ${CP} MonitorVmStartTerminate >>>>>>>>> >>>>>>>>> See the log attached. >>>>>>>>> >>>>>>>>> Note @build jdk.testlibrary.* instead of @build jdk.testlibrary.ProcessTools to make sure all testlibrary classes are compiled >>>>>>>>> to the right place when running tests concurrently. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Katja (Not a Reviewer) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/12/2014 12:37 AM, Erik Gahlin wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Could I have a review of a test that has been failing >>>>>>>>>> intermittently. The test now uses files for synchronization >>>>>>>>>> instead of waiting for a process that sleeps. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~egahlin/8028474/ >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8028474 >>>>>>>>>> >>>>>>>>>> Description: >>>>>>>>>> >>>>>>>>>> The test starts ten Java processes, each with a unique id. >>>>>>>>>> >>>>>>>>>> Each process creates a file named after the id and then it waits for >>>>>>>>>> the test to remove the file, at which the Java process exits. >>>>>>>>>> >>>>>>>>>> The processes are monitored by the test to make sure notifications >>>>>>>>>> are sent when processes are started/terminated. >>>>>>>>>> >>>>>>>>>> To avoid Java processes being left behind, in case of an unexpected >>>>>>>>>> failure, shutdown hooks are registered that remove files when the test >>>>>>>>>> exits. If files are not removed, i.e. due to a JVM crash, >>>>>>>>>> the Java processes will exit themselves after 1000 s. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Erik >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jul 1 07:54:52 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 09:54:52 +0200 Subject: RFR: 8048687 [TESTBUG] com/sun/jdi/ExclusiveBind.java "Could not find or load main class" In-Reply-To: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> References: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> Message-ID: <53B2694C.2050701@oracle.com> Looks good! -JB- On 07/01/2014 09:38 AM, Staffan Larsen wrote: > Please review this test fix. > > webrev: http://cr.openjdk.java.net/~sla/8048687/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048687 > > The test tries to start a process but fails with: > > > ----------System.out:(35/1961)---------- > vmOpts: > javaOpts: -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M > Command line: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/macosx-amd64/bin/java -classpath /export/local/aurora/sandbox/results/workDir/classes/1/com/sun/jdi -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=61682 HelloWorld ] > ... > ----------System.err:(16/856)---------- > [process1] Error: Could not find or load main class > Failed to start a process (thread dump follows) > > > At first glance the command line looks ok, but what I missed here is that there are two spaces before "-Xmixed". Two spaces in a command line is ok, but in this case it means that the String[] argument to ProcessBuilder has one empty String element. That is not ok since that would turn into an actual empty argument to the process. We can actually see this in the output from the process, too: > > [process1] Error: Could not find or load main class > > If it was the HelloWorld class that could not be found it should have said: > > [process1] Error: Could not find or load main class HelloWorld > > But now it is the empty string class that we can't find. > > The fix makes sure there are no empty Strings in the process arguments. > > Thanks, > /Staffan > From erik.gahlin at oracle.com Tue Jul 1 08:23:05 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 01 Jul 2014 10:23:05 +0200 Subject: RFR: 8048687 [TESTBUG] com/sun/jdi/ExclusiveBind.java "Could not find or load main class" In-Reply-To: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> References: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> Message-ID: <53B26FE9.9020707@oracle.com> Looks good! Erik Staffan Larsen skrev 2014-07-01 09:38: > Please review this test fix. > > webrev: http://cr.openjdk.java.net/~sla/8048687/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048687 > > The test tries to start a process but fails with: > > > ----------System.out:(35/1961)---------- > vmOpts: > javaOpts: -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M > Command line: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/macosx-amd64/bin/java -classpath /export/local/aurora/sandbox/results/workDir/classes/1/com/sun/jdi -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=61682 HelloWorld ] > ... > ----------System.err:(16/856)---------- > [process1] Error: Could not find or load main class > Failed to start a process (thread dump follows) > > > At first glance the command line looks ok, but what I missed here is that there are two spaces before "-Xmixed". Two spaces in a command line is ok, but in this case it means that the String[] argument to ProcessBuilder has one empty String element. That is not ok since that would turn into an actual empty argument to the process. We can actually see this in the output from the process, too: > > [process1] Error: Could not find or load main class > > If it was the HelloWorld class that could not be found it should have said: > > [process1] Error: Could not find or load main class HelloWorld > > But now it is the empty string class that we can't find. > > The fix makes sure there are no empty Strings in the process arguments. > > Thanks, > /Staffan From staffan.larsen at oracle.com Tue Jul 1 08:22:30 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 10:22:30 +0200 Subject: RFR: 8048687 [TESTBUG] com/sun/jdi/ExclusiveBind.java "Could not find or load main class" In-Reply-To: <53B26FE9.9020707@oracle.com> References: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> <53B26FE9.9020707@oracle.com> Message-ID: Erik, Jaroslav: Thanks! I need one official Reviewer to have a look as well. Thanks, /Staffan On 1 jul 2014, at 10:23, Erik Gahlin wrote: > Looks good! > > Erik > > Staffan Larsen skrev 2014-07-01 09:38: >> Please review this test fix. >> >> webrev: http://cr.openjdk.java.net/~sla/8048687/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8048687 >> >> The test tries to start a process but fails with: >> >> >> ----------System.out:(35/1961)---------- >> vmOpts: >> javaOpts: -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M >> Command line: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/macosx-amd64/bin/java -classpath /export/local/aurora/sandbox/results/workDir/classes/1/com/sun/jdi -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=61682 HelloWorld ] >> ... >> ----------System.err:(16/856)---------- >> [process1] Error: Could not find or load main class >> Failed to start a process (thread dump follows) >> >> >> At first glance the command line looks ok, but what I missed here is that there are two spaces before "-Xmixed". Two spaces in a command line is ok, but in this case it means that the String[] argument to ProcessBuilder has one empty String element. That is not ok since that would turn into an actual empty argument to the process. We can actually see this in the output from the process, too: >> >> [process1] Error: Could not find or load main class >> >> If it was the HelloWorld class that could not be found it should have said: >> >> [process1] Error: Could not find or load main class HelloWorld >> >> But now it is the empty string class that we can't find. >> >> The fix makes sure there are no empty Strings in the process arguments. >> >> Thanks, >> /Staffan > From jaroslav.bachorik at oracle.com Tue Jul 1 08:29:43 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 10:29:43 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> Message-ID: <53B27177.3060100@oracle.com> On 07/01/2014 08:17 AM, Staffan Larsen wrote: > Jaroslav, > > Great cleanup! > > How about using Process.destroyForcibly() instead of sending the ?shutdown? message? Maybe not as ?nice?, but much less code. The target process needs to hang around for a while till the test tries to shut it down. We would need to put a monitor wait there and rely on the OS being able to shut the process down. The Process.destroyForcibly() spec leaves it to the OS specific implementations to do the right thing. For the major OSes it seems to force kill the process but I'm not sure about eg. embedded devices. > > test/sun/tools/jstatd/JstatdTest.java: > 323 port = Integer.toString(31111); //Utils.getFreePort()); > Looks like a mistake? Definitely a mistake :( Thanks for spotting it! Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 -JB- > > > /Staffan > > > On 30 jun 2014, at 18:43, Jaroslav Bachorik wrote: > >> Please, review the following test change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >> >> Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. >> >> Thanks, >> >> -JB- > From david.holmes at oracle.com Tue Jul 1 08:32:00 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Jul 2014 18:32:00 +1000 Subject: RFR: 8048687 [TESTBUG] com/sun/jdi/ExclusiveBind.java "Could not find or load main class" In-Reply-To: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> References: <6105BF65-1278-4A28-8621-8D819FC0A528@oracle.com> Message-ID: <53B27200.1090702@oracle.com> Looks good to me too! David On 1/07/2014 5:38 PM, Staffan Larsen wrote: > Please review this test fix. > > webrev: http://cr.openjdk.java.net/~sla/8048687/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048687 > > The test tries to start a process but fails with: > > > ----------System.out:(35/1961)---------- > vmOpts: > javaOpts: -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M > Command line: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/macosx-amd64/bin/java -classpath /export/local/aurora/sandbox/results/workDir/classes/1/com/sun/jdi -Xmixed -server -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=61682 HelloWorld ] > ... > ----------System.err:(16/856)---------- > [process1] Error: Could not find or load main class > Failed to start a process (thread dump follows) > > > At first glance the command line looks ok, but what I missed here is that there are two spaces before "-Xmixed". Two spaces in a command line is ok, but in this case it means that the String[] argument to ProcessBuilder has one empty String element. That is not ok since that would turn into an actual empty argument to the process. We can actually see this in the output from the process, too: > > [process1] Error: Could not find or load main class > > If it was the HelloWorld class that could not be found it should have said: > > [process1] Error: Could not find or load main class HelloWorld > > But now it is the empty string class that we can't find. > > The fix makes sure there are no empty Strings in the process arguments. > > Thanks, > /Staffan > From staffan.larsen at oracle.com Tue Jul 1 08:54:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 10:54:42 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: <53B27177.3060100@oracle.com> References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> Message-ID: On 1 jul 2014, at 10:29, Jaroslav Bachorik wrote: > On 07/01/2014 08:17 AM, Staffan Larsen wrote: >> Jaroslav, >> >> Great cleanup! >> >> How about using Process.destroyForcibly() instead of sending the ?shutdown? message? Maybe not as ?nice?, but much less code. > > The target process needs to hang around for a while till the test tries to shut it down. We would need to put a monitor wait there and rely on the OS being able to shut the process down. Not sure what you mean. Why can?t we terminate the process at the same place we call RunnerUtil.stopApplication()? > The Process.destroyForcibly() spec leaves it to the OS specific implementations to do the right thing. For the major OSes it seems to force kill the process but I'm not sure about eg. embedded devices. I think the idea of Process.destroyForcibly() is that we /can/ rely on it. If we can?t rely on our own implementation, then the API is not very usable. > >> >> test/sun/tools/jstatd/JstatdTest.java: >> 323 port = Integer.toString(31111); //Utils.getFreePort()); >> Looks like a mistake? > > Definitely a mistake :( Thanks for spotting it! > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 Looks good! Thanks, /Staffan > > -JB- > >> >> >> /Staffan >> >> >> On 30 jun 2014, at 18:43, Jaroslav Bachorik wrote: >> >>> Please, review the following test change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>> >>> Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. >>> >>> Thanks, >>> >>> -JB- >> > From david.holmes at oracle.com Tue Jul 1 09:03:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Jul 2014 19:03:44 +1000 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> Message-ID: <53B27970.5060006@oracle.com> On 1/07/2014 6:54 PM, Staffan Larsen wrote: > > On 1 jul 2014, at 10:29, Jaroslav Bachorik wrote: > >> On 07/01/2014 08:17 AM, Staffan Larsen wrote: >>> Jaroslav, >>> >>> Great cleanup! >>> >>> How about using Process.destroyForcibly() instead of sending the ?shutdown? message? Maybe not as ?nice?, but much less code. >> >> The target process needs to hang around for a while till the test tries to shut it down. We would need to put a monitor wait there and rely on the OS being able to shut the process down. > > Not sure what you mean. Why can?t we terminate the process at the same place we call RunnerUtil.stopApplication()? > >> The Process.destroyForcibly() spec leaves it to the OS specific implementations to do the right thing. For the major OSes it seems to force kill the process but I'm not sure about eg. embedded devices. > > I think the idea of Process.destroyForcibly() is that we /can/ rely on it. If we can?t rely on our own implementation, then the API is not very usable. Right. It is the OS that is key not the device. Linux/Solaris will send a SIGKILL. Windows does terminateProcess for both destroy and destroyForcibly. David ----- >> >>> >>> test/sun/tools/jstatd/JstatdTest.java: >>> 323 port = Integer.toString(31111); //Utils.getFreePort()); >>> Looks like a mistake? >> >> Definitely a mistake :( Thanks for spotting it! >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 > > Looks good! > > Thanks, > /Staffan > > >> >> -JB- >> >>> >>> >>> /Staffan >>> >>> >>> On 30 jun 2014, at 18:43, Jaroslav Bachorik wrote: >>> >>>> Please, review the following test change. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>>> >>>> Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Tue Jul 1 09:05:00 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 11:05:00 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> Message-ID: <53B279BC.6040002@oracle.com> On 07/01/2014 10:54 AM, Staffan Larsen wrote: > > On 1 jul 2014, at 10:29, Jaroslav Bachorik wrote: > >> On 07/01/2014 08:17 AM, Staffan Larsen wrote: >>> Jaroslav, >>> >>> Great cleanup! >>> >>> How about using Process.destroyForcibly() instead of sending the ?shutdown? message? Maybe not as ?nice?, but much less code. >> >> The target process needs to hang around for a while till the test tries to shut it down. We would need to put a monitor wait there and rely on the OS being able to shut the process down. > > Not sure what you mean. Why can?t we terminate the process at the same place we call RunnerUtil.stopApplication()? The target application does nothing except of waiting to be shut down. It needs to hang around for the test to be able to attach to it. It used to listen on a socket to receive the shutdown message, now it reads from stdin to block and wait for shutdown. If the read from stdin is removed we would need to add another wait mechanism to make sure the application is alive until the test shuts it down. > >> The Process.destroyForcibly() spec leaves it to the OS specific implementations to do the right thing. For the major OSes it seems to force kill the process but I'm not sure about eg. embedded devices. > > I think the idea of Process.destroyForcibly() is that we /can/ rely on it. If we can?t rely on our own implementation, then the API is not very usable. Might be the case - ... * The default implementation of this method invokes {@link #destroy} * and so may not forcibly terminate the process. Concrete implementations * of this class are strongly encouraged to override this method with a * compliant implementation. ... If it can be confirmed that a process will always be forcibly destroyed I have nothing against using this API call instead of hand-crafting the shutdown mechanism. -JB- > >> >>> >>> test/sun/tools/jstatd/JstatdTest.java: >>> 323 port = Integer.toString(31111); //Utils.getFreePort()); >>> Looks like a mistake? >> >> Definitely a mistake :( Thanks for spotting it! >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 > > Looks good! > > Thanks, > /Staffan > > >> >> -JB- >> >>> >>> >>> /Staffan >>> >>> >>> On 30 jun 2014, at 18:43, Jaroslav Bachorik wrote: >>> >>>> Please, review the following test change. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>>> >>>> Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From staffan.larsen at oracle.com Tue Jul 1 09:37:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 11:37:33 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: <53B279BC.6040002@oracle.com> References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> <53B279BC.6040002@oracle.com> Message-ID: On 1 jul 2014, at 11:05, Jaroslav Bachorik wrote: > On 07/01/2014 10:54 AM, Staffan Larsen wrote: >> >> On 1 jul 2014, at 10:29, Jaroslav Bachorik wrote: >> >>> On 07/01/2014 08:17 AM, Staffan Larsen wrote: >>>> Jaroslav, >>>> >>>> Great cleanup! >>>> >>>> How about using Process.destroyForcibly() instead of sending the ?shutdown? message? Maybe not as ?nice?, but much less code. >>> >>> The target process needs to hang around for a while till the test tries to shut it down. We would need to put a monitor wait there and rely on the OS being able to shut the process down. >> >> Not sure what you mean. Why can?t we terminate the process at the same place we call RunnerUtil.stopApplication()? > > The target application does nothing except of waiting to be shut down. It needs to hang around for the test to be able to attach to it. It used to listen on a socket to receive the shutdown message, now it reads from stdin to block and wait for shutdown. If the read from stdin is removed we would need to add another wait mechanism to make sure the application is alive until the test shuts it down. Right. I would suggest a simple "for(;;) Thread.sleep(1000);? loop for this. > >> >>> The Process.destroyForcibly() spec leaves it to the OS specific implementations to do the right thing. For the major OSes it seems to force kill the process but I'm not sure about eg. embedded devices. >> >> I think the idea of Process.destroyForcibly() is that we /can/ rely on it. If we can?t rely on our own implementation, then the API is not very usable. > > Might be the case - > ... > * The default implementation of this method invokes {@link #destroy} > * and so may not forcibly terminate the process. Concrete implementations > * of this class are strongly encouraged to override this method with a > * compliant implementation. > ... > > If it can be confirmed that a process will always be forcibly destroyed I have nothing against using this API call instead of hand-crafting the shutdown mechanism. All of the implementation of Process in the JDK do provide methods for forcibly terminating the process. The above reference to a default implementation is for allowing other Process implementation outside of the JDK. Our testing would never encounter those. /Staffan > > -JB- > >> >>> >>>> >>>> test/sun/tools/jstatd/JstatdTest.java: >>>> 323 port = Integer.toString(31111); //Utils.getFreePort()); >>>> Looks like a mistake? >>> >>> Definitely a mistake :( Thanks for spotting it! >>> >>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 >> >> Looks good! >> >> Thanks, >> /Staffan >> >> >>> >>> -JB- >>> >>>> >>>> >>>> /Staffan >>>> >>>> >>>> On 30 jun 2014, at 18:43, Jaroslav Bachorik wrote: >>>> >>>>> Please, review the following test change. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>>>> >>>>> Intricate log parsing in order to get an application PID is replaced with the new Process.getPid() API call. While doing this cleanup it also become obvious that it was unnecessary to start a socket server for each launched test application just in order to shut it down when the same functionality can be achieved through the usage of stdin/stdout provided by the Process instance. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jul 1 11:44:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 13:44:43 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> <09FCC0B8-CC24-488B-99C7-66D3D17267AE@oracle.com> Message-ID: <6460809F-BD67-46F9-B2B7-81C6E136E4FE@oracle.com> I?m still looking for a Review of this test code. Thanks, /Staffan On 23 jun 2014, at 10:33, Staffan Larsen wrote: > Fancy! > > new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ > > /Staffan > > On 18 jun 2014, at 13:59, Peter Allwin wrote: > >> This looks a lot better! >> >> (Since we?re using fancy new features we could use streams to find the connector instance) >> >> AttachingConnector ac = Bootstrap.virtualMachineManager().attachingConnectors() >> .stream() >> .filter(c -> c.name().equals("com.sun.jdi.ProcessAttach")) >> .findFirst() >> .orElseThrow(() -> new RuntimeException("Unable to locate ProcessAttachingConnector")); >> >> Thanks! >> /peter >> >> On 17 Jun 2014, at 19:46, Staffan Larsen wrote: >> >>> Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ >>> >>> Thanks, >>> /Staffan >>> >>> On 17 jun 2014, at 15:12, Staffan Larsen wrote: >>> >>>> >>>> On 17 jun 2014, at 15:03, Alan Bateman wrote: >>>> >>>>> On 17/06/2014 13:35, Staffan Larsen wrote: >>>>>> : >>>>>> >>>>>> It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. >>>>>> >>>>>> Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. >>>>>> >>>>>> >>>>> Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. >>>> >>>> Ah, I see. I misunderstood your comment. >>>> >>>> I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. >>>> >>>> /Staffan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Jul 1 11:54:44 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Jul 2014 15:54:44 +0400 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <6460809F-BD67-46F9-B2B7-81C6E136E4FE@oracle.com> References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> <09FCC0B8-CC24-488B-99C7-66D3D17267AE@oracle.com> <6460809F-BD67-46F9-B2B7-81C6E136E4FE@oracle.com> Message-ID: <53B2A184.8060901@oracle.com> Staffan, Looks good for me. -Dmitry On 2014-07-01 15:44, Staffan Larsen wrote: > I?m still looking for a Review of this test code. > > Thanks, > /Staffan > > On 23 jun 2014, at 10:33, Staffan Larsen > wrote: > >> Fancy! >> >> new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ >> >> /Staffan >> >> On 18 jun 2014, at 13:59, Peter Allwin > > wrote: >> >>> This looks a lot better! >>> >>> (Since we?re using fancy new features we could use streams to find >>> the connector instance) >>> >>> AttachingConnector ac = >>> Bootstrap.virtualMachineManager().attachingConnectors() >>> .stream() >>> .filter(c -> c.name().equals("com.sun.jdi.ProcessAttach")) >>> .findFirst() >>> .orElseThrow(() -> new RuntimeException("Unable to locate >>> ProcessAttachingConnector")); >>> >>> Thanks! >>> /peter >>> >>> On 17 Jun 2014, at 19:46, Staffan Larsen >> > wrote: >>> >>>> Here is a rewrite of the test in Java instead of a shell script. >>>> Should be easier to maintain. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 17 jun 2014, at 15:12, Staffan Larsen >>> > wrote: >>>> >>>>> >>>>> On 17 jun 2014, at 15:03, Alan Bateman >>>> > wrote: >>>>> >>>>>> On 17/06/2014 13:35, Staffan Larsen wrote: >>>>>>> : >>>>>>> >>>>>>> It could be a timing issue, but in the other direction. If cygwin >>>>>>> hasn?t yet started the real windows process when I run ps, then >>>>>>> maybe ps will not list it. But given the ?sleep 2? before the ps >>>>>>> invocation, the process should have had time to started. No >>>>>>> guarantees of course. >>>>>>> >>>>>>> Making the sleep shorter will not help as the process we are >>>>>>> starting will not terminate until we tell it to. >>>>>>> >>>>>>> >>>>>> Okay, although what I was suggesting is to use your patch but >>>>>> additionally move the sleep at L79 into the new while loop so that >>>>>> it doesn't spin quickly through the 10 iterations. That would give >>>>>> the test 10 attempts (and 10 seconds) to get the pid. >>>>> >>>>> Ah, I see. I misunderstood your comment. >>>>> >>>>> I started looking at rewriting the test in pure Java instead of the >>>>> shell script. With the new Process.getPid() this looks like the >>>>> best approach. I?ll come back with a new review request soon. >>>>> >>>>> /Staffan >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Tue Jul 1 12:09:18 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 14:09:18 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> <53B279BC.6040002@oracle.com> Message-ID: <53B2A4EE.5030507@oracle.com> On 07/01/2014 11:37 AM, Staffan Larsen wrote: > > On 1 jul 2014, at 11:05, Jaroslav Bachorik > wrote: > >> On 07/01/2014 10:54 AM, Staffan Larsen wrote: >>> >>> On 1 jul 2014, at 10:29, Jaroslav Bachorik >>> > >>> wrote: >>> >>>> On 07/01/2014 08:17 AM, Staffan Larsen wrote: >>>>> Jaroslav, >>>>> >>>>> Great cleanup! >>>>> >>>>> How about using Process.destroyForcibly() instead of sending the >>>>> ?shutdown? message? Maybe not as ?nice?, but much less code. >>>> >>>> The target process needs to hang around for a while till the test >>>> tries to shut it down. We would need to put a monitor wait there and >>>> rely on the OS being able to shut the process down. >>> >>> Not sure what you mean. Why can?t we terminate the process at the >>> same place we call RunnerUtil.stopApplication()? >> >> The target application does nothing except of waiting to be shut down. >> It needs to hang around for the test to be able to attach to it. It >> used to listen on a socket to receive the shutdown message, now it >> reads from stdin to block and wait for shutdown. If the read from >> stdin is removed we would need to add another wait mechanism to make >> sure the application is alive until the test shuts it down. > > Right. I would suggest a simple "for(;;) Thread.sleep(1000);? loop for this. > >> >>> >>>> The Process.destroyForcibly() spec leaves it to the OS specific >>>> implementations to do the right thing. For the major OSes it seems >>>> to force kill the process but I'm not sure about eg. embedded devices. >>> >>> I think the idea of Process.destroyForcibly() is that we /can/ rely >>> on it. If we can?t rely on our own implementation, then the API is >>> not very usable. >> >> Might be the case - >> ... >> * The default implementation of this method invokes {@link #destroy} >> * and so may not forcibly terminate the process. Concrete implementations >> * of this class are strongly encouraged to override this method with a >> * compliant implementation. >> ... >> >> If it can be confirmed that a process will always be forcibly >> destroyed I have nothing against using this API call instead of >> hand-crafting the shutdown mechanism. > > All of the implementation of Process in the JDK do provide methods for > forcibly terminating the process. The above reference to a default > implementation is for allowing other Process implementation outside of > the JDK. Our testing would never encounter those. Yes, this sounds reasonable. Unfortunately, Process.destroyForcibly() sets the application's exit code to 143 and it makes a lot of the tests fail :( I would better leave it at checking the stdin for the shutdown message, even though it requires more code. -JB- > > /Staffan > >> >> -JB- >> >>> >>>> >>>>> >>>>> test/sun/tools/jstatd/JstatdTest.java: >>>>> 323 port = Integer.toString(31111); >>>>> //Utils.getFreePort()); >>>>> Looks like a mistake? >>>> >>>> Definitely a mistake :( Thanks for spotting it! >>>> >>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 >>> >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>> >>>> >>>> -JB- >>>> >>>>> >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 30 jun 2014, at 18:43, Jaroslav Bachorik >>>>> >>>> > wrote: >>>>> >>>>>> Please, review the following test change. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>>>>> >>>>>> Intricate log parsing in order to get an application PID is >>>>>> replaced with the new Process.getPid() API call. While doing this >>>>>> cleanup it also become obvious that it was unnecessary to start a >>>>>> socket server for each launched test application just in order to >>>>>> shut it down when the same functionality can be achieved through >>>>>> the usage of stdin/stdout provided by the Process instance. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- > From staffan.larsen at oracle.com Tue Jul 1 12:14:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 14:14:41 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: <53B2A4EE.5030507@oracle.com> References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> <53B279BC.6040002@oracle.com> <53B2A4EE.5030507@oracle.com> Message-ID: On 1 jul 2014, at 14:09, Jaroslav Bachorik wrote: > On 07/01/2014 11:37 AM, Staffan Larsen wrote: >> >> On 1 jul 2014, at 11:05, Jaroslav Bachorik > > wrote: >> >>> On 07/01/2014 10:54 AM, Staffan Larsen wrote: >>>> >>>> On 1 jul 2014, at 10:29, Jaroslav Bachorik >>>> > >>>> wrote: >>>> >>>>> On 07/01/2014 08:17 AM, Staffan Larsen wrote: >>>>>> Jaroslav, >>>>>> >>>>>> Great cleanup! >>>>>> >>>>>> How about using Process.destroyForcibly() instead of sending the >>>>>> ?shutdown? message? Maybe not as ?nice?, but much less code. >>>>> >>>>> The target process needs to hang around for a while till the test >>>>> tries to shut it down. We would need to put a monitor wait there and >>>>> rely on the OS being able to shut the process down. >>>> >>>> Not sure what you mean. Why can?t we terminate the process at the >>>> same place we call RunnerUtil.stopApplication()? >>> >>> The target application does nothing except of waiting to be shut down. >>> It needs to hang around for the test to be able to attach to it. It >>> used to listen on a socket to receive the shutdown message, now it >>> reads from stdin to block and wait for shutdown. If the read from >>> stdin is removed we would need to add another wait mechanism to make >>> sure the application is alive until the test shuts it down. >> >> Right. I would suggest a simple "for(;;) Thread.sleep(1000);? loop for this. >> >>> >>>> >>>>> The Process.destroyForcibly() spec leaves it to the OS specific >>>>> implementations to do the right thing. For the major OSes it seems >>>>> to force kill the process but I'm not sure about eg. embedded devices. >>>> >>>> I think the idea of Process.destroyForcibly() is that we /can/ rely >>>> on it. If we can?t rely on our own implementation, then the API is >>>> not very usable. >>> >>> Might be the case - >>> ... >>> * The default implementation of this method invokes {@link #destroy} >>> * and so may not forcibly terminate the process. Concrete implementations >>> * of this class are strongly encouraged to override this method with a >>> * compliant implementation. >>> ... >>> >>> If it can be confirmed that a process will always be forcibly >>> destroyed I have nothing against using this API call instead of >>> hand-crafting the shutdown mechanism. >> >> All of the implementation of Process in the JDK do provide methods for >> forcibly terminating the process. The above reference to a default >> implementation is for allowing other Process implementation outside of >> the JDK. Our testing would never encounter those. > > Yes, this sounds reasonable. Unfortunately, Process.destroyForcibly() sets the application's exit code to 143 and it makes a lot of the tests fail :( > > I would better leave it at checking the stdin for the shutdown message, even though it requires more code. OK. I just want us to consider using it for future tests. /Staffan > > -JB- > > > >> >> /Staffan >> >>> >>> -JB- >>> >>>> >>>>> >>>>>> >>>>>> test/sun/tools/jstatd/JstatdTest.java: >>>>>> 323 port = Integer.toString(31111); >>>>>> //Utils.getFreePort()); >>>>>> Looks like a mistake? >>>>> >>>>> Definitely a mistake :( Thanks for spotting it! >>>>> >>>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 >>>> >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 30 jun 2014, at 18:43, Jaroslav Bachorik >>>>>> >>>>> > wrote: >>>>>> >>>>>>> Please, review the following test change. >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>>>>>> >>>>>>> Intricate log parsing in order to get an application PID is >>>>>>> replaced with the new Process.getPid() API call. While doing this >>>>>>> cleanup it also become obvious that it was unnecessary to start a >>>>>>> socket server for each launched test application just in order to >>>>>>> shut it down when the same functionality can be achieved through >>>>>>> the usage of stdin/stdout provided by the Process instance. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >> > From staffan.larsen at oracle.com Tue Jul 1 12:34:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 14:34:02 +0200 Subject: RFR: JDK-8048710 Use ServiceLoader for the jvmstat protocols In-Reply-To: <53B16561.4020506@oracle.com> References: <53B16561.4020506@oracle.com> Message-ID: <74F7B3F8-491E-46B4-8A80-F2A69F3D3867@oracle.com> Thanks, Alan. On 30 jun 2014, at 15:25, Alan Bateman wrote: > On 30/06/2014 12:22, Staffan Larsen wrote: >> All, >> >> The jvmstat implementation has three different protocols (file, local and rmi). These protocol implementations are currently loaded with Class.forName() using a specific scheme to create the class name. A more standard approach is to use ServiceLoader for this instead. This also makes it easier to break out different implementation classes for different packagings. >> >> webrev: http://cr.openjdk.java.net/~sla/8048710/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8048710 >> > This looks good to me. > > One comment on monitoredHostServiceLoader is that it specifies the class loader as null and so will search the system class loader. I think this is okay as it provides a bit of flexibility to deploy other protocols on the class path if needed. > > One other comment is that using ServiceLoader with a security manager often requires additional permissions to be granted because it involve scanning the class path. I don't know if we have any tests that use jvmstat with a security manager, just something to mention in case it comes up. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Tue Jul 1 12:35:07 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Jul 2014 08:35:07 -0400 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B26555.5090203@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> Message-ID: <53B2AAFB.5070306@oracle.com> Hi Erik, Consider switching to System.nanoTime; it is not sensitive to clock changes and avoids leaving a land mine that may cause a spurious non-repeatable test failure. 'Deducing it from the log' means there is a failure and creates probably an hour or two of work for some quality engineer and burns a couple of hours re-running the test run. Roger On 7/1/2014 3:37 AM, Erik Gahlin wrote: > > >> JavaProcess.waitForRemoval: How about using timestamps >> (currentTimeMillis()) before the loop and for each ite >> ration to determine if the timeout has expired (instead of "time+=100?)? >> > The code now uses currentTimeMillis(). Premature timeouts due to clock > changes can be deduced from the log. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jul 1 13:00:18 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 15:00:18 +0200 Subject: RFR 8048193: [tests] Replace JPS and stdout based PID retrieval by Process.getPid() In-Reply-To: References: <53B193A7.2020109@oracle.com> <217A09C7-92F0-427B-AEB2-794EC5B54F3D@oracle.com> <53B27177.3060100@oracle.com> <53B279BC.6040002@oracle.com> <53B2A4EE.5030507@oracle.com> Message-ID: <53B2B0E2.9060904@oracle.com> On 07/01/2014 02:14 PM, Staffan Larsen wrote: > > On 1 jul 2014, at 14:09, Jaroslav Bachorik wrote: > >> On 07/01/2014 11:37 AM, Staffan Larsen wrote: >>> >>> On 1 jul 2014, at 11:05, Jaroslav Bachorik >> > wrote: >>> >>>> On 07/01/2014 10:54 AM, Staffan Larsen wrote: >>>>> >>>>> On 1 jul 2014, at 10:29, Jaroslav Bachorik >>>>> > >>>>> wrote: >>>>> >>>>>> On 07/01/2014 08:17 AM, Staffan Larsen wrote: >>>>>>> Jaroslav, >>>>>>> >>>>>>> Great cleanup! >>>>>>> >>>>>>> How about using Process.destroyForcibly() instead of sending the >>>>>>> ?shutdown? message? Maybe not as ?nice?, but much less code. >>>>>> >>>>>> The target process needs to hang around for a while till the test >>>>>> tries to shut it down. We would need to put a monitor wait there and >>>>>> rely on the OS being able to shut the process down. >>>>> >>>>> Not sure what you mean. Why can?t we terminate the process at the >>>>> same place we call RunnerUtil.stopApplication()? >>>> >>>> The target application does nothing except of waiting to be shut down. >>>> It needs to hang around for the test to be able to attach to it. It >>>> used to listen on a socket to receive the shutdown message, now it >>>> reads from stdin to block and wait for shutdown. If the read from >>>> stdin is removed we would need to add another wait mechanism to make >>>> sure the application is alive until the test shuts it down. >>> >>> Right. I would suggest a simple "for(;;) Thread.sleep(1000);? loop for this. >>> >>>> >>>>> >>>>>> The Process.destroyForcibly() spec leaves it to the OS specific >>>>>> implementations to do the right thing. For the major OSes it seems >>>>>> to force kill the process but I'm not sure about eg. embedded devices. >>>>> >>>>> I think the idea of Process.destroyForcibly() is that we /can/ rely >>>>> on it. If we can?t rely on our own implementation, then the API is >>>>> not very usable. >>>> >>>> Might be the case - >>>> ... >>>> * The default implementation of this method invokes {@link #destroy} >>>> * and so may not forcibly terminate the process. Concrete implementations >>>> * of this class are strongly encouraged to override this method with a >>>> * compliant implementation. >>>> ... >>>> >>>> If it can be confirmed that a process will always be forcibly >>>> destroyed I have nothing against using this API call instead of >>>> hand-crafting the shutdown mechanism. >>> >>> All of the implementation of Process in the JDK do provide methods for >>> forcibly terminating the process. The above reference to a default >>> implementation is for allowing other Process implementation outside of >>> the JDK. Our testing would never encounter those. >> >> Yes, this sounds reasonable. Unfortunately, Process.destroyForcibly() sets the application's exit code to 143 and it makes a lot of the tests fail :( >> >> I would better leave it at checking the stdin for the shutdown message, even though it requires more code. > > OK. I just want us to consider using it for future tests. Sure. Thanks! -JB- > > /Staffan > >> >> -JB- >> >> >> >>> >>> /Staffan >>> >>>> >>>> -JB- >>>> >>>>> >>>>>> >>>>>>> >>>>>>> test/sun/tools/jstatd/JstatdTest.java: >>>>>>> 323 port = Integer.toString(31111); >>>>>>> //Utils.getFreePort()); >>>>>>> Looks like a mistake? >>>>>> >>>>>> Definitely a mistake :( Thanks for spotting it! >>>>>> >>>>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.01 >>>>> >>>>> Looks good! >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 30 jun 2014, at 18:43, Jaroslav Bachorik >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> Please, review the following test change. >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8048193 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8048193/webrev.00 >>>>>>>> >>>>>>>> Intricate log parsing in order to get an application PID is >>>>>>>> replaced with the new Process.getPid() API call. While doing this >>>>>>>> cleanup it also become obvious that it was unnecessary to start a >>>>>>>> socket server for each launched test application just in order to >>>>>>>> shut it down when the same functionality can be achieved through >>>>>>>> the usage of stdin/stdout provided by the Process instance. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>> >> > From daniel.daugherty at oracle.com Tue Jul 1 13:17:56 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 01 Jul 2014 07:17:56 -0600 Subject: RFR (XS) fix for a safepoint deadlock (8047720) In-Reply-To: <53B21D10.5090501@oracle.com> References: <53AD9949.9030601@oracle.com> <53B0F6A9.1060109@oracle.com> <53B0FB78.6060506@oracle.com> <53B199A8.7040003@oracle.com> <53B21D10.5090501@oracle.com> Message-ID: <53B2B504.9090405@oracle.com> On 6/30/14 8:29 PM, David Holmes wrote: > Hi Dan, > > I disagree on a few points but lets wait to see what Markus' work shows. Thanks. > Though I would be surprised if it detects the indirect safepoint > blocking caused by submitting a synchronous, safepoint-needing, VM op. I did not mean to imply that Markus' work would have helped find this bug. However, in fixing this bug I didn't want to add something that Markus would later want to re-implement in a different way. Dan > > David > > On 1/07/2014 3:08 AM, Daniel D. Daugherty wrote: >> David, >> >> Thanks for the review. Obviously I can't list you as a reviewer >> since I already pushed the changeset... >> >> >> On 6/29/14 11:54 PM, David Holmes wrote: >>> Correction ... >>> >>> On 30/06/2014 3:33 PM, David Holmes wrote: >>>> Hi Dan, >>>> >>>> I see this has already gone in but I think it is worth looking >>>> closer at >>>> this. >>>> >>>> On 28/06/2014 2:18 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a fix ready for the following bug: >>>>> >>>>> 8047720 Xprof hangs on Solaris >>>>> https://bugs.openjdk.java.net/browse/JDK-8047720 >>>>> >>>>> Here is the webrev URL: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8047720-webrev/0-jdk9-hs-rt/ >>>>> >>>>> This deadlock occurred between the following threads: >>>>> >>>>> Main thread - Trying to stop the WatcherThread as part of >>>>> shutting down the VM; this thread is blocked >>>>> on the PeriodicTask_lock which keeps it from >>>>> reaching a safepoint. >>>>> WatcherThread - Requested a VM_ForceSafepoint to complete >>>>> a JavaThread::java_suspend() call as part >>>>> of a FlatProfiler record_thread_ticks() >>>>> call; this thread owns the PeriodicTask_lock >>>>> since it is processing a periodic task. >>>>> VMThread - Trying to start a safepoint; this thread is >>>>> blocked waiting for the Main thread to reach >>>>> a safepoint. >>>>> >>>>> The PeriodicTask_lock is one of the VM internal locks and is >>>>> typically managed using Mutex::_no_safepoint_check_flag to >>>>> avoid deadlocks. Yes, the irony is dripping on the floor... :-) >>>> >>>> What was overlooked here is that the holder of a lock that is acquired >>>> without safepoint checks, must never block at a safepoint whilst >>>> holding >>>> that lock. >> >> I'm not sure about the above rule when you're talking about >> internal VM threads that are really JavaThreads. JavaThreads >> can run into all kinds of our special logic when doing thread >> state transitions and the like. JavaThreads can also post JVM/TI >> events which can lead to blocking at safepoints or blocking on >> JVM/TI raw monitors in event handlers, etc... >> >> >> >>>> In this case the blocking is indirect, caused by the >>>> synchronous nature of the VM_Operation, rather than a direct result of >>>> "blocking for the safepoint" (which the WatcherThread does not >>>> participate in). >> >> Right. The WatcherThread intentionally does not participate in >> safepoints when using the PeriodicTask_lock. To me, that means >> that other threads using that lock should not participate in >> the safepoint protocol. >> >> I believe we're trying to be consistent about how we use locks >> with respect to honoring the safepoint protocol or not. Markus G >> has a bug fix in process where he's trying to add sanity checks >> that detect inconsistent use of locks. In this particular case, >> I believe that the Main thread's use of the PeriodicTask_lock >> with the safepoint protocol enabled would be seen as inconsistent. >> However, I may not have all the details for what Markus is doing. >> >> >>>> I wonder if the WatcherThread should really be using >>>> the async variant of VM_ForceSafepoint here? >> >> The WatcherThread is trying to do a JavaThread::java_suspend() >> call. JavaThread::java_suspend() cannot return to the caller >> until it is sure that the target thread will not execute any >> more bytecodes. Switching to an async VM_ForceSafepoint would >> break that invariant and cause subtle deadlocks because a target >> JavaThread could acquire a Java monitor when the suspend >> requesting thread thinks it is suspended. Been down that road >> before and it is not pretty. >> >> >> >>>> >>>>> The interesting part of this deadlock is that I think that it >>>>> is possible for other periodic tasks to hit it. Anything that >>>>> causes the WatcherThread to start a safepoint while processing >>>>> a periodic task should be susceptible to this race. Think about >>>>> the -XX:+DeoptimizeALot option and how it causes VM_Deopt >>>>> requests on thread state transitions... Interesting... >>>> >>>> I don't think so. You need three threads involved to get the deadlock. >>> >>> But that isn't the point. As you state this deadlock, at VM shutdown, >>> could impact any synchronous safepoint operations executed by the >>> WatcherThread. >> >> Right. The problem is that the WatcherThread holds the >> PeriodicTask_lock across the potential for VM operations >> so we have to be very, very careful with non-WatcherThread >> uses of that lock to avoid deadlocks. >> >> >> >>> >>> That aside ... >>> >>>> In the current case the main thread's locking of the PeriodicTask_lock >>>> without a safepoint check is what causes the problem - that >>>> violates the >>>> rules surrounding use of "no safepoint checks". The other methods >>>> that a >>>> JavaThread might call that acquire the PeriodicTask_lock do perform >>>> the >>>> safepoint checks, so they wouldn't deadlock. Hence it seems to me that >>>> only WatcherThread::stop can lead to this problem. And as >>>> WatcherThread::stop is only called from before_exit, and that can only >>>> be called once, it seems to me that we could/should actually >>>> acquire the >>>> lock with a safepoint check. >> >> Agreed that only the WatcherThread::stop() call can lead to this >> deadlock >> because it is that call that catches the PeriodicTask_lock being held >> across a VM operation. That's the heart of this deadlock and we're only >> differing on how to solve that deadlock. >> >> The primary purpose of WatcherThread::stop() is setting the >> _should_terminate >> flag so that the WatcherThread knows that it should stop dispatching >> periodic >> tasks. _should_terminate is already volatile and the existing code >> does an >> OrderAccess::fence() just to be sure the update is seen. The secondary >> purpose of WatcherThread::stop() is waking up the WatcherThread so >> that it >> stops in a more timely fashion. The WatcherThread waits for a fixed >> amount of >> time so it will eventually wake up and see the new _should_terminate >> value. >> >> If caller of WatcherThread::stop() cannot get the PeriodicTask_lock, >> then >> that means the WatcherThread is active so WatcherThread::stop() only has >> to set the flag. It is possible for the WatcherThread::stop() call to >> race >> with the WatcherThread dropping the PeriodicTask_lock and waiting. In >> that >> case, the WatcherThread waits for a fixed amount of time so it will >> eventually wake up and see the new _should_terminate value. >> >> I intentionally don't want WatcherThread::stop() to honor the safepoint >> protocol when accessing the PeriodicTask_lock so that we remain >> consistent >> with our use of that lock. See my comments above about Markus' work >> in this >> area. >> >> WatcherThread::stop() will honor the safepoint protocol a couple of >> lines >> down from my changes: >> >> 1380 // it is ok to take late safepoints here, if needed >> 1381 MutexLocker mu(Terminator_lock); >> >> The subsequent wait() loop also honors the safepoint protocol. >> >> Dan >> >> >>> >>> David >>> ----- >>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> Testing: >>>>> - I found a way to add delays to the right spots in the >>>>> VM to make the deadlock reproduce in just about every >>>>> run of the test associated with the bug. The new >>>>> os::naked_short_sleep() function is your friend. Thanks >>>>> to Fred for adding that! See the bug report for the >>>>> debugging diffs. >>>>> - 72 hours of running the test in the bug report with >>>>> delays enabled for product, fastdebug and jvmg bits >>>>> in parallel on my Solaris X86 server. >>>>> - JPRT test run >>>>> - Aurora Adhoc results are in process; we're having issues >>>>> with both a broken testbase build and infra problems >>>>> with results not being uploaded. >>>>> >> From daniel.daugherty at oracle.com Tue Jul 1 13:39:02 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 01 Jul 2014 07:39:02 -0600 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: References: <41B20693-4703-4AAA-9A02-905FE28F7F2E@oracle.com> <53A00E53.5040106@oracle.com> <5AA0206E-6C89-40A0-84FF-F13ADD8CF4D1@oracle.com> <53A03CAB.6050206@oracle.com> <09D86058-1054-42C2-9689-7E6D4726A789@oracle.com> <09FCC0B8-CC24-488B-99C7-66D3D17267AE@oracle.com> Message-ID: <53B2B9F6.4040005@oracle.com> On 6/23/14 2:33 AM, Staffan Larsen wrote: > Fancy! > > new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ > test/com/sun/jdi/ProcessAttachTest.java New test looks very good. There's a couple of really long lines, but I can't think of a way to break the lines that makes sense with this new streams coding style. Thumbs up. Dan > > /Staffan > > On 18 jun 2014, at 13:59, Peter Allwin > wrote: > >> This looks a lot better! >> >> (Since we?re using fancy new features we could use streams to find >> the connector instance) >> >> AttachingConnector ac = >> Bootstrap.virtualMachineManager().attachingConnectors() >> .stream() >> .filter(c -> c.name().equals("com.sun.jdi.ProcessAttach")) >> .findFirst() >> .orElseThrow(() -> new RuntimeException("Unable to locate >> ProcessAttachingConnector")); >> >> Thanks! >> /peter >> >> On 17 Jun 2014, at 19:46, Staffan Larsen > > wrote: >> >>> Here is a rewrite of the test in Java instead of a shell script. >>> Should be easier to maintain. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ >>> >>> >>> Thanks, >>> /Staffan >>> >>> On 17 jun 2014, at 15:12, Staffan Larsen >> > wrote: >>> >>>> >>>> On 17 jun 2014, at 15:03, Alan Bateman >>> > wrote: >>>> >>>>> On 17/06/2014 13:35, Staffan Larsen wrote: >>>>>> : >>>>>> >>>>>> It could be a timing issue, but in the other direction. If cygwin >>>>>> hasn?t yet started the real windows process when I run ps, then >>>>>> maybe ps will not list it. But given the ?sleep 2? before the ps >>>>>> invocation, the process should have had time to started. No >>>>>> guarantees of course. >>>>>> >>>>>> Making the sleep shorter will not help as the process we are >>>>>> starting will not terminate until we tell it to. >>>>>> >>>>>> >>>>> Okay, although what I was suggesting is to use your patch but >>>>> additionally move the sleep at L79 into the new while loop so that >>>>> it doesn't spin quickly through the 10 iterations. That would give >>>>> the test 10 attempts (and 10 seconds) to get the pid. >>>> >>>> Ah, I see. I misunderstood your comment. >>>> >>>> I started looking at rewriting the test in pure Java instead of the >>>> shell script. With the new Process.getPid() this looks like the >>>> best approach. I?ll come back with a new review request soon. >>>> >>>> /Staffan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Tue Jul 1 15:03:21 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 1 Jul 2014 08:03:21 -0700 (PDT) Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows Message-ID: <92ee45fb-71d5-4a89-802e-a6e30ba396dd@default> Staffan, since I'm working on JDK-8048892 right now I happen to know test/com/sun/jdi/ProcessAttachTest.sh has used @debuggeeVMOptions. ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(...) will not add test.vm.options and test.java.options to the command line. You need to use: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(...)) You can look at the ProcessTools.executeTestJvm() for more information. Thanks, Katja ----- Original Message ----- From: daniel.daugherty at oracle.com To: staffan.larsen at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, July 1, 2014 3:37:38 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows On 6/23/14 2:33 AM, Staffan Larsen wrote: Fancy! new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ test/com/sun/jdi/ProcessAttachTest.java New test looks very good. There's a couple of really long lines, but I can't think of a way to break the lines that makes sense with this new streams coding style. Thumbs up. Dan /Staffan On 18 jun 2014, at 13:59, Peter Allwin < peter.allwin at oracle.com > wrote: This looks a lot better! (Since we?re using fancy new features we could use streams to find the connector instance) AttachingConnector ac = Bootstrap.virtualMachineManager().attachingConnectors() .stream() .filter(c -> c.name().equals( "com.sun.jdi.ProcessAttach" )) .findFirst() .orElseThrow(() -> new RuntimeException( "Unable to locate ProcessAttachingConnector" )); Thanks! /peter On 17 Jun 2014, at 19:46, Staffan Larsen < staffan.larsen at oracle.com > wrote: Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ Thanks, /Staffan On 17 jun 2014, at 15:12, Staffan Larsen < staffan.larsen at oracle.com > wrote: On 17 jun 2014, at 15:03, Alan Bateman < Alan.Bateman at oracle.com > wrote: On 17/06/2014 13:35, Staffan Larsen wrote: : It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. Ah, I see. I misunderstood your comment. I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jul 1 15:20:53 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 17:20:53 +0200 Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows In-Reply-To: <92ee45fb-71d5-4a89-802e-a6e30ba396dd@default> References: <92ee45fb-71d5-4a89-802e-a6e30ba396dd@default> Message-ID: <44248872-C8CB-4278-956C-9A8CD74A5E2C@oracle.com> Katja, I intentionally did not include javaoptions when launching the new JVMs since I could not think of any options that would affect how -agentlib:jdwp=suspend=y|n works or does not work (which is what this test verifies). /Staffan On 1 jul 2014, at 17:03, Yekaterina Kantserova wrote: > Staffan, > > since I'm working on JDK-8048892 right now I happen to know test/com/sun/jdi/ProcessAttachTest.sh has used @debuggeeVMOptions. > > ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(...) > > will not add test.vm.options and test.java.options to the command line. You need to use: > > ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(...)) > > You can look at the ProcessTools.executeTestJvm() for more information. > > Thanks, > Katja > > > > ----- Original Message ----- > From: daniel.daugherty at oracle.com > To: staffan.larsen at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Tuesday, July 1, 2014 3:37:38 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: Re: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows > > On 6/23/14 2:33 AM, Staffan Larsen wrote: > Fancy! > > new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ > > test/com/sun/jdi/ProcessAttachTest.java > New test looks very good. There's a couple of really long lines, > but I can't think of a way to break the lines that makes sense > with this new streams coding style. > > Thumbs up. > > Dan > > > > /Staffan > > On 18 jun 2014, at 13:59, Peter Allwin wrote: > > This looks a lot better! > > (Since we?re using fancy new features we could use streams to find the connector instance) > > AttachingConnector ac = Bootstrap.virtualMachineManager().attachingConnectors() > .stream() > .filter(c -> c.name().equals("com.sun.jdi.ProcessAttach")) > .findFirst() > .orElseThrow(() -> new RuntimeException("Unable to locate ProcessAttachingConnector")); > > Thanks! > /peter > > On 17 Jun 2014, at 19:46, Staffan Larsen wrote: > > Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. > > webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ > > Thanks, > /Staffan > > On 17 jun 2014, at 15:12, Staffan Larsen wrote: > > > On 17 jun 2014, at 15:03, Alan Bateman wrote: > > On 17/06/2014 13:35, Staffan Larsen wrote: > : > > It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. > > Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. > > > Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. > > Ah, I see. I misunderstood your comment. > > I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. > > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Tue Jul 1 15:23:49 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 1 Jul 2014 08:23:49 -0700 (PDT) Subject: RFR(S): 8048892: TEST_BUG: shell script tests need to be change to not use retired @debuggeeVMOptions mechanism Message-ID: Hi, Could I please have a review of this fix. webrev: http://cr.openjdk.java.net/~ykantser/8048892/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8048892 The fix is verified internally on all basic platforms. I have also taken the opportunity to re-write com/sun/jdi/SuspendNoFlagTest.sh in java using testlibrary's functionality in order to make the test more compact and easier to maintain. Thanks, Katja From staffan.larsen at oracle.com Tue Jul 1 15:27:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Jul 2014 17:27:41 +0200 Subject: RFR(S): 8048892: TEST_BUG: shell script tests need to be change to not use retired @debuggeeVMOptions mechanism In-Reply-To: References: Message-ID: <724D974B-E850-4724-BED3-BF65879149CE@oracle.com> Looks good! Thanks, /Staffan On 1 jul 2014, at 17:23, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8048892/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048892 > > The fix is verified internally on all basic platforms. I have also taken the opportunity to re-write com/sun/jdi/SuspendNoFlagTest.sh in java using testlibrary's functionality in order to make the test more compact and easier to maintain. > > Thanks, > Katja From yekaterina.kantserova at oracle.com Tue Jul 1 15:29:36 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 1 Jul 2014 08:29:36 -0700 (PDT) Subject: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows Message-ID: <2b7bc04b-5fe7-442d-ba78-d951372c98f1@default> Oh, great, than no worries. // Katja ----- Original Message ----- From: staffan.larsen at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, July 1, 2014 5:20:57 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows Katja, I intentionally did not include javaoptions when launching the new JVMs since I could not think of any options that would affect how -agentlib:jdwp=suspend=y|n works or does not work (which is what this test verifies). /Staffan On 1 jul 2014, at 17:03, Yekaterina Kantserova < yekaterina.kantserova at oracle.com > wrote: Staffan, since I'm working on JDK-8048892 right now I happen to know test/com/sun/jdi/ProcessAttachTest.sh has used @debuggeeVMOptions. ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(...) will not add test.vm.options and test.java.options to the command line. You need to use: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(...)) You can look at the ProcessTools.executeTestJvm() for more information. Thanks, Katja ----- Original Message ----- From: daniel.daugherty at oracle.com To: staffan.larsen at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, July 1, 2014 3:37:38 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR: 8046883 com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows On 6/23/14 2:33 AM, Staffan Larsen wrote: Fancy! new review: http://cr.openjdk.java.net/~sla/8046883/webrev.01/ test/com/sun/jdi/ProcessAttachTest.java New test looks very good. There's a couple of really long lines, but I can't think of a way to break the lines that makes sense with this new streams coding style. Thumbs up. Dan /Staffan On 18 jun 2014, at 13:59, Peter Allwin < peter.allwin at oracle.com > wrote: This looks a lot better! (Since we?re using fancy new features we could use streams to find the connector instance) AttachingConnector ac = Bootstrap.virtualMachineManager().attachingConnectors() .stream() .filter(c -> c.name().equals( "com.sun.jdi.ProcessAttach" )) .findFirst() .orElseThrow(() -> new RuntimeException( "Unable to locate ProcessAttachingConnector" )); Thanks! /peter On 17 Jun 2014, at 19:46, Staffan Larsen < staffan.larsen at oracle.com > wrote: Here is a rewrite of the test in Java instead of a shell script. Should be easier to maintain. webrev: http://cr.openjdk.java.net/~sla/8046883/webrev.00/ Thanks, /Staffan On 17 jun 2014, at 15:12, Staffan Larsen < staffan.larsen at oracle.com > wrote: On 17 jun 2014, at 15:03, Alan Bateman < Alan.Bateman at oracle.com > wrote: On 17/06/2014 13:35, Staffan Larsen wrote: : It could be a timing issue, but in the other direction. If cygwin hasn?t yet started the real windows process when I run ps, then maybe ps will not list it. But given the ?sleep 2? before the ps invocation, the process should have had time to started. No guarantees of course. Making the sleep shorter will not help as the process we are starting will not terminate until we tell it to. Okay, although what I was suggesting is to use your patch but additionally move the sleep at L79 into the new while loop so that it doesn't spin quickly through the 10 iterations. That would give the test 10 attempts (and 10 seconds) to get the pid. Ah, I see. I misunderstood your comment. I started looking at rewriting the test in pure Java instead of the shell script. With the new Process.getPid() this looks like the best approach. I?ll come back with a new review request soon. /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jul 1 15:31:36 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 17:31:36 +0200 Subject: RFR(S): 8048892: TEST_BUG: shell script tests need to be change to not use retired @debuggeeVMOptions mechanism In-Reply-To: References: Message-ID: <53B2D458.2050907@oracle.com> Looks fine. -JB- On 07/01/2014 05:23 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8048892/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048892 > > The fix is verified internally on all basic platforms. I have also taken the opportunity to re-write com/sun/jdi/SuspendNoFlagTest.sh in java using testlibrary's functionality in order to make the test more compact and easier to maintain. > > Thanks, > Katja > From yekaterina.kantserova at oracle.com Tue Jul 1 19:28:13 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 1 Jul 2014 12:28:13 -0700 (PDT) Subject: RFR(S): 8048892: TEST_BUG: shell script tests need to be change to not use retired @debuggeeVMOptions mechanism Message-ID: <059369c0-ffc2-4474-9937-91fc51f76d13@default> Staffan, Jaroslav, thanks for your reviews! Staffan, could you please be my sponsor and push the fix? The patch is attached to this mail. // Katja ----- Original Message ----- From: staffan.larsen at oracle.com To: yekaterina.kantserova at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Tuesday, July 1, 2014 5:27:44 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(S): 8048892: TEST_BUG: shell script tests need to be change to not use retired @debuggeeVMOptions mechanism Looks good! Thanks, /Staffan On 1 jul 2014, at 17:23, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > webrev: http://cr.openjdk.java.net/~ykantser/8048892/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8048892 > > The fix is verified internally on all basic platforms. I have also taken the opportunity to re-write com/sun/jdi/SuspendNoFlagTest.sh in java using testlibrary's functionality in order to make the test more compact and easier to maintain. > > Thanks, > Katja -------------- next part -------------- A non-text attachment was scrubbed... Name: 8048892.patch.zip Type: application/zip Size: 3039 bytes Desc: not available URL: From shanliang.jiang at oracle.com Tue Jul 1 19:47:22 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 01 Jul 2014 21:47:22 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <0d1001cf920e$cff48620$6fdd9260$@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> <0d1001cf920e$cff48620$6fdd9260$@oracle.com> Message-ID: <53B3104A.9010800@oracle.com> I am still thinking to keep the original fix, because: 1) to throw InterruptedException does not fix the test failure, it might give more info for diagnostics. If it was really caused by an InterruptedException, then to fix the issue we still need to know who could interrupt the test main thread, in which case and why, and whether possible to ignore it (skip the test or try again?). 2) the test library is used also by other tests and to modify it might make new fail, it is better to concentrate at first on a single test before knowing the exact cause. Shanliang Christian Tornqvist wrote: > > I can't remember if there was a reason for doing it like this, but it > seems reasonable to not catch the InterruptedException in getOutput(). > > > > Thanks, > > Christian > > > > *From:* Staffan Larsen [mailto:staffan.larsen at oracle.com] > *Sent:* Friday, June 27, 2014 4:49 AM > *To:* shanliang > *Cc:* Jaroslav Bachorik; serviceability-dev at openjdk.java.net > serviceability-dev at openjdk.java.net; Christian Tornqvist > *Subject:* Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java > fails intermittently > > > > It does look suspicious to catch and ignore the InterruptedException, > especially since the OutputAnalyzer constructor will fail in this case. > > > > Christian is the original author of these classes: do you know if > there is a good rationale for doing this? Or should we propagate the > InterruptedException? > > > > Thanks, > > /Staffan > > > > On 26 jun 2014, at 17:24, shanliang > wrote: > > > > Jaroslav Bachorik wrote: > > Hi Shanliang, > > On 06/26/2014 03:15 PM, shanliang wrote: > > Hi, > > Today ProcessTools.executeProcess has the code: > new OutputAnalyzer(pb.start()); > > and OutputAnalyzer constructor calls immediately: > exitValue = process.exitValue(); > > the test got exception because the process did not end. > > > Are you sure about this? > > The OutputAnalyzer constructor, before calling > process.exitValue(), calls ProcessTools.getOutput(process) > which actually does process.waitFor() > > Good catch! > > > A probable explanation would be that process.waitFor() gets > interrupted without the target process actually ending. > > Either the result of ProcessTools.getOutput() should be > checked for null to detect this situation or > ProcessTools.getOutput() should throw a more aggressive > exception when waitFor() gets interrupted. > > It was possible beacause of an InterruptedException, but maybe a > Process issue too. > > process.waitFor() was called by the test main thread, I am > wondering who wanted to interrupt this thread? > > Not know why ProcessTools.getOutput() catches InterruptedException > and then returns null, are there some other tests dependent to > this behavior? otherwise better to not catch InterruptedException. > > I think to keep this modification, it will allow us to get more > information if the bug is reproduced, if getting an > InterruptedException then we need to do more investigation for > why, if no exception then we may rise a question to process.waitFor(). > > Shanliang > > > -JB- > > > > So a direct solution for the test is not to call: > ProcessTools.executeTestJvm(args); > > but: > ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); > Process process = pb.start(); > process.waitFor(); > OutputAnalyzer output = new OutputAnalyzer(process); > > here we do waiting: > process.waitFor(); > before constructing an OutputAnalyzer. > > ProcessTools is a tool class we may have same issue for > other tests > using this class. So we may need to improve the test library. > > bug: https://bugs.openjdk.java.net/browse/JDK-8031554 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ > > > > Thanks, > Shanliang > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Jul 1 20:44:00 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Jul 2014 22:44:00 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53B3104A.9010800@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> <0d1001cf920e$cff48620$6fdd9260$@oracle.com> <53B3104A.9010800@oracle.com> Message-ID: <53B31D90.9080104@oracle.com> Hi Shanliang, On 07/01/2014 09:47 PM, shanliang wrote: > I am still thinking to keep the original fix, because: > 1) to throw InterruptedException does not fix the test failure, it might > give more info for diagnostics. If it was really caused by an > InterruptedException, then to fix the issue we still need to know who > could interrupt the test main thread, in which case and why, and whether > possible to ignore it (skip the test or try again?). I'm sorry but I can't agree with this. The proposed patch does not add anything else than making the InterruptedException visible. Adding process.waitFor() will solve nothing as it is already called by ProcessTools.getOutput(process) while creating OutputAnalyzer. > 2) the test library is used also by other tests and to modify it might > make new fail, it is better to concentrate at first on a single test > before knowing the exact cause. I wouldn't expect new failures - when an InterruptedException was thrown the ProcessTools.executeTestJvm(args) returned null. Either the test would fail with NPE or custom assert - it makes no sense to work with "null" process. IMO, this should be fixed in the test library. -JB- > > Shanliang > > Christian Tornqvist wrote: >> >> I can?t remember if there was a reason for doing it like this, but it >> seems reasonable to not catch the InterruptedException in getOutput(). >> >> Thanks, >> >> Christian >> >> *From:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >> *Sent:* Friday, June 27, 2014 4:49 AM >> *To:* shanliang >> *Cc:* Jaroslav Bachorik; serviceability-dev at openjdk.java.net >> serviceability-dev at openjdk.java.net; Christian Tornqvist >> *Subject:* Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java >> fails intermittently >> >> It does look suspicious to catch and ignore the InterruptedException, >> especially since the OutputAnalyzer constructor will fail in this case. >> >> Christian is the original author of these classes: do you know if >> there is a good rationale for doing this? Or should we propagate the >> InterruptedException? >> >> Thanks, >> >> /Staffan >> >> On 26 jun 2014, at 17:24, shanliang > > wrote: >> >> >> >> Jaroslav Bachorik wrote: >> >> Hi Shanliang, >> >> On 06/26/2014 03:15 PM, shanliang wrote: >> >> Hi, >> >> Today ProcessTools.executeProcess has the code: >> new OutputAnalyzer(pb.start()); >> >> and OutputAnalyzer constructor calls immediately: >> exitValue = process.exitValue(); >> >> the test got exception because the process did not end. >> >> >> Are you sure about this? >> >> The OutputAnalyzer constructor, before calling >> process.exitValue(), calls ProcessTools.getOutput(process) >> which actually does process.waitFor() >> >> Good catch! >> >> >> A probable explanation would be that process.waitFor() gets >> interrupted without the target process actually ending. >> >> Either the result of ProcessTools.getOutput() should be >> checked for null to detect this situation or >> ProcessTools.getOutput() should throw a more aggressive >> exception when waitFor() gets interrupted. >> >> It was possible beacause of an InterruptedException, but maybe a >> Process issue too. >> >> process.waitFor() was called by the test main thread, I am >> wondering who wanted to interrupt this thread? >> >> Not know why ProcessTools.getOutput() catches InterruptedException >> and then returns null, are there some other tests dependent to >> this behavior? otherwise better to not catch InterruptedException. >> >> I think to keep this modification, it will allow us to get more >> information if the bug is reproduced, if getting an >> InterruptedException then we need to do more investigation for >> why, if no exception then we may rise a question to process.waitFor(). >> >> Shanliang >> >> >> -JB- >> >> >> >> So a direct solution for the test is not to call: >> ProcessTools.executeTestJvm(args); >> >> but: >> ProcessBuilder pb = >> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >> Process process = pb.start(); >> process.waitFor(); >> OutputAnalyzer output = new OutputAnalyzer(process); >> >> here we do waiting: >> process.waitFor(); >> before constructing an OutputAnalyzer. >> >> ProcessTools is a tool class we may have same issue for >> other tests >> using this class. So we may need to improve the test library. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >> >> >> >> Thanks, >> Shanliang >> > From shanliang.jiang at oracle.com Tue Jul 1 21:40:49 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 01 Jul 2014 23:40:49 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53B31D90.9080104@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> <0d1001cf920e$cff48620$6fdd9260$@oracle.com> <53B3104A.9010800@oracle.com> <53B31D90.9080104@oracle.com> Message-ID: <53B32AE1.9000304@oracle.com> Jaroslav Bachorik wrote: > Hi Shanliang, > > On 07/01/2014 09:47 PM, shanliang wrote: >> I am still thinking to keep the original fix, because: >> 1) to throw InterruptedException does not fix the test failure, it might >> give more info for diagnostics. If it was really caused by an >> InterruptedException, then to fix the issue we still need to know who >> could interrupt the test main thread, in which case and why, and whether >> possible to ignore it (skip the test or try again?). > > I'm sorry but I can't agree with this. The proposed patch does not add > anything else than making the InterruptedException visible. Adding > process.waitFor() will solve nothing as it is already called by > ProcessTools.getOutput(process) while creating OutputAnalyzer. > >> 2) the test library is used also by other tests and to modify it might >> make new fail, it is better to concentrate at first on a single test >> before knowing the exact cause. > > I wouldn't expect new failures - when an InterruptedException was > thrown the ProcessTools.executeTestJvm(args) returned null. Either the > test would fail with NPE or custom assert - it makes no sense to work > with "null" process. > > IMO, this should be fixed in the test library. Sorry I may miss something here, you suggested: "Either the result of ProcessTools.getOutput() should be checked for null to detect this situation or ProcessTools.getOutput() should throw a more aggressive exception when waitFor() gets interrupted." We still need to do something when an InterruptedException happens, skip the test or retry? before making a decision we should know why there was an InterruptedException and in which case, I really do not have any idea, and I do not want to exclude other possibilities. Yes what my fix does is to expose an InterruptedException if it happens, but it could make sure that it was really because of an InterruptedException. About new failure, there could be a negative test which expected a IllegalStateException --> failed OutputAnalyser, who knows. Shanliang > > -JB- > >> >> Shanliang >> >> Christian Tornqvist wrote: >>> >>> I can?t remember if there was a reason for doing it like this, but it >>> seems reasonable to not catch the InterruptedException in getOutput(). >>> >>> Thanks, >>> >>> Christian >>> >>> *From:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>> *Sent:* Friday, June 27, 2014 4:49 AM >>> *To:* shanliang >>> *Cc:* Jaroslav Bachorik; serviceability-dev at openjdk.java.net >>> serviceability-dev at openjdk.java.net; Christian Tornqvist >>> *Subject:* Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java >>> fails intermittently >>> >>> It does look suspicious to catch and ignore the InterruptedException, >>> especially since the OutputAnalyzer constructor will fail in this case. >>> >>> Christian is the original author of these classes: do you know if >>> there is a good rationale for doing this? Or should we propagate the >>> InterruptedException? >>> >>> Thanks, >>> >>> /Staffan >>> >>> On 26 jun 2014, at 17:24, shanliang >> > wrote: >>> >>> >>> >>> Jaroslav Bachorik wrote: >>> >>> Hi Shanliang, >>> >>> On 06/26/2014 03:15 PM, shanliang wrote: >>> >>> Hi, >>> >>> Today ProcessTools.executeProcess has the code: >>> new OutputAnalyzer(pb.start()); >>> >>> and OutputAnalyzer constructor calls immediately: >>> exitValue = process.exitValue(); >>> >>> the test got exception because the process did not end. >>> >>> >>> Are you sure about this? >>> >>> The OutputAnalyzer constructor, before calling >>> process.exitValue(), calls ProcessTools.getOutput(process) >>> which actually does process.waitFor() >>> >>> Good catch! >>> >>> >>> A probable explanation would be that process.waitFor() gets >>> interrupted without the target process actually ending. >>> >>> Either the result of ProcessTools.getOutput() should be >>> checked for null to detect this situation or >>> ProcessTools.getOutput() should throw a more aggressive >>> exception when waitFor() gets interrupted. >>> >>> It was possible beacause of an InterruptedException, but maybe a >>> Process issue too. >>> >>> process.waitFor() was called by the test main thread, I am >>> wondering who wanted to interrupt this thread? >>> >>> Not know why ProcessTools.getOutput() catches InterruptedException >>> and then returns null, are there some other tests dependent to >>> this behavior? otherwise better to not catch InterruptedException. >>> >>> I think to keep this modification, it will allow us to get more >>> information if the bug is reproduced, if getting an >>> InterruptedException then we need to do more investigation for >>> why, if no exception then we may rise a question to >>> process.waitFor(). >>> >>> Shanliang >>> >>> >>> -JB- >>> >>> >>> >>> So a direct solution for the test is not to call: >>> ProcessTools.executeTestJvm(args); >>> >>> but: >>> ProcessBuilder pb = >>> >>> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >>> Process process = pb.start(); >>> process.waitFor(); >>> OutputAnalyzer output = new >>> OutputAnalyzer(process); >>> >>> here we do waiting: >>> process.waitFor(); >>> before constructing an OutputAnalyzer. >>> >>> ProcessTools is a tool class we may have same issue for >>> other tests >>> using this class. So we may need to improve the test >>> library. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >>> >>> >>> >>> Thanks, >>> Shanliang >>> >> > From jaroslav.bachorik at oracle.com Wed Jul 2 07:58:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Jul 2014 09:58:31 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53B32AE1.9000304@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> <0d1001cf920e$cff48620$6fdd9260$@oracle.com> <53B3104A.9010800@oracle.com> <53B31D90.9080104@oracle.com> <53B32AE1.9000304@oracle.com> Message-ID: <53B3BBA7.6070100@oracle.com> On 07/01/2014 11:40 PM, shanliang wrote: > Jaroslav Bachorik wrote: >> Hi Shanliang, >> >> On 07/01/2014 09:47 PM, shanliang wrote: >>> I am still thinking to keep the original fix, because: >>> 1) to throw InterruptedException does not fix the test failure, it might >>> give more info for diagnostics. If it was really caused by an >>> InterruptedException, then to fix the issue we still need to know who >>> could interrupt the test main thread, in which case and why, and whether >>> possible to ignore it (skip the test or try again?). >> >> I'm sorry but I can't agree with this. The proposed patch does not add >> anything else than making the InterruptedException visible. Adding >> process.waitFor() will solve nothing as it is already called by >> ProcessTools.getOutput(process) while creating OutputAnalyzer. >> >>> 2) the test library is used also by other tests and to modify it might >>> make new fail, it is better to concentrate at first on a single test >>> before knowing the exact cause. >> >> I wouldn't expect new failures - when an InterruptedException was >> thrown the ProcessTools.executeTestJvm(args) returned null. Either the >> test would fail with NPE or custom assert - it makes no sense to work >> with "null" process. >> >> IMO, this should be fixed in the test library. > Sorry I may miss something here, you suggested: > "Either the result of ProcessTools.getOutput() should be checked for > null to detect this situation or ProcessTools.getOutput() should throw a > more aggressive exception when waitFor() gets interrupted." > > We still need to do something when an InterruptedException happens, skip > the test or retry? before making a decision we should know why there was > an InterruptedException and in which case, I really do not have any > idea, and I do not want to exclude other possibilities. The most probable explanation, based on the analysis of many intermittent test failures, is that the harness is trying to time out the test. But it is just an educated guess ... > > Yes what my fix does is to expose an InterruptedException if it happens, > but it could make sure that it was really because of an > InterruptedException. I don't feel particularly happy about the code duplication introduced by this fix. But if official reviewers are fine with it I won't block this review. > > About new failure, there could be a negative test which expected a > IllegalStateException --> failed OutputAnalyser, who knows. My concern is that there also might be other tests failing intermittently (or providing wrong results) due to the InterruptedException being silently swallowed. You might run the whole testsuite with the modified ProcessTools.getOutput() on JPRT and see if there are any negative tests failing (they should since instead of null value they will receive InterryptedException). -JB- > > Shanliang >> >> -JB- >> >>> >>> Shanliang >>> >>> Christian Tornqvist wrote: >>>> >>>> I can?t remember if there was a reason for doing it like this, but it >>>> seems reasonable to not catch the InterruptedException in getOutput(). >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> *From:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>>> *Sent:* Friday, June 27, 2014 4:49 AM >>>> *To:* shanliang >>>> *Cc:* Jaroslav Bachorik; serviceability-dev at openjdk.java.net >>>> serviceability-dev at openjdk.java.net; Christian Tornqvist >>>> *Subject:* Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java >>>> fails intermittently >>>> >>>> It does look suspicious to catch and ignore the InterruptedException, >>>> especially since the OutputAnalyzer constructor will fail in this case. >>>> >>>> Christian is the original author of these classes: do you know if >>>> there is a good rationale for doing this? Or should we propagate the >>>> InterruptedException? >>>> >>>> Thanks, >>>> >>>> /Staffan >>>> >>>> On 26 jun 2014, at 17:24, shanliang >>> > wrote: >>>> >>>> >>>> >>>> Jaroslav Bachorik wrote: >>>> >>>> Hi Shanliang, >>>> >>>> On 06/26/2014 03:15 PM, shanliang wrote: >>>> >>>> Hi, >>>> >>>> Today ProcessTools.executeProcess has the code: >>>> new OutputAnalyzer(pb.start()); >>>> >>>> and OutputAnalyzer constructor calls immediately: >>>> exitValue = process.exitValue(); >>>> >>>> the test got exception because the process did not end. >>>> >>>> >>>> Are you sure about this? >>>> >>>> The OutputAnalyzer constructor, before calling >>>> process.exitValue(), calls ProcessTools.getOutput(process) >>>> which actually does process.waitFor() >>>> >>>> Good catch! >>>> >>>> >>>> A probable explanation would be that process.waitFor() gets >>>> interrupted without the target process actually ending. >>>> >>>> Either the result of ProcessTools.getOutput() should be >>>> checked for null to detect this situation or >>>> ProcessTools.getOutput() should throw a more aggressive >>>> exception when waitFor() gets interrupted. >>>> >>>> It was possible beacause of an InterruptedException, but maybe a >>>> Process issue too. >>>> >>>> process.waitFor() was called by the test main thread, I am >>>> wondering who wanted to interrupt this thread? >>>> >>>> Not know why ProcessTools.getOutput() catches InterruptedException >>>> and then returns null, are there some other tests dependent to >>>> this behavior? otherwise better to not catch InterruptedException. >>>> >>>> I think to keep this modification, it will allow us to get more >>>> information if the bug is reproduced, if getting an >>>> InterruptedException then we need to do more investigation for >>>> why, if no exception then we may rise a question to >>>> process.waitFor(). >>>> >>>> Shanliang >>>> >>>> >>>> -JB- >>>> >>>> >>>> >>>> So a direct solution for the test is not to call: >>>> ProcessTools.executeTestJvm(args); >>>> >>>> but: >>>> ProcessBuilder pb = >>>> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >>>> Process process = pb.start(); >>>> process.waitFor(); >>>> OutputAnalyzer output = new >>>> OutputAnalyzer(process); >>>> >>>> here we do waiting: >>>> process.waitFor(); >>>> before constructing an OutputAnalyzer. >>>> >>>> ProcessTools is a tool class we may have same issue for >>>> other tests >>>> using this class. So we may need to improve the test >>>> library. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >>>> >>>> >>>> >>>> Thanks, >>>> Shanliang >>>> >>> >> > From shanliang.jiang at oracle.com Wed Jul 2 08:05:37 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 02 Jul 2014 10:05:37 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53B3BBA7.6070100@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> <0d1001cf920e$cff48620$6fdd9260$@oracle.com> <53B3104A.9010800@oracle.com> <53B31D90.9080104@oracle.com> <53B32AE1.9000304@oracle.com> <53B3BBA7.6070100@oracle.com> Message-ID: <53B3BD51.3060702@oracle.com> Jaroslav Bachorik wrote: > On 07/01/2014 11:40 PM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> Hi Shanliang, >>> >>> On 07/01/2014 09:47 PM, shanliang wrote: >>>> I am still thinking to keep the original fix, because: >>>> 1) to throw InterruptedException does not fix the test failure, it >>>> might >>>> give more info for diagnostics. If it was really caused by an >>>> InterruptedException, then to fix the issue we still need to know who >>>> could interrupt the test main thread, in which case and why, and >>>> whether >>>> possible to ignore it (skip the test or try again?). >>> >>> I'm sorry but I can't agree with this. The proposed patch does not add >>> anything else than making the InterruptedException visible. Adding >>> process.waitFor() will solve nothing as it is already called by >>> ProcessTools.getOutput(process) while creating OutputAnalyzer. >>> >>>> 2) the test library is used also by other tests and to modify it might >>>> make new fail, it is better to concentrate at first on a single test >>>> before knowing the exact cause. >>> >>> I wouldn't expect new failures - when an InterruptedException was >>> thrown the ProcessTools.executeTestJvm(args) returned null. Either the >>> test would fail with NPE or custom assert - it makes no sense to work >>> with "null" process. >>> >>> IMO, this should be fixed in the test library. >> Sorry I may miss something here, you suggested: >> "Either the result of ProcessTools.getOutput() should be checked for >> null to detect this situation or ProcessTools.getOutput() should throw a >> more aggressive exception when waitFor() gets interrupted." >> >> We still need to do something when an InterruptedException happens, skip >> the test or retry? before making a decision we should know why there was >> an InterruptedException and in which case, I really do not have any >> idea, and I do not want to exclude other possibilities. > > The most probable explanation, based on the analysis of many > intermittent test failures, is that the harness is trying to time out > the test. But it is just an educated guess ... Thought about this possibility, but a harness would kill the test instead to interrupt the test thread? > >> >> Yes what my fix does is to expose an InterruptedException if it happens, >> but it could make sure that it was really because of an >> InterruptedException. > > I don't feel particularly happy about the code duplication introduced > by this fix. But if official reviewers are fine with it I won't block > this review. > >> >> About new failure, there could be a negative test which expected a >> IllegalStateException --> failed OutputAnalyser, who knows. > > My concern is that there also might be other tests failing > intermittently (or providing wrong results) due to the > InterruptedException being silently swallowed. I agree that we need to do investigation on the test library, but better to do it later when we have more info from this test. Thanks, Shanliang > > You might run the whole testsuite with the modified > ProcessTools.getOutput() on JPRT and see if there are any negative > tests failing (they should since instead of null value they will > receive InterryptedException). > > -JB- > >> >> Shanliang >>> >>> -JB- >>> >>>> >>>> Shanliang >>>> >>>> Christian Tornqvist wrote: >>>>> >>>>> I can?t remember if there was a reason for doing it like this, but it >>>>> seems reasonable to not catch the InterruptedException in >>>>> getOutput(). >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> *From:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>>>> *Sent:* Friday, June 27, 2014 4:49 AM >>>>> *To:* shanliang >>>>> *Cc:* Jaroslav Bachorik; serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net; Christian Tornqvist >>>>> *Subject:* Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java >>>>> fails intermittently >>>>> >>>>> It does look suspicious to catch and ignore the InterruptedException, >>>>> especially since the OutputAnalyzer constructor will fail in this >>>>> case. >>>>> >>>>> Christian is the original author of these classes: do you know if >>>>> there is a good rationale for doing this? Or should we propagate the >>>>> InterruptedException? >>>>> >>>>> Thanks, >>>>> >>>>> /Staffan >>>>> >>>>> On 26 jun 2014, at 17:24, shanliang >>>> > wrote: >>>>> >>>>> >>>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>> Hi Shanliang, >>>>> >>>>> On 06/26/2014 03:15 PM, shanliang wrote: >>>>> >>>>> Hi, >>>>> >>>>> Today ProcessTools.executeProcess has the code: >>>>> new OutputAnalyzer(pb.start()); >>>>> >>>>> and OutputAnalyzer constructor calls immediately: >>>>> exitValue = process.exitValue(); >>>>> >>>>> the test got exception because the process did not end. >>>>> >>>>> >>>>> Are you sure about this? >>>>> >>>>> The OutputAnalyzer constructor, before calling >>>>> process.exitValue(), calls ProcessTools.getOutput(process) >>>>> which actually does process.waitFor() >>>>> >>>>> Good catch! >>>>> >>>>> >>>>> A probable explanation would be that process.waitFor() gets >>>>> interrupted without the target process actually ending. >>>>> >>>>> Either the result of ProcessTools.getOutput() should be >>>>> checked for null to detect this situation or >>>>> ProcessTools.getOutput() should throw a more aggressive >>>>> exception when waitFor() gets interrupted. >>>>> >>>>> It was possible beacause of an InterruptedException, but maybe a >>>>> Process issue too. >>>>> >>>>> process.waitFor() was called by the test main thread, I am >>>>> wondering who wanted to interrupt this thread? >>>>> >>>>> Not know why ProcessTools.getOutput() catches >>>>> InterruptedException >>>>> and then returns null, are there some other tests dependent to >>>>> this behavior? otherwise better to not catch >>>>> InterruptedException. >>>>> >>>>> I think to keep this modification, it will allow us to get more >>>>> information if the bug is reproduced, if getting an >>>>> InterruptedException then we need to do more investigation for >>>>> why, if no exception then we may rise a question to >>>>> process.waitFor(). >>>>> >>>>> Shanliang >>>>> >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>> So a direct solution for the test is not to call: >>>>> ProcessTools.executeTestJvm(args); >>>>> >>>>> but: >>>>> ProcessBuilder pb = >>>>> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >>>>> Process process = pb.start(); >>>>> process.waitFor(); >>>>> OutputAnalyzer output = new >>>>> OutputAnalyzer(process); >>>>> >>>>> here we do waiting: >>>>> process.waitFor(); >>>>> before constructing an OutputAnalyzer. >>>>> >>>>> ProcessTools is a tool class we may have same issue for >>>>> other tests >>>>> using this class. So we may need to improve the test >>>>> library. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>> >>> >> > From david.holmes at oracle.com Wed Jul 2 10:48:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Jul 2014 20:48:02 +1000 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B2AAFB.5070306@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> <53B2AAFB.5070306@oracle.com> Message-ID: <53B3E362.1060008@oracle.com> On 1/07/2014 10:35 PM, roger riggs wrote: > Hi Erik, > > Consider switching to System.nanoTime; it is not sensitive to clock changes Not completely true unfortunately. The change to use CLOCK_MONOTONIC_RAW will make it true (OS bugs not withstanding). But I would suggest switching anyway. David > and avoids leaving a land mine that may cause a spurious non-repeatable > test failure. > 'Deducing it from the log' means there is a failure and creates probably > an hour or two of work > for some quality engineer and burns a couple of hours re-running the > test run. > > Roger > > > > On 7/1/2014 3:37 AM, Erik Gahlin wrote: >> >> >>> JavaProcess.waitForRemoval: How about using timestamps >>> (currentTimeMillis()) before the loop and for each ite >>> ration to determine if the timeout has expired (instead of "time+=100?)? >>> >> The code now uses currentTimeMillis(). Premature timeouts due to clock >> changes can be deduced from the log. >> > From staffan.larsen at oracle.com Wed Jul 2 11:32:20 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Jul 2014 13:32:20 +0200 Subject: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently In-Reply-To: <53B3BD51.3060702@oracle.com> References: <53AC1D03.9080200@oracle.com> <53AC212B.1040101@oracle.com> <53AC3B45.8010009@oracle.com> <266C2BDB-7C07-41B5-AEA8-CA081E3092F9@oracle.com> <0d1001cf920e$cff48620$6fdd9260$@oracle.com> <53B3104A.9010800@oracle.com> <53B31D90.9080104@oracle.com> <53B32AE1.9000304@oracle.com> <53B3BBA7.6070100@oracle.com> <53B3BD51.3060702@oracle.com> Message-ID: <17463FCA-AAB0-42C4-804E-4AEA162BF0C8@oracle.com> I agree with Jaroslav here, and would like a different patch. The proposed patch does not solve the problem and as a debugging help it is implemented at the wrong level. I think the ProcessTools.getOutput() should be updated to throw the InterruptedException - this looks wrong in the library. The impact on other tests should be minimal, I don?t believe anyone depends on getOutput() swallowing InterruptedException - if they do, we have to fix that, too (which at the same time would make those tests more stable). Thanks, /Staffan On 2 jul 2014, at 10:05, shanliang wrote: > Jaroslav Bachorik wrote: >> On 07/01/2014 11:40 PM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> Hi Shanliang, >>>> >>>> On 07/01/2014 09:47 PM, shanliang wrote: >>>>> I am still thinking to keep the original fix, because: >>>>> 1) to throw InterruptedException does not fix the test failure, it might >>>>> give more info for diagnostics. If it was really caused by an >>>>> InterruptedException, then to fix the issue we still need to know who >>>>> could interrupt the test main thread, in which case and why, and whether >>>>> possible to ignore it (skip the test or try again?). >>>> >>>> I'm sorry but I can't agree with this. The proposed patch does not add >>>> anything else than making the InterruptedException visible. Adding >>>> process.waitFor() will solve nothing as it is already called by >>>> ProcessTools.getOutput(process) while creating OutputAnalyzer. >>>> >>>>> 2) the test library is used also by other tests and to modify it might >>>>> make new fail, it is better to concentrate at first on a single test >>>>> before knowing the exact cause. >>>> >>>> I wouldn't expect new failures - when an InterruptedException was >>>> thrown the ProcessTools.executeTestJvm(args) returned null. Either the >>>> test would fail with NPE or custom assert - it makes no sense to work >>>> with "null" process. >>>> >>>> IMO, this should be fixed in the test library. >>> Sorry I may miss something here, you suggested: >>> "Either the result of ProcessTools.getOutput() should be checked for >>> null to detect this situation or ProcessTools.getOutput() should throw a >>> more aggressive exception when waitFor() gets interrupted." >>> >>> We still need to do something when an InterruptedException happens, skip >>> the test or retry? before making a decision we should know why there was >>> an InterruptedException and in which case, I really do not have any >>> idea, and I do not want to exclude other possibilities. >> >> The most probable explanation, based on the analysis of many intermittent test failures, is that the harness is trying to time out the test. But it is just an educated guess ... > Thought about this possibility, but a harness would kill the test instead to interrupt the test thread? >> >>> >>> Yes what my fix does is to expose an InterruptedException if it happens, >>> but it could make sure that it was really because of an >>> InterruptedException. >> >> I don't feel particularly happy about the code duplication introduced by this fix. But if official reviewers are fine with it I won't block this review. >> >>> >>> About new failure, there could be a negative test which expected a >>> IllegalStateException --> failed OutputAnalyser, who knows. >> >> My concern is that there also might be other tests failing intermittently (or providing wrong results) due to the InterruptedException being silently swallowed. > I agree that we need to do investigation on the test library, but better to do it later when we have more info from this test. > > Thanks, > Shanliang >> >> You might run the whole testsuite with the modified ProcessTools.getOutput() on JPRT and see if there are any negative tests failing (they should since instead of null value they will receive InterryptedException). >> >> -JB- >> >>> >>> Shanliang >>>> >>>> -JB- >>>> >>>>> >>>>> Shanliang >>>>> >>>>> Christian Tornqvist wrote: >>>>>> >>>>>> I can?t remember if there was a reason for doing it like this, but it >>>>>> seems reasonable to not catch the InterruptedException in getOutput(). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Christian >>>>>> >>>>>> *From:*Staffan Larsen [mailto:staffan.larsen at oracle.com] >>>>>> *Sent:* Friday, June 27, 2014 4:49 AM >>>>>> *To:* shanliang >>>>>> *Cc:* Jaroslav Bachorik; serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net; Christian Tornqvist >>>>>> *Subject:* Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java >>>>>> fails intermittently >>>>>> >>>>>> It does look suspicious to catch and ignore the InterruptedException, >>>>>> especially since the OutputAnalyzer constructor will fail in this case. >>>>>> >>>>>> Christian is the original author of these classes: do you know if >>>>>> there is a good rationale for doing this? Or should we propagate the >>>>>> InterruptedException? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> /Staffan >>>>>> >>>>>> On 26 jun 2014, at 17:24, shanliang >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> Jaroslav Bachorik wrote: >>>>>> >>>>>> Hi Shanliang, >>>>>> >>>>>> On 06/26/2014 03:15 PM, shanliang wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Today ProcessTools.executeProcess has the code: >>>>>> new OutputAnalyzer(pb.start()); >>>>>> >>>>>> and OutputAnalyzer constructor calls immediately: >>>>>> exitValue = process.exitValue(); >>>>>> >>>>>> the test got exception because the process did not end. >>>>>> >>>>>> >>>>>> Are you sure about this? >>>>>> >>>>>> The OutputAnalyzer constructor, before calling >>>>>> process.exitValue(), calls ProcessTools.getOutput(process) >>>>>> which actually does process.waitFor() >>>>>> >>>>>> Good catch! >>>>>> >>>>>> >>>>>> A probable explanation would be that process.waitFor() gets >>>>>> interrupted without the target process actually ending. >>>>>> >>>>>> Either the result of ProcessTools.getOutput() should be >>>>>> checked for null to detect this situation or >>>>>> ProcessTools.getOutput() should throw a more aggressive >>>>>> exception when waitFor() gets interrupted. >>>>>> >>>>>> It was possible beacause of an InterruptedException, but maybe a >>>>>> Process issue too. >>>>>> >>>>>> process.waitFor() was called by the test main thread, I am >>>>>> wondering who wanted to interrupt this thread? >>>>>> >>>>>> Not know why ProcessTools.getOutput() catches InterruptedException >>>>>> and then returns null, are there some other tests dependent to >>>>>> this behavior? otherwise better to not catch InterruptedException. >>>>>> >>>>>> I think to keep this modification, it will allow us to get more >>>>>> information if the bug is reproduced, if getting an >>>>>> InterruptedException then we need to do more investigation for >>>>>> why, if no exception then we may rise a question to >>>>>> process.waitFor(). >>>>>> >>>>>> Shanliang >>>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> >>>>>> So a direct solution for the test is not to call: >>>>>> ProcessTools.executeTestJvm(args); >>>>>> >>>>>> but: >>>>>> ProcessBuilder pb = >>>>>> ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args)); >>>>>> Process process = pb.start(); >>>>>> process.waitFor(); >>>>>> OutputAnalyzer output = new >>>>>> OutputAnalyzer(process); >>>>>> >>>>>> here we do waiting: >>>>>> process.waitFor(); >>>>>> before constructing an OutputAnalyzer. >>>>>> >>>>>> ProcessTools is a tool class we may have same issue for >>>>>> other tests >>>>>> using this class. So we may need to improve the test >>>>>> library. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8031554 >>>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/ >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Shanliang -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Jul 2 16:28:48 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 02 Jul 2014 10:28:48 -0600 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: <53B4300C.7040401@us.ibm.com> References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> Message-ID: <53B43340.6020508@oracle.com> Adding the Serviceability team to the thread since JVM/TI is owned by them... Dan On 7/2/14 10:15 AM, Maynard Johnson wrote: > Cross-posting to see if Hotspot developers can help. > > -Maynard > > > -------- Original Message -------- > Subject: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero > Date: Wed, 25 Jun 2014 10:18:17 -0500 > From: Maynard Johnson > To: ppc-aix-port-dev at openjdk.java.net > > Hello, PowerPC OpenJDK folks, > I am just now starting to get involved in the OpenJDK project. My goal is to ensure that the standard serviceability tools and tooling (jdb, JVMTI, jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to start with since I have some experience from a client perspective with the JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) provides an agent library that implements the JVMTI API. Using this agent library to profile Java apps on my Intel-based laptop with OpenJDK (using various versions, up to current jdk9-dev) works fine. But the same profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails miserably. > > The oprofile agent library registers for callbacks for CompiledMethodLoad, CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, it writes information about the JVMTI event to a file. After profiling completes, oprofile's post-processing phase involves interpreting the information from the agent library's output file and generating an ELF file to represent the JITed code. When I profile an OpenJDK app on my Power system, the post-processing phase fails while trying to resolve overlapping symbols. The failure is due to the fact that it is unexpectedly finding symbols with code size of zero overlapping at the starting address of some other symbol with non-zero code size. The symbols in question here are from DynamicCodeGenerated events. > > Are these "code size=0" events valid? If so, I can fix the oprofile code to handle them. If they're not valid, then below is some debug information I've collected so far. > > ---------------------------- > > I instrumented JvmtiExport::post_dynamic_code_generated_internal (in hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a symbol with code size of zero was detected and then ran the following command: > > java -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so -version > > The debug output from my instrumentation was as follows: > > Code size is ZERO!! Dynamic code generated event sent for flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 > Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 > Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 > Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 > Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 > Code size is ZERO!! Dynamic code generated event sent for verify_oop; code begin: 0x3fff6801665c; code end: 0x3fff6801665c > openjdk version "1.9.0-internal" > OpenJDK Runtime Environment (build 1.9.0-internal-mpj_2014_06_18_09_55-b00) > OpenJDK 64-Bit Server VM (build 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) > > > I don't have access to an AIX system to know if the same issue would be seen there. Let me know if there's any other information I can provide. > > Thanks for the help. > > -Maynard > > > From volker.simonis at gmail.com Wed Jul 2 17:38:42 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Jul 2014 19:38:42 +0200 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: <53B43340.6020508@oracle.com> References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> Message-ID: Hi Maynard, I really apologize that I've somehow missed your first message. ppc-aix-port-dev was the right list to post to. I'll analyze this problem instantly and let you know why we post this zero-code size events. Regards, Volker PS: really great to see that somebody is working on oprofile/OpenJDK integration! On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty wrote: > Adding the Serviceability team to the thread since JVM/TI is owned > by them... > > Dan > > > > On 7/2/14 10:15 AM, Maynard Johnson wrote: >> >> Cross-posting to see if Hotspot developers can help. >> >> -Maynard >> >> >> -------- Original Message -------- >> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >> size of zero >> Date: Wed, 25 Jun 2014 10:18:17 -0500 >> From: Maynard Johnson >> To: ppc-aix-port-dev at openjdk.java.net >> >> Hello, PowerPC OpenJDK folks, >> I am just now starting to get involved in the OpenJDK project. My goal is >> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >> start with since I have some experience from a client perspective with the >> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >> provides an agent library that implements the JVMTI API. Using this agent >> library to profile Java apps on my Intel-based laptop with OpenJDK (using >> various versions, up to current jdk9-dev) works fine. But the same >> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >> miserably. >> >> The oprofile agent library registers for callbacks for CompiledMethodLoad, >> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >> it writes information about the JVMTI event to a file. After profiling >> completes, oprofile's post-processing phase involves interpreting the >> information from the agent library's output file and generating an ELF file >> to represent the JITed code. When I profile an OpenJDK app on my Power >> system, the post-processing phase fails while trying to resolve overlapping >> symbols. The failure is due to the fact that it is unexpectedly finding >> symbols with code size of zero overlapping at the starting address of some >> other symbol with non-zero code size. The symbols in question here are from >> DynamicCodeGenerated events. >> >> Are these "code size=0" events valid? If so, I can fix the oprofile code >> to handle them. If they're not valid, then below is some debug information >> I've collected so far. >> >> ---------------------------- >> >> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >> symbol with code size of zero was detected and then ran the following >> command: >> >> java >> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >> -version >> >> The debug output from my instrumentation was as follows: >> >> Code size is ZERO!! Dynamic code generated event sent for >> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >> Code size is ZERO!! Dynamic code generated event sent for >> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >> Code size is ZERO!! Dynamic code generated event sent for >> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >> Code size is ZERO!! Dynamic code generated event sent for >> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >> Code size is ZERO!! Dynamic code generated event sent for >> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >> openjdk version "1.9.0-internal" >> OpenJDK Runtime Environment (build >> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >> OpenJDK 64-Bit Server VM (build >> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >> >> >> I don't have access to an AIX system to know if the same issue would be >> seen there. Let me know if there's any other information I can provide. >> >> Thanks for the help. >> >> -Maynard >> >> >> > From volker.simonis at gmail.com Wed Jul 2 18:21:44 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 Jul 2014 20:21:44 +0200 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> Message-ID: After a quick look I can say that at least for the "flush_icache_stub" and "verify_oop" cases we indeed generate no code. Other platforms like x86 for example generate code for instruction cache flushing. The starting address of this code is saved in a function pointer and called if necessary. On PPC64 we just save the address of a normal C-funtion in this function pointer and implement the cache flush with the help of inline assembler in the C-function. However this saving of the C-function address in the corresponding function pointer is still done in a helper method which triggers the creation of the JvmtiExport::post_dynamic_code_generated_internal event - but with zero size in that case. I agree that it is questionable if we really need to post these events although they didn't hurt until know. Maybe we can remove them - please let me think one more night about it:) Regards, Volker On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: > Hi Maynard, > > I really apologize that I've somehow missed your first message. > ppc-aix-port-dev was the right list to post to. > > I'll analyze this problem instantly and let you know why we post this > zero-code size events. > > Regards, > Volker > > PS: really great to see that somebody is working on oprofile/OpenJDK > integration! > > > On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty > wrote: >> Adding the Serviceability team to the thread since JVM/TI is owned >> by them... >> >> Dan >> >> >> >> On 7/2/14 10:15 AM, Maynard Johnson wrote: >>> >>> Cross-posting to see if Hotspot developers can help. >>> >>> -Maynard >>> >>> >>> -------- Original Message -------- >>> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >>> size of zero >>> Date: Wed, 25 Jun 2014 10:18:17 -0500 >>> From: Maynard Johnson >>> To: ppc-aix-port-dev at openjdk.java.net >>> >>> Hello, PowerPC OpenJDK folks, >>> I am just now starting to get involved in the OpenJDK project. My goal is >>> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >>> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >>> start with since I have some experience from a client perspective with the >>> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >>> provides an agent library that implements the JVMTI API. Using this agent >>> library to profile Java apps on my Intel-based laptop with OpenJDK (using >>> various versions, up to current jdk9-dev) works fine. But the same >>> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >>> miserably. >>> >>> The oprofile agent library registers for callbacks for CompiledMethodLoad, >>> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >>> it writes information about the JVMTI event to a file. After profiling >>> completes, oprofile's post-processing phase involves interpreting the >>> information from the agent library's output file and generating an ELF file >>> to represent the JITed code. When I profile an OpenJDK app on my Power >>> system, the post-processing phase fails while trying to resolve overlapping >>> symbols. The failure is due to the fact that it is unexpectedly finding >>> symbols with code size of zero overlapping at the starting address of some >>> other symbol with non-zero code size. The symbols in question here are from >>> DynamicCodeGenerated events. >>> >>> Are these "code size=0" events valid? If so, I can fix the oprofile code >>> to handle them. If they're not valid, then below is some debug information >>> I've collected so far. >>> >>> ---------------------------- >>> >>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >>> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >>> symbol with code size of zero was detected and then ran the following >>> command: >>> >>> java >>> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >>> -version >>> >>> The debug output from my instrumentation was as follows: >>> >>> Code size is ZERO!! Dynamic code generated event sent for >>> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >>> Code size is ZERO!! Dynamic code generated event sent for >>> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >>> Code size is ZERO!! Dynamic code generated event sent for >>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>> Code size is ZERO!! Dynamic code generated event sent for >>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>> Code size is ZERO!! Dynamic code generated event sent for >>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >>> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >>> openjdk version "1.9.0-internal" >>> OpenJDK Runtime Environment (build >>> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >>> OpenJDK 64-Bit Server VM (build >>> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >>> >>> >>> I don't have access to an AIX system to know if the same issue would be >>> seen there. Let me know if there's any other information I can provide. >>> >>> Thanks for the help. >>> >>> -Maynard >>> >>> >>> >> From serguei.spitsyn at oracle.com Thu Jul 3 05:04:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 02 Jul 2014 22:04:54 -0700 Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" In-Reply-To: <882452e7-0b02-414a-8a04-125737cb2faf@default> References: <882452e7-0b02-414a-8a04-125737cb2faf@default> Message-ID: <53B4E476.2050306@oracle.com> Hi Markus, Sorry for the latency. I hope this review is still needed. src/share/vm/interpreter/oopMapCache.hpp A minor comment: The function blocks indentation was originally aligned, but this fix partially broke it: - uintptr_t entry_at(int offset) { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } + uintptr_t entry_at(int offset) const { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } void set_expression_stack_size(int sz) { _expression_stack_size = sz; } #ifdef ENABLE_ZAP_DEAD_LOCALS - bool is_dead(int offset) { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } + bool is_dead(int offset) const { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } #endif // Lookup - bool match(methodHandle method, int bci) { return _method == method() && _bci == bci; } - bool is_empty(); + bool match(methodHandle method, int bci) const { return _method == method() && _bci == bci; } + bool is_empty() const; || src/share/vm/runtime/vframe.cpp The implementation of the ::stack_data () combined the logics from ::locals() and ::expressions(). As a result, the function became unreasonably more complex to have a deal with this combination. The original approach looks better even though some fragments are repeated twice. In other words, more simple and flat lines is better than less lines with more complexity as it adds another dimension to track down. I need a little bit more time to better understand the vframe.cpp part of the fix. Thanks, Serguei On 6/25/14 4:58 AM, Markus Gr?nlund wrote: > > Greetings, > > Kindly looking for reviews for the following change: > > Bug: http://bugs.openjdk.java.net/browse/JDK-8039905 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/ > > > Description: > > JVMTI inspection code for following references makes use of a > VM_HeapWalkOperation in order to follow-up root sets. > > In bug: > > https://bugs.openjdk.java.net/browse/JDK-8038624 - > "interpretedVFrame::expressions() must respect InterpreterOopMap for > liveness", it was found that the interpretedVFrame code had a > discrepancy between basing length information from both asking the > interpreter frame (which saw live expression slots for calls > instructions) as well as the oop map (which did not). > > The liveness decisions for a particular BCI should be based on what > the oopmap gives, and that was done as of that bug (8038624). > > In that process, I added an assert in an attempt to validate certain > assumptions, and this assert has triggered during nightly testing in > some cases. > > I have therefore inspected the GC code which follow-up roots from an > interpreted frame (please see frame::oops_interpreted_do() and > InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), > and reworked InterpretedVFrame so that inspections for the locals and > expression slots are done in the same way as the GC code (especially > in regards to taking decisions on the InterpreterOopMap). > > I needed to use InterpreterOopMap from a const context, and this is > why I have "constified" this class where needed, as well as making > "number_of_entries()" a const public accessor (to easily reach > oop_mask length info). > > Testing completed: > > nsk/jdi* tests (especially the problematic ones reported for 8039905) > > compiler/6507107/HeapWalkingTest > > Thanks > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Jul 3 09:22:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Jul 2014 11:22:57 +0200 Subject: RFR: 8049229 sun/tools/jps/jps-l_1.sh fails with Execution failed: exit code 1 Message-ID: <09D80BFD-2A7A-4FE3-BB8B-20B67ACAEF28@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8049229 webrev: http://cr.openjdk.java.net/~sla/8049229/webrev.00/ The problem here is that the awk scripts in the test match the lines in the ups output that end in ?.jar" twice and end up failing. The solution is to stop matching after we have found one match. Thanks, /Staffan From dmitry.samersoff at oracle.com Thu Jul 3 09:57:48 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Jul 2014 13:57:48 +0400 Subject: RFR: 8049229 sun/tools/jps/jps-l_1.sh fails with Execution failed: exit code 1 In-Reply-To: <09D80BFD-2A7A-4FE3-BB8B-20B67ACAEF28@oracle.com> References: <09D80BFD-2A7A-4FE3-BB8B-20B67ACAEF28@oracle.com> Message-ID: <53B5291C.5090301@oracle.com> Looks good for me. On 2014-07-03 13:22, Staffan Larsen wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8049229 > webrev: http://cr.openjdk.java.net/~sla/8049229/webrev.00/ > > The problem here is that the awk scripts in the test match the lines in the ups output that end in ?.jar" twice and end up failing. The solution is to stop matching after we have found one match. > > Thanks, > /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Thu Jul 3 10:58:35 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 03 Jul 2014 03:58:35 -0700 Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" In-Reply-To: <53B4E476.2050306@oracle.com> References: <882452e7-0b02-414a-8a04-125737cb2faf@default> <53B4E476.2050306@oracle.com> Message-ID: <53B5375B.8090207@oracle.com> Markus, I've done another pass through the webrev. It looks good in general. Thank you for fixing it! As for the ::locals() and ::expressions() refactoring, my guess is that your motivation was to make it closer to what the GC is doing. Is it true? You can keep it as you like because my comment is not a big or strong statement. It is just my personal preference. But, the refactoring made it harder to review the changes as the original mapping has gone. As we privately discussed, this code may need further improvements related to the dead locals and so, we may need to open new bugs for recognized issues. Also, It seems you are right on the meaning of the T_CONFLICT that it is set for the dead locals. However, in my bug/testcase context the T_CONFLICT value was not set for dead local. The observed value of the dead local was T_INT (as uninitialized data) which looks pretty strange. It is possible, we have a deal with another bug here. Thanks, Serguei On 7/2/14 10:04 PM, serguei.spitsyn at oracle.com wrote: > Hi Markus, > > Sorry for the latency. > I hope this review is still needed. > > src/share/vm/interpreter/oopMapCache.hpp > > A minor comment: > The function blocks indentation was originally aligned, but this fix > partially broke it: > - uintptr_t entry_at(int offset) { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } > + uintptr_t entry_at(int offset) const { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } > > void set_expression_stack_size(int sz) { _expression_stack_size = sz; } > > #ifdef ENABLE_ZAP_DEAD_LOCALS > - bool is_dead(int offset) { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } > + bool is_dead(int offset) const { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } > #endif > > > // Lookup > - bool match(methodHandle method, int bci) { return _method == method() && _bci == bci; } > - bool is_empty(); > + bool match(methodHandle method, int bci) const { return _method == method() && _bci == bci; } > + bool is_empty() const; > || > src/share/vm/runtime/vframe.cpp > > The implementation of the ::stack_data () combined the logics from > ::locals() and ::expressions(). > As a result, the function became unreasonably more complex to have a > deal with this combination. > The original approach looks better even though some fragments are > repeated twice. > In other words, more simple and flat lines is better than less lines > with more complexity > as it adds another dimension to track down. > > > I need a little bit more time to better understand the vframe.cpp part > of the fix. > > Thanks, > Serguei > > > > > > On 6/25/14 4:58 AM, Markus Gr?nlund wrote: >> >> Greetings, >> >> Kindly looking for reviews for the following change: >> >> Bug: http://bugs.openjdk.java.net/browse/JDK-8039905 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/ >> >> >> Description: >> >> JVMTI inspection code for following references makes use of a >> VM_HeapWalkOperation in order to follow-up root sets. >> >> In bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8038624 - >> "interpretedVFrame::expressions() must respect InterpreterOopMap for >> liveness", it was found that the interpretedVFrame code had a >> discrepancy between basing length information from both asking the >> interpreter frame (which saw live expression slots for calls >> instructions) as well as the oop map (which did not). >> >> The liveness decisions for a particular BCI should be based on what >> the oopmap gives, and that was done as of that bug (8038624). >> >> In that process, I added an assert in an attempt to validate certain >> assumptions, and this assert has triggered during nightly testing in >> some cases. >> >> I have therefore inspected the GC code which follow-up roots from an >> interpreted frame (please see frame::oops_interpreted_do() and >> InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), >> and reworked InterpretedVFrame so that inspections for the locals >> and expression slots are done in the same way as the GC code >> (especially in regards to taking decisions on the InterpreterOopMap). >> >> I needed to use InterpreterOopMap from a const context, and this is >> why I have "constified" this class where needed, as well as making >> "number_of_entries()" a const public accessor (to easily reach >> oop_mask length info). >> >> Testing completed: >> >> nsk/jdi* tests (especially the problematic ones reported for 8039905) >> >> compiler/6507107/HeapWalkingTest >> >> Thanks >> >> Markus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Thu Jul 3 11:06:08 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 03 Jul 2014 13:06:08 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B2AAFB.5070306@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> <53B2AAFB.5070306@oracle.com> Message-ID: <53B53920.1020804@oracle.com> Hi Roger, The test has been updated. It now uses System.nanoTime. http://cr.openjdk.java.net/~egahlin/8028474_6/ Thanks Erik roger riggs skrev 2014-07-01 14:35: > Hi Erik, > > Consider switching to System.nanoTime; it is not sensitive to clock > changes > and avoids leaving a land mine that may cause a spurious > non-repeatable test failure. > 'Deducing it from the log' means there is a failure and creates > probably an hour or two of work > for some quality engineer and burns a couple of hours re-running the > test run. > > Roger > > > > On 7/1/2014 3:37 AM, Erik Gahlin wrote: >> >> >>> JavaProcess.waitForRemoval: How about using timestamps >>> (currentTimeMillis()) before the loop and for each ite >>> ration to determine if the timeout has expired (instead of "time+=100?)? >>> >> The code now uses currentTimeMillis(). Premature timeouts due to >> clock changes can be deduced from the log. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Jul 3 13:06:58 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Jul 2014 15:06:58 +0200 Subject: RFR: 8049229 sun/tools/jps/jps-l_1.sh fails with Execution failed: exit code 1 In-Reply-To: <09D80BFD-2A7A-4FE3-BB8B-20B67ACAEF28@oracle.com> References: <09D80BFD-2A7A-4FE3-BB8B-20B67ACAEF28@oracle.com> Message-ID: <53B55572.6050006@oracle.com> Looks fine. Those simple file names really look like FQNs ... -JB- On 07/03/2014 11:22 AM, Staffan Larsen wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8049229 > webrev: http://cr.openjdk.java.net/~sla/8049229/webrev.00/ > > The problem here is that the awk scripts in the test match the lines in the ups output that end in ?.jar" twice and end up failing. The solution is to stop matching after we have found one match. > > Thanks, > /Staffan > From jaroslav.bachorik at oracle.com Thu Jul 3 14:03:17 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Jul 2014 16:03:17 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B53920.1020804@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> <53B2AAFB.5070306@oracle.com> <53B53920.1020804@oracle.com> Message-ID: <53B562A5.6080405@oracle.com> Hi Erik, nice cleanup! L160 "break" statement after this line would save unnecessary iterating when a process has already been found L172 You could use "return true". - 'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to be true on L171 -JB- On 07/03/2014 01:06 PM, Erik Gahlin wrote: > Hi Roger, > > The test has been updated. It now uses System.nanoTime. > > http://cr.openjdk.java.net/~egahlin/8028474_6/ > > Thanks > Erik > > roger riggs skrev 2014-07-01 14:35: >> Hi Erik, >> >> Consider switching to System.nanoTime; it is not sensitive to clock >> changes >> and avoids leaving a land mine that may cause a spurious >> non-repeatable test failure. >> 'Deducing it from the log' means there is a failure and creates >> probably an hour or two of work >> for some quality engineer and burns a couple of hours re-running the >> test run. >> >> Roger >> >> >> >> On 7/1/2014 3:37 AM, Erik Gahlin wrote: >>> >>> >>>> JavaProcess.waitForRemoval: How about using timestamps >>>> (currentTimeMillis()) before the loop and for each ite >>>> ration to determine if the timeout has expired (instead of "time+=100?)? >>>> >>> The code now uses currentTimeMillis(). Premature timeouts due to >>> clock changes can be deduced from the log. >>> >> > From jaroslav.bachorik at oracle.com Thu Jul 3 14:42:37 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Jul 2014 16:42:37 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B56C64.90703@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> <53B2AAFB.5070306@oracle.com> <53B53920.1020804@oracle.com> <53B562A5.6080405@oracle.com> <53B56C64.90703@oracle.com> Message-ID: <53B56BDD.1020607@oracle.com> On 07/03/2014 04:44 PM, Erik Gahlin wrote: > Hi Jaroslav, > > Here is an updated webrev: > > http://cr.openjdk.java.net/~egahlin/8028474_7/ Thanks. No more comments. -JB- > > See comments inline. > > Jaroslav Bachorik skrev 2014-07-03 16:03: >> Hi Erik, >> >> nice cleanup! >> >> L160 "break" statement after this line would save unnecessary >> iterating when a process has already been found >> > I'm not a big fan of break statements in nested loops, so refactored out > a separate method that returns when the process has been found. Also > updated releaseStarted > >> L172 You could use "return true". - >> 'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to >> be true on L171 >> > > Ops, not sure how it got there. > > Thanks > Erik > >> -JB- >> >> On 07/03/2014 01:06 PM, Erik Gahlin wrote: >>> Hi Roger, >>> >>> The test has been updated. It now uses System.nanoTime. >>> >>> http://cr.openjdk.java.net/~egahlin/8028474_6/ >>> >>> Thanks >>> Erik >>> >>> roger riggs skrev 2014-07-01 14:35: >>>> Hi Erik, >>>> >>>> Consider switching to System.nanoTime; it is not sensitive to clock >>>> changes >>>> and avoids leaving a land mine that may cause a spurious >>>> non-repeatable test failure. >>>> 'Deducing it from the log' means there is a failure and creates >>>> probably an hour or two of work >>>> for some quality engineer and burns a couple of hours re-running the >>>> test run. >>>> >>>> Roger >>>> >>>> >>>> >>>> On 7/1/2014 3:37 AM, Erik Gahlin wrote: >>>>> >>>>> >>>>>> JavaProcess.waitForRemoval: How about using timestamps >>>>>> (currentTimeMillis()) before the loop and for each ite >>>>>> ration to determine if the timeout has expired (instead of >>>>>> "time+=100?)? >>>>>> >>>>> The code now uses currentTimeMillis(). Premature timeouts due to >>>>> clock changes can be deduced from the log. >>>>> >>>> >>> >> > From markus.gronlund at oracle.com Thu Jul 3 16:34:31 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 3 Jul 2014 09:34:31 -0700 (PDT) Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" In-Reply-To: <53B5375B.8090207@oracle.com> References: <882452e7-0b02-414a-8a04-125737cb2faf@default> <53B4E476.2050306@oracle.com> <53B5375B.8090207@oracle.com> Message-ID: <1a896fae-6d6d-4c84-a057-b5d9e34ec2c5@default> Hi Serguei, ? Thanks a lot for taking a look at this. ? Yes, the primary motivation for changing this is to have this code "do the same" as the GC in respect of InterpretedVFrame (granted, we do care about value slots here, where GC doesn't). ? Sorry about making this more complex, I have tried to make some of it a bit easier to read based on your input, please take a look if you think this is easier to follow: ? New webrev suggestion: http://cr.openjdk.java.net/~mgronlun/8039905/webrev02/ ? And I agree with all the points about T_CONFLICT and dead locals that we need to consider as a next step. ? Thanks again for taking the time ? Many thanks Markus ? From: Serguei Spitsyn Sent: den 3 juli 2014 12:59 To: Markus Gr?nlund; hotspot-runtime-dev; Serviceability Dev Subject: Re: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" ? Markus, I've done another pass through the webrev. It looks good in general. Thank you for fixing it! As for the ::locals() and ::expressions() refactoring, my guess is that your motivation was to make it closer to what the GC is doing. Is it true? You can keep it as you like because my comment is not a big or strong statement. It is just my personal preference. But, the refactoring made it harder to review the changes as the original mapping has gone. As we privately discussed, this code may need further improvements related to the dead locals and so, we may need to open new bugs for recognized issues. Also, It seems you are right on the meaning of the T_CONFLICT that it is set for the dead locals. However, in my bug/testcase context the T_CONFLICT value was not set for dead local. The observed value of the dead local was T_INT (as uninitialized data) which looks pretty strange. It is possible, we have a deal with another bug here. Thanks, Serguei On 7/2/14 10:04 PM, HYPERLINK "mailto:serguei.spitsyn at oracle.com"serguei.spitsyn at oracle.com wrote: Hi Markus, Sorry for the latency. I hope this review is still needed. src/share/vm/interpreter/oopMapCache.hpp A minor comment: ?The function blocks indentation was originally aligned, but this fix partially broke it: -? uintptr_t entry_at(int offset)??????????? { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } +? uintptr_t entry_at(int offset) const????????? { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } ???void set_expression_stack_size(int sz)??? { _expression_stack_size = sz; } ?#ifdef ENABLE_ZAP_DEAD_LOCALS -? bool is_dead(int offset)?????????????????????? { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } +? bool is_dead(int offset) const??????????????? { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } #endif ? ???// Lookup -? bool match(methodHandle method, int bci)?????? { return _method == method() && _bci == bci; } -? bool is_empty(); +? bool match(methodHandle method, int bci) const { return _method == method() && _bci == bci; } +? bool is_empty() const; src/share/vm/runtime/vframe.cpp ? The implementation of the ::stack_data () combined the logics from ::locals() and ::expressions(). ? As a result, the function became unreasonably more complex to have a deal with this combination. ? The original approach looks better even though some fragments are repeated twice. ? In other words, more simple and flat lines is better than less lines with more complexity ? as it adds another dimension to track down. I need a little bit more time to better understand the vframe.cpp part of the fix. Thanks, Serguei On 6/25/14 4:58 AM, Markus Gr?nlund wrote: Greetings, ? Kindly looking for reviews for the following change: ? Bug: http://bugs.openjdk.java.net/browse/JDK-8039905 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8039905/webrev01/"http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/ ? Description: ? JVMTI inspection code for following references makes use of a VM_HeapWalkOperation in order to follow-up root sets. ? In bug: ? https://bugs.openjdk.java.net/browse/JDK-8038624 - "interpretedVFrame::expressions() must respect InterpreterOopMap for liveness", it was found that the interpretedVFrame code had a discrepancy between basing length information from both asking the interpreter frame (which saw live expression slots for calls instructions) as well as the oop map (which did not).? ? The liveness decisions for a particular BCI should be based on what the oopmap gives, and that was done as of that bug (8038624). ? In that process, I added an assert in an attempt to validate certain assumptions, and this assert has triggered during nightly testing in some cases. ? I have therefore inspected the GC code which follow-up roots from an interpreted frame (please see frame::oops_interpreted_do() and InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), and reworked ?InterpretedVFrame so that inspections for the locals and expression slots are done in the same way as the GC code (especially in regards to taking decisions on the InterpreterOopMap). ? I needed to use InterpreterOopMap from a const context, and this is why I have "constified" this class where needed, as well as making "number_of_entries()" a const public accessor (to easily reach oop_mask length info). ? Testing completed: ? nsk/jdi* tests (especially the problematic ones reported for 8039905) compiler/6507107/HeapWalkingTest ? Thanks Markus ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Jul 3 17:46:11 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Jul 2014 19:46:11 +0200 Subject: RFR(M): 8028474: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh timeout, leaves looping process behind In-Reply-To: <53B56BDD.1020607@oracle.com> References: <5398DA16.7090200@oracle.com> <539AD9AE.2050309@oracle.com> <539EC7A4.10006@oracle.com> <1F79073E-B42B-4791-9699-D5F3EFF92618@oracle.com> <53A0AF91.9060204@oracle.com> <5E3DE5CC-ED99-4D5A-8922-B867AB059ED5@oracle.com> <53A141B9.5000403@oracle.com> <53AB53B6.4020604@oracle.com> <3E657906-6D57-4B13-AF71-DB0EB15F4C48@oracle.com> <53B26555.5090203@oracle.com> <53B2AAFB.5070306@oracle.com> <53B53920.1020804@oracle.com> <53B562A5.6080405@oracle.com> <53B56C64.90703@oracle.com> <53B56BDD.1020607@oracle.com> Message-ID: I?m still ok with this. /Staffan On 3 jul 2014, at 16:42, Jaroslav Bachorik wrote: > On 07/03/2014 04:44 PM, Erik Gahlin wrote: >> Hi Jaroslav, >> >> Here is an updated webrev: >> >> http://cr.openjdk.java.net/~egahlin/8028474_7/ > > Thanks. No more comments. > > -JB- > >> >> See comments inline. >> >> Jaroslav Bachorik skrev 2014-07-03 16:03: >>> Hi Erik, >>> >>> nice cleanup! >>> >>> L160 "break" statement after this line would save unnecessary >>> iterating when a process has already been found >>> >> I'm not a big fan of break statements in nested loops, so refactored out >> a separate method that returns when the process has been found. Also >> updated releaseStarted >> >>> L172 You could use "return true". - >>> 'MonitoredVmUtil.mainArgs(target).contains(args)' has been asserted to >>> be true on L171 >>> >> >> Ops, not sure how it got there. >> >> Thanks >> Erik >> >>> -JB- >>> >>> On 07/03/2014 01:06 PM, Erik Gahlin wrote: >>>> Hi Roger, >>>> >>>> The test has been updated. It now uses System.nanoTime. >>>> >>>> http://cr.openjdk.java.net/~egahlin/8028474_6/ >>>> >>>> Thanks >>>> Erik >>>> >>>> roger riggs skrev 2014-07-01 14:35: >>>>> Hi Erik, >>>>> >>>>> Consider switching to System.nanoTime; it is not sensitive to clock >>>>> changes >>>>> and avoids leaving a land mine that may cause a spurious >>>>> non-repeatable test failure. >>>>> 'Deducing it from the log' means there is a failure and creates >>>>> probably an hour or two of work >>>>> for some quality engineer and burns a couple of hours re-running the >>>>> test run. >>>>> >>>>> Roger >>>>> >>>>> >>>>> >>>>> On 7/1/2014 3:37 AM, Erik Gahlin wrote: >>>>>> >>>>>> >>>>>>> JavaProcess.waitForRemoval: How about using timestamps >>>>>>> (currentTimeMillis()) before the loop and for each ite >>>>>>> ration to determine if the timeout has expired (instead of >>>>>>> "time+=100?)? >>>>>>> >>>>>> The code now uses currentTimeMillis(). Premature timeouts due to >>>>>> clock changes can be deduced from the log. >>>>>> >>>>> >>>> >>> >> > From markus.gronlund at oracle.com Thu Jul 3 18:38:20 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 3 Jul 2014 11:38:20 -0700 (PDT) Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" In-Reply-To: <53B593BD.6010707@oracle.com> References: <882452e7-0b02-414a-8a04-125737cb2faf@default> <53B4E476.2050306@oracle.com> <53B5375B.8090207@oracle.com> <1a896fae-6d6d-4c84-a057-b5d9e34ec2c5@default> <53B593BD.6010707@oracle.com> Message-ID: Hi Coleen, Thanks for taking a look. What about this? http://cr.openjdk.java.net/~mgronlun/8039905/webrev03/ If you are ok i will push this suggestion. /Markus -----Original Message----- From: Coleen Phillimore Sent: den 3 juli 2014 19:33 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" Hi Markus, I generally agree with Serguei about adding a conditional to have one function do two different things, but in this case the less duplication with the size calculations overrides this concern. I think your refactoring improves this. I have two requests though. Can you make 350 StackValueCollection* interpretedVFrame::stack_data(bool expressions /* false */) const { The boolean not be a default parameter. Another request that I normally make is that the bool be some sort of enum but since this isn't widespread, I think this would be overkill. The second is can you make this parameter not be a non-const reference. 289 static void stack_locals(const InterpreterOopMap& oop_mask, 290 const frame& fr, 291 int length, 292 int max_locals, 293 StackValueCollection& result) { also in stack_expressions(). You can't tell which parameter is being modified. You can't tell anyway but passing *result in the caller looks weird. Maybe making result the first parameter would also help show that that's what's being modified. These are minor style comments. I've verified the content makes sense. Please check in if no further discussion is needed. Thank you for fixing this! The gatekeepers will thank you too. Thanks, Coleen On 7/3/14, 12:34 PM, Markus Gr?nlund wrote: > Hi Serguei, > > > > Thanks a lot for taking a look at this. > > > > Yes, the primary motivation for changing this is to have this code "do the same" as the GC in respect of InterpretedVFrame (granted, we do care about value slots here, where GC doesn't). > > > > Sorry about making this more complex, I have tried to make some of it a bit easier to read based on your input, please take a look if you think this is easier to follow: > > > > New webrev suggestion: > http://cr.openjdk.java.net/~mgronlun/8039905/webrev02/ > > > > And I agree with all the points about T_CONFLICT and dead locals that we need to consider as a next step. > > > > Thanks again for taking the time > > > > Many thanks > > Markus > > > > From: Serguei Spitsyn > Sent: den 3 juli 2014 12:59 > To: Markus Gr?nlund; hotspot-runtime-dev; Serviceability Dev > Subject: Re: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" > > > > Markus, > > I've done another pass through the webrev. > It looks good in general. > Thank you for fixing it! > > As for the ::locals() and ::expressions() refactoring, my guess is > that your motivation was to make it closer to what the GC is doing. Is it true? > You can keep it as you like because my comment is not a big or strong statement. > It is just my personal preference. > But, the refactoring made it harder to review the changes as the original mapping has gone. > > As we privately discussed, this code may need further improvements > related to the dead locals and so, we may need to open new bugs for recognized issues. > Also, It seems you are right on the meaning of the T_CONFLICT that it is set for the dead locals. > However, in my bug/testcase context the T_CONFLICT value was not set for dead local. > The observed value of the dead local was T_INT (as uninitialized data) which looks pretty strange. > It is possible, we have a deal with another bug here. > > Thanks, > Serguei > > > On 7/2/14 10:04 PM, HYPERLINK "mailto:serguei.spitsyn at oracle.com"serguei.spitsyn at oracle.com wrote: > > Hi Markus, > > Sorry for the latency. > I hope this review is still needed. > > src/share/vm/interpreter/oopMapCache.hpp > > A minor comment: > The function blocks indentation was originally aligned, but this fix partially broke it: > > - uintptr_t entry_at(int offset) { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } > + uintptr_t entry_at(int offset) const { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } > > void set_expression_stack_size(int sz) { _expression_stack_size = sz; } > > #ifdef ENABLE_ZAP_DEAD_LOCALS > - bool is_dead(int offset) { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } > + bool is_dead(int offset) const { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } > #endif > > > // Lookup > - bool match(methodHandle method, int bci) { return _method == method() && _bci == bci; } > - bool is_empty(); > + bool match(methodHandle method, int bci) const { return _method == > + method() && _bci == bci; } bool is_empty() const; > > > src/share/vm/runtime/vframe.cpp > > The implementation of the ::stack_data () combined the logics from ::locals() and ::expressions(). > As a result, the function became unreasonably more complex to have a deal with this combination. > The original approach looks better even though some fragments are repeated twice. > In other words, more simple and flat lines is better than less lines with more complexity > as it adds another dimension to track down. > > > I need a little bit more time to better understand the vframe.cpp part of the fix. > > Thanks, > Serguei > > > > > > On 6/25/14 4:58 AM, Markus Gr?nlund wrote: > > Greetings, > > > > Kindly looking for reviews for the following change: > > > > Bug: http://bugs.openjdk.java.net/browse/JDK-8039905 > > Webrev: HYPERLINK > "http://cr.openjdk.java.net/%7Emgronlun/8039905/webrev01/"http://cr.op > enjdk.java.net/~mgronlun/8039905/webrev01/ > > > > Description: > > > > JVMTI inspection code for following references makes use of a VM_HeapWalkOperation in order to follow-up root sets. > > > > In bug: > > > > https://bugs.openjdk.java.net/browse/JDK-8038624 - "interpretedVFrame::expressions() must respect InterpreterOopMap for liveness", it was found that the interpretedVFrame code had a discrepancy between basing length information from both asking the interpreter frame (which saw live expression slots for calls instructions) as well as the oop map (which did not). > > > > The liveness decisions for a particular BCI should be based on what the oopmap gives, and that was done as of that bug (8038624). > > > > In that process, I added an assert in an attempt to validate certain assumptions, and this assert has triggered during nightly testing in some cases. > > > > I have therefore inspected the GC code which follow-up roots from an interpreted frame (please see frame::oops_interpreted_do() and InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), and reworked InterpretedVFrame so that inspections for the locals and expression slots are done in the same way as the GC code (especially in regards to taking decisions on the InterpreterOopMap). > > > > I needed to use InterpreterOopMap from a const context, and this is why I have "constified" this class where needed, as well as making "number_of_entries()" a const public accessor (to easily reach oop_mask length info). > > > > Testing completed: > > > > nsk/jdi* tests (especially the problematic ones reported for 8039905) > > compiler/6507107/HeapWalkingTest > > > > Thanks > > Markus > > > > From coleen.phillimore at oracle.com Thu Jul 3 19:24:29 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Jul 2014 15:24:29 -0400 Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" In-Reply-To: References: <882452e7-0b02-414a-8a04-125737cb2faf@default> <53B4E476.2050306@oracle.com> <53B5375B.8090207@oracle.com> <1a896fae-6d6d-4c84-a057-b5d9e34ec2c5@default> <53B593BD.6010707@oracle.com> Message-ID: <53B5ADED.1090700@oracle.com> On 7/3/14, 2:38 PM, Markus Gr?nlund wrote: > Hi Coleen, > > Thanks for taking a look. What about this? > > http://cr.openjdk.java.net/~mgronlun/8039905/webrev03/ > > If you are ok i will push this suggestion. Yes, I think this looks good. Ship it! Thanks! Coleen > > /Markus > > > -----Original Message----- > From: Coleen Phillimore > Sent: den 3 juli 2014 19:33 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" > > > Hi Markus, > > I generally agree with Serguei about adding a conditional to have one function do two different things, but in this case the less duplication > with the size calculations overrides this concern. I think your > refactoring improves this. I have two requests though. Can you make > > 350 StackValueCollection* interpretedVFrame::stack_data(bool expressions /* false */) const { > > > The boolean not be a default parameter. Another request that I > normally make is that the bool be some sort of enum but since this isn't widespread, I think this would be overkill. > > The second is can you make this parameter not be a non-const reference. > > 289 static void stack_locals(const InterpreterOopMap& oop_mask, > 290 const frame& fr, > 291 int length, > 292 int max_locals, > 293 StackValueCollection& result) { > also in stack_expressions(). > > You can't tell which parameter is being modified. You can't tell > anyway but passing *result in the caller looks weird. Maybe making > result the first parameter would also help show that that's what's being modified. > > These are minor style comments. I've verified the content makes sense. > Please check in if no further discussion is needed. Thank you for fixing this! The gatekeepers will thank you too. > > Thanks, > Coleen > > On 7/3/14, 12:34 PM, Markus Gr?nlund wrote: >> Hi Serguei, >> >> >> >> Thanks a lot for taking a look at this. >> >> >> >> Yes, the primary motivation for changing this is to have this code "do the same" as the GC in respect of InterpretedVFrame (granted, we do care about value slots here, where GC doesn't). >> >> >> >> Sorry about making this more complex, I have tried to make some of it a bit easier to read based on your input, please take a look if you think this is easier to follow: >> >> >> >> New webrev suggestion: >> http://cr.openjdk.java.net/~mgronlun/8039905/webrev02/ >> >> >> >> And I agree with all the points about T_CONFLICT and dead locals that we need to consider as a next step. >> >> >> >> Thanks again for taking the time >> >> >> >> Many thanks >> >> Markus >> >> >> >> From: Serguei Spitsyn >> Sent: den 3 juli 2014 12:59 >> To: Markus Gr?nlund; hotspot-runtime-dev; Serviceability Dev >> Subject: Re: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" >> >> >> >> Markus, >> >> I've done another pass through the webrev. >> It looks good in general. >> Thank you for fixing it! >> >> As for the ::locals() and ::expressions() refactoring, my guess is >> that your motivation was to make it closer to what the GC is doing. Is it true? >> You can keep it as you like because my comment is not a big or strong statement. >> It is just my personal preference. >> But, the refactoring made it harder to review the changes as the original mapping has gone. >> >> As we privately discussed, this code may need further improvements >> related to the dead locals and so, we may need to open new bugs for recognized issues. >> Also, It seems you are right on the meaning of the T_CONFLICT that it is set for the dead locals. >> However, in my bug/testcase context the T_CONFLICT value was not set for dead local. >> The observed value of the dead local was T_INT (as uninitialized data) which looks pretty strange. >> It is possible, we have a deal with another bug here. >> >> Thanks, >> Serguei >> >> >> On 7/2/14 10:04 PM, HYPERLINK "mailto:serguei.spitsyn at oracle.com"serguei.spitsyn at oracle.com wrote: >> >> Hi Markus, >> >> Sorry for the latency. >> I hope this review is still needed. >> >> src/share/vm/interpreter/oopMapCache.hpp >> >> A minor comment: >> The function blocks indentation was originally aligned, but this fix partially broke it: >> >> - uintptr_t entry_at(int offset) { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } >> + uintptr_t entry_at(int offset) const { int i = offset * bits_per_entry; return bit_mask()[i / BitsPerWord] >> (i % BitsPerWord); } >> >> void set_expression_stack_size(int sz) { _expression_stack_size = sz; } >> >> #ifdef ENABLE_ZAP_DEAD_LOCALS >> - bool is_dead(int offset) { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } >> + bool is_dead(int offset) const { return (entry_at(offset) & (1 << dead_bit_number)) != 0; } >> #endif >> >> >> // Lookup >> - bool match(methodHandle method, int bci) { return _method == method() && _bci == bci; } >> - bool is_empty(); >> + bool match(methodHandle method, int bci) const { return _method == >> + method() && _bci == bci; } bool is_empty() const; >> >> >> src/share/vm/runtime/vframe.cpp >> >> The implementation of the ::stack_data () combined the logics from ::locals() and ::expressions(). >> As a result, the function became unreasonably more complex to have a deal with this combination. >> The original approach looks better even though some fragments are repeated twice. >> In other words, more simple and flat lines is better than less lines with more complexity >> as it adds another dimension to track down. >> >> >> I need a little bit more time to better understand the vframe.cpp part of the fix. >> >> Thanks, >> Serguei >> >> >> >> >> >> On 6/25/14 4:58 AM, Markus Gr?nlund wrote: >> >> Greetings, >> >> >> >> Kindly looking for reviews for the following change: >> >> >> >> Bug: http://bugs.openjdk.java.net/browse/JDK-8039905 >> >> Webrev: HYPERLINK >> "http://cr.openjdk.java.net/%7Emgronlun/8039905/webrev01/"http://cr.op >> enjdk.java.net/~mgronlun/8039905/webrev01/ >> >> >> >> Description: >> >> >> >> JVMTI inspection code for following references makes use of a VM_HeapWalkOperation in order to follow-up root sets. >> >> >> >> In bug: >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8038624 - "interpretedVFrame::expressions() must respect InterpreterOopMap for liveness", it was found that the interpretedVFrame code had a discrepancy between basing length information from both asking the interpreter frame (which saw live expression slots for calls instructions) as well as the oop map (which did not). >> >> >> >> The liveness decisions for a particular BCI should be based on what the oopmap gives, and that was done as of that bug (8038624). >> >> >> >> In that process, I added an assert in an attempt to validate certain assumptions, and this assert has triggered during nightly testing in some cases. >> >> >> >> I have therefore inspected the GC code which follow-up roots from an interpreted frame (please see frame::oops_interpreted_do() and InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), and reworked InterpretedVFrame so that inspections for the locals and expression slots are done in the same way as the GC code (especially in regards to taking decisions on the InterpreterOopMap). >> >> >> >> I needed to use InterpreterOopMap from a const context, and this is why I have "constified" this class where needed, as well as making "number_of_entries()" a const public accessor (to easily reach oop_mask length info). >> >> >> >> Testing completed: >> >> >> >> nsk/jdi* tests (especially the problematic ones reported for 8039905) >> >> compiler/6507107/HeapWalkingTest >> >> >> >> Thanks >> >> Markus >> >> >> >> From markus.gronlund at oracle.com Thu Jul 3 21:20:46 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Thu, 3 Jul 2014 14:20:46 -0700 (PDT) Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" In-Reply-To: <53B5ADED.1090700@oracle.com> References: <882452e7-0b02-414a-8a04-125737cb2faf@default> <53B4E476.2050306@oracle.com> <53B5375B.8090207@oracle.com> <1a896fae-6d6d-4c84-a057-b5d9e34ec2c5@default> <53B593BD.6010707@oracle.com> <53B5ADED.1090700@oracle.com> Message-ID: Coleen, Serguei, Thanks for your reviews! Cheers Markus -----Original Message----- From: Coleen Phillimore Sent: den 3 juli 2014 21:24 To: Markus Gr?nlund Cc: hotspot-runtime-dev at openjdk.java.net; Serviceability Dev Subject: Re: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_frame_expression_stack_size() >= length) failed: error in expression stack!" On 7/3/14, 2:38 PM, Markus Gr?nlund wrote: > Hi Coleen, > > Thanks for taking a look. What about this? > > http://cr.openjdk.java.net/~mgronlun/8039905/webrev03/ > > If you are ok i will push this suggestion. Yes, I think this looks good. Ship it! Thanks! Coleen From markus.gronlund at oracle.com Fri Jul 4 11:43:24 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 4 Jul 2014 04:43:24 -0700 (PDT) Subject: RFR(XS): 8049324: interpretedVFrame::expressions to index oopmap correctly Message-ID: Greetings, ? In the process of trying to make the fix for https://bugs.openjdk.java.net/browse/JDK-8039905 more readable, I messed up the indexing of into the oopmap for the expression slots (in addition to being lazy on testing the new patch suggestion.) ? This omission made for a few additional failures in nightly testing - my bad. ? This fix will remedy this problem. ? bug: https://bugs.openjdk.java.net/browse/JDK-8049324 webrev: http://cr.openjdk.java.net/~mgronlun/8049324/webrev01/ ? Local testing run (Windows x64): ? nsk/jdi* nsk/jvmti* ? Sorry for any inconvenience caused by this ? Regards Markus ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Jul 4 15:59:47 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Jul 2014 17:59:47 +0200 Subject: PowerPC: core file option not available with serviceability tools In-Reply-To: <53B5A92A.401@us.ibm.com> References: <53B5A92A.401@us.ibm.com> Message-ID: Hi Maynard, we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and AIX (we have other proprietary servicibility tools). Because of that (and because SA isn't specified by the SE specification) porting the SA agent was no top priority until now. But there are no technical reasons why it should not work (it's just a lack of resources). Of course contributions are always highly welcome:) That said, the SA agent library and jar file actually gets build. If you do a complete build you'll find them under: hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so in the build directory. They are just not copied into the jdk workspace and the created images because they don't work out of the box. The following two patches for the jdk9 top-level and hotspot repositories respectively should fix the build such that the agent files will be correctly copied into the images. http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/ They will get you to the point where for example 'jstack' will run up to the following point: > images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547 Attaching to core core.13547 from executable ./jdk/bin/java, please wait... WARNING: Hotspot VM version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may see unexpected results. Debugger attached successfully. Server compiler detected. JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 Deadlock Detection: Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) at sun.tools.jstack.JStack.main(JStack.java:106) Caused by: java.lang.ExceptionInInitializerError at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:54) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) ... 6 more Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64 not yet supported at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97) at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42) at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) at sun.jvm.hotspot.runtime.Threads.(Threads.java:50) ... 16 more And that's the point where I was saying that "contributions are always highly welcome:)" Now all the Linux/PPC64 specific class under hotspot/agent/src/share/classes/ would have to be implemented (e.g. sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you interested in contributing to this project? Regards, Volker PS: I cc-ed serviceability-dev because I remember that they started a poll a while ago about who is using the SA tools. I'm therefore not quite sure what's the current status and what are the future plan for these libraries. On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson wrote: > Hi, all, > On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack, jmap, jsadebugd -- have an option to pass a core file instead of a process ID; for example: > > $ jstack -h > Usage: > jstack [-l] > (to connect to running process) > jstack -F [-m] [-l] > (to connect to a hung process) > jstack [-m] [-l] > (to connect to a core file) > jstack [-m] [-l] [server_id@] > (to connect to a remote debug server) > > But on my PowerLinux box, the core file option is missing from the usage output. I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.java requires the existence of sun.jvm.hotspot.tools.JStack for the core file option to be made available. On my Intel system, the sun.jvm.hotspot.tools.JStack class is packaged in sa-jdi.jar in /jvm/openjdk-1.9.0-internal/lib/. But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for this or is it an oversight? > > The jsadebugd tool does not run at all on PowerLinux; it gets the following error: > > Error: Could not find or load main class sun.jvm.hotspot.jdi.SADebugServer > > On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar mentioned above. > > I've spent the past day or so looking at makefiles until I'm cross-eyed, but haven't yet found where the issue might be. Any tips would be appreciated. > > Thanks. > -Maynard > From serguei.spitsyn at oracle.com Sat Jul 5 06:16:07 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 04 Jul 2014 23:16:07 -0700 Subject: RFR(XS): 8049324: interpretedVFrame::expressions to index oopmap correctly In-Reply-To: References: Message-ID: <53B79827.7000802@oracle.com> It looks good. Thanks, Serguei On 7/4/14 4:43 AM, Markus Gr?nlund wrote: > > Greetings, > > In the process of trying to make the fix for > https://bugs.openjdk.java.net/browse/JDK-8039905 more readable, I > messed up the indexing of into the oopmap for the expression slots (in > addition to being lazy on testing the new patch suggestion...) > > This omission made for a few additional failures in nightly testing -- > my bad. > > This fix will remedy this problem. > > bug: https://bugs.openjdk.java.net/browse/JDK-8049324 > > webrev: http://cr.openjdk.java.net/~mgronlun/8049324/webrev01/ > > > Local testing run (Windows x64): > > nsk/jdi* > > nsk/jvmti* > > Sorry for any inconvenience caused by this > > Regards > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Sat Jul 5 18:16:35 2014 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Sat, 5 Jul 2014 11:16:35 -0700 (PDT) Subject: RFR(XS): 8049324: interpretedVFrame::expressions to index oopmap correctly In-Reply-To: <53B83107.8030805@oracle.com> References: <53B83107.8030805@oracle.com> Message-ID: <63e21ba8-75d6-4072-9aa4-12581e3beb7a@default> Coleen and Serguei, Again, thanks for your reviews. /Markus -----Original Message----- From: Coleen Phillimore Sent: den 5 juli 2014 19:08 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8049324: interpretedVFrame::expressions to index oopmap correctly Looks good, not that I noticed the indexing problem in the first place... Coleen On 7/4/14, 7:43 AM, Markus Gr?nlund wrote: > Greetings, > > > > In the process of trying to make the fix for https://bugs.openjdk.java.net/browse/JDK-8039905 more readable, I messed up the indexing of into the oopmap for the expression slots (in addition to being lazy on testing the new patch suggestion.) > > > > This omission made for a few additional failures in nightly testing - my bad. > > > > This fix will remedy this problem. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8049324 > > webrev: http://cr.openjdk.java.net/~mgronlun/8049324/webrev01/ > > > > Local testing run (Windows x64): > > > > nsk/jdi* > > nsk/jvmti* > > > > Sorry for any inconvenience caused by this > > > > Regards > > Markus > > > > > > > > From erik.gahlin at oracle.com Sun Jul 6 16:53:59 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sun, 06 Jul 2014 18:53:59 +0200 Subject: RFR(S): 8049340: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out Message-ID: <53B97F27.3030208@oracle.com> Hi, Could I have a review of a small test fix. Webrev: http://cr.openjdk.java.net/~egahlin/8049340_1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8049340 Testing: 100 iterations locally 25 iterations locally under high load (CPU > 95%) 5 JPRT runs L226-229: If the file is removed by the test process before Files.exist statement is reached in the child process an Error is thrown. The test will pass without this change, but it makes log easier to read. L244: Use println instead of print. L292-299: The actual problem, see comment in file. L312: Typo, should be "stderr" instead of "stder" Thanks Erik From jaroslav.bachorik at oracle.com Mon Jul 7 08:23:02 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Jul 2014 10:23:02 +0200 Subject: RFR(S): 8049340: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out In-Reply-To: <53B97F27.3030208@oracle.com> References: <53B97F27.3030208@oracle.com> Message-ID: <53BA58E6.9000404@oracle.com> Hi Erik, I have a comment regarding the test timeout - you should scale the timeout according to "test.timeout.factor" system property set by JTReg (you can use "jdk.testlibrary.Utils.TIMEOUT_FACTOR" to access it easily) to prevent intermittent timeouts on slow configurations. Or you could completely omit the timeout and loop forever, relying on the harness to timeout the test. Other than that the change looks fine. Cheers, -JB- On 07/06/2014 06:53 PM, Erik Gahlin wrote: > Hi, > > Could I have a review of a small test fix. > > Webrev: > http://cr.openjdk.java.net/~egahlin/8049340_1/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8049340 > > Testing: > 100 iterations locally > 25 iterations locally under high load (CPU > 95%) > 5 JPRT runs > > L226-229: > If the file is removed by the test process before Files.exist statement > is reached in the child process > an Error is thrown. The test will pass without this change, but it makes > log easier to read. > > L244: > Use println instead of print. > > L292-299: > The actual problem, see comment in file. > > L312: > Typo, should be "stderr" instead of "stder" > > Thanks > Erik From jaroslav.bachorik at oracle.com Mon Jul 7 10:15:18 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Jul 2014 12:15:18 +0200 Subject: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 Message-ID: <53BA7336.2000402@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 jdk.testlibrary.ProcessThread was erroneously starting the external application with timeout of -1 - meaning no waiting for the target application to initialize. What it should have done was to wait for the target application indefinitely and let the harness timeout the test. The change modifies jdk.testlibrary.ProcessTools.startProcess() methods to be explicit about the meaning of "-1" and "0" (newly added) timeouts. It also adds a convenient method where you can start a process waiting for the warmup indefinitely without actually providing "0" and a dummy TimeUnit. I also took liberty and encapsulated the "test.timeout.factor" system property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. The changes to the test library keep the current semantics (eg. the timeout of -1 still means no wait etc.) - they are only enhancing it. Thanks, -JB- From erik.gahlin at oracle.com Mon Jul 7 10:28:08 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 07 Jul 2014 12:28:08 +0200 Subject: RFR(S): 8049340: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out In-Reply-To: <53BA58E6.9000404@oracle.com> References: <53B97F27.3030208@oracle.com> <53BA58E6.9000404@oracle.com> Message-ID: <53BA7638.9050508@oracle.com> Hi, I'm generally in favor of looping forever, but for this test it doesn't work since the test spawns child processes. Here is an updated version that forwards the system property. http://cr.openjdk.java.net/~egahlin/8049340_3/ I avoided Utils.TIMEOUT_FACTOR, since it would mean passing the testlibrary on the class path, making the test more complex. Thanks Erik Jaroslav Bachorik skrev 2014-07-07 10:23: > Hi Erik, > > I have a comment regarding the test timeout - you should scale the > timeout according to "test.timeout.factor" system property set by > JTReg (you can use "jdk.testlibrary.Utils.TIMEOUT_FACTOR" to access it > easily) to prevent intermittent timeouts on slow configurations. Or > you could completely omit the timeout and loop forever, relying on the > harness to timeout the test. > > Other than that the change looks fine. > > Cheers, > > -JB- > > On 07/06/2014 06:53 PM, Erik Gahlin wrote: >> Hi, >> >> Could I have a review of a small test fix. >> >> Webrev: >> http://cr.openjdk.java.net/~egahlin/8049340_1/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8049340 >> >> Testing: >> 100 iterations locally >> 25 iterations locally under high load (CPU > 95%) >> 5 JPRT runs >> >> L226-229: >> If the file is removed by the test process before Files.exist statement >> is reached in the child process >> an Error is thrown. The test will pass without this change, but it makes >> log easier to read. >> >> L244: >> Use println instead of print. >> >> L292-299: >> The actual problem, see comment in file. >> >> L312: >> Typo, should be "stderr" instead of "stder" >> >> Thanks >> Erik > From jaroslav.bachorik at oracle.com Mon Jul 7 11:19:22 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Jul 2014 13:19:22 +0200 Subject: RFR(S): 8049340: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out In-Reply-To: <53BA7638.9050508@oracle.com> References: <53B97F27.3030208@oracle.com> <53BA58E6.9000404@oracle.com> <53BA7638.9050508@oracle.com> Message-ID: <53BA823A.3080109@oracle.com> On 07/07/2014 12:28 PM, Erik Gahlin wrote: > Hi, > > I'm generally in favor of looping forever, but for this test it doesn't > work since the test spawns child processes. Here is an updated version > that forwards the system property. > > http://cr.openjdk.java.net/~egahlin/8049340_3/ > > I avoided Utils.TIMEOUT_FACTOR, since it would mean passing the > testlibrary on the class path, making the test more complex. Ok. I see. No problem. L39 import jdk.testlibrary.Utils; - unused import -JB- > > Thanks > Erik > > Jaroslav Bachorik skrev 2014-07-07 10:23: >> Hi Erik, >> >> I have a comment regarding the test timeout - you should scale the >> timeout according to "test.timeout.factor" system property set by >> JTReg (you can use "jdk.testlibrary.Utils.TIMEOUT_FACTOR" to access it >> easily) to prevent intermittent timeouts on slow configurations. Or >> you could completely omit the timeout and loop forever, relying on the >> harness to timeout the test. >> >> Other than that the change looks fine. >> >> Cheers, >> >> -JB- >> >> On 07/06/2014 06:53 PM, Erik Gahlin wrote: >>> Hi, >>> >>> Could I have a review of a small test fix. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8049340_1/ >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8049340 >>> >>> Testing: >>> 100 iterations locally >>> 25 iterations locally under high load (CPU > 95%) >>> 5 JPRT runs >>> >>> L226-229: >>> If the file is removed by the test process before Files.exist statement >>> is reached in the child process >>> an Error is thrown. The test will pass without this change, but it makes >>> log easier to read. >>> >>> L244: >>> Use println instead of print. >>> >>> L292-299: >>> The actual problem, see comment in file. >>> >>> L312: >>> Typo, should be "stderr" instead of "stder" >>> >>> Thanks >>> Erik >> > From erik.gahlin at oracle.com Mon Jul 7 11:54:27 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 07 Jul 2014 13:54:27 +0200 Subject: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53BA7336.2000402@oracle.com> References: <53BA7336.2000402@oracle.com> Message-ID: <53BA8A73.40006@oracle.com> Looks good Erik Jaroslav Bachorik skrev 2014-07-07 12:15: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 > Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 > > jdk.testlibrary.ProcessThread was erroneously starting the external > application with timeout of -1 - meaning no waiting for the target > application to initialize. What it should have done was to wait for > the target application indefinitely and let the harness timeout the test. > > The change modifies jdk.testlibrary.ProcessTools.startProcess() > methods to be explicit about the meaning of "-1" and "0" (newly added) > timeouts. It also adds a convenient method where you can start a > process waiting for the warmup indefinitely without actually providing > "0" and a dummy TimeUnit. > > I also took liberty and encapsulated the "test.timeout.factor" system > property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. > > The changes to the test library keep the current semantics (eg. the > timeout of -1 still means no wait etc.) - they are only enhancing it. > > Thanks, > > -JB- From olivier.lagneau at oracle.com Mon Jul 7 13:25:51 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Mon, 07 Jul 2014 15:25:51 +0200 Subject: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53BA7336.2000402@oracle.com> References: <53BA7336.2000402@oracle.com> Message-ID: <53BA9FDF.7080803@oracle.com> Hi Jaroslav, Thats looks good to me. Olivier. On 07/07/2014 12:15, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 > Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 > > jdk.testlibrary.ProcessThread was erroneously starting the external > application with timeout of -1 - meaning no waiting for the target > application to initialize. What it should have done was to wait for > the target application indefinitely and let the harness timeout the test. > > The change modifies jdk.testlibrary.ProcessTools.startProcess() > methods to be explicit about the meaning of "-1" and "0" (newly added) > timeouts. It also adds a convenient method where you can start a > process waiting for the warmup indefinitely without actually providing > "0" and a dummy TimeUnit. > > I also took liberty and encapsulated the "test.timeout.factor" system > property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. > > The changes to the test library keep the current semantics (eg. the > timeout of -1 still means no wait etc.) - they are only enhancing it. > > Thanks, > > -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From maynardj at us.ibm.com Mon Jul 7 14:18:30 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 07 Jul 2014 09:18:30 -0500 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> Message-ID: <53BAAC36.8030507@us.ibm.com> On 07/02/2014 01:21 PM, Volker Simonis wrote: > After a quick look I can say that at least for the "flush_icache_stub" > and "verify_oop" cases we indeed generate no code. Other platforms > like x86 for example generate code for instruction cache flushing. The > starting address of this code is saved in a function pointer and > called if necessary. On PPC64 we just save the address of a normal > C-funtion in this function pointer and implement the cache flush with > the help of inline assembler in the C-function. However this saving of > the C-function address in the corresponding function pointer is still > done in a helper method which triggers the creation of the > JvmtiExport::post_dynamic_code_generated_internal event - but with > zero size in that case. > > I agree that it is questionable if we really need to post these events > although they didn't hurt until know. Maybe we can remove them - > please let me think one more night about it:) Any further thoughts on this, Volker? Thanks. -Maynard > > Regards, > Volker > > > > On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: >> Hi Maynard, >> >> I really apologize that I've somehow missed your first message. >> ppc-aix-port-dev was the right list to post to. >> >> I'll analyze this problem instantly and let you know why we post this >> zero-code size events. >> >> Regards, >> Volker >> >> PS: really great to see that somebody is working on oprofile/OpenJDK >> integration! >> >> >> On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty >> wrote: >>> Adding the Serviceability team to the thread since JVM/TI is owned >>> by them... >>> >>> Dan >>> >>> >>> >>> On 7/2/14 10:15 AM, Maynard Johnson wrote: >>>> >>>> Cross-posting to see if Hotspot developers can help. >>>> >>>> -Maynard >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >>>> size of zero >>>> Date: Wed, 25 Jun 2014 10:18:17 -0500 >>>> From: Maynard Johnson >>>> To: ppc-aix-port-dev at openjdk.java.net >>>> >>>> Hello, PowerPC OpenJDK folks, >>>> I am just now starting to get involved in the OpenJDK project. My goal is >>>> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >>>> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >>>> start with since I have some experience from a client perspective with the >>>> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >>>> provides an agent library that implements the JVMTI API. Using this agent >>>> library to profile Java apps on my Intel-based laptop with OpenJDK (using >>>> various versions, up to current jdk9-dev) works fine. But the same >>>> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >>>> miserably. >>>> >>>> The oprofile agent library registers for callbacks for CompiledMethodLoad, >>>> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >>>> it writes information about the JVMTI event to a file. After profiling >>>> completes, oprofile's post-processing phase involves interpreting the >>>> information from the agent library's output file and generating an ELF file >>>> to represent the JITed code. When I profile an OpenJDK app on my Power >>>> system, the post-processing phase fails while trying to resolve overlapping >>>> symbols. The failure is due to the fact that it is unexpectedly finding >>>> symbols with code size of zero overlapping at the starting address of some >>>> other symbol with non-zero code size. The symbols in question here are from >>>> DynamicCodeGenerated events. >>>> >>>> Are these "code size=0" events valid? If so, I can fix the oprofile code >>>> to handle them. If they're not valid, then below is some debug information >>>> I've collected so far. >>>> >>>> ---------------------------- >>>> >>>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >>>> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >>>> symbol with code size of zero was detected and then ran the following >>>> command: >>>> >>>> java >>>> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >>>> -version >>>> >>>> The debug output from my instrumentation was as follows: >>>> >>>> Code size is ZERO!! Dynamic code generated event sent for >>>> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >>>> Code size is ZERO!! Dynamic code generated event sent for >>>> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >>>> Code size is ZERO!! Dynamic code generated event sent for >>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>> Code size is ZERO!! Dynamic code generated event sent for >>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>> Code size is ZERO!! Dynamic code generated event sent for >>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >>>> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >>>> openjdk version "1.9.0-internal" >>>> OpenJDK Runtime Environment (build >>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >>>> OpenJDK 64-Bit Server VM (build >>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >>>> >>>> >>>> I don't have access to an AIX system to know if the same issue would be >>>> seen there. Let me know if there's any other information I can provide. >>>> >>>> Thanks for the help. >>>> >>>> -Maynard >>>> >>>> >>>> >>> > From volker.simonis at gmail.com Mon Jul 7 15:51:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 7 Jul 2014 17:51:20 +0200 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: <53BAAC36.8030507@us.ibm.com> References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> <53BAAC36.8030507@us.ibm.com> Message-ID: Hi Maynard, I've opened bug "PPC64: Don't use StubCodeMarks for zero-length stubs" (https://bugs.openjdk.java.net/browse/JDK-8049441) for this issue. Until it is resolved in the main code line, you can use the attached patch to work around the problem. Regards, Volker On Mon, Jul 7, 2014 at 4:18 PM, Maynard Johnson wrote: > On 07/02/2014 01:21 PM, Volker Simonis wrote: >> After a quick look I can say that at least for the "flush_icache_stub" >> and "verify_oop" cases we indeed generate no code. Other platforms >> like x86 for example generate code for instruction cache flushing. The >> starting address of this code is saved in a function pointer and >> called if necessary. On PPC64 we just save the address of a normal >> C-funtion in this function pointer and implement the cache flush with >> the help of inline assembler in the C-function. However this saving of >> the C-function address in the corresponding function pointer is still >> done in a helper method which triggers the creation of the >> JvmtiExport::post_dynamic_code_generated_internal event - but with >> zero size in that case. >> >> I agree that it is questionable if we really need to post these events >> although they didn't hurt until know. Maybe we can remove them - >> please let me think one more night about it:) > Any further thoughts on this, Volker? Thanks. > > -Maynard >> >> Regards, >> Volker >> >> >> >> On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> I really apologize that I've somehow missed your first message. >>> ppc-aix-port-dev was the right list to post to. >>> >>> I'll analyze this problem instantly and let you know why we post this >>> zero-code size events. >>> >>> Regards, >>> Volker >>> >>> PS: really great to see that somebody is working on oprofile/OpenJDK >>> integration! >>> >>> >>> On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty >>> wrote: >>>> Adding the Serviceability team to the thread since JVM/TI is owned >>>> by them... >>>> >>>> Dan >>>> >>>> >>>> >>>> On 7/2/14 10:15 AM, Maynard Johnson wrote: >>>>> >>>>> Cross-posting to see if Hotspot developers can help. >>>>> >>>>> -Maynard >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >>>>> size of zero >>>>> Date: Wed, 25 Jun 2014 10:18:17 -0500 >>>>> From: Maynard Johnson >>>>> To: ppc-aix-port-dev at openjdk.java.net >>>>> >>>>> Hello, PowerPC OpenJDK folks, >>>>> I am just now starting to get involved in the OpenJDK project. My goal is >>>>> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >>>>> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >>>>> start with since I have some experience from a client perspective with the >>>>> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >>>>> provides an agent library that implements the JVMTI API. Using this agent >>>>> library to profile Java apps on my Intel-based laptop with OpenJDK (using >>>>> various versions, up to current jdk9-dev) works fine. But the same >>>>> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >>>>> miserably. >>>>> >>>>> The oprofile agent library registers for callbacks for CompiledMethodLoad, >>>>> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >>>>> it writes information about the JVMTI event to a file. After profiling >>>>> completes, oprofile's post-processing phase involves interpreting the >>>>> information from the agent library's output file and generating an ELF file >>>>> to represent the JITed code. When I profile an OpenJDK app on my Power >>>>> system, the post-processing phase fails while trying to resolve overlapping >>>>> symbols. The failure is due to the fact that it is unexpectedly finding >>>>> symbols with code size of zero overlapping at the starting address of some >>>>> other symbol with non-zero code size. The symbols in question here are from >>>>> DynamicCodeGenerated events. >>>>> >>>>> Are these "code size=0" events valid? If so, I can fix the oprofile code >>>>> to handle them. If they're not valid, then below is some debug information >>>>> I've collected so far. >>>>> >>>>> ---------------------------- >>>>> >>>>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >>>>> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >>>>> symbol with code size of zero was detected and then ran the following >>>>> command: >>>>> >>>>> java >>>>> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >>>>> -version >>>>> >>>>> The debug output from my instrumentation was as follows: >>>>> >>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >>>>> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >>>>> openjdk version "1.9.0-internal" >>>>> OpenJDK Runtime Environment (build >>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >>>>> OpenJDK 64-Bit Server VM (build >>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >>>>> >>>>> >>>>> I don't have access to an AIX system to know if the same issue would be >>>>> seen there. Let me know if there's any other information I can provide. >>>>> >>>>> Thanks for the help. >>>>> >>>>> -Maynard >>>>> >>>>> >>>>> >>>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_zero_length_stubs.patch Type: text/x-patch Size: 1180 bytes Desc: not available URL: From maynardj at us.ibm.com Mon Jul 7 17:40:01 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 07 Jul 2014 12:40:01 -0500 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> <53BAAC36.8030507@us.ibm.com> Message-ID: <53BADB71.2080200@us.ibm.com> On 07/07/2014 10:51 AM, Volker Simonis wrote: > Hi Maynard, > > I've opened bug "PPC64: Don't use StubCodeMarks for zero-length stubs" > (https://bugs.openjdk.java.net/browse/JDK-8049441) for this issue. > Until it is resolved in the main code line, you can use the attached > patch to work around the problem. Thanks. The patch does indeed resolve the problem. Now oprofile can properly handle the JVMTI events and can also resolve samples in JITed code to the associated Java methods. :-) -Maynard > > Regards, > Volker > > > On Mon, Jul 7, 2014 at 4:18 PM, Maynard Johnson wrote: >> On 07/02/2014 01:21 PM, Volker Simonis wrote: >>> After a quick look I can say that at least for the "flush_icache_stub" >>> and "verify_oop" cases we indeed generate no code. Other platforms >>> like x86 for example generate code for instruction cache flushing. The >>> starting address of this code is saved in a function pointer and >>> called if necessary. On PPC64 we just save the address of a normal >>> C-funtion in this function pointer and implement the cache flush with >>> the help of inline assembler in the C-function. However this saving of >>> the C-function address in the corresponding function pointer is still >>> done in a helper method which triggers the creation of the >>> JvmtiExport::post_dynamic_code_generated_internal event - but with >>> zero size in that case. >>> >>> I agree that it is questionable if we really need to post these events >>> although they didn't hurt until know. Maybe we can remove them - >>> please let me think one more night about it:) >> Any further thoughts on this, Volker? Thanks. >> >> -Maynard >>> >>> Regards, >>> Volker >>> >>> >>> >>> On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: >>>> Hi Maynard, >>>> >>>> I really apologize that I've somehow missed your first message. >>>> ppc-aix-port-dev was the right list to post to. >>>> >>>> I'll analyze this problem instantly and let you know why we post this >>>> zero-code size events. >>>> >>>> Regards, >>>> Volker >>>> >>>> PS: really great to see that somebody is working on oprofile/OpenJDK >>>> integration! >>>> >>>> >>>> On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty >>>> wrote: >>>>> Adding the Serviceability team to the thread since JVM/TI is owned >>>>> by them... >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> On 7/2/14 10:15 AM, Maynard Johnson wrote: >>>>>> >>>>>> Cross-posting to see if Hotspot developers can help. >>>>>> >>>>>> -Maynard >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >>>>>> size of zero >>>>>> Date: Wed, 25 Jun 2014 10:18:17 -0500 >>>>>> From: Maynard Johnson >>>>>> To: ppc-aix-port-dev at openjdk.java.net >>>>>> >>>>>> Hello, PowerPC OpenJDK folks, >>>>>> I am just now starting to get involved in the OpenJDK project. My goal is >>>>>> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >>>>>> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >>>>>> start with since I have some experience from a client perspective with the >>>>>> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >>>>>> provides an agent library that implements the JVMTI API. Using this agent >>>>>> library to profile Java apps on my Intel-based laptop with OpenJDK (using >>>>>> various versions, up to current jdk9-dev) works fine. But the same >>>>>> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >>>>>> miserably. >>>>>> >>>>>> The oprofile agent library registers for callbacks for CompiledMethodLoad, >>>>>> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >>>>>> it writes information about the JVMTI event to a file. After profiling >>>>>> completes, oprofile's post-processing phase involves interpreting the >>>>>> information from the agent library's output file and generating an ELF file >>>>>> to represent the JITed code. When I profile an OpenJDK app on my Power >>>>>> system, the post-processing phase fails while trying to resolve overlapping >>>>>> symbols. The failure is due to the fact that it is unexpectedly finding >>>>>> symbols with code size of zero overlapping at the starting address of some >>>>>> other symbol with non-zero code size. The symbols in question here are from >>>>>> DynamicCodeGenerated events. >>>>>> >>>>>> Are these "code size=0" events valid? If so, I can fix the oprofile code >>>>>> to handle them. If they're not valid, then below is some debug information >>>>>> I've collected so far. >>>>>> >>>>>> ---------------------------- >>>>>> >>>>>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >>>>>> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >>>>>> symbol with code size of zero was detected and then ran the following >>>>>> command: >>>>>> >>>>>> java >>>>>> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >>>>>> -version >>>>>> >>>>>> The debug output from my instrumentation was as follows: >>>>>> >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >>>>>> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >>>>>> openjdk version "1.9.0-internal" >>>>>> OpenJDK Runtime Environment (build >>>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >>>>>> OpenJDK 64-Bit Server VM (build >>>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >>>>>> >>>>>> >>>>>> I don't have access to an AIX system to know if the same issue would be >>>>>> seen there. Let me know if there's any other information I can provide. >>>>>> >>>>>> Thanks for the help. >>>>>> >>>>>> -Maynard >>>>>> >>>>>> >>>>>> >>>>> >>> >> From erik.gahlin at oracle.com Tue Jul 8 08:06:59 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 08 Jul 2014 10:06:59 +0200 Subject: RFR(S): 8049340: sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java timed out In-Reply-To: <53BA823A.3080109@oracle.com> References: <53B97F27.3030208@oracle.com> <53BA58E6.9000404@oracle.com> <53BA7638.9050508@oracle.com> <53BA823A.3080109@oracle.com> Message-ID: <53BBA6A3.6080705@oracle.com> Thanks, will remove unused import before I push. Still need a (R)eviewer. Or I will have to wait until next Tuesday, when you hopefully will become one ;) Erik Jaroslav Bachorik skrev 07/07/14 13:19: > On 07/07/2014 12:28 PM, Erik Gahlin wrote: >> Hi, >> >> I'm generally in favor of looping forever, but for this test it doesn't >> work since the test spawns child processes. Here is an updated version >> that forwards the system property. >> >> http://cr.openjdk.java.net/~egahlin/8049340_3/ >> >> I avoided Utils.TIMEOUT_FACTOR, since it would mean passing the >> testlibrary on the class path, making the test more complex. > > Ok. I see. No problem. > L39 import jdk.testlibrary.Utils; - unused import > > -JB- > >> >> Thanks >> Erik >> >> Jaroslav Bachorik skrev 2014-07-07 10:23: >>> Hi Erik, >>> >>> I have a comment regarding the test timeout - you should scale the >>> timeout according to "test.timeout.factor" system property set by >>> JTReg (you can use "jdk.testlibrary.Utils.TIMEOUT_FACTOR" to access it >>> easily) to prevent intermittent timeouts on slow configurations. Or >>> you could completely omit the timeout and loop forever, relying on the >>> harness to timeout the test. >>> >>> Other than that the change looks fine. >>> >>> Cheers, >>> >>> -JB- >>> >>> On 07/06/2014 06:53 PM, Erik Gahlin wrote: >>>> Hi, >>>> >>>> Could I have a review of a small test fix. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~egahlin/8049340_1/ >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8049340 >>>> >>>> Testing: >>>> 100 iterations locally >>>> 25 iterations locally under high load (CPU > 95%) >>>> 5 JPRT runs >>>> >>>> L226-229: >>>> If the file is removed by the test process before Files.exist >>>> statement >>>> is reached in the child process >>>> an Error is thrown. The test will pass without this change, but it >>>> makes >>>> log easier to read. >>>> >>>> L244: >>>> Use println instead of print. >>>> >>>> L292-299: >>>> The actual problem, see comment in file. >>>> >>>> L312: >>>> Typo, should be "stderr" instead of "stder" >>>> >>>> Thanks >>>> Erik >>> >> > From daniel.daugherty at oracle.com Tue Jul 8 15:45:59 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 08 Jul 2014 09:45:59 -0600 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: References: Message-ID: <53BC1237.2060006@oracle.com> Adding the Serviceability Team since JVM/TI belongs to them. Dan On 7/8/14 9:41 AM, Volker Simonis wrote: > Hi, > > could somebody please review and push the following small, PPC64-only > change to any of the hs team repositories: > > http://cr.openjdk.java.net/~simonis/webrevs/8049441/ > https://bugs.openjdk.java.net/browse/JDK-8049441 > > Background: > > For some stubs we actually do not really generate code on PPC64 but > instead we use a native C-function with inline-assembly. If the > generators of these stubs contain a StubCodeMark, they will trigger > JvmtiExport::post_dynamic_code_generated_internal events with a zero > length code size. These events may fool clients like Oprofile which > register for these events (thanks to Maynard Johnson who reported this > - see http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). > > This change simply removes the StubCodeMark from > ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() > because they don't generate assembly code. It also removes the > StubCodeMark from generate_throw_exception() because it doesn't really > generate a plain stub but a runtime stub for which the JVMT dynamic > code event is already generated by RuntimeStub::new_runtime_stub() -> > CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated(). > > Thank you and best regards, > Volker From jeremymanson at google.com Wed Jul 9 00:22:41 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 8 Jul 2014 17:22:41 -0700 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: References: <536C48B1.7070408@oracle.com> Message-ID: Sorry about the delay. What I said in the last message is nonsense. values() returns a collection that calls containsValue() on the HashMap to determine whether the object is present. That's potentially O(n). By using HashSet(values()), we call contains() on a HashSet instead, which is O(1). I measured this with a class with 6K methods, and saw a 40x speedup in invocations of visibleMethods() from this change. Jeremy On Fri, May 9, 2014 at 9:32 AM, Jeremy Manson wrote: > Hi David, > > Hm. This was done several years ago in response to a user request, and he > claimed it cleared up the problem, but you're right - contains() on the > collection returned by map.values() should have been an O(1) operation, > both then and now. So I'll check into it and get back on this next week. > > Jeremy > > > On Thu, May 8, 2014 at 8:17 PM, David Holmes > wrote: > >> Hi Jeremy, >> >> >> On 9/05/2014 4:56 AM, Jeremy Manson wrote: >> >>> I'm testing out my newly acquired OpenJDK authorship with something >>> simple. If I did this wrong, I apologize. >>> >>> Basically, the debugger becomes very slow if there are a lot of methods >>> in a class. This can happen (O(thousands)) if you are using a code >>> generation tool. >>> >>> http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ >>> >> >> I find it counter-intuitive that this makes things faster: >> >> - list.retainAll(map.values()); >> + list.retainAll(new HashSet(map.values())); >> >> Can you explain why introducing the intermediate HashSet improves things? >> A comment in the code would also be good. >> >> Thanks, >> David >> >> >> >> >> Reviews from reviewers and committing from committers would be >>> appreciated. Thanks! >>> >>> Jeremy >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maynardj at us.ibm.com Wed Jul 9 13:45:33 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 09 Jul 2014 08:45:33 -0500 Subject: PowerPC: core file option not available with serviceability tools In-Reply-To: References: <53B5A92A.401@us.ibm.com> Message-ID: <53BD477D.2090107@us.ibm.com> On 07/04/2014 10:59 AM, Volker Simonis wrote: > Hi Maynard, > > we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and > AIX (we have other proprietary servicibility tools). Because of that > (and because SA isn't specified by the SE specification) porting the > SA agent was no top priority until now. But there are no technical > reasons why it should not work (it's just a lack of resources). Of > course contributions are always highly welcome:) > > That said, the SA agent library and jar file actually gets build. If > you do a complete build you'll find them under: > > hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar > hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so > > in the build directory. They are just not copied into the jdk > workspace and the created images because they don't work out of the > box. > > The following two patches for the jdk9 top-level and hotspot > repositories respectively should fix the build such that the agent > files will be correctly copied into the images. > > http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel > http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/ > > They will get you to the point where for example 'jstack' will run up > to the following point: Ok, great. This should be enough to get me started. I should have time to begin on this later this week or early next week. I may come knocking at your "door" for some occasional help, but I'll try to keep that to a minimum. I was wondering if a bug report should be opened in JBS, just to record that the issue is being worked. Thoughts? -Maynard > >> images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547 > Attaching to core core.13547 from executable ./jdk/bin/java, please wait... > WARNING: Hotspot VM version > 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with > SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may > see unexpected results. > Debugger attached successfully. > Server compiler detected. > JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 > Deadlock Detection: > > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) > at sun.tools.jstack.JStack.main(JStack.java:106) > Caused by: java.lang.ExceptionInInitializerError > at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:54) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) > at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) > ... 6 more > Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64 > not yet supported > at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97) > at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42) > at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) > at sun.jvm.hotspot.runtime.Threads.(Threads.java:50) > ... 16 more > > And that's the point where I was saying that "contributions are always > highly welcome:)" > > Now all the Linux/PPC64 specific class under > hotspot/agent/src/share/classes/ would have to be implemented (e.g. > sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you > interested in contributing to this project? > > Regards, > Volker > > PS: I cc-ed serviceability-dev because I remember that they started a > poll a while ago about who is using the SA tools. I'm therefore not > quite sure what's the current status and what are the future plan for > these libraries. > > > On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson wrote: >> Hi, all, >> On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack, jmap, jsadebugd -- have an option to pass a core file instead of a process ID; for example: >> >> $ jstack -h >> Usage: >> jstack [-l] >> (to connect to running process) >> jstack -F [-m] [-l] >> (to connect to a hung process) >> jstack [-m] [-l] >> (to connect to a core file) >> jstack [-m] [-l] [server_id@] >> (to connect to a remote debug server) >> >> But on my PowerLinux box, the core file option is missing from the usage output. I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.java requires the existence of sun.jvm.hotspot.tools.JStack for the core file option to be made available. On my Intel system, the sun.jvm.hotspot.tools.JStack class is packaged in sa-jdi.jar in /jvm/openjdk-1.9.0-internal/lib/. But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for this or is it an oversight? >> >> The jsadebugd tool does not run at all on PowerLinux; it gets the following error: >> >> Error: Could not find or load main class sun.jvm.hotspot.jdi.SADebugServer >> >> On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar mentioned above. >> >> I've spent the past day or so looking at makefiles until I'm cross-eyed, but haven't yet found where the issue might be. Any tips would be appreciated. >> >> Thanks. >> -Maynard >> > From volker.simonis at gmail.com Wed Jul 9 17:36:21 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Jul 2014 19:36:21 +0200 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 Message-ID: Hi, could someone please review and sponsor the following change which does some preliminary work for enabling the SA agent on Linux/PPC64: http://cr.openjdk.java.net/~simonis/webrevs/8049715/ https://bugs.openjdk.java.net/browse/JDK-8049715 Details: Currently, we don't support the SA agent on Linux/PPC64. This change fixes the buildsystem such that the SA libraries (i.e. libsaproc.so and sa-jdi.jar) will be correctly build and copied into the resulting jdk images. This change also contains some small fixes in sa-jdi.jar to correctly detect Linux/PPC64 as supported SA platform. (The actual implementation of the Linux/PPC64 specific code will be handled by "8049716 PPC64: Implement SA on Linux/PPC64" - https://bugs.openjdk.java.net/browse/JDK-8049716). One thing which require special attention are the changes in make/linux/makefiles/defs.make which may touch the closed ppc port. In my change I've simply added 'ppc' to the list of supported architectures, but this may break the 32-bit ppc build. I think the current code is to verbose and error prone anyway. It would be better to have something like: ADD_SA_BINARIES = $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) $(EXPORT_LIB_DIR)/sa-jdi.jar ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) ifeq ($(ZIP_DEBUGINFO_FILES),1) ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz else ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo endif endif ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 ppc64)) EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) endif With this solution we only define ADD_SA_BINARIES once (because the various definitions for the different platforms are equal anyway). But again this may affect other closed ports so please advise which solution you'd prefer. Notice that this change also requires a tiny fix in the top-level repository which must be pushed AFTER this change. Thank you and best regards, Volker From volker.simonis at gmail.com Wed Jul 9 17:38:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Jul 2014 19:38:12 +0200 Subject: PowerPC: core file option not available with serviceability tools In-Reply-To: <53BD477D.2090107@us.ibm.com> References: <53B5A92A.401@us.ibm.com> <53BD477D.2090107@us.ibm.com> Message-ID: On Wed, Jul 9, 2014 at 3:45 PM, Maynard Johnson wrote: > On 07/04/2014 10:59 AM, Volker Simonis wrote: >> Hi Maynard, >> >> we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and >> AIX (we have other proprietary servicibility tools). Because of that >> (and because SA isn't specified by the SE specification) porting the >> SA agent was no top priority until now. But there are no technical >> reasons why it should not work (it's just a lack of resources). Of >> course contributions are always highly welcome:) >> >> That said, the SA agent library and jar file actually gets build. If >> you do a complete build you'll find them under: >> >> hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar >> hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so >> >> in the build directory. They are just not copied into the jdk >> workspace and the created images because they don't work out of the >> box. >> >> The following two patches for the jdk9 top-level and hotspot >> repositories respectively should fix the build such that the agent >> files will be correctly copied into the images. >> >> http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel >> http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/ >> >> They will get you to the point where for example 'jstack' will run up >> to the following point: > Ok, great. This should be enough to get me started. I should have time to begin on this later this week or early next week. Hi Maynard, great to welcome you in the ppc64 porting team:) > I may come knocking at your "door" for some occasional help, but I'll try to keep that to a minimum. Please feel free to ask any questions. The OpenJDK project and especially the HotSpot part are known to take some getting used to. > I was wondering if a bug report should be opened in JBS, just to record that the issue is being worked. Thoughts? I have opened "8049715: PPC64: First steps to enable SA on Linux/PPC64" (https://bugs.openjdk.java.net/browse/JDK-8049715) for the patch which I sent you with the last mail. I've already sent out webrevs for that change and hopefully it will be fixed within the next few days. For the actual port of the ppc64-specific stuff I opened bug "8049716 PPC64: Implement SA on Linux/PPC64" (https://bugs.openjdk.java.net/browse/JDK-8049716). I can also help with hosting the webrevs, once you have a running version. Regards, Volker > > -Maynard >> >>> images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547 >> Attaching to core core.13547 from executable ./jdk/bin/java, please wait... >> WARNING: Hotspot VM version >> 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with >> SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may >> see unexpected results. >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 >> Deadlock Detection: >> >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) >> at sun.tools.jstack.JStack.main(JStack.java:106) >> Caused by: java.lang.ExceptionInInitializerError >> at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610) >> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:54) >> at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >> at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) >> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >> at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) >> ... 6 more >> Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64 >> not yet supported >> at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97) >> at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42) >> at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52) >> at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) >> at sun.jvm.hotspot.runtime.Threads.(Threads.java:50) >> ... 16 more >> >> And that's the point where I was saying that "contributions are always >> highly welcome:)" >> >> Now all the Linux/PPC64 specific class under >> hotspot/agent/src/share/classes/ would have to be implemented (e.g. >> sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you >> interested in contributing to this project? >> >> Regards, >> Volker >> >> PS: I cc-ed serviceability-dev because I remember that they started a >> poll a while ago about who is using the SA tools. I'm therefore not >> quite sure what's the current status and what are the future plan for >> these libraries. >> >> >> On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson wrote: >>> Hi, all, >>> On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack, jmap, jsadebugd -- have an option to pass a core file instead of a process ID; for example: >>> >>> $ jstack -h >>> Usage: >>> jstack [-l] >>> (to connect to running process) >>> jstack -F [-m] [-l] >>> (to connect to a hung process) >>> jstack [-m] [-l] >>> (to connect to a core file) >>> jstack [-m] [-l] [server_id@] >>> (to connect to a remote debug server) >>> >>> But on my PowerLinux box, the core file option is missing from the usage output. I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.java requires the existence of sun.jvm.hotspot.tools.JStack for the core file option to be made available. On my Intel system, the sun.jvm.hotspot.tools.JStack class is packaged in sa-jdi.jar in /jvm/openjdk-1.9.0-internal/lib/. But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for this or is it an oversight? >>> >>> The jsadebugd tool does not run at all on PowerLinux; it gets the following error: >>> >>> Error: Could not find or load main class sun.jvm.hotspot.jdi.SADebugServer >>> >>> On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar mentioned above. >>> >>> I've spent the past day or so looking at makefiles until I'm cross-eyed, but haven't yet found where the issue might be. Any tips would be appreciated. >>> >>> Thanks. >>> -Maynard >>> >> > From joe.darcy at oracle.com Wed Jul 9 17:53:29 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 10:53:29 -0700 Subject: JDK 9 RFR of JDK-8049736: Fix raw and unchecked lint warnings in sun.tracing Message-ID: <53BD8199.60401@oracle.com> Hello, Please review the patch below which addresses JDK-8049736: Fix raw and unchecked lint warnings in sun.tracing Thanks, -Joe diff -r 2b7bf1d63a9c src/share/classes/sun/tracing/ProviderSkeleton.java --- a/src/share/classes/sun/tracing/ProviderSkeleton.java Wed Jul 09 10:02:30 2014 -0700 +++ b/src/share/classes/sun/tracing/ProviderSkeleton.java Wed Jul 09 10:53:02 2014 -0700 @@ -154,7 +154,7 @@ * @return always null, if the method is a user-defined probe */ public Object invoke(Object proxy, Method method, Object[] args) { - Class declaringClass = method.getDeclaringClass(); + Class declaringClass = method.getDeclaringClass(); // not a provider subtype's own method if (declaringClass != providerType) { try { diff -r 2b7bf1d63a9c src/share/classes/sun/tracing/dtrace/DTraceProvider.java --- a/src/share/classes/sun/tracing/dtrace/DTraceProvider.java Wed Jul 09 10:02:30 2014 -0700 +++ b/src/share/classes/sun/tracing/dtrace/DTraceProvider.java Wed Jul 09 10:53:02 2014 -0700 @@ -50,7 +50,7 @@ private Object proxy; // For proxy generation - private final static Class[] constructorParams = { InvocationHandler.class }; + private final static Class[] constructorParams = { InvocationHandler.class }; private final String proxyClassNamePrefix = "$DTraceTracingProxy"; static final String DEFAULT_MODULE = "java_tracing"; @@ -135,7 +135,7 @@ * Invoke its constructor with the designated invocation handler. */ try { - Constructor cons = proxyClass.getConstructor(constructorParams); + Constructor cons = proxyClass.getConstructor(constructorParams); return (T)cons.newInstance(new Object[] { this }); } catch (ReflectiveOperationException e) { throw new InternalError(e.toString(), e); From erik.gahlin at oracle.com Wed Jul 9 17:56:25 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 09 Jul 2014 19:56:25 +0200 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: References: Message-ID: <53BD8249.7090304@oracle.com> Looks good! Not a Reviewer, but I can sponsor it. Erik Jeremy Manson skrev 08/05/14 20:56: > I'm testing out my newly acquired OpenJDK authorship with something > simple. If I did this wrong, I apologize. > > Basically, the debugger becomes very slow if there are a lot of > methods in a class. This can happen (O(thousands)) if you are using a > code generation tool. > > http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ > > > Reviews from reviewers and committing from committers would be > appreciated. Thanks! > > Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jul 9 21:36:19 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 14:36:19 -0700 Subject: JDK 9 RFR of JDK-8049794: Fix raw and unchecked warnings in jvmstat Message-ID: <53BDB5D3.2050608@oracle.com> Hello, Please review these changes to address JDK-8049794: Fix raw and unchecked warnings in jvmstat http://cr.openjdk.java.net/~darcy/8049794.0/ Patch below. Thanks, -Joe --- old/src/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java 2014-07-09 14:30:52.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/monitor/event/MonitorStatusChangeEvent.java 2014-07-09 14:30:52.000000000 -0700 @@ -27,6 +27,7 @@ import java.util.List; import sun.jvmstat.monitor.MonitoredVm; +import sun.jvmstat.monitor.Monitor; /** * Provides a description of a change in status of the instrumentation @@ -42,13 +43,13 @@ * List of instrumentation objects inserted since the last event. * Elements of this list will always be of type Monitor. */ - protected List inserted; + protected List inserted; /** * List of instrumentation objects removed since the last event. * Elements of this list will always be of type Monitor. */ - protected List removed; + protected List removed; /** * Construct a new MonitorStatusChangeEvent. @@ -59,8 +60,8 @@ * @param removed the list of instrumentation objects removed since * the last event. */ - public MonitorStatusChangeEvent(MonitoredVm vm, List inserted, - List removed) { + public MonitorStatusChangeEvent(MonitoredVm vm, List inserted, + List removed) { super(vm); this.inserted = inserted; this.removed = removed; @@ -75,7 +76,7 @@ * new instrumentation was inserted, an emply List is * returned. */ - public List getInserted() { + public List getInserted() { return inserted; } @@ -87,7 +88,7 @@ * instrumentation exported by the MonitoredHost. If no * instrumentation was removed, an emply List is returned. */ - public List getRemoved() { + public List getRemoved() { return removed; } } --- old/src/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java 2014-07-09 14:30:52.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/monitor/event/VmStatusChangeEvent.java 2014-07-09 14:30:52.000000000 -0700 @@ -44,7 +44,7 @@ * active Java Virtual Machine on the MonitoredHost. This Set will only * contain Integer objects. */ - protected Set active; + protected Set active; /** * The set of Java Virtual Machines started on MonitoredHost since the @@ -52,7 +52,7 @@ * lvmid for each Java Virtual Machine started on the * MonitoredHost. This Set will only contain Integer objects. */ - protected Set started; + protected Set started; /** * The set of Java Virtual Machines terminated on MonitoredHost since the @@ -60,7 +60,7 @@ * lvmid for each Java Virtual Machine started on the * MonitoredHost. This Set will only contain Integer objects. */ - protected Set terminated; + protected Set terminated; /** * Construct a new VmStatusChangeEvent instance. @@ -72,8 +72,8 @@ * @param terminated the set of Java Virtual Machines terminated since * the last event. */ - public VmStatusChangeEvent(MonitoredHost host, Set active, - Set started, Set terminated) { + public VmStatusChangeEvent(MonitoredHost host, Set active, + Set started, Set terminated) { super(host); this.active = active; this.started = started; @@ -90,7 +90,7 @@ * there are no active Java Virtual Machines on the host, * an empty Set is returned. */ - public Set getActive() { + public Set getActive() { return active; } @@ -105,7 +105,7 @@ * no Java Virtual Machines were recently started on the * host, an empty Set is returned. */ - public Set getStarted() { + public Set getStarted() { return started; } @@ -120,7 +120,7 @@ * no Java Virtual Machines were recently terminated on the * host, an empty Set is returned. */ - public Set getTerminated() { + public Set getTerminated() { return terminated; } } --- old/src/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java 2014-07-09 14:30:53.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/AbstractPerfDataBuffer.java 2014-07-09 14:30:52.000000000 -0700 @@ -169,7 +169,7 @@ try { Class implClass = Class.forName(classname); - Constructor cons = implClass.getConstructor(new Class[] { + Constructor cons = implClass.getConstructor(new Class[] { Class.forName("java.nio.ByteBuffer"), Integer.TYPE }); --- old/src/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java 2014-07-09 14:30:53.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/MonitorStatus.java 2014-07-09 14:30:53.000000000 -0700 @@ -26,6 +26,7 @@ package sun.jvmstat.perfdata.monitor; import java.util.List; +import sun.jvmstat.monitor.Monitor; /** * Immutable class containing the list of inserted and deleted @@ -39,12 +40,12 @@ /** * The list of Monitors inserted since the last query. */ - protected List inserted; + protected List inserted; /** * The list of Monitors removed since the last query. */ - protected List removed; + protected List removed; /** * Create a MonitorStatus instance. @@ -52,7 +53,7 @@ * @param inserted the list of Monitors inserted * @param removed the list of Monitors removed */ - public MonitorStatus(List inserted, List removed) { + public MonitorStatus(List inserted, List removed) { this.inserted = inserted; this.removed = removed; } @@ -62,7 +63,7 @@ * * @return List - the List of Monitor objects inserted or an empty List. */ - public List getInserted() { + public List getInserted() { return inserted; } @@ -71,7 +72,7 @@ * * @return List - the List of Monitor objects removed or an empty List. */ - public List getRemoved() { + public List getRemoved() { return removed; } } --- old/src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java 2014-07-09 14:30:53.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java 2014-07-09 14:30:53.000000000 -0700 @@ -66,7 +66,7 @@ /** * A cache of resolved monitor aliases. */ - protected Map aliasCache; + protected Map aliasCache; /** @@ -79,9 +79,9 @@ protected PerfDataBufferImpl(ByteBuffer buffer, int lvmid) { this.buffer = buffer; this.lvmid = lvmid; - this.monitors = new TreeMap(); - this.aliasMap = new HashMap>(); - this.aliasCache = new HashMap(); + this.monitors = new TreeMap<>(); + this.aliasMap = new HashMap<>(); + this.aliasCache = new HashMap<>(); } /** @@ -200,12 +200,12 @@ protected Monitor findByAlias(String name) { assert Thread.holdsLock(this); - Monitor m = (Monitor)aliasCache.get(name); + Monitor m = aliasCache.get(name); if (m == null) { - ArrayList al = aliasMap.get(name); + ArrayList al = aliasMap.get(name); if (al != null) { - for (Iterator i = al.iterator(); i.hasNext() && m == null; ) { - String alias = (String)i.next(); + for (Iterator i = al.iterator(); i.hasNext() && m == null; ) { + String alias = i.next(); m = monitors.get(alias); } } @@ -287,21 +287,21 @@ Pattern pattern = Pattern.compile(patternString); Matcher matcher = pattern.matcher(""); - List matches = new ArrayList(); + List matches = new ArrayList<>(); - Set monitorSet = monitors.entrySet(); + Set> monitorSet = monitors.entrySet(); - for (Iterator i = monitorSet.iterator(); i.hasNext(); /* empty */) { - Map.Entry me = (Map.Entry)i.next(); - String name = (String)me.getKey(); - Monitor m = (Monitor)me.getValue(); + for (Iterator> i = monitorSet.iterator(); i.hasNext(); /* empty */) { + Map.Entry me = i.next(); + String name = me.getKey(); + Monitor m = me.getValue(); // apply pattern to monitor item name matcher.reset(name); // if the pattern matches, then add monitor to list if (matcher.lookingAt()) { - matches.add((Monitor)me.getValue()); + matches.add(me.getValue()); } } return matches; --- old/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java 2014-07-09 14:30:54.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java 2014-07-09 14:30:54.000000000 -0700 @@ -143,16 +143,17 @@ * @param inserted List of Monitor objects inserted. * @param removed List of Monitor objects removed. */ - void fireMonitorStatusChangedEvents(List inserted, List removed) { + @SuppressWarnings("unchecked") // Cast of result of clone + void fireMonitorStatusChangedEvents(List inserted, List removed) { MonitorStatusChangeEvent ev = null; - ArrayList registered = null; + ArrayList registered = null; synchronized (listeners) { registered = (ArrayList)listeners.clone(); } - for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { - VmListener l = (VmListener)i.next(); + for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { + VmListener l = i.next(); // lazily create the event object; if (ev == null) { ev = new MonitorStatusChangeEvent(this, inserted, removed); @@ -190,8 +191,8 @@ super.run(); try { MonitorStatus status = getMonitorStatus(); - List inserted = status.getInserted(); - List removed = status.getRemoved(); + List inserted = status.getInserted(); + List removed = status.getRemoved(); if (!inserted.isEmpty() || !removed.isEmpty()) { fireMonitorStatusChangedEvents(inserted, removed); --- old/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java 2014-07-09 14:30:54.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java 2014-07-09 14:30:54.000000000 -0700 @@ -160,17 +160,18 @@ * @param terminated a set of Integer objects containing the vmid of * terminated Vms since last interval. */ - private void fireVmStatusChangedEvents(Set active, Set started, - Set terminated) { - ArrayList registered = null; + @SuppressWarnings("unchecked") // Cast of result of clone + private void fireVmStatusChangedEvents(Set active, Set started, + Set terminated) { + ArrayList registered = null; VmStatusChangeEvent ev = null; synchronized(listeners) { registered = (ArrayList)listeners.clone(); } - for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { - HostListener l = (HostListener)i.next(); + for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { + HostListener l = i.next(); if (ev == null) { ev = new VmStatusChangeEvent(this, active, started, terminated); } @@ -186,7 +187,7 @@ super.run(); // save the last set of active JVMs - Set lastActiveVms = activeVms; + Set lastActiveVms = activeVms; // get the current set of active JVMs activeVms = (HashSet)vmManager.activeVms(); @@ -194,20 +195,20 @@ if (activeVms.isEmpty()) { return; } - Set startedVms = new HashSet(); - Set terminatedVms = new HashSet(); + Set startedVms = new HashSet<>(); + Set terminatedVms = new HashSet<>(); - for (Iterator i = activeVms.iterator(); i.hasNext(); /* empty */) { - Integer vmid = (Integer)i.next(); + for (Iterator i = activeVms.iterator(); i.hasNext(); /* empty */) { + Integer vmid = i.next(); if (!lastActiveVms.contains(vmid)) { // a new file has been detected, add to set startedVms.add(vmid); } } - for (Iterator i = lastActiveVms.iterator(); i.hasNext(); + for (Iterator i = lastActiveVms.iterator(); i.hasNext(); /* empty */) { - Object o = i.next(); + Integer o = i.next(); if (!activeVms.contains(o)) { // JVM has terminated, remove it from the active list terminatedVms.add(o); --- old/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java 2014-07-09 14:30:55.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java 2014-07-09 14:30:55.000000000 -0700 @@ -246,17 +246,18 @@ * Vm Identifiers of terminated JVMs since last * interval. */ - private void fireVmStatusChangedEvents(Set active, Set started, - Set terminated) { - ArrayList registered = null; + @SuppressWarnings("unchecked") // Cast of result of clone + private void fireVmStatusChangedEvents(Set active, Set started, + Set terminated) { + ArrayList registered = null; VmStatusChangeEvent ev = null; synchronized(listeners) { registered = (ArrayList)listeners.clone(); } - for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { - HostListener l = (HostListener)i.next(); + for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { + HostListener l = i.next(); if (ev == null) { ev = new VmStatusChangeEvent(this, active, started, terminated); } @@ -267,16 +268,17 @@ /** * Fire hostDisconnectEvent events. */ + @SuppressWarnings("unchecked") // Cast of result of clone void fireDisconnectedEvents() { - ArrayList registered = null; + ArrayList registered = null; HostEvent ev = null; synchronized(listeners) { registered = (ArrayList)listeners.clone(); } - for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { - HostListener l = (HostListener)i.next(); + for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { + HostListener l = i.next(); if (ev == null) { ev = new HostEvent(this); } @@ -292,7 +294,7 @@ super.run(); // save the last set of active JVMs - Set lastActiveVms = activeVms; + Set lastActiveVms = activeVms; try { // get the current set of active JVMs @@ -313,20 +315,20 @@ return; } - Set startedVms = new HashSet(); - Set terminatedVms = new HashSet(); + Set startedVms = new HashSet<>(); + Set terminatedVms = new HashSet<>(); - for (Iterator i = activeVms.iterator(); i.hasNext(); /* empty */ ) { - Integer vmid = (Integer)i.next(); + for (Iterator i = activeVms.iterator(); i.hasNext(); /* empty */ ) { + Integer vmid = i.next(); if (!lastActiveVms.contains(vmid)) { // a new file has been detected, add to set startedVms.add(vmid); } } - for (Iterator i = lastActiveVms.iterator(); i.hasNext(); + for (Iterator i = lastActiveVms.iterator(); i.hasNext(); /* empty */ ) { - Object o = i.next(); + Integer o = i.next(); if (!activeVms.contains(o)) { // JVM has terminated, remove it from the active list terminatedVms.add(o); --- old/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java 2014-07-09 14:30:55.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java 2014-07-09 14:30:55.000000000 -0700 @@ -198,16 +198,17 @@ * @param inserted List of Monitor objects inserted. * @param removed List of Monitor objects removed. */ - void fireMonitorStatusChangedEvents(List inserted, List removed) { - ArrayList registered = null; + @SuppressWarnings("unchecked") // Cast of result of clone + void fireMonitorStatusChangedEvents(List inserted, List removed) { + ArrayList registered = null; MonitorStatusChangeEvent ev = null; synchronized(listeners) { registered = (ArrayList)listeners.clone(); } - for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { - VmListener l = (VmListener)i.next(); + for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { + VmListener l = i.next(); if (ev == null) { ev = new MonitorStatusChangeEvent(this, inserted, removed); } @@ -218,16 +219,17 @@ /** * Fire MonitoredVmStructureChanged events. */ + @SuppressWarnings("unchecked") // Cast of result of clone void fireMonitorsUpdatedEvents() { - ArrayList registered = null; + ArrayList registered = null; VmEvent ev = null; synchronized(listeners) { registered = (ArrayList)listeners.clone(); } - for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { - VmListener l = (VmListener)i.next(); + for (Iterator i = registered.iterator(); i.hasNext(); /* empty */) { + VmListener l = i.next(); if (ev == null) { ev = new VmEvent(this); } @@ -256,8 +258,8 @@ try { MonitorStatus status = getMonitorStatus(); - List inserted = status.getInserted(); - List removed = status.getRemoved(); + List inserted = status.getInserted(); + List removed = status.getRemoved(); if (!inserted.isEmpty() || !removed.isEmpty()) { fireMonitorStatusChangedEvents(inserted, removed); --- old/src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java 2014-07-09 14:30:56.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java 2014-07-09 14:30:55.000000000 -0700 @@ -47,7 +47,7 @@ private static final boolean DEBUG = false; private static final int syncWaitMs = Integer.getInteger("sun.jvmstat.perdata.syncWaitMs", 5000); - private static final ArrayList EMPTY_LIST = new ArrayList(0); + private static final ArrayList EMPTY_LIST = new ArrayList(0); /* * the following constants must be kept in sync with struct @@ -190,8 +190,8 @@ getNewMonitors(map); // current implementation doesn't support deletion or reuse of entries - ArrayList removed = EMPTY_LIST; - ArrayList inserted = insertedMonitors; + ArrayList removed = EMPTY_LIST; + ArrayList inserted = insertedMonitors; insertedMonitors = new ArrayList(); return new MonitorStatus(inserted, removed); @@ -618,14 +618,14 @@ /** * Method to dump debugging information */ - private void dumpAll(Map map, int lvmid) { + private void dumpAll(Map map, int lvmid) { if (DEBUG) { - Set keys = map.keySet(); + Set keys = map.keySet(); System.err.println("Dump for " + lvmid); int j = 0; - for (Iterator i = keys.iterator(); i.hasNext(); j++) { - Monitor monitor = (Monitor)map.get(i.next()); + for (Iterator i = keys.iterator(); i.hasNext(); j++) { + Monitor monitor = map.get(i.next()); System.err.println(j + "\t" + monitor.getName() + "=" + monitor.getValue()); } --- old/src/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java 2014-07-09 14:30:56.000000000 -0700 +++ new/src/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java 2014-07-09 14:30:56.000000000 -0700 @@ -65,7 +65,7 @@ private static final boolean DEBUG = false; private static final int syncWaitMs = Integer.getInteger("sun.jvmstat.perdata.syncWaitMs", 5000); - private static final ArrayList EMPTY_LIST = new ArrayList(0); + private static final ArrayList EMPTY_LIST = new ArrayList<>(0); /* * These are primarily for documentary purposes and the match up @@ -198,10 +198,10 @@ getNewMonitors(map); // current implementation doesn't support deletion of reuse of entries - ArrayList removed = EMPTY_LIST; - ArrayList inserted = insertedMonitors; + ArrayList removed = EMPTY_LIST; + ArrayList inserted = insertedMonitors; - insertedMonitors = new ArrayList(); + insertedMonitors = new ArrayList<>(); return new MonitorStatus(inserted, removed); } @@ -524,7 +524,7 @@ System.err.println("Dump for " + lvmid); int j = 0; - for (Iterator i = keys.iterator(); i.hasNext(); j++) { + for (Iterator i = keys.iterator(); i.hasNext(); j++) { Monitor monitor = map.get(i.next()); System.err.println(j + "\t" + monitor.getName() + "=" + monitor.getValue()); From mandy.chung at oracle.com Wed Jul 9 21:48:45 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jul 2014 14:48:45 -0700 Subject: JDK 9 RFR of JDK-8049794: Fix raw and unchecked warnings in jvmstat In-Reply-To: <53BDB5D3.2050608@oracle.com> References: <53BDB5D3.2050608@oracle.com> Message-ID: <53BDB8BD.5050000@oracle.com> On 7/9/2014 2:36 PM, Joe Darcy wrote: > Hello, > > Please review these changes to address > > JDK-8049794: Fix raw and unchecked warnings in jvmstat > http://cr.openjdk.java.net/~darcy/8049794.0/ > I looked through the patch and the generified types look right except this: > --- > old/src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java > 2014-07-09 14:30:56.000000000 -0700 > +++ > new/src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java > 2014-07-09 14:30:55.000000000 -0700 > ... > /** > * Method to dump debugging information > */ > - private void dumpAll(Map map, int lvmid) { > + private void dumpAll(Map map, int lvmid) { > if (DEBUG) { > - Set keys = map.keySet(); > + Set keys = map.keySet(); > > System.err.println("Dump for " + lvmid); > int j = 0; > - for (Iterator i = keys.iterator(); i.hasNext(); j++) { > - Monitor monitor = (Monitor)map.get(i.next()); > + for (Iterator i = keys.iterator(); i.hasNext(); j++) { > + Monitor monitor = map.get(i.next()); > System.err.println(j + "\t" + monitor.getName() > + "=" + monitor.getValue()); > } dumpAll method is called from the pollFor(Map map, String name, long timeLimit) method. I think it can take Map map argument instead. Mandy From jeremymanson at google.com Wed Jul 9 22:02:39 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 9 Jul 2014 15:02:39 -0700 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: <53BD8249.7090304@oracle.com> References: <53BD8249.7090304@oracle.com> Message-ID: Thanks, Erik. All we need is a reviewer to say yes, then. :) Jeremy On Wed, Jul 9, 2014 at 10:56 AM, Erik Gahlin wrote: > Looks good! > > Not a Reviewer, but I can sponsor it. > > Erik > > Jeremy Manson skrev 08/05/14 20:56: > > I'm testing out my newly acquired OpenJDK authorship with something > simple. If I did this wrong, I apologize. > > Basically, the debugger becomes very slow if there are a lot of methods > in a class. This can happen (O(thousands)) if you are using a code > generation tool. > > http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ > > Reviews from reviewers and committing from committers would be > appreciated. Thanks! > > Jeremy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jul 9 23:58:31 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 16:58:31 -0700 Subject: JDK 9 RFR of JDK-8049794: Fix raw and unchecked warnings in jvmstat In-Reply-To: <53BDB8BD.5050000@oracle.com> References: <53BDB5D3.2050608@oracle.com> <53BDB8BD.5050000@oracle.com> Message-ID: <53BDD727.2030707@oracle.com> On 07/09/2014 02:48 PM, Mandy Chung wrote: > > On 7/9/2014 2:36 PM, Joe Darcy wrote: >> Hello, >> >> Please review these changes to address >> >> JDK-8049794: Fix raw and unchecked warnings in jvmstat >> http://cr.openjdk.java.net/~darcy/8049794.0/ >> > > I looked through the patch and the generified types look right except > this: > >> --- >> old/src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java >> 2014-07-09 14:30:56.000000000 -0700 >> +++ >> new/src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java >> 2014-07-09 14:30:55.000000000 -0700 >> ... >> /** >> * Method to dump debugging information >> */ >> - private void dumpAll(Map map, int lvmid) { >> + private void dumpAll(Map map, int lvmid) { >> if (DEBUG) { >> - Set keys = map.keySet(); >> + Set keys = map.keySet(); >> >> System.err.println("Dump for " + lvmid); >> int j = 0; >> - for (Iterator i = keys.iterator(); i.hasNext(); j++) { >> - Monitor monitor = (Monitor)map.get(i.next()); >> + for (Iterator i = keys.iterator(); i.hasNext(); j++) { >> + Monitor monitor = map.get(i.next()); >> System.err.println(j + "\t" + monitor.getName() >> + "=" + monitor.getValue()); >> } > > dumpAll method is called from the pollFor(Map map, > String name, long timeLimit) method. I think it can take > Map map argument instead. > Hi Mandy, I made the changes you suggested and that works fine (and matches the analogous code in the v2_0 case). I'll push as amended. Thanks for the review, -Joe From joe.darcy at oracle.com Thu Jul 10 01:10:20 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 18:10:20 -0700 Subject: JDK 9 RFR of JDK-8049820: Fix raw and unchecked lint warnings in sun.management Message-ID: <53BDE7FC.5090506@oracle.com> Hello, Another batch of lint warnings removal; this time for 8049820: Fix raw and unchecked lint warnings in sun.management http://cr.openjdk.java.net/~darcy/8049820.0/ Patch below. Thanks, -Joe --- old/src/share/classes/sun/management/DiagnosticCommandImpl.java 2014-07-09 18:07:40.000000000 -0700 +++ new/src/share/classes/sun/management/DiagnosticCommandImpl.java 2014-07-09 18:07:40.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -84,10 +84,10 @@ Exception cause = null; if (info.getPermissionClass() != null) { try { - Class c = Class.forName(info.getPermissionClass()); + Class c = Class.forName(info.getPermissionClass()); if (info.getPermissionAction() == null) { try { - Constructor constructor = c.getConstructor(String.class); + Constructor constructor = c.getConstructor(String.class); permission = (Permission) constructor.newInstance(info.getPermissionName()); } catch (InstantiationException | IllegalAccessException @@ -98,7 +98,7 @@ } if (permission == null) { try { - Constructor constructor = c.getConstructor(String.class, String.class); + Constructor constructor = c.getConstructor(String.class, String.class); permission = (Permission) constructor.newInstance( info.getPermissionName(), info.getPermissionAction()); @@ -158,7 +158,7 @@ SortedSet operations = new TreeSet<>(new OperationInfoComparator()); Map wrappersmap; if (!isSupported) { - wrappersmap = (Map) Collections.EMPTY_MAP; + wrappersmap = Collections.emptyMap(); } else { try { String[] command = getDiagnosticCommands(); @@ -189,7 +189,7 @@ } } } catch (IllegalArgumentException | UnsupportedOperationException e) { - wrappersmap = (Map) Collections.EMPTY_MAP; + wrappersmap = Collections.emptyMap(); } } wrappers = Collections.unmodifiableMap(wrappersmap); --- old/src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java 2014-07-09 18:07:41.000000000 -0700 +++ new/src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java 2014-07-09 18:07:41.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -65,7 +65,7 @@ final GcInfoBuilder builder = AccessController.doPrivileged (new PrivilegedAction() { public GcInfoBuilder run() { try { - Class cl = Class.forName("com.sun.management.GcInfo"); + Class cl = Class.forName("com.sun.management.GcInfo"); Field f = cl.getDeclaredField("builder"); f.setAccessible(true); return (GcInfoBuilder)f.get(gcNotifInfo.getGcInfo()); --- old/src/share/classes/sun/management/GcInfoCompositeData.java 2014-07-09 18:07:41.000000000 -0700 +++ new/src/share/classes/sun/management/GcInfoCompositeData.java 2014-07-09 18:07:41.000000000 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -72,7 +72,7 @@ final GcInfoBuilder builder = AccessController.doPrivileged (new PrivilegedAction() { public GcInfoBuilder run() { try { - Class cl = Class.forName("com.sun.management.GcInfo"); + Class cl = Class.forName("com.sun.management.GcInfo"); Field f = cl.getDeclaredField("builder"); f.setAccessible(true); return (GcInfoBuilder)f.get(info); @@ -84,7 +84,7 @@ final Object[] extAttr = AccessController.doPrivileged (new PrivilegedAction() { public Object[] run() { try { - Class cl = Class.forName("com.sun.management.GcInfo"); + Class cl = Class.forName("com.sun.management.GcInfo"); Field f = cl.getDeclaredField("extAttributes"); f.setAccessible(true); return (Object[])f.get(info); @@ -182,8 +182,8 @@ return baseGcInfoItemNames; } - private static OpenType[] baseGcInfoItemTypes = null; - static synchronized OpenType[] getBaseGcInfoItemTypes() { + private static OpenType[] baseGcInfoItemTypes = null; + static synchronized OpenType[] getBaseGcInfoItemTypes() { if (baseGcInfoItemTypes == null) { OpenType memoryUsageOpenType = memoryUsageMapType.getOpenType(); baseGcInfoItemTypes = new OpenType[] { --- old/src/share/classes/sun/management/MappedMXBeanType.java 2014-07-09 18:07:42.000000000 -0700 +++ new/src/share/classes/sun/management/MappedMXBeanType.java 2014-07-09 18:07:42.000000000 -0700 @@ -227,6 +227,7 @@ // Enum <-> enum's name // static class EnumMXBeanType extends MappedMXBeanType { + @SuppressWarnings("rawtypes") final Class enumClass; EnumMXBeanType(Class c) { this.enumClass = c; @@ -754,7 +755,7 @@ } } - private static class InProgress extends OpenType { + private static class InProgress extends OpenType { private static final String description = "Marker to detect recursive type use -- internal use only!"; @@ -783,7 +784,7 @@ static { OpenType t; try { - t = new InProgress(); + t = new InProgress<>(); } catch (OpenDataException e) { // Should not reach here throw new AssertionError(e); @@ -791,7 +792,7 @@ inProgress = t; } - private static final OpenType[] simpleTypes = { + private static final OpenType[] simpleTypes = { BIGDECIMAL, BIGINTEGER, BOOLEAN, BYTE, CHARACTER, DATE, DOUBLE, FLOAT, INTEGER, LONG, OBJECTNAME, SHORT, STRING, VOID, From mandy.chung at oracle.com Thu Jul 10 01:26:18 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jul 2014 18:26:18 -0700 Subject: JDK 9 RFR of JDK-8049820: Fix raw and unchecked lint warnings in sun.management In-Reply-To: <53BDE7FC.5090506@oracle.com> References: <53BDE7FC.5090506@oracle.com> Message-ID: <53BDEBBA.5030306@oracle.com> On 7/9/2014 6:10 PM, Joe Darcy wrote: > Hello, > > Another batch of lint warnings removal; this time for > > 8049820: Fix raw and unchecked lint warnings in sun.management > http://cr.openjdk.java.net/~darcy/8049820.0/ 230 @SuppressWarnings("rawtypes") 231 final Class enumClass; Why can't the enumClass field be declared of Class type? Other than that, looks fine. Mandy From joe.darcy at oracle.com Thu Jul 10 01:35:01 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 18:35:01 -0700 Subject: JDK 9 RFR of JDK-8049820: Fix raw and unchecked lint warnings in sun.management In-Reply-To: <53BDEBBA.5030306@oracle.com> References: <53BDE7FC.5090506@oracle.com> <53BDEBBA.5030306@oracle.com> Message-ID: <53BDEDC5.8080302@oracle.com> Hi Mandy, On 07/09/2014 06:26 PM, Mandy Chung wrote: > > On 7/9/2014 6:10 PM, Joe Darcy wrote: >> Hello, >> >> Another batch of lint warnings removal; this time for >> >> 8049820: Fix raw and unchecked lint warnings in sun.management >> http://cr.openjdk.java.net/~darcy/8049820.0/ > > 230 @SuppressWarnings("rawtypes") > 231 final Class enumClass; > > Why can't the enumClass field be declared of Class type? > > Other than that, looks fine. > Mandy > My first attempt at generifying this class used Class as you suggest. The problem occurs in the call to the static method Enum.valueOf which has a declaration of public static > T valueOf(Class enumType, String name) The problem here is the recursive "T extends Enum", following the recursive F-bound of the java.lang.Enum type itself. Using a wildcard for Class doesn't work with this method signature; something like Class doesn't work either because the more specific recursive binding is not captured, so I reluctantly fell back to using a raw type. Thanks, -Joe From mandy.chung at oracle.com Thu Jul 10 02:40:03 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jul 2014 19:40:03 -0700 Subject: JDK 9 RFR of JDK-8049820: Fix raw and unchecked lint warnings in sun.management In-Reply-To: <53BDEDC5.8080302@oracle.com> References: <53BDE7FC.5090506@oracle.com> <53BDEBBA.5030306@oracle.com> <53BDEDC5.8080302@oracle.com> Message-ID: <53BDFD03.7020400@oracle.com> On 7/9/2014 6:35 PM, Joe Darcy wrote: > Hi Mandy, > > On 07/09/2014 06:26 PM, Mandy Chung wrote: >> >> On 7/9/2014 6:10 PM, Joe Darcy wrote: >>> Hello, >>> >>> Another batch of lint warnings removal; this time for >>> >>> 8049820: Fix raw and unchecked lint warnings in sun.management >>> http://cr.openjdk.java.net/~darcy/8049820.0/ >> >> 230 @SuppressWarnings("rawtypes") >> 231 final Class enumClass; >> >> Why can't the enumClass field be declared of Class type? >> >> Other than that, looks fine. >> Mandy >> > > My first attempt at generifying this class used Class as you > suggest. The problem occurs in the call to the static method > Enum.valueOf which has a declaration of > > public static > T valueOf(Class enumType, > String name) > > The problem here is the recursive "T extends Enum", following the > recursive F-bound of the java.lang.Enum type itself. Using a wildcard > for Class doesn't work with this method signature; something like > Class doesn't work either because the more specific > recursive binding is not captured, so I reluctantly fell back to using > a raw type. I see, thanks. The patch is good to go. Mandy From david.holmes at oracle.com Thu Jul 10 02:41:33 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jul 2014 12:41:33 +1000 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: References: Message-ID: <53BDFD5D.4050908@oracle.com> Hi Volker, Comments below where you might expect them :) On 10/07/2014 3:36 AM, Volker Simonis wrote: > Hi, > > could someone please review and sponsor the following change which > does some preliminary work for enabling the SA agent on Linux/PPC64: > > http://cr.openjdk.java.net/~simonis/webrevs/8049715/ > https://bugs.openjdk.java.net/browse/JDK-8049715 > > Details: > > Currently, we don't support the SA agent on Linux/PPC64. This change > fixes the buildsystem such that the SA libraries (i.e. libsaproc.so > and sa-jdi.jar) will be correctly build and copied into the resulting > jdk images. > > This change also contains some small fixes in sa-jdi.jar to correctly > detect Linux/PPC64 as supported SA platform. (The actual > implementation of the Linux/PPC64 specific code will be handled by > "8049716 PPC64: Implement SA on Linux/PPC64" - > https://bugs.openjdk.java.net/browse/JDK-8049716). > > One thing which require special attention are the changes in > make/linux/makefiles/defs.make which may touch the closed ppc port. In > my change I've simply added 'ppc' to the list of supported > architectures, but this may break the 32-bit ppc build. I think the It wouldn't break it but I was expecting to see ppc64 here. > current code is to verbose and error prone anyway. It would be better > to have something like: > > ADD_SA_BINARIES = > $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) > $(EXPORT_LIB_DIR)/sa-jdi.jar > > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > ifeq ($(ZIP_DEBUGINFO_FILES),1) > ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz > else > ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo > endif > endif > > ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 ppc64)) > EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) You wouldn't need/want the $(HS_ARCH) there. > endif > > With this solution we only define ADD_SA_BINARIES once (because the > various definitions for the different platforms are equal anyway). But > again this may affect other closed ports so please advise which > solution you'd prefer. The above is problematic for customizations. An alternative would be to set ADD_SA_BINARIES/default once with all the file names. Then: ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) # No SA Support for IA64 or zero ifneq (, $(findstring $(ARCH), ia64, zero)) ADD_SA_BINARIES/$(ARCH) = Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) if needed. Does that seem reasonable? > Notice that this change also requires a tiny fix in the top-level > repository which must be pushed AFTER this change. Can you elaborate please? Thanks, David > Thank you and best regards, > Volker > From david.holmes at oracle.com Thu Jul 10 02:44:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jul 2014 12:44:18 +1000 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: <53BD8249.7090304@oracle.com> References: <53BD8249.7090304@oracle.com> Message-ID: <53BDFE02.5000504@oracle.com> I'm good with it too - as Erik is happy with it. So Reviewed. David On 10/07/2014 3:56 AM, Erik Gahlin wrote: > Looks good! > > Not a Reviewer, but I can sponsor it. > > Erik > > Jeremy Manson skrev 08/05/14 20:56: >> I'm testing out my newly acquired OpenJDK authorship with something >> simple. If I did this wrong, I apologize. >> >> Basically, the debugger becomes very slow if there are a lot of >> methods in a class. This can happen (O(thousands)) if you are using a >> code generation tool. >> >> http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ >> >> >> Reviews from reviewers and committing from committers would be >> appreciated. Thanks! >> >> Jeremy > From joe.darcy at oracle.com Thu Jul 10 04:25:26 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jul 2014 21:25:26 -0700 Subject: JDK 9 RFR of JDK-8049820: Fix raw and unchecked lint warnings in sun.management In-Reply-To: <53BDFD03.7020400@oracle.com> References: <53BDE7FC.5090506@oracle.com> <53BDEBBA.5030306@oracle.com> <53BDEDC5.8080302@oracle.com> <53BDFD03.7020400@oracle.com> Message-ID: <53BE15B6.8060706@oracle.com> PS Upon double-checking, I neglected to include the changes to one other file in my earlier review request: --- a/src/share/classes/sun/management/GcInfoBuilder.java Thu Jul 10 03:07:48 2014 +0000 +++ b/src/share/classes/sun/management/GcInfoBuilder.java Wed Jul 09 21:24:03 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -98,7 +98,7 @@ // First, fill with the attributes in the GcInfo String[] gcInfoItemNames = GcInfoCompositeData.getBaseGcInfoItemNames(); - OpenType[] gcInfoItemTypes = GcInfoCompositeData.getBaseGcInfoItemTypes(); + OpenType[] gcInfoItemTypes = GcInfoCompositeData.getBaseGcInfoItemTypes(); int numGcInfoItems = gcInfoItemNames.length; int itemCount = numGcInfoItems + gcExtItemCount; I'll include this straightforward change in the push. Thanks, -Joe On 07/09/2014 07:40 PM, Mandy Chung wrote: > > On 7/9/2014 6:35 PM, Joe Darcy wrote: >> Hi Mandy, >> >> On 07/09/2014 06:26 PM, Mandy Chung wrote: >>> >>> On 7/9/2014 6:10 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> Another batch of lint warnings removal; this time for >>>> >>>> 8049820: Fix raw and unchecked lint warnings in sun.management >>>> http://cr.openjdk.java.net/~darcy/8049820.0/ >>> >>> 230 @SuppressWarnings("rawtypes") >>> 231 final Class enumClass; >>> >>> Why can't the enumClass field be declared of Class type? >>> >>> Other than that, looks fine. >>> Mandy >>> >> >> My first attempt at generifying this class used Class as you >> suggest. The problem occurs in the call to the static method >> Enum.valueOf which has a declaration of >> >> public static > T valueOf(Class enumType, >> String name) >> >> The problem here is the recursive "T extends Enum", following the >> recursive F-bound of the java.lang.Enum type itself. Using a wildcard >> for Class doesn't work with this method signature; something like >> Class doesn't work either because the more specific >> recursive binding is not captured, so I reluctantly fell back to >> using a raw type. > > I see, thanks. The patch is good to go. > Mandy > From mandy.chung at oracle.com Thu Jul 10 05:00:17 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jul 2014 22:00:17 -0700 Subject: JDK 9 RFR of JDK-8049820: Fix raw and unchecked lint warnings in sun.management In-Reply-To: <53BE15B6.8060706@oracle.com> References: <53BDE7FC.5090506@oracle.com> <53BDEBBA.5030306@oracle.com> <53BDEDC5.8080302@oracle.com> <53BDFD03.7020400@oracle.com> <53BE15B6.8060706@oracle.com> Message-ID: <53BE1DE1.5080805@oracle.com> Thumbs up. Mandy On 7/9/2014 9:25 PM, Joe Darcy wrote: > PS Upon double-checking, I neglected to include the changes to one > other file in my earlier review request: > > --- a/src/share/classes/sun/management/GcInfoBuilder.java Thu Jul > 10 03:07:48 2014 +0000 > +++ b/src/share/classes/sun/management/GcInfoBuilder.java Wed Jul > 09 21:24:03 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -98,7 +98,7 @@ > > // First, fill with the attributes in the GcInfo > String[] gcInfoItemNames = > GcInfoCompositeData.getBaseGcInfoItemNames(); > - OpenType[] gcInfoItemTypes = > GcInfoCompositeData.getBaseGcInfoItemTypes(); > + OpenType[] gcInfoItemTypes = > GcInfoCompositeData.getBaseGcInfoItemTypes(); > int numGcInfoItems = gcInfoItemNames.length; > > int itemCount = numGcInfoItems + gcExtItemCount; > > > I'll include this straightforward change in the push. > > Thanks, > > -Joe > > On 07/09/2014 07:40 PM, Mandy Chung wrote: >> >> On 7/9/2014 6:35 PM, Joe Darcy wrote: >>> Hi Mandy, >>> >>> On 07/09/2014 06:26 PM, Mandy Chung wrote: >>>> >>>> On 7/9/2014 6:10 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> Another batch of lint warnings removal; this time for >>>>> >>>>> 8049820: Fix raw and unchecked lint warnings in sun.management >>>>> http://cr.openjdk.java.net/~darcy/8049820.0/ >>>> >>>> 230 @SuppressWarnings("rawtypes") >>>> 231 final Class enumClass; >>>> >>>> Why can't the enumClass field be declared of Class type? >>>> >>>> Other than that, looks fine. >>>> Mandy >>>> >>> >>> My first attempt at generifying this class used Class as you >>> suggest. The problem occurs in the call to the static method >>> Enum.valueOf which has a declaration of >>> >>> public static > T valueOf(Class enumType, >>> String name) >>> >>> The problem here is the recursive "T extends Enum", following the >>> recursive F-bound of the java.lang.Enum type itself. Using a >>> wildcard for Class doesn't work with this method signature; >>> something like Class doesn't work either because the >>> more specific recursive binding is not captured, so I reluctantly >>> fell back to using a raw type. >> >> I see, thanks. The patch is good to go. >> Mandy >> > From volker.simonis at gmail.com Thu Jul 10 10:12:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Jul 2014 12:12:55 +0200 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: <53BDFD5D.4050908@oracle.com> References: <53BDFD5D.4050908@oracle.com> Message-ID: Hi David, thanks for looking at this. Here's my new version of the change with some of your suggestions applied: http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 Please find more information inline: On Thu, Jul 10, 2014 at 4:41 AM, David Holmes wrote: > Hi Volker, > > Comments below where you might expect them :) > > > On 10/07/2014 3:36 AM, Volker Simonis wrote: >> >> Hi, >> >> could someone please review and sponsor the following change which >> does some preliminary work for enabling the SA agent on Linux/PPC64: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >> https://bugs.openjdk.java.net/browse/JDK-8049715 >> >> Details: >> >> Currently, we don't support the SA agent on Linux/PPC64. This change >> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >> and sa-jdi.jar) will be correctly build and copied into the resulting >> jdk images. >> >> This change also contains some small fixes in sa-jdi.jar to correctly >> detect Linux/PPC64 as supported SA platform. (The actual >> implementation of the Linux/PPC64 specific code will be handled by >> "8049716 PPC64: Implement SA on Linux/PPC64" - >> https://bugs.openjdk.java.net/browse/JDK-8049716). >> >> One thing which require special attention are the changes in >> make/linux/makefiles/defs.make which may touch the closed ppc port. In >> my change I've simply added 'ppc' to the list of supported >> architectures, but this may break the 32-bit ppc build. I think the > > > It wouldn't break it but I was expecting to see ppc64 here. > The problem is that currently the decision if the SA agent will be build is based on the value of HS_ARCH. But HS_ARCH is the 'basic architecture' (i.e. x86 or sparc) so there's no easy way to choose the SA agent for only a 64-bit platform (like ppc64 or amd64) and not for its 32-bit counterpart (i.e. i386 or ppc). The only possibility with the current solution would be to only conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But that wouldn't make the code nicer either:) > >> current code is to verbose and error prone anyway. It would be better >> to have something like: >> >> ADD_SA_BINARIES = >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >> $(EXPORT_LIB_DIR)/sa-jdi.jar >> >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> ifeq ($(ZIP_DEBUGINFO_FILES),1) >> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >> else >> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >> endif >> endif >> >> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 ppc64)) >> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) > > > You wouldn't need/want the $(HS_ARCH) there. > Sorry, that was a type of course. It should read: ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 ppc64)) EXPORT_LIST += $(ADD_SA_BINARIES) But that's not necessary now anymore (see new version below). > >> endif >> >> With this solution we only define ADD_SA_BINARIES once (because the >> various definitions for the different platforms are equal anyway). But >> again this may affect other closed ports so please advise which >> solution you'd prefer. > > > The above is problematic for customizations. An alternative would be to set > ADD_SA_BINARIES/default once with all the file names. Then: > > ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) > # No SA Support for IA64 or zero > ifneq (, $(findstring $(ARCH), ia64, zero)) > ADD_SA_BINARIES/$(ARCH) = > > Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) if > needed. > > Does that seem reasonable? > The problem with using ARCH is that it is not "reliable" in the sens that its value differs for top-level and hotspot-only makes. See "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 build". But using ADD_SA_BINARIES/default to save redundant lines is a good idea. I've updated the patch accordingly and think that the new solution is a good compromise between readability and not touching existing/closed part. Are you fine with the new version at http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? > >> Notice that this change also requires a tiny fix in the top-level >> repository which must be pushed AFTER this change. > > > Can you elaborate please? > I've also submitted the corresponding top-level repository change for review which expects to find the SA agent libraries on Linux/ppc64 in order to copy them into the image directory: http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ But once that will be pushed, the build will fail if these HS changes will not be in place to actually build the libraries. > Thanks, > David > > >> Thank you and best regards, >> Volker >> > From volker.simonis at gmail.com Thu Jul 10 10:30:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Jul 2014 12:30:55 +0200 Subject: "8046282: SA update" seems to break the SA/jstack in OpenJDK Message-ID: Hi, the change "8046282: SA update" introduced the following new code in agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java + traceIDField = type.getField("_trace_id"); But I can not find the corresponding field in src/share/vm/oops/klass.hpp. The Klass class only contains the macro TRACE_DEFINE_KLASS_TRACE_ID which is defined to "typedef int ___IGNORED_hs_trace_type2" in traceMacros.hpp. This leads to an error when calling for example jstack on a core file: $ images/j2sdk-image/bin/jstack ./images/j2sdk-image/bin/java core Attaching to core core from executable ./images/j2sdk-image/bin/java, please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.9.0-internal-d046063_2014_07_10_11_16-b00 Deadlock Detection: Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) at sun.tools.jstack.JStack.main(JStack.java:106) Caused by: java.lang.ExceptionInInitializerError at sun.jvm.hotspot.oops.ObjectHeap.initialize(ObjectHeap.java:74) at sun.jvm.hotspot.oops.ObjectHeap.(ObjectHeap.java:110) at sun.jvm.hotspot.runtime.VM.getObjectHeap(VM.java:582) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:55) at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) ... 6 more Caused by: java.lang.RuntimeException: field "_trace_id" not found in type Klass at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) at sun.jvm.hotspot.oops.Klass.initialize(Klass.java:58) at sun.jvm.hotspot.oops.Klass.access$000(Klass.java:33) at sun.jvm.hotspot.oops.Klass$1.update(Klass.java:37) at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) at sun.jvm.hotspot.oops.Klass.(Klass.java:35) ... 18 more Is this a problem with OpenJDK only (i.e. is '_trace_id' defined in Oracle proprietary builds) ?. Or is this another problem? Thank you and best regards, Volker From erik.gahlin at oracle.com Thu Jul 10 15:40:16 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 10 Jul 2014 17:40:16 +0200 Subject: "8046282: SA update" seems to break the SA/jstack in OpenJDK In-Reply-To: References: Message-ID: <53BEB3E0.9060203@oracle.com> Hi , I can confirm the macro evaluates to _trace_id in Oracles closed code :( Sorry about that. I have filed a P2 bug to have it fixed. See. https://bugs.openjdk.java.net/browse/JDK-8049881 Thanks for reporting Erik Volker Simonis skrev 2014-07-10 12:30: > Hi, > > the change "8046282: SA update" introduced the following new code in > agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java > > + traceIDField = type.getField("_trace_id"); > > But I can not find the corresponding field in > src/share/vm/oops/klass.hpp. The Klass class only contains the macro > TRACE_DEFINE_KLASS_TRACE_ID which is defined to "typedef int > ___IGNORED_hs_trace_type2" in traceMacros.hpp. > > This leads to an error when calling for example jstack on a core file: > > $ images/j2sdk-image/bin/jstack ./images/j2sdk-image/bin/java core > Attaching to core core from executable ./images/j2sdk-image/bin/java, > please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 1.9.0-internal-d046063_2014_07_10_11_16-b00 > Deadlock Detection: > > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) > at sun.tools.jstack.JStack.main(JStack.java:106) > Caused by: java.lang.ExceptionInInitializerError > at sun.jvm.hotspot.oops.ObjectHeap.initialize(ObjectHeap.java:74) > at sun.jvm.hotspot.oops.ObjectHeap.(ObjectHeap.java:110) > at sun.jvm.hotspot.runtime.VM.getObjectHeap(VM.java:582) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:55) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) > at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) > ... 6 more > Caused by: java.lang.RuntimeException: field "_trace_id" not found in type Klass > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > at sun.jvm.hotspot.oops.Klass.initialize(Klass.java:58) > at sun.jvm.hotspot.oops.Klass.access$000(Klass.java:33) > at sun.jvm.hotspot.oops.Klass$1.update(Klass.java:37) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) > at sun.jvm.hotspot.oops.Klass.(Klass.java:35) > ... 18 more > > Is this a problem with OpenJDK only (i.e. is '_trace_id' defined in > Oracle proprietary builds) ?. Or is this another problem? > > Thank you and best regards, > Volker From volker.simonis at gmail.com Thu Jul 10 15:44:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 10 Jul 2014 17:44:14 +0200 Subject: "8046282: SA update" seems to break the SA/jstack in OpenJDK In-Reply-To: <53BEB3E0.9060203@oracle.com> References: <53BEB3E0.9060203@oracle.com> Message-ID: Hi Erik, thanks for the fast confirmation and for opening the bug report. Regards, Volker On Thu, Jul 10, 2014 at 5:40 PM, Erik Gahlin wrote: > Hi , > > I can confirm the macro evaluates to _trace_id in Oracles closed code :( > > Sorry about that. I have filed a P2 bug to have it fixed. See. > https://bugs.openjdk.java.net/browse/JDK-8049881 > > Thanks for reporting > Erik > > Volker Simonis skrev 2014-07-10 12:30: > >> Hi, >> >> the change "8046282: SA update" introduced the following new code in >> agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java >> >> + traceIDField = type.getField("_trace_id"); >> >> But I can not find the corresponding field in >> src/share/vm/oops/klass.hpp. The Klass class only contains the macro >> TRACE_DEFINE_KLASS_TRACE_ID which is defined to "typedef int >> ___IGNORED_hs_trace_type2" in traceMacros.hpp. >> >> This leads to an error when calling for example jstack on a core file: >> >> $ images/j2sdk-image/bin/jstack ./images/j2sdk-image/bin/java core >> Attaching to core core from executable ./images/j2sdk-image/bin/java, >> please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 1.9.0-internal-d046063_2014_07_10_11_16-b00 >> Deadlock Detection: >> >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:484) >> at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) >> at sun.tools.jstack.JStack.main(JStack.java:106) >> Caused by: java.lang.ExceptionInInitializerError >> at sun.jvm.hotspot.oops.ObjectHeap.initialize(ObjectHeap.java:74) >> at sun.jvm.hotspot.oops.ObjectHeap.(ObjectHeap.java:110) >> at sun.jvm.hotspot.runtime.VM.getObjectHeap(VM.java:582) >> at >> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:55) >> at >> sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >> at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) >> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) >> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) >> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >> at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) >> ... 6 more >> Caused by: java.lang.RuntimeException: field "_trace_id" not found in type >> Klass >> at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) >> at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) >> at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) >> at sun.jvm.hotspot.oops.Klass.initialize(Klass.java:58) >> at sun.jvm.hotspot.oops.Klass.access$000(Klass.java:33) >> at sun.jvm.hotspot.oops.Klass$1.update(Klass.java:37) >> at >> sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) >> at sun.jvm.hotspot.oops.Klass.(Klass.java:35) >> ... 18 more >> >> Is this a problem with OpenJDK only (i.e. is '_trace_id' defined in >> Oracle proprietary builds) ?. Or is this another problem? >> >> Thank you and best regards, >> Volker > > From mandy.chung at oracle.com Thu Jul 10 23:07:36 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Jul 2014 16:07:36 -0700 Subject: JDK 9 RFR of JDK-8049736: Fix raw and unchecked lint warnings in sun.tracing In-Reply-To: <53BD8199.60401@oracle.com> References: <53BD8199.60401@oracle.com> Message-ID: <53BF1CB8.1000104@oracle.com> Looks good. Mandy On 7/9/14 10:53 AM, Joe Darcy wrote: > Hello, > > Please review the patch below which addresses > > JDK-8049736: Fix raw and unchecked lint warnings in sun.tracing > > Thanks, > > -Joe > > diff -r 2b7bf1d63a9c src/share/classes/sun/tracing/ProviderSkeleton.java > --- a/src/share/classes/sun/tracing/ProviderSkeleton.java Wed Jul > 09 10:02:30 2014 -0700 > +++ b/src/share/classes/sun/tracing/ProviderSkeleton.java Wed Jul > 09 10:53:02 2014 -0700 > @@ -154,7 +154,7 @@ > * @return always null, if the method is a user-defined probe > */ > public Object invoke(Object proxy, Method method, Object[] args) { > - Class declaringClass = method.getDeclaringClass(); > + Class declaringClass = method.getDeclaringClass(); > // not a provider subtype's own method > if (declaringClass != providerType) { > try { > diff -r 2b7bf1d63a9c > src/share/classes/sun/tracing/dtrace/DTraceProvider.java > --- a/src/share/classes/sun/tracing/dtrace/DTraceProvider.java Wed Jul > 09 10:02:30 2014 -0700 > +++ b/src/share/classes/sun/tracing/dtrace/DTraceProvider.java Wed Jul > 09 10:53:02 2014 -0700 > @@ -50,7 +50,7 @@ > private Object proxy; > > // For proxy generation > - private final static Class[] constructorParams = { > InvocationHandler.class }; > + private final static Class[] constructorParams = { > InvocationHandler.class }; > private final String proxyClassNamePrefix = "$DTraceTracingProxy"; > > static final String DEFAULT_MODULE = "java_tracing"; > @@ -135,7 +135,7 @@ > * Invoke its constructor with the designated invocation > handler. > */ > try { > - Constructor cons = > proxyClass.getConstructor(constructorParams); > + Constructor cons = > proxyClass.getConstructor(constructorParams); > return (T)cons.newInstance(new Object[] { this }); > } catch (ReflectiveOperationException e) { > throw new InternalError(e.toString(), e); > From david.holmes at oracle.com Fri Jul 11 04:36:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jul 2014 14:36:44 +1000 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: References: <53BDFD5D.4050908@oracle.com> Message-ID: <53BF69DC.9010305@oracle.com> Hi Volker, On 10/07/2014 8:12 PM, Volker Simonis wrote: > Hi David, > > thanks for looking at this. Here's my new version of the change with > some of your suggestions applied: > > http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 I have a simpler counter proposal (also default -> DEFAULT as that seems to be the style): # Serviceability Binaries ADD_SA_BINARIES/DEFAULT = $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ $(EXPORT_LIB_DIR)/sa-jdi.jar ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) ifeq ($(ZIP_DEBUGINFO_FILES),1) ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz else ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo endif endif ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) # No SA Support for IA64 or zero ADD_SA_BINARIES/ia64 = ADD_SA_BINARIES/zero = --- The open logic only has to worry about open platforms. The custom makefile can accept the default or override as it desires. I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the above is simple and clear. Ok? I'll sponsor this one of course (so its safe for other reviewers to jump in now :) ). Thanks, David > Please find more information inline: > > On Thu, Jul 10, 2014 at 4:41 AM, David Holmes wrote: >> Hi Volker, >> >> Comments below where you might expect them :) >> >> >> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could someone please review and sponsor the following change which >>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>> >>> Details: >>> >>> Currently, we don't support the SA agent on Linux/PPC64. This change >>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>> and sa-jdi.jar) will be correctly build and copied into the resulting >>> jdk images. >>> >>> This change also contains some small fixes in sa-jdi.jar to correctly >>> detect Linux/PPC64 as supported SA platform. (The actual >>> implementation of the Linux/PPC64 specific code will be handled by >>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>> >>> One thing which require special attention are the changes in >>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>> my change I've simply added 'ppc' to the list of supported >>> architectures, but this may break the 32-bit ppc build. I think the >> >> >> It wouldn't break it but I was expecting to see ppc64 here. >> > > The problem is that currently the decision if the SA agent will be > build is based on the value of HS_ARCH. But HS_ARCH is the 'basic > architecture' (i.e. x86 or sparc) so there's no easy way to choose the > SA agent for only a 64-bit platform (like ppc64 or amd64) and not for > its 32-bit counterpart (i.e. i386 or ppc). > > The only possibility with the current solution would be to only > conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But > that wouldn't make the code nicer either:) > >> >>> current code is to verbose and error prone anyway. It would be better >>> to have something like: >>> >>> ADD_SA_BINARIES = >>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>> >>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>> else >>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>> endif >>> endif >>> >>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 ppc64)) >>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >> >> >> You wouldn't need/want the $(HS_ARCH) there. >> > > Sorry, that was a type of course. It should read: > > ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 ppc64)) > EXPORT_LIST += $(ADD_SA_BINARIES) > > But that's not necessary now anymore (see new version below). > >> >>> endif >>> >>> With this solution we only define ADD_SA_BINARIES once (because the >>> various definitions for the different platforms are equal anyway). But >>> again this may affect other closed ports so please advise which >>> solution you'd prefer. >> >> >> The above is problematic for customizations. An alternative would be to set >> ADD_SA_BINARIES/default once with all the file names. Then: >> >> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >> # No SA Support for IA64 or zero >> ifneq (, $(findstring $(ARCH), ia64, zero)) >> ADD_SA_BINARIES/$(ARCH) = >> >> Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) if >> needed. >> >> Does that seem reasonable? >> > > The problem with using ARCH is that it is not "reliable" in the sens > that its value differs for top-level and hotspot-only makes. See > "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for > hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 > build". > > But using ADD_SA_BINARIES/default to save redundant lines is a good > idea. I've updated the patch accordingly and think that the new > solution is a good compromise between readability and not touching > existing/closed part. > > Are you fine with the new version at > http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? > >> >>> Notice that this change also requires a tiny fix in the top-level >>> repository which must be pushed AFTER this change. >> >> >> Can you elaborate please? >> > > I've also submitted the corresponding top-level repository change for > review which expects to find the SA agent libraries on Linux/ppc64 in > order to copy them into the image directory: > http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ > > But once that will be pushed, the build will fail if these HS changes > will not be in place to actually build the libraries. > >> Thanks, >> David >> >> >>> Thank you and best regards, >>> Volker >>> >> From jaroslav.bachorik at oracle.com Fri Jul 11 10:11:56 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 11 Jul 2014 12:11:56 +0200 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: References: Message-ID: <53BFB86C.4040403@oracle.com> Hi Jeremy, On 05/08/2014 08:56 PM, Jeremy Manson wrote: > I'm testing out my newly acquired OpenJDK authorship with something > simple. If I did this wrong, I apologize. > > Basically, the debugger becomes very slow if there are a lot of methods > in a class. This can happen (O(thousands)) if you are using a code > generation tool. > > http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ Have you considered using streams to avoid creation of an additional HashSet? -JB- > > Reviews from reviewers and committing from committers would be > appreciated. Thanks! > > Jeremy From volker.simonis at gmail.com Fri Jul 11 11:54:24 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Jul 2014 13:54:24 +0200 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: <53BF69DC.9010305@oracle.com> References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> Message-ID: On Fri, Jul 11, 2014 at 6:36 AM, David Holmes wrote: > Hi Volker, > > > On 10/07/2014 8:12 PM, Volker Simonis wrote: >> >> Hi David, >> >> thanks for looking at this. Here's my new version of the change with >> some of your suggestions applied: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 > > > I have a simpler counter proposal (also default -> DEFAULT as that seems to > be the style): > > # Serviceability Binaries > > ADD_SA_BINARIES/DEFAULT = > $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ > > $(EXPORT_LIB_DIR)/sa-jdi.jar > > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > ifeq ($(ZIP_DEBUGINFO_FILES),1) > ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz > else > ADD_SA_BINARIES/DEFAULT += > $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo > endif > endif > > ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) > > > # No SA Support for IA64 or zero > ADD_SA_BINARIES/ia64 = > ADD_SA_BINARIES/zero = > > --- > > The open logic only has to worry about open platforms. The custom makefile > can accept the default or override as it desires. > > I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the > above is simple and clear. > > Ok? > Perfect! Here's the new webrev with your proposed changes (tested on Linux/x86_64 and ppc64): http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 Thanks for sponsoring, Volker > I'll sponsor this one of course (so its safe for other reviewers to jump in > now :) ). > > Thanks, > David > > > >> Please find more information inline: >> >> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >> wrote: >>> >>> Hi Volker, >>> >>> Comments below where you might expect them :) >>> >>> >>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>> >>>> >>>> Hi, >>>> >>>> could someone please review and sponsor the following change which >>>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>> >>>> Details: >>>> >>>> Currently, we don't support the SA agent on Linux/PPC64. This change >>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>> and sa-jdi.jar) will be correctly build and copied into the resulting >>>> jdk images. >>>> >>>> This change also contains some small fixes in sa-jdi.jar to correctly >>>> detect Linux/PPC64 as supported SA platform. (The actual >>>> implementation of the Linux/PPC64 specific code will be handled by >>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>> >>>> One thing which require special attention are the changes in >>>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>>> my change I've simply added 'ppc' to the list of supported >>>> architectures, but this may break the 32-bit ppc build. I think the >>> >>> >>> >>> It wouldn't break it but I was expecting to see ppc64 here. >>> >> >> The problem is that currently the decision if the SA agent will be >> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >> architecture' (i.e. x86 or sparc) so there's no easy way to choose the >> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >> its 32-bit counterpart (i.e. i386 or ppc). >> >> The only possibility with the current solution would be to only >> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >> that wouldn't make the code nicer either:) >> >>> >>>> current code is to verbose and error prone anyway. It would be better >>>> to have something like: >>>> >>>> ADD_SA_BINARIES = >>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>> >>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>> else >>>> ADD_SA_BINARIES += >>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>> endif >>>> endif >>>> >>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>> ppc64)) >>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>> >>> >>> >>> You wouldn't need/want the $(HS_ARCH) there. >>> >> >> Sorry, that was a type of course. It should read: >> >> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >> ppc64)) >> EXPORT_LIST += $(ADD_SA_BINARIES) >> >> But that's not necessary now anymore (see new version below). >> >>> >>>> endif >>>> >>>> With this solution we only define ADD_SA_BINARIES once (because the >>>> various definitions for the different platforms are equal anyway). But >>>> again this may affect other closed ports so please advise which >>>> solution you'd prefer. >>> >>> >>> >>> The above is problematic for customizations. An alternative would be to >>> set >>> ADD_SA_BINARIES/default once with all the file names. Then: >>> >>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>> # No SA Support for IA64 or zero >>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>> ADD_SA_BINARIES/$(ARCH) = >>> >>> Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) >>> if >>> needed. >>> >>> Does that seem reasonable? >>> >> >> The problem with using ARCH is that it is not "reliable" in the sens >> that its value differs for top-level and hotspot-only makes. See >> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >> build". >> >> But using ADD_SA_BINARIES/default to save redundant lines is a good >> idea. I've updated the patch accordingly and think that the new >> solution is a good compromise between readability and not touching >> existing/closed part. >> >> Are you fine with the new version at >> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >> >>> >>>> Notice that this change also requires a tiny fix in the top-level >>>> repository which must be pushed AFTER this change. >>> >>> >>> >>> Can you elaborate please? >>> >> >> I've also submitted the corresponding top-level repository change for >> review which expects to find the SA agent libraries on Linux/ppc64 in >> order to copy them into the image directory: >> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >> >> But once that will be pushed, the build will fail if these HS changes >> will not be in place to actually build the libraries. >> >>> Thanks, >>> David >>> >>> >>>> Thank you and best regards, >>>> Volker >>>> >>> > From david.holmes at oracle.com Fri Jul 11 12:02:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jul 2014 22:02:49 +1000 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> Message-ID: <53BFD269.2050500@oracle.com> I'll test it out with my local custom changes while we wait for a second reviewer. I plan to push to hs-rt repo. Thanks, David On 11/07/2014 9:54 PM, Volker Simonis wrote: > On Fri, Jul 11, 2014 at 6:36 AM, David Holmes wrote: >> Hi Volker, >> >> >> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thanks for looking at this. Here's my new version of the change with >>> some of your suggestions applied: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >> >> >> I have a simpler counter proposal (also default -> DEFAULT as that seems to >> be the style): >> >> # Serviceability Binaries >> >> ADD_SA_BINARIES/DEFAULT = >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >> >> $(EXPORT_LIB_DIR)/sa-jdi.jar >> >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> ifeq ($(ZIP_DEBUGINFO_FILES),1) >> ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >> else >> ADD_SA_BINARIES/DEFAULT += >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >> endif >> endif >> >> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >> >> >> # No SA Support for IA64 or zero >> ADD_SA_BINARIES/ia64 = >> ADD_SA_BINARIES/zero = >> >> --- >> >> The open logic only has to worry about open platforms. The custom makefile >> can accept the default or override as it desires. >> >> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the >> above is simple and clear. >> >> Ok? >> > > Perfect! > > Here's the new webrev with your proposed changes (tested on > Linux/x86_64 and ppc64): > > http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 > > Thanks for sponsoring, > Volker > >> I'll sponsor this one of course (so its safe for other reviewers to jump in >> now :) ). >> >> Thanks, >> David >> >> >> >>> Please find more information inline: >>> >>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> Comments below where you might expect them :) >>>> >>>> >>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> could someone please review and sponsor the following change which >>>>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>> >>>>> Details: >>>>> >>>>> Currently, we don't support the SA agent on Linux/PPC64. This change >>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>> and sa-jdi.jar) will be correctly build and copied into the resulting >>>>> jdk images. >>>>> >>>>> This change also contains some small fixes in sa-jdi.jar to correctly >>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>> >>>>> One thing which require special attention are the changes in >>>>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>>>> my change I've simply added 'ppc' to the list of supported >>>>> architectures, but this may break the 32-bit ppc build. I think the >>>> >>>> >>>> >>>> It wouldn't break it but I was expecting to see ppc64 here. >>>> >>> >>> The problem is that currently the decision if the SA agent will be >>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>> architecture' (i.e. x86 or sparc) so there's no easy way to choose the >>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>> its 32-bit counterpart (i.e. i386 or ppc). >>> >>> The only possibility with the current solution would be to only >>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>> that wouldn't make the code nicer either:) >>> >>>> >>>>> current code is to verbose and error prone anyway. It would be better >>>>> to have something like: >>>>> >>>>> ADD_SA_BINARIES = >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>> >>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>> else >>>>> ADD_SA_BINARIES += >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>> endif >>>>> endif >>>>> >>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>> ppc64)) >>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>> >>>> >>>> >>>> You wouldn't need/want the $(HS_ARCH) there. >>>> >>> >>> Sorry, that was a type of course. It should read: >>> >>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>> ppc64)) >>> EXPORT_LIST += $(ADD_SA_BINARIES) >>> >>> But that's not necessary now anymore (see new version below). >>> >>>> >>>>> endif >>>>> >>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>> various definitions for the different platforms are equal anyway). But >>>>> again this may affect other closed ports so please advise which >>>>> solution you'd prefer. >>>> >>>> >>>> >>>> The above is problematic for customizations. An alternative would be to >>>> set >>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>> >>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>> # No SA Support for IA64 or zero >>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>> ADD_SA_BINARIES/$(ARCH) = >>>> >>>> Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) >>>> if >>>> needed. >>>> >>>> Does that seem reasonable? >>>> >>> >>> The problem with using ARCH is that it is not "reliable" in the sens >>> that its value differs for top-level and hotspot-only makes. See >>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>> build". >>> >>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>> idea. I've updated the patch accordingly and think that the new >>> solution is a good compromise between readability and not touching >>> existing/closed part. >>> >>> Are you fine with the new version at >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>> >>>> >>>>> Notice that this change also requires a tiny fix in the top-level >>>>> repository which must be pushed AFTER this change. >>>> >>>> >>>> >>>> Can you elaborate please? >>>> >>> >>> I've also submitted the corresponding top-level repository change for >>> review which expects to find the SA agent libraries on Linux/ppc64 in >>> order to copy them into the image directory: >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>> >>> But once that will be pushed, the build will fail if these HS changes >>> will not be in place to actually build the libraries. >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>> >> From vladimir.kozlov at oracle.com Fri Jul 11 21:13:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Jul 2014 14:13:23 -0700 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> Message-ID: <53C05373.7000104@oracle.com> This looks good. Vladimir On 7/11/14 4:54 AM, Volker Simonis wrote: > On Fri, Jul 11, 2014 at 6:36 AM, David Holmes wrote: >> Hi Volker, >> >> >> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thanks for looking at this. Here's my new version of the change with >>> some of your suggestions applied: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >> >> >> I have a simpler counter proposal (also default -> DEFAULT as that seems to >> be the style): >> >> # Serviceability Binaries >> >> ADD_SA_BINARIES/DEFAULT = >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >> >> $(EXPORT_LIB_DIR)/sa-jdi.jar >> >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> ifeq ($(ZIP_DEBUGINFO_FILES),1) >> ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >> else >> ADD_SA_BINARIES/DEFAULT += >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >> endif >> endif >> >> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >> >> >> # No SA Support for IA64 or zero >> ADD_SA_BINARIES/ia64 = >> ADD_SA_BINARIES/zero = >> >> --- >> >> The open logic only has to worry about open platforms. The custom makefile >> can accept the default or override as it desires. >> >> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the >> above is simple and clear. >> >> Ok? >> > > Perfect! > > Here's the new webrev with your proposed changes (tested on > Linux/x86_64 and ppc64): > > http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 > > Thanks for sponsoring, > Volker > >> I'll sponsor this one of course (so its safe for other reviewers to jump in >> now :) ). >> >> Thanks, >> David >> >> >> >>> Please find more information inline: >>> >>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> Comments below where you might expect them :) >>>> >>>> >>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> could someone please review and sponsor the following change which >>>>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>> >>>>> Details: >>>>> >>>>> Currently, we don't support the SA agent on Linux/PPC64. This change >>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>> and sa-jdi.jar) will be correctly build and copied into the resulting >>>>> jdk images. >>>>> >>>>> This change also contains some small fixes in sa-jdi.jar to correctly >>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>> >>>>> One thing which require special attention are the changes in >>>>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>>>> my change I've simply added 'ppc' to the list of supported >>>>> architectures, but this may break the 32-bit ppc build. I think the >>>> >>>> >>>> >>>> It wouldn't break it but I was expecting to see ppc64 here. >>>> >>> >>> The problem is that currently the decision if the SA agent will be >>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>> architecture' (i.e. x86 or sparc) so there's no easy way to choose the >>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>> its 32-bit counterpart (i.e. i386 or ppc). >>> >>> The only possibility with the current solution would be to only >>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>> that wouldn't make the code nicer either:) >>> >>>> >>>>> current code is to verbose and error prone anyway. It would be better >>>>> to have something like: >>>>> >>>>> ADD_SA_BINARIES = >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>> >>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>> else >>>>> ADD_SA_BINARIES += >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>> endif >>>>> endif >>>>> >>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>> ppc64)) >>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>> >>>> >>>> >>>> You wouldn't need/want the $(HS_ARCH) there. >>>> >>> >>> Sorry, that was a type of course. It should read: >>> >>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>> ppc64)) >>> EXPORT_LIST += $(ADD_SA_BINARIES) >>> >>> But that's not necessary now anymore (see new version below). >>> >>>> >>>>> endif >>>>> >>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>> various definitions for the different platforms are equal anyway). But >>>>> again this may affect other closed ports so please advise which >>>>> solution you'd prefer. >>>> >>>> >>>> >>>> The above is problematic for customizations. An alternative would be to >>>> set >>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>> >>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>> # No SA Support for IA64 or zero >>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>> ADD_SA_BINARIES/$(ARCH) = >>>> >>>> Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) >>>> if >>>> needed. >>>> >>>> Does that seem reasonable? >>>> >>> >>> The problem with using ARCH is that it is not "reliable" in the sens >>> that its value differs for top-level and hotspot-only makes. See >>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>> build". >>> >>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>> idea. I've updated the patch accordingly and think that the new >>> solution is a good compromise between readability and not touching >>> existing/closed part. >>> >>> Are you fine with the new version at >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>> >>>> >>>>> Notice that this change also requires a tiny fix in the top-level >>>>> repository which must be pushed AFTER this change. >>>> >>>> >>>> >>>> Can you elaborate please? >>>> >>> >>> I've also submitted the corresponding top-level repository change for >>> review which expects to find the SA agent libraries on Linux/ppc64 in >>> order to copy them into the image directory: >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>> >>> But once that will be pushed, the build will fail if these HS changes >>> will not be in place to actually build the libraries. >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>> >> From jeremymanson at google.com Fri Jul 11 21:28:39 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 11 Jul 2014 14:28:39 -0700 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: <53BFB86C.4040403@oracle.com> References: <53BFB86C.4040403@oracle.com> Message-ID: Hi Jaroslav, I haven't written many Streams yet, so perhaps I'm missing something obvious / well-known. Streams can replace the original code in an obvious way (filter the elements of list based on whether they are contained in map.values()), but I'm not sure how the filter operation becomes O(1) unless we build the HashSet? Jeremy On Fri, Jul 11, 2014 at 3:11 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > Hi Jeremy, > > > On 05/08/2014 08:56 PM, Jeremy Manson wrote: > >> I'm testing out my newly acquired OpenJDK authorship with something >> simple. If I did this wrong, I apologize. >> >> Basically, the debugger becomes very slow if there are a lot of methods >> in a class. This can happen (O(thousands)) if you are using a code >> generation tool. >> >> http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ >> > > Have you considered using streams to avoid creation of an additional > HashSet? > > -JB- > > > >> Reviews from reviewers and committing from committers would be >> appreciated. Thanks! >> >> Jeremy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From poonam.bajaj at oracle.com Sat Jul 12 01:23:25 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Sat, 12 Jul 2014 06:53:25 +0530 Subject: "8046282: SA update" seems to break the SA/jstack in OpenJDK In-Reply-To: References: Message-ID: <53C08E0D.9050606@oracle.com> Hi Volker, Thanks. There is a bug filed for this issue: https://bugs.openjdk.java.net/browse/JDK-8049881 I am working on this bug. Thanks, Poonam On 7/10/2014 4:00 PM, Volker Simonis wrote: > Hi, > > the change "8046282: SA update" introduced the following new code in > agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java > > + traceIDField = type.getField("_trace_id"); > > But I can not find the corresponding field in > src/share/vm/oops/klass.hpp. The Klass class only contains the macro > TRACE_DEFINE_KLASS_TRACE_ID which is defined to "typedef int > ___IGNORED_hs_trace_type2" in traceMacros.hpp. > > This leads to an error when calling for example jstack on a core file: > > $ images/j2sdk-image/bin/jstack ./images/j2sdk-image/bin/java core > Attaching to core core from executable ./images/j2sdk-image/bin/java, > please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 1.9.0-internal-d046063_2014_07_10_11_16-b00 > Deadlock Detection: > > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:484) > at sun.tools.jstack.JStack.runJStackTool(JStack.java:140) > at sun.tools.jstack.JStack.main(JStack.java:106) > Caused by: java.lang.ExceptionInInitializerError > at sun.jvm.hotspot.oops.ObjectHeap.initialize(ObjectHeap.java:74) > at sun.jvm.hotspot.oops.ObjectHeap.(ObjectHeap.java:110) > at sun.jvm.hotspot.runtime.VM.getObjectHeap(VM.java:582) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:55) > at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62) > at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) > at sun.jvm.hotspot.tools.JStack.run(JStack.java:66) > at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.JStack.main(JStack.java:92) > ... 6 more > Caused by: java.lang.RuntimeException: field "_trace_id" not found in type Klass > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:183) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:190) > at sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:194) > at sun.jvm.hotspot.oops.Klass.initialize(Klass.java:58) > at sun.jvm.hotspot.oops.Klass.access$000(Klass.java:33) > at sun.jvm.hotspot.oops.Klass$1.update(Klass.java:37) > at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394) > at sun.jvm.hotspot.oops.Klass.(Klass.java:35) > ... 18 more > > Is this a problem with OpenJDK only (i.e. is '_trace_id' defined in > Oracle proprietary builds) ?. Or is this another problem? > > Thank you and best regards, > Volker From jaroslav.bachorik at oracle.com Sat Jul 12 09:57:21 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Sat, 12 Jul 2014 11:57:21 +0200 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: References: <53BFB86C.4040403@oracle.com> Message-ID: <53C10681.1070303@oracle.com> On 07/11/2014 11:28 PM, Jeremy Manson wrote: > Hi Jaroslav, > > I haven't written many Streams yet, so perhaps I'm missing something > obvious / well-known. Streams can replace the original code in an > obvious way (filter the elements of list based on whether they are > contained in map.values()), but I'm not sure how the filter operation > becomes O(1) unless we build the HashSet? Probably I should have been more explicit about this. The map keys (a set) are derived from the map values by concatenating the method name with the method signature. Utilizing this you can then come up with a code like this: return allMethods().stream() .filter((m) -> map.keySet().contains(getMethodTag(m))) .collect(Collectors.toList()); "getMethodTag(method)" is the function used to generate the hash key from a Method instance (to be extracted from the current source code). But we would need a benchmark to figure out which construct actually performs better (the algorithmic complexity is the same). -JB- > > Jeremy > > > On Fri, Jul 11, 2014 at 3:11 AM, Jaroslav Bachorik > > wrote: > > Hi Jeremy, > > > On 05/08/2014 08:56 PM, Jeremy Manson wrote: > > I'm testing out my newly acquired OpenJDK authorship with something > simple. If I did this wrong, I apologize. > > Basically, the debugger becomes very slow if there are a lot of > methods > in a class. This can happen (O(thousands)) if you are using a code > generation tool. > > http://cr.openjdk.java.net/~__jmanson/8042778/webrev.00/ > > > > Have you considered using streams to avoid creation of an additional > HashSet? > > -JB- > > > > Reviews from reviewers and committing from committers would be > appreciated. Thanks! > > Jeremy > > > From david.holmes at oracle.com Sun Jul 13 21:22:45 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jul 2014 07:22:45 +1000 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> Message-ID: <53C2F8A5.7050006@oracle.com> Hi Volker, Just discovered you didn't quite pick up on all of my change - the ARM entry is to be deleted. Only the open platforms need to be listed: >> # No SA Support for IA64 or zero >> ADD_SA_BINARIES/ia64 = >> ADD_SA_BINARIES/zero = Thanks, David On 11/07/2014 9:54 PM, Volker Simonis wrote: > On Fri, Jul 11, 2014 at 6:36 AM, David Holmes wrote: >> Hi Volker, >> >> >> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thanks for looking at this. Here's my new version of the change with >>> some of your suggestions applied: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >> >> >> I have a simpler counter proposal (also default -> DEFAULT as that seems to >> be the style): >> >> # Serviceability Binaries >> >> ADD_SA_BINARIES/DEFAULT = >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >> >> $(EXPORT_LIB_DIR)/sa-jdi.jar >> >> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >> ifeq ($(ZIP_DEBUGINFO_FILES),1) >> ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >> else >> ADD_SA_BINARIES/DEFAULT += >> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >> endif >> endif >> >> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >> >> >> # No SA Support for IA64 or zero >> ADD_SA_BINARIES/ia64 = >> ADD_SA_BINARIES/zero = >> >> --- >> >> The open logic only has to worry about open platforms. The custom makefile >> can accept the default or override as it desires. >> >> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the >> above is simple and clear. >> >> Ok? >> > > Perfect! > > Here's the new webrev with your proposed changes (tested on > Linux/x86_64 and ppc64): > > http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 > > Thanks for sponsoring, > Volker > >> I'll sponsor this one of course (so its safe for other reviewers to jump in >> now :) ). >> >> Thanks, >> David >> >> >> >>> Please find more information inline: >>> >>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> Comments below where you might expect them :) >>>> >>>> >>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> could someone please review and sponsor the following change which >>>>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>> >>>>> Details: >>>>> >>>>> Currently, we don't support the SA agent on Linux/PPC64. This change >>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>> and sa-jdi.jar) will be correctly build and copied into the resulting >>>>> jdk images. >>>>> >>>>> This change also contains some small fixes in sa-jdi.jar to correctly >>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>> >>>>> One thing which require special attention are the changes in >>>>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>>>> my change I've simply added 'ppc' to the list of supported >>>>> architectures, but this may break the 32-bit ppc build. I think the >>>> >>>> >>>> >>>> It wouldn't break it but I was expecting to see ppc64 here. >>>> >>> >>> The problem is that currently the decision if the SA agent will be >>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>> architecture' (i.e. x86 or sparc) so there's no easy way to choose the >>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>> its 32-bit counterpart (i.e. i386 or ppc). >>> >>> The only possibility with the current solution would be to only >>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>> that wouldn't make the code nicer either:) >>> >>>> >>>>> current code is to verbose and error prone anyway. It would be better >>>>> to have something like: >>>>> >>>>> ADD_SA_BINARIES = >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>> >>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>> else >>>>> ADD_SA_BINARIES += >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>> endif >>>>> endif >>>>> >>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>> ppc64)) >>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>> >>>> >>>> >>>> You wouldn't need/want the $(HS_ARCH) there. >>>> >>> >>> Sorry, that was a type of course. It should read: >>> >>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>> ppc64)) >>> EXPORT_LIST += $(ADD_SA_BINARIES) >>> >>> But that's not necessary now anymore (see new version below). >>> >>>> >>>>> endif >>>>> >>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>> various definitions for the different platforms are equal anyway). But >>>>> again this may affect other closed ports so please advise which >>>>> solution you'd prefer. >>>> >>>> >>>> >>>> The above is problematic for customizations. An alternative would be to >>>> set >>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>> >>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>> # No SA Support for IA64 or zero >>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>> ADD_SA_BINARIES/$(ARCH) = >>>> >>>> Each ARCH handled elsewhere would then still set ADD_SA_BINARIES/$(ARCH) >>>> if >>>> needed. >>>> >>>> Does that seem reasonable? >>>> >>> >>> The problem with using ARCH is that it is not "reliable" in the sens >>> that its value differs for top-level and hotspot-only makes. See >>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>> build". >>> >>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>> idea. I've updated the patch accordingly and think that the new >>> solution is a good compromise between readability and not touching >>> existing/closed part. >>> >>> Are you fine with the new version at >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>> >>>> >>>>> Notice that this change also requires a tiny fix in the top-level >>>>> repository which must be pushed AFTER this change. >>>> >>>> >>>> >>>> Can you elaborate please? >>>> >>> >>> I've also submitted the corresponding top-level repository change for >>> review which expects to find the SA agent libraries on Linux/ppc64 in >>> order to copy them into the image directory: >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>> >>> But once that will be pushed, the build will fail if these HS changes >>> will not be in place to actually build the libraries. >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>> >> From volker.simonis at gmail.com Mon Jul 14 09:44:51 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Jul 2014 11:44:51 +0200 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: <53C2F8A5.7050006@oracle.com> References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> <53C2F8A5.7050006@oracle.com> Message-ID: On Sun, Jul 13, 2014 at 11:22 PM, David Holmes wrote: > Hi Volker, > > Just discovered you didn't quite pick up on all of my change - the ARM entry > is to be deleted. Only the open platforms need to be listed: > > >>> # No SA Support for IA64 or zero >>> ADD_SA_BINARIES/ia64 = >>> ADD_SA_BINARIES/zero = > OK, but then I also remove IA64 as it isn't an open platform either: http://cr.openjdk.java.net/~simonis/webrevs/8049715.v4/ I've also added Vladimir as reviewer. Thank you and best regards, Volker > Thanks, > David > > On 11/07/2014 9:54 PM, Volker Simonis wrote: >> >> On Fri, Jul 11, 2014 at 6:36 AM, David Holmes >> wrote: >>> >>> Hi Volker, >>> >>> >>> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>>> >>>> >>>> Hi David, >>>> >>>> thanks for looking at this. Here's my new version of the change with >>>> some of your suggestions applied: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >>> >>> >>> >>> I have a simpler counter proposal (also default -> DEFAULT as that seems >>> to >>> be the style): >>> >>> # Serviceability Binaries >>> >>> ADD_SA_BINARIES/DEFAULT = >>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >>> >>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>> >>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>> ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>> else >>> ADD_SA_BINARIES/DEFAULT += >>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>> endif >>> endif >>> >>> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >>> >>> >>> # No SA Support for IA64 or zero >>> ADD_SA_BINARIES/ia64 = >>> ADD_SA_BINARIES/zero = >>> >>> --- >>> >>> The open logic only has to worry about open platforms. The custom >>> makefile >>> can accept the default or override as it desires. >>> >>> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the >>> above is simple and clear. >>> >>> Ok? >>> >> >> Perfect! >> >> Here's the new webrev with your proposed changes (tested on >> Linux/x86_64 and ppc64): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 >> >> Thanks for sponsoring, >> Volker >> >>> I'll sponsor this one of course (so its safe for other reviewers to jump >>> in >>> now :) ). >>> >>> Thanks, >>> David >>> >>> >>> >>>> Please find more information inline: >>>> >>>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>>> wrote: >>>>> >>>>> >>>>> Hi Volker, >>>>> >>>>> Comments below where you might expect them :) >>>>> >>>>> >>>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> could someone please review and sponsor the following change which >>>>>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>>> >>>>>> Details: >>>>>> >>>>>> Currently, we don't support the SA agent on Linux/PPC64. This change >>>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>>> and sa-jdi.jar) will be correctly build and copied into the resulting >>>>>> jdk images. >>>>>> >>>>>> This change also contains some small fixes in sa-jdi.jar to correctly >>>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>>> >>>>>> One thing which require special attention are the changes in >>>>>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>>>>> my change I've simply added 'ppc' to the list of supported >>>>>> architectures, but this may break the 32-bit ppc build. I think the >>>>> >>>>> >>>>> >>>>> >>>>> It wouldn't break it but I was expecting to see ppc64 here. >>>>> >>>> >>>> The problem is that currently the decision if the SA agent will be >>>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>>> architecture' (i.e. x86 or sparc) so there's no easy way to choose the >>>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>>> its 32-bit counterpart (i.e. i386 or ppc). >>>> >>>> The only possibility with the current solution would be to only >>>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>>> that wouldn't make the code nicer either:) >>>> >>>>> >>>>>> current code is to verbose and error prone anyway. It would be better >>>>>> to have something like: >>>>>> >>>>>> ADD_SA_BINARIES = >>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>>> >>>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>>> else >>>>>> ADD_SA_BINARIES += >>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>>> endif >>>>>> endif >>>>>> >>>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>>> ppc64)) >>>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>>> >>>>> >>>>> >>>>> >>>>> You wouldn't need/want the $(HS_ARCH) there. >>>>> >>>> >>>> Sorry, that was a type of course. It should read: >>>> >>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>> ppc64)) >>>> EXPORT_LIST += $(ADD_SA_BINARIES) >>>> >>>> But that's not necessary now anymore (see new version below). >>>> >>>>> >>>>>> endif >>>>>> >>>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>>> various definitions for the different platforms are equal anyway). But >>>>>> again this may affect other closed ports so please advise which >>>>>> solution you'd prefer. >>>>> >>>>> >>>>> >>>>> >>>>> The above is problematic for customizations. An alternative would be to >>>>> set >>>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>>> >>>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>>> # No SA Support for IA64 or zero >>>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>>> ADD_SA_BINARIES/$(ARCH) = >>>>> >>>>> Each ARCH handled elsewhere would then still set >>>>> ADD_SA_BINARIES/$(ARCH) >>>>> if >>>>> needed. >>>>> >>>>> Does that seem reasonable? >>>>> >>>> >>>> The problem with using ARCH is that it is not "reliable" in the sens >>>> that its value differs for top-level and hotspot-only makes. See >>>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>>> build". >>>> >>>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>>> idea. I've updated the patch accordingly and think that the new >>>> solution is a good compromise between readability and not touching >>>> existing/closed part. >>>> >>>> Are you fine with the new version at >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>>> >>>>> >>>>>> Notice that this change also requires a tiny fix in the top-level >>>>>> repository which must be pushed AFTER this change. >>>>> >>>>> >>>>> >>>>> >>>>> Can you elaborate please? >>>>> >>>> >>>> I've also submitted the corresponding top-level repository change for >>>> review which expects to find the SA agent libraries on Linux/ppc64 in >>>> order to copy them into the image directory: >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>>> >>>> But once that will be pushed, the build will fail if these HS changes >>>> will not be in place to actually build the libraries. >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>> >>> > From david.holmes at oracle.com Mon Jul 14 11:09:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jul 2014 21:09:31 +1000 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> <53C2F8A5.7050006@oracle.com> Message-ID: <53C3BA6B.70600@oracle.com> On 14/07/2014 7:44 PM, Volker Simonis wrote: > On Sun, Jul 13, 2014 at 11:22 PM, David Holmes wrote: >> Hi Volker, >> >> Just discovered you didn't quite pick up on all of my change - the ARM entry >> is to be deleted. Only the open platforms need to be listed: >> >> >>>> # No SA Support for IA64 or zero >>>> ADD_SA_BINARIES/ia64 = >>>> ADD_SA_BINARIES/zero = >> > > OK, but then I also remove IA64 as it isn't an open platform either: > > http://cr.openjdk.java.net/~simonis/webrevs/8049715.v4/ Yes good point. ia64 should be eradicated from the build system :) I will put this altogether in the AM. > I've also added Vladimir as reviewer. Great Thanks, David > Thank you and best regards, > Volker > > >> Thanks, >> David >> >> On 11/07/2014 9:54 PM, Volker Simonis wrote: >>> >>> On Fri, Jul 11, 2014 at 6:36 AM, David Holmes >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> >>>> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> thanks for looking at this. Here's my new version of the change with >>>>> some of your suggestions applied: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >>>> >>>> >>>> >>>> I have a simpler counter proposal (also default -> DEFAULT as that seems >>>> to >>>> be the style): >>>> >>>> # Serviceability Binaries >>>> >>>> ADD_SA_BINARIES/DEFAULT = >>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >>>> >>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>> >>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>> ADD_SA_BINARIES/DEFAULT += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>> else >>>> ADD_SA_BINARIES/DEFAULT += >>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>> endif >>>> endif >>>> >>>> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >>>> >>>> >>>> # No SA Support for IA64 or zero >>>> ADD_SA_BINARIES/ia64 = >>>> ADD_SA_BINARIES/zero = >>>> >>>> --- >>>> >>>> The open logic only has to worry about open platforms. The custom >>>> makefile >>>> can accept the default or override as it desires. >>>> >>>> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) but the >>>> above is simple and clear. >>>> >>>> Ok? >>>> >>> >>> Perfect! >>> >>> Here's the new webrev with your proposed changes (tested on >>> Linux/x86_64 and ppc64): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 >>> >>> Thanks for sponsoring, >>> Volker >>> >>>> I'll sponsor this one of course (so its safe for other reviewers to jump >>>> in >>>> now :) ). >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>>> Please find more information inline: >>>>> >>>>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Volker, >>>>>> >>>>>> Comments below where you might expect them :) >>>>>> >>>>>> >>>>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> could someone please review and sponsor the following change which >>>>>>> does some preliminary work for enabling the SA agent on Linux/PPC64: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>>>> >>>>>>> Details: >>>>>>> >>>>>>> Currently, we don't support the SA agent on Linux/PPC64. This change >>>>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>>>> and sa-jdi.jar) will be correctly build and copied into the resulting >>>>>>> jdk images. >>>>>>> >>>>>>> This change also contains some small fixes in sa-jdi.jar to correctly >>>>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>>>> >>>>>>> One thing which require special attention are the changes in >>>>>>> make/linux/makefiles/defs.make which may touch the closed ppc port. In >>>>>>> my change I've simply added 'ppc' to the list of supported >>>>>>> architectures, but this may break the 32-bit ppc build. I think the >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It wouldn't break it but I was expecting to see ppc64 here. >>>>>> >>>>> >>>>> The problem is that currently the decision if the SA agent will be >>>>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>>>> architecture' (i.e. x86 or sparc) so there's no easy way to choose the >>>>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>>>> its 32-bit counterpart (i.e. i386 or ppc). >>>>> >>>>> The only possibility with the current solution would be to only >>>>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>>>> that wouldn't make the code nicer either:) >>>>> >>>>>> >>>>>>> current code is to verbose and error prone anyway. It would be better >>>>>>> to have something like: >>>>>>> >>>>>>> ADD_SA_BINARIES = >>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>>>> >>>>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>>> ADD_SA_BINARIES += $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>>>> else >>>>>>> ADD_SA_BINARIES += >>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>>>> endif >>>>>>> endif >>>>>>> >>>>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>>>> ppc64)) >>>>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> You wouldn't need/want the $(HS_ARCH) there. >>>>>> >>>>> >>>>> Sorry, that was a type of course. It should read: >>>>> >>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>> ppc64)) >>>>> EXPORT_LIST += $(ADD_SA_BINARIES) >>>>> >>>>> But that's not necessary now anymore (see new version below). >>>>> >>>>>> >>>>>>> endif >>>>>>> >>>>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>>>> various definitions for the different platforms are equal anyway). But >>>>>>> again this may affect other closed ports so please advise which >>>>>>> solution you'd prefer. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The above is problematic for customizations. An alternative would be to >>>>>> set >>>>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>>>> >>>>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>>>> # No SA Support for IA64 or zero >>>>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>>>> ADD_SA_BINARIES/$(ARCH) = >>>>>> >>>>>> Each ARCH handled elsewhere would then still set >>>>>> ADD_SA_BINARIES/$(ARCH) >>>>>> if >>>>>> needed. >>>>>> >>>>>> Does that seem reasonable? >>>>>> >>>>> >>>>> The problem with using ARCH is that it is not "reliable" in the sens >>>>> that its value differs for top-level and hotspot-only makes. See >>>>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>>>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>>>> build". >>>>> >>>>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>>>> idea. I've updated the patch accordingly and think that the new >>>>> solution is a good compromise between readability and not touching >>>>> existing/closed part. >>>>> >>>>> Are you fine with the new version at >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>>>> >>>>>> >>>>>>> Notice that this change also requires a tiny fix in the top-level >>>>>>> repository which must be pushed AFTER this change. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Can you elaborate please? >>>>>> >>>>> >>>>> I've also submitted the corresponding top-level repository change for >>>>> review which expects to find the SA agent libraries on Linux/ppc64 in >>>>> order to copy them into the image directory: >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>>>> >>>>> But once that will be pushed, the build will fail if these HS changes >>>>> will not be in place to actually build the libraries. >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>> >>>> >> From volker.simonis at gmail.com Mon Jul 14 18:24:42 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Jul 2014 20:24:42 +0200 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: <53BC1237.2060006@oracle.com> References: <53BC1237.2060006@oracle.com> Message-ID: Hi everybody, can somebody PLEASE review and sponsor this tiny, ppc64-only change. Thanks, Volker On Tue, Jul 8, 2014 at 5:45 PM, Daniel D. Daugherty wrote: > Adding the Serviceability Team since JVM/TI belongs to them. > > Dan > > > > On 7/8/14 9:41 AM, Volker Simonis wrote: >> >> Hi, >> >> could somebody please review and push the following small, PPC64-only >> change to any of the hs team repositories: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049441/ >> https://bugs.openjdk.java.net/browse/JDK-8049441 >> >> Background: >> >> For some stubs we actually do not really generate code on PPC64 but >> instead we use a native C-function with inline-assembly. If the >> generators of these stubs contain a StubCodeMark, they will trigger >> JvmtiExport::post_dynamic_code_generated_internal events with a zero >> length code size. These events may fool clients like Oprofile which >> register for these events (thanks to Maynard Johnson who reported this >> - see >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). >> >> This change simply removes the StubCodeMark from >> ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() >> because they don't generate assembly code. It also removes the >> StubCodeMark from generate_throw_exception() because it doesn't really >> generate a plain stub but a runtime stub for which the JVMT dynamic >> code event is already generated by RuntimeStub::new_runtime_stub() -> >> CodeBlob::trace_new_stub() -> >> JvmtiExport::post_dynamic_code_generated(). >> >> Thank you and best regards, >> Volker > > From serguei.spitsyn at oracle.com Mon Jul 14 20:35:42 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 14 Jul 2014 13:35:42 -0700 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: References: <53BC1237.2060006@oracle.com> Message-ID: <53C43F1E.2030805@oracle.com> Hi Volker, It looks good in general. But I don't understand all the details. For instance, your email description of the fix tells that the the event is posted by: RuntimeStub::new_runtime_stub() -> CodeBlob::trace_new_stub() -> JvmtiExport::post_dynamic_code_generated() I see the new_runtime_stub() call in the generate_throw_exception() but there is no such call in the generate_icache_flush() and generate_handler_for_unsafe_access() . Probably, the StubCodeMark just needs to be removed there. Could you, please, explain this a little bit? We also need someone from the compiler team to look at this. I also included into the cc-list Oleg, who recently touched this area. Thanks, Serguei On 7/14/14 11:24 AM, Volker Simonis wrote: > Hi everybody, > > can somebody PLEASE review and sponsor this tiny, ppc64-only change. > > Thanks, > Volker > > > On Tue, Jul 8, 2014 at 5:45 PM, Daniel D. Daugherty > wrote: >> Adding the Serviceability Team since JVM/TI belongs to them. >> >> Dan >> >> >> >> On 7/8/14 9:41 AM, Volker Simonis wrote: >>> Hi, >>> >>> could somebody please review and push the following small, PPC64-only >>> change to any of the hs team repositories: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049441/ >>> https://bugs.openjdk.java.net/browse/JDK-8049441 >>> >>> Background: >>> >>> For some stubs we actually do not really generate code on PPC64 but >>> instead we use a native C-function with inline-assembly. If the >>> generators of these stubs contain a StubCodeMark, they will trigger >>> JvmtiExport::post_dynamic_code_generated_internal events with a zero >>> length code size. These events may fool clients like Oprofile which >>> register for these events (thanks to Maynard Johnson who reported this >>> - see >>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). >>> >>> This change simply removes the StubCodeMark from >>> ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() >>> because they don't generate assembly code. It also removes the >>> StubCodeMark from generate_throw_exception() because it doesn't really >>> generate a plain stub but a runtime stub for which the JVMT dynamic >>> code event is already generated by RuntimeStub::new_runtime_stub() -> >>> CodeBlob::trace_new_stub() -> >>> JvmtiExport::post_dynamic_code_generated(). >>> >>> Thank you and best regards, >>> Volker >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jul 14 22:56:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jul 2014 08:56:42 +1000 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: <53C3BA6B.70600@oracle.com> References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> <53C2F8A5.7050006@oracle.com> <53C3BA6B.70600@oracle.com> Message-ID: <53C4602A.90505@oracle.com> All changes (hotspot and top-level) are now in the jdk9/hs-rt forest. David On 14/07/2014 9:09 PM, David Holmes wrote: > On 14/07/2014 7:44 PM, Volker Simonis wrote: >> On Sun, Jul 13, 2014 at 11:22 PM, David Holmes >> wrote: >>> Hi Volker, >>> >>> Just discovered you didn't quite pick up on all of my change - the >>> ARM entry >>> is to be deleted. Only the open platforms need to be listed: >>> >>> >>>>> # No SA Support for IA64 or zero >>>>> ADD_SA_BINARIES/ia64 = >>>>> ADD_SA_BINARIES/zero = >>> >> >> OK, but then I also remove IA64 as it isn't an open platform either: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v4/ > > Yes good point. ia64 should be eradicated from the build system :) > > I will put this altogether in the AM. > >> I've also added Vladimir as reviewer. > > Great > > Thanks, > David > > >> Thank you and best regards, >> Volker >> >> >>> Thanks, >>> David >>> >>> On 11/07/2014 9:54 PM, Volker Simonis wrote: >>>> >>>> On Fri, Jul 11, 2014 at 6:36 AM, David Holmes >>>> wrote: >>>>> >>>>> Hi Volker, >>>>> >>>>> >>>>> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> thanks for looking at this. Here's my new version of the change with >>>>>> some of your suggestions applied: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >>>>> >>>>> >>>>> >>>>> I have a simpler counter proposal (also default -> DEFAULT as that >>>>> seems >>>>> to >>>>> be the style): >>>>> >>>>> # Serviceability Binaries >>>>> >>>>> ADD_SA_BINARIES/DEFAULT = >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >>>>> >>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>> >>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>> ADD_SA_BINARIES/DEFAULT += >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>> else >>>>> ADD_SA_BINARIES/DEFAULT += >>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>> endif >>>>> endif >>>>> >>>>> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >>>>> >>>>> >>>>> # No SA Support for IA64 or zero >>>>> ADD_SA_BINARIES/ia64 = >>>>> ADD_SA_BINARIES/zero = >>>>> >>>>> --- >>>>> >>>>> The open logic only has to worry about open platforms. The custom >>>>> makefile >>>>> can accept the default or override as it desires. >>>>> >>>>> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) >>>>> but the >>>>> above is simple and clear. >>>>> >>>>> Ok? >>>>> >>>> >>>> Perfect! >>>> >>>> Here's the new webrev with your proposed changes (tested on >>>> Linux/x86_64 and ppc64): >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 >>>> >>>> Thanks for sponsoring, >>>> Volker >>>> >>>>> I'll sponsor this one of course (so its safe for other reviewers to >>>>> jump >>>>> in >>>>> now :) ). >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> >>>>>> Please find more information inline: >>>>>> >>>>>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Volker, >>>>>>> >>>>>>> Comments below where you might expect them :) >>>>>>> >>>>>>> >>>>>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> could someone please review and sponsor the following change which >>>>>>>> does some preliminary work for enabling the SA agent on >>>>>>>> Linux/PPC64: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>>>>> >>>>>>>> Details: >>>>>>>> >>>>>>>> Currently, we don't support the SA agent on Linux/PPC64. This >>>>>>>> change >>>>>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>>>>> and sa-jdi.jar) will be correctly build and copied into the >>>>>>>> resulting >>>>>>>> jdk images. >>>>>>>> >>>>>>>> This change also contains some small fixes in sa-jdi.jar to >>>>>>>> correctly >>>>>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>>>>> >>>>>>>> One thing which require special attention are the changes in >>>>>>>> make/linux/makefiles/defs.make which may touch the closed ppc >>>>>>>> port. In >>>>>>>> my change I've simply added 'ppc' to the list of supported >>>>>>>> architectures, but this may break the 32-bit ppc build. I think the >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It wouldn't break it but I was expecting to see ppc64 here. >>>>>>> >>>>>> >>>>>> The problem is that currently the decision if the SA agent will be >>>>>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>>>>> architecture' (i.e. x86 or sparc) so there's no easy way to choose >>>>>> the >>>>>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>>>>> its 32-bit counterpart (i.e. i386 or ppc). >>>>>> >>>>>> The only possibility with the current solution would be to only >>>>>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>>>>> that wouldn't make the code nicer either:) >>>>>> >>>>>>> >>>>>>>> current code is to verbose and error prone anyway. It would be >>>>>>>> better >>>>>>>> to have something like: >>>>>>>> >>>>>>>> ADD_SA_BINARIES = >>>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>>>>> >>>>>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>>>> ADD_SA_BINARIES += >>>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>>>>> else >>>>>>>> ADD_SA_BINARIES += >>>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>>>>> endif >>>>>>>> endif >>>>>>>> >>>>>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>>>>> ppc64)) >>>>>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> You wouldn't need/want the $(HS_ARCH) there. >>>>>>> >>>>>> >>>>>> Sorry, that was a type of course. It should read: >>>>>> >>>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc >>>>>> sparcv9 >>>>>> ppc64)) >>>>>> EXPORT_LIST += $(ADD_SA_BINARIES) >>>>>> >>>>>> But that's not necessary now anymore (see new version below). >>>>>> >>>>>>> >>>>>>>> endif >>>>>>>> >>>>>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>>>>> various definitions for the different platforms are equal >>>>>>>> anyway). But >>>>>>>> again this may affect other closed ports so please advise which >>>>>>>> solution you'd prefer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The above is problematic for customizations. An alternative would >>>>>>> be to >>>>>>> set >>>>>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>>>>> >>>>>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>>>>> # No SA Support for IA64 or zero >>>>>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>>>>> ADD_SA_BINARIES/$(ARCH) = >>>>>>> >>>>>>> Each ARCH handled elsewhere would then still set >>>>>>> ADD_SA_BINARIES/$(ARCH) >>>>>>> if >>>>>>> needed. >>>>>>> >>>>>>> Does that seem reasonable? >>>>>>> >>>>>> >>>>>> The problem with using ARCH is that it is not "reliable" in the sens >>>>>> that its value differs for top-level and hotspot-only makes. See >>>>>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>>>>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>>>>> build". >>>>>> >>>>>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>>>>> idea. I've updated the patch accordingly and think that the new >>>>>> solution is a good compromise between readability and not touching >>>>>> existing/closed part. >>>>>> >>>>>> Are you fine with the new version at >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>>>>> >>>>>>> >>>>>>>> Notice that this change also requires a tiny fix in the top-level >>>>>>>> repository which must be pushed AFTER this change. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can you elaborate please? >>>>>>> >>>>>> >>>>>> I've also submitted the corresponding top-level repository change for >>>>>> review which expects to find the SA agent libraries on Linux/ppc64 in >>>>>> order to copy them into the image directory: >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>>>>> >>>>>> But once that will be pushed, the build will fail if these HS changes >>>>>> will not be in place to actually build the libraries. >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>>> >>>>>>> >>>>> >>> From jeremymanson at google.com Tue Jul 15 06:54:06 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 14 Jul 2014 23:54:06 -0700 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: <53C10681.1070303@oracle.com> References: <53BFB86C.4040403@oracle.com> <53C10681.1070303@oracle.com> Message-ID: Hi Jaroslav, I see. Thanks for the clarification. Since it has already gone in, I won't bother to check the performance difference, but I would think that that approach would suffer roughly as much from object instantiation woes, because it constructs lots of extra String objects (to get the method tag). Jeremy On Sat, Jul 12, 2014 at 2:57 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > On 07/11/2014 11:28 PM, Jeremy Manson wrote: > >> Hi Jaroslav, >> >> I haven't written many Streams yet, so perhaps I'm missing something >> obvious / well-known. Streams can replace the original code in an >> obvious way (filter the elements of list based on whether they are >> contained in map.values()), but I'm not sure how the filter operation >> becomes O(1) unless we build the HashSet? >> > > Probably I should have been more explicit about this. > > The map keys (a set) are derived from the map values by concatenating the > method name with the method signature. Utilizing this you can then come up > with a code like this: > > return allMethods().stream() > .filter((m) -> map.keySet().contains(getMethodTag(m))) > .collect(Collectors.toList()); > > "getMethodTag(method)" is the function used to generate the hash key from > a Method instance (to be extracted from the current source code). > > But we would need a benchmark to figure out which construct actually > performs better (the algorithmic complexity is the same). > > -JB- > > >> Jeremy >> >> >> On Fri, Jul 11, 2014 at 3:11 AM, Jaroslav Bachorik >> > >> wrote: >> >> Hi Jeremy, >> >> >> On 05/08/2014 08:56 PM, Jeremy Manson wrote: >> >> I'm testing out my newly acquired OpenJDK authorship with >> something >> simple. If I did this wrong, I apologize. >> >> Basically, the debugger becomes very slow if there are a lot of >> methods >> in a class. This can happen (O(thousands)) if you are using a >> code >> generation tool. >> >> http://cr.openjdk.java.net/~__jmanson/8042778/webrev.00/ >> >> >> >> >> Have you considered using streams to avoid creation of an additional >> HashSet? >> >> -JB- >> >> >> >> Reviews from reviewers and committing from committers would be >> appreciated. Thanks! >> >> Jeremy >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jul 15 07:37:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Jul 2014 09:37:12 +0200 Subject: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64 In-Reply-To: <53C4602A.90505@oracle.com> References: <53BDFD5D.4050908@oracle.com> <53BF69DC.9010305@oracle.com> <53C2F8A5.7050006@oracle.com> <53C3BA6B.70600@oracle.com> <53C4602A.90505@oracle.com> Message-ID: Great! Thanks a lot, Volker On Tue, Jul 15, 2014 at 12:56 AM, David Holmes wrote: > All changes (hotspot and top-level) are now in the jdk9/hs-rt forest. > > David > > > On 14/07/2014 9:09 PM, David Holmes wrote: >> >> On 14/07/2014 7:44 PM, Volker Simonis wrote: >>> >>> On Sun, Jul 13, 2014 at 11:22 PM, David Holmes >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> Just discovered you didn't quite pick up on all of my change - the >>>> ARM entry >>>> is to be deleted. Only the open platforms need to be listed: >>>> >>>> >>>>>> # No SA Support for IA64 or zero >>>>>> ADD_SA_BINARIES/ia64 = >>>>>> ADD_SA_BINARIES/zero = >>>> >>>> >>> >>> OK, but then I also remove IA64 as it isn't an open platform either: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v4/ >> >> >> Yes good point. ia64 should be eradicated from the build system :) >> >> I will put this altogether in the AM. >> >>> I've also added Vladimir as reviewer. >> >> >> Great >> >> Thanks, >> David >> >> >>> Thank you and best regards, >>> Volker >>> >>> >>>> Thanks, >>>> David >>>> >>>> On 11/07/2014 9:54 PM, Volker Simonis wrote: >>>>> >>>>> >>>>> On Fri, Jul 11, 2014 at 6:36 AM, David Holmes >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Volker, >>>>>> >>>>>> >>>>>> On 10/07/2014 8:12 PM, Volker Simonis wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> thanks for looking at this. Here's my new version of the change with >>>>>>> some of your suggestions applied: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I have a simpler counter proposal (also default -> DEFAULT as that >>>>>> seems >>>>>> to >>>>>> be the style): >>>>>> >>>>>> # Serviceability Binaries >>>>>> >>>>>> ADD_SA_BINARIES/DEFAULT = >>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) \ >>>>>> >>>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>>> >>>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>> ADD_SA_BINARIES/DEFAULT += >>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>>> else >>>>>> ADD_SA_BINARIES/DEFAULT += >>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>>> endif >>>>>> endif >>>>>> >>>>>> ADD_SA_BINARIES/$(HS_ARCH) = $(ADD_SA_BINARIES/DEFAULT) >>>>>> >>>>>> >>>>>> # No SA Support for IA64 or zero >>>>>> ADD_SA_BINARIES/ia64 = >>>>>> ADD_SA_BINARIES/zero = >>>>>> >>>>>> --- >>>>>> >>>>>> The open logic only has to worry about open platforms. The custom >>>>>> makefile >>>>>> can accept the default or override as it desires. >>>>>> >>>>>> I thought about conditionally setting ADD_SA_BINARIES/$(HS_ARCH) >>>>>> but the >>>>>> above is simple and clear. >>>>>> >>>>>> Ok? >>>>>> >>>>> >>>>> Perfect! >>>>> >>>>> Here's the new webrev with your proposed changes (tested on >>>>> Linux/x86_64 and ppc64): >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v3 >>>>> >>>>> Thanks for sponsoring, >>>>> Volker >>>>> >>>>>> I'll sponsor this one of course (so its safe for other reviewers to >>>>>> jump >>>>>> in >>>>>> now :) ). >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>>> Please find more information inline: >>>>>>> >>>>>>> On Thu, Jul 10, 2014 at 4:41 AM, David Holmes >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Volker, >>>>>>>> >>>>>>>> Comments below where you might expect them :) >>>>>>>> >>>>>>>> >>>>>>>> On 10/07/2014 3:36 AM, Volker Simonis wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could someone please review and sponsor the following change which >>>>>>>>> does some preliminary work for enabling the SA agent on >>>>>>>>> Linux/PPC64: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049715 >>>>>>>>> >>>>>>>>> Details: >>>>>>>>> >>>>>>>>> Currently, we don't support the SA agent on Linux/PPC64. This >>>>>>>>> change >>>>>>>>> fixes the buildsystem such that the SA libraries (i.e. libsaproc.so >>>>>>>>> and sa-jdi.jar) will be correctly build and copied into the >>>>>>>>> resulting >>>>>>>>> jdk images. >>>>>>>>> >>>>>>>>> This change also contains some small fixes in sa-jdi.jar to >>>>>>>>> correctly >>>>>>>>> detect Linux/PPC64 as supported SA platform. (The actual >>>>>>>>> implementation of the Linux/PPC64 specific code will be handled by >>>>>>>>> "8049716 PPC64: Implement SA on Linux/PPC64" - >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716). >>>>>>>>> >>>>>>>>> One thing which require special attention are the changes in >>>>>>>>> make/linux/makefiles/defs.make which may touch the closed ppc >>>>>>>>> port. In >>>>>>>>> my change I've simply added 'ppc' to the list of supported >>>>>>>>> architectures, but this may break the 32-bit ppc build. I think the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It wouldn't break it but I was expecting to see ppc64 here. >>>>>>>> >>>>>>> >>>>>>> The problem is that currently the decision if the SA agent will be >>>>>>> build is based on the value of HS_ARCH. But HS_ARCH is the 'basic >>>>>>> architecture' (i.e. x86 or sparc) so there's no easy way to choose >>>>>>> the >>>>>>> SA agent for only a 64-bit platform (like ppc64 or amd64) and not for >>>>>>> its 32-bit counterpart (i.e. i386 or ppc). >>>>>>> >>>>>>> The only possibility with the current solution would be to only >>>>>>> conditionally set ADD_SA_BINARIES/ppc if ARCH_DATA_MODEL is 64. But >>>>>>> that wouldn't make the code nicer either:) >>>>>>> >>>>>>>> >>>>>>>>> current code is to verbose and error prone anyway. It would be >>>>>>>>> better >>>>>>>>> to have something like: >>>>>>>>> >>>>>>>>> ADD_SA_BINARIES = >>>>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.$(LIBRARY_SUFFIX) >>>>>>>>> $(EXPORT_LIB_DIR)/sa-jdi.jar >>>>>>>>> >>>>>>>>> ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) >>>>>>>>> ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>>>>>> ADD_SA_BINARIES += >>>>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.diz >>>>>>>>> else >>>>>>>>> ADD_SA_BINARIES += >>>>>>>>> $(EXPORT_JRE_LIB_ARCH_DIR)/libsaproc.debuginfo >>>>>>>>> endif >>>>>>>>> endif >>>>>>>>> >>>>>>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc sparcv9 >>>>>>>>> ppc64)) >>>>>>>>> EXPORT_LIST += $(ADD_SA_BINARIES/$(HS_ARCH)) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You wouldn't need/want the $(HS_ARCH) there. >>>>>>>> >>>>>>> >>>>>>> Sorry, that was a type of course. It should read: >>>>>>> >>>>>>> ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586 sparc >>>>>>> sparcv9 >>>>>>> ppc64)) >>>>>>> EXPORT_LIST += $(ADD_SA_BINARIES) >>>>>>> >>>>>>> But that's not necessary now anymore (see new version below). >>>>>>> >>>>>>>> >>>>>>>>> endif >>>>>>>>> >>>>>>>>> With this solution we only define ADD_SA_BINARIES once (because the >>>>>>>>> various definitions for the different platforms are equal >>>>>>>>> anyway). But >>>>>>>>> again this may affect other closed ports so please advise which >>>>>>>>> solution you'd prefer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The above is problematic for customizations. An alternative would >>>>>>>> be to >>>>>>>> set >>>>>>>> ADD_SA_BINARIES/default once with all the file names. Then: >>>>>>>> >>>>>>>> ADD_SA_BINARIES/$(ARCH) = $(ADD_SA_BINARIES/default) >>>>>>>> # No SA Support for IA64 or zero >>>>>>>> ifneq (, $(findstring $(ARCH), ia64, zero)) >>>>>>>> ADD_SA_BINARIES/$(ARCH) = >>>>>>>> >>>>>>>> Each ARCH handled elsewhere would then still set >>>>>>>> ADD_SA_BINARIES/$(ARCH) >>>>>>>> if >>>>>>>> needed. >>>>>>>> >>>>>>>> Does that seem reasonable? >>>>>>>> >>>>>>> >>>>>>> The problem with using ARCH is that it is not "reliable" in the sens >>>>>>> that its value differs for top-level and hotspot-only makes. See >>>>>>> "8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for >>>>>>> hotspot ARCH" and my fix "8048232: Fix for 8046471 breaks PPC64 >>>>>>> build". >>>>>>> >>>>>>> But using ADD_SA_BINARIES/default to save redundant lines is a good >>>>>>> idea. I've updated the patch accordingly and think that the new >>>>>>> solution is a good compromise between readability and not touching >>>>>>> existing/closed part. >>>>>>> >>>>>>> Are you fine with the new version at >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715.v2 ? >>>>>>> >>>>>>>> >>>>>>>>> Notice that this change also requires a tiny fix in the top-level >>>>>>>>> repository which must be pushed AFTER this change. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Can you elaborate please? >>>>>>>> >>>>>>> >>>>>>> I've also submitted the corresponding top-level repository change for >>>>>>> review which expects to find the SA agent libraries on Linux/ppc64 in >>>>>>> order to copy them into the image directory: >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049715_top_level/ >>>>>>> >>>>>>> But once that will be pushed, the build will fail if these HS changes >>>>>>> will not be in place to actually build the libraries. >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker >>>>>>>>> >>>>>>>> >>>>>> >>>> > From volker.simonis at gmail.com Tue Jul 15 08:48:16 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Jul 2014 10:48:16 +0200 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: <53C43F1E.2030805@oracle.com> References: <53BC1237.2060006@oracle.com> <53C43F1E.2030805@oracle.com> Message-ID: On Mon, Jul 14, 2014 at 10:35 PM, serguei.spitsyn at oracle.com wrote: > Hi Volker, > > It looks good in general. > > But I don't understand all the details. > For instance, your email description of the fix tells that the the event is > posted by: > > RuntimeStub::new_runtime_stub() -> CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated() > > I see the new_runtime_stub() call in the generate_throw_exception() but > there is no such call > in the generate_icache_flush() and generate_handler_for_unsafe_access() . > > Probably, the StubCodeMark just needs to be removed there. > Could you, please, explain this a little bit? > Hi Serguei, Thank you for looking at my change. I tried to explain your questions in my initial mail but maybe I wasn't clear enough: - in generate_icache_flush() and generate_verify_oop() we DO NOT GENERATE any stub code. We don't use dynamically generated stubs on ppc64 for flushing the icache or verifying oops but call C-functions instead. So there's no need to generate post_dynamic_code_generated() events for them and also no need for a StubCodeMark. - for generate_throw_exception() we dynamically generate a runtime stub instead of an simple stub and for runtime stubs the JVMT dynamic code event is already generated by RuntimeStub::new_runtime_stub() -> CodeBlob::trace_new_stub() -> JvmtiExport::post_dynamic_code_generated(). This is exactly the way how it works on other CPU architectures. The usage of a StubCodeMark in generate_throw_exception() was simply a "day one" bug in the ppc64 port. - I haven't changed generate_handler_for_unsafe_access() so I don't actually understand your concerns. generate_handler_for_unsafe_access() correctly contains a StubCodeMark because it dynamically generates stub code - even if it is just the output of a "not yet implemented" message. Regards, Volker > We also need someone from the compiler team to look at this. > I also included into the cc-list Oleg, who recently touched this area. > > Thanks, > Serguei > > > > On 7/14/14 11:24 AM, Volker Simonis wrote: > > Hi everybody, > > can somebody PLEASE review and sponsor this tiny, ppc64-only change. > > Thanks, > Volker > > > On Tue, Jul 8, 2014 at 5:45 PM, Daniel D. Daugherty > wrote: > > Adding the Serviceability Team since JVM/TI belongs to them. > > Dan > > > > On 7/8/14 9:41 AM, Volker Simonis wrote: > > Hi, > > could somebody please review and push the following small, PPC64-only > change to any of the hs team repositories: > > http://cr.openjdk.java.net/~simonis/webrevs/8049441/ > https://bugs.openjdk.java.net/browse/JDK-8049441 > > Background: > > For some stubs we actually do not really generate code on PPC64 but > instead we use a native C-function with inline-assembly. If the > generators of these stubs contain a StubCodeMark, they will trigger > JvmtiExport::post_dynamic_code_generated_internal events with a zero > length code size. These events may fool clients like Oprofile which > register for these events (thanks to Maynard Johnson who reported this > - see > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). > > This change simply removes the StubCodeMark from > ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() > because they don't generate assembly code. It also removes the > StubCodeMark from generate_throw_exception() because it doesn't really > generate a plain stub but a runtime stub for which the JVMT dynamic > code event is already generated by RuntimeStub::new_runtime_stub() -> > CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated(). > > Thank you and best regards, > Volker > > From serguei.spitsyn at oracle.com Tue Jul 15 09:09:39 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 15 Jul 2014 02:09:39 -0700 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: References: <53BC1237.2060006@oracle.com> <53C43F1E.2030805@oracle.com> Message-ID: <53C4EFD3.7000609@oracle.com> On 7/15/14 1:48 AM, Volker Simonis wrote: > On Mon, Jul 14, 2014 at 10:35 PM, serguei.spitsyn at oracle.com > wrote: >> Hi Volker, >> >> It looks good in general. >> >> But I don't understand all the details. >> For instance, your email description of the fix tells that the the event is >> posted by: >> >> RuntimeStub::new_runtime_stub() -> CodeBlob::trace_new_stub() -> >> JvmtiExport::post_dynamic_code_generated() >> >> I see the new_runtime_stub() call in the generate_throw_exception() but >> there is no such call >> in the generate_icache_flush() and generate_handler_for_unsafe_access() . >> >> Probably, the StubCodeMark just needs to be removed there. >> Could you, please, explain this a little bit? >> > Hi Serguei, > > Thank you for looking at my change. I tried to explain your questions > in my initial mail but maybe I wasn't clear enough: > > - in generate_icache_flush() and generate_verify_oop() we DO NOT > GENERATE any stub code. We don't use dynamically generated stubs on > ppc64 for flushing the icache or verifying oops but call C-functions > instead. So there's no need to generate post_dynamic_code_generated() > events for them and also no need for a StubCodeMark. > > - for generate_throw_exception() we dynamically generate a runtime > stub instead of an simple stub and for runtime stubs the JVMT dynamic > code event is already generated by RuntimeStub::new_runtime_stub() -> > CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated(). This is exactly the way > how it works on other CPU architectures. The usage of a StubCodeMark > in generate_throw_exception() was simply a "day one" bug in the ppc64 > port. Thank you for the extra details! I asked for that as my knowledge in this area is limited. The fix looks good to me. I can be a sponsor for integration if needed. But a Review is still required. > > - I haven't changed generate_handler_for_unsafe_access() so I don't > actually understand your concerns. I accidentally copied a wrong name. Sorry. I had to copy: generate_verify_oop(). Thanks, Serguei > generate_handler_for_unsafe_access() correctly contains a StubCodeMark > because it dynamically generates stub code - even if it is just the > output of a "not yet implemented" message. > > Regards, > Volker > >> We also need someone from the compiler team to look at this. >> I also included into the cc-list Oleg, who recently touched this area. >> >> Thanks, >> Serguei >> >> >> >> On 7/14/14 11:24 AM, Volker Simonis wrote: >> >> Hi everybody, >> >> can somebody PLEASE review and sponsor this tiny, ppc64-only change. >> >> Thanks, >> Volker >> >> >> On Tue, Jul 8, 2014 at 5:45 PM, Daniel D. Daugherty >> wrote: >> >> Adding the Serviceability Team since JVM/TI belongs to them. >> >> Dan >> >> >> >> On 7/8/14 9:41 AM, Volker Simonis wrote: >> >> Hi, >> >> could somebody please review and push the following small, PPC64-only >> change to any of the hs team repositories: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049441/ >> https://bugs.openjdk.java.net/browse/JDK-8049441 >> >> Background: >> >> For some stubs we actually do not really generate code on PPC64 but >> instead we use a native C-function with inline-assembly. If the >> generators of these stubs contain a StubCodeMark, they will trigger >> JvmtiExport::post_dynamic_code_generated_internal events with a zero >> length code size. These events may fool clients like Oprofile which >> register for these events (thanks to Maynard Johnson who reported this >> - see >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). >> >> This change simply removes the StubCodeMark from >> ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() >> because they don't generate assembly code. It also removes the >> StubCodeMark from generate_throw_exception() because it doesn't really >> generate a plain stub but a runtime stub for which the JVMT dynamic >> code event is already generated by RuntimeStub::new_runtime_stub() -> >> CodeBlob::trace_new_stub() -> >> JvmtiExport::post_dynamic_code_generated(). >> >> Thank you and best regards, >> Volker >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue Jul 15 09:45:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Jul 2014 11:45:20 +0200 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: <53C4EFD3.7000609@oracle.com> References: <53BC1237.2060006@oracle.com> <53C43F1E.2030805@oracle.com> <53C4EFD3.7000609@oracle.com> Message-ID: Hi Serguei, thanks for sponsoring! So just waiting for another reviewer. Anybody volunteers:) Regards, Volker On Tue, Jul 15, 2014 at 11:09 AM, serguei.spitsyn at oracle.com wrote: > On 7/15/14 1:48 AM, Volker Simonis wrote: > > On Mon, Jul 14, 2014 at 10:35 PM, serguei.spitsyn at oracle.com > wrote: > > Hi Volker, > > It looks good in general. > > But I don't understand all the details. > For instance, your email description of the fix tells that the the event is > posted by: > > RuntimeStub::new_runtime_stub() -> CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated() > > I see the new_runtime_stub() call in the generate_throw_exception() but > there is no such call > in the generate_icache_flush() and generate_handler_for_unsafe_access() . > > Probably, the StubCodeMark just needs to be removed there. > Could you, please, explain this a little bit? > > Hi Serguei, > > Thank you for looking at my change. I tried to explain your questions > in my initial mail but maybe I wasn't clear enough: > > - in generate_icache_flush() and generate_verify_oop() we DO NOT > GENERATE any stub code. We don't use dynamically generated stubs on > ppc64 for flushing the icache or verifying oops but call C-functions > instead. So there's no need to generate post_dynamic_code_generated() > events for them and also no need for a StubCodeMark. > > - for generate_throw_exception() we dynamically generate a runtime > stub instead of an simple stub and for runtime stubs the JVMT dynamic > code event is already generated by RuntimeStub::new_runtime_stub() -> > CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated(). This is exactly the way > how it works on other CPU architectures. The usage of a StubCodeMark > in generate_throw_exception() was simply a "day one" bug in the ppc64 > port. > > > Thank you for the extra details! > I asked for that as my knowledge in this area is limited. > > The fix looks good to me. > I can be a sponsor for integration if needed. > But a Review is still required. > > > > - I haven't changed generate_handler_for_unsafe_access() so I don't > actually understand your concerns. > > > I accidentally copied a wrong name. Sorry. > I had to copy: generate_verify_oop(). > > Thanks, > Serguei > > generate_handler_for_unsafe_access() correctly contains a StubCodeMark > because it dynamically generates stub code - even if it is just the > output of a "not yet implemented" message. > > Regards, > Volker > > We also need someone from the compiler team to look at this. > I also included into the cc-list Oleg, who recently touched this area. > > Thanks, > Serguei > > > > On 7/14/14 11:24 AM, Volker Simonis wrote: > > Hi everybody, > > can somebody PLEASE review and sponsor this tiny, ppc64-only change. > > Thanks, > Volker > > > On Tue, Jul 8, 2014 at 5:45 PM, Daniel D. Daugherty > wrote: > > Adding the Serviceability Team since JVM/TI belongs to them. > > Dan > > > > On 7/8/14 9:41 AM, Volker Simonis wrote: > > Hi, > > could somebody please review and push the following small, PPC64-only > change to any of the hs team repositories: > > http://cr.openjdk.java.net/~simonis/webrevs/8049441/ > https://bugs.openjdk.java.net/browse/JDK-8049441 > > Background: > > For some stubs we actually do not really generate code on PPC64 but > instead we use a native C-function with inline-assembly. If the > generators of these stubs contain a StubCodeMark, they will trigger > JvmtiExport::post_dynamic_code_generated_internal events with a zero > length code size. These events may fool clients like Oprofile which > register for these events (thanks to Maynard Johnson who reported this > - see > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). > > This change simply removes the StubCodeMark from > ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() > because they don't generate assembly code. It also removes the > StubCodeMark from generate_throw_exception() because it doesn't really > generate a plain stub but a runtime stub for which the JVMT dynamic > code event is already generated by RuntimeStub::new_runtime_stub() -> > CodeBlob::trace_new_stub() -> > JvmtiExport::post_dynamic_code_generated(). > > Thank you and best regards, > Volker > > > From daniel.daugherty at oracle.com Tue Jul 15 14:00:47 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Jul 2014 08:00:47 -0600 Subject: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs In-Reply-To: <53BC1237.2060006@oracle.com> References: <53BC1237.2060006@oracle.com> Message-ID: <53C5340F.80109@oracle.com> > http://cr.openjdk.java.net/~simonis/webrevs/8049441/ src/cpu/ppc/vm/icache_ppc.cpp No comments. src/cpu/ppc/vm/stubGenerator_ppc.cpp No comments. Thumbs up. Dan On 7/8/14 9:45 AM, Daniel D. Daugherty wrote: > Adding the Serviceability Team since JVM/TI belongs to them. > > Dan > > > On 7/8/14 9:41 AM, Volker Simonis wrote: >> Hi, >> >> could somebody please review and push the following small, PPC64-only >> change to any of the hs team repositories: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049441/ >> https://bugs.openjdk.java.net/browse/JDK-8049441 >> >> Background: >> >> For some stubs we actually do not really generate code on PPC64 but >> instead we use a native C-function with inline-assembly. If the >> generators of these stubs contain a StubCodeMark, they will trigger >> JvmtiExport::post_dynamic_code_generated_internal events with a zero >> length code size. These events may fool clients like Oprofile which >> register for these events (thanks to Maynard Johnson who reported this >> - see >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-June/002032.html). >> >> This change simply removes the StubCodeMark from >> ICacheStubGenerator::generate_icache_flush() and generate_verify_oop() >> because they don't generate assembly code. It also removes the >> StubCodeMark from generate_throw_exception() because it doesn't really >> generate a plain stub but a runtime stub for which the JVMT dynamic >> code event is already generated by RuntimeStub::new_runtime_stub() -> >> CodeBlob::trace_new_stub() -> >> JvmtiExport::post_dynamic_code_generated(). >> >> Thank you and best regards, >> Volker > > > > From jaroslav.bachorik at oracle.com Fri Jul 18 11:44:42 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 18 Jul 2014 13:44:42 +0200 Subject: RFR 8035829: [parfait] JNI exception pending in jdk/src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Message-ID: <53C908AA.5080800@oracle.com> Please, review the following fix Issue : https://bugs.openjdk.java.net/browse/JDK-8035829 Webrev: http://cr.openjdk.java.net/~jbachorik/8035829/webrev.00 This issue has been identified by Parfait static code analysis tool - there are missing checks for pending Java exceptions thrown from a native code. Any time a function can throw an exception the calling code must check for this eventuality. Thanks, -JB- From sundararajan.athijegannathan at oracle.com Fri Jul 18 11:52:40 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 18 Jul 2014 17:22:40 +0530 Subject: RFR 8035829: [parfait] JNI exception pending in jdk/src/windows/native/sun/tools/attach/WindowsVirtualMachine.c In-Reply-To: <53C908AA.5080800@oracle.com> References: <53C908AA.5080800@oracle.com> Message-ID: <53C90A88.8050403@oracle.com> +1 On Friday 18 July 2014 05:14 PM, Jaroslav Bachorik wrote: > Please, review the following fix > > Issue : https://bugs.openjdk.java.net/browse/JDK-8035829 > Webrev: http://cr.openjdk.java.net/~jbachorik/8035829/webrev.00 > > This issue has been identified by Parfait static code analysis tool - > there are missing checks for pending Java exceptions thrown from a > native code. Any time a function can throw an exception the calling > code must check for this eventuality. > > Thanks, > > -JB- From kevin.walls at oracle.com Fri Jul 18 12:02:10 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 18 Jul 2014 13:02:10 +0100 Subject: RR(S) 8049684: pstack crashes on java core dump Message-ID: <53C90CC2.5020602@oracle.com> Hi, May I get a review of this little change: pstack can crash on a Java core, where the core is transported from one machine to another, and they have different JDKs but in the same directory location. So pstack does find libjvm etc, and does find libjvm_db.so (but clearly symbols are not going to be good). libjvm_db.c's parse_vmstructs fails early, after the call to libproc's ps_pglobal_lookup(), which is before it has cleared its VMStructEntry, which it will then test for non-null pointers in a few fields, and free them (bad). Seen on Solaris, though the same problem is in the bsd code. bug https://bugs.openjdk.java.net/browse/JDK-8049684 webrev http://cr.openjdk.java.net/~kevinw/8049684/webrev.01/ I can reproduce this with a script, but it is time-consuming to copy/unpack different JDKs in place, generate a core, replace the JDK, run pstack. Does not seem appropriate to add as a regression test given the simple change. Thanks Kevin From kevin.walls at oracle.com Fri Jul 18 12:03:06 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 18 Jul 2014 13:03:06 +0100 Subject: RFR 8035829: [parfait] JNI exception pending in jdk/src/windows/native/sun/tools/attach/WindowsVirtualMachine.c In-Reply-To: <53C908AA.5080800@oracle.com> References: <53C908AA.5080800@oracle.com> Message-ID: <53C90CFA.6000202@oracle.com> Hi, Looks good to me, Regards Kevin On 18/07/14 12:44, Jaroslav Bachorik wrote: > Please, review the following fix > > Issue : https://bugs.openjdk.java.net/browse/JDK-8035829 > Webrev: http://cr.openjdk.java.net/~jbachorik/8035829/webrev.00 > > This issue has been identified by Parfait static code analysis tool - > there are missing checks for pending Java exceptions thrown from a > native code. Any time a function can throw an exception the calling > code must check for this eventuality. > > Thanks, > > -JB- From sundararajan.athijegannathan at oracle.com Fri Jul 18 12:04:56 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 18 Jul 2014 17:34:56 +0530 Subject: RR(S) 8049684: pstack crashes on java core dump In-Reply-To: <53C90CC2.5020602@oracle.com> References: <53C90CC2.5020602@oracle.com> Message-ID: <53C90D68.2010309@oracle.com> +1 On Friday 18 July 2014 05:32 PM, Kevin Walls wrote: > Hi, > > May I get a review of this little change: > > pstack can crash on a Java core, where the core is transported from > one machine to another, and they have different JDKs but in the same > directory location. So pstack does find libjvm etc, and does find > libjvm_db.so (but clearly symbols are not going to be good). > libjvm_db.c's parse_vmstructs fails early, after the call to libproc's > ps_pglobal_lookup(), which is before it has cleared its VMStructEntry, > which it will then test for non-null pointers in a few fields, and > free them (bad). > > Seen on Solaris, though the same problem is in the bsd code. > > bug > https://bugs.openjdk.java.net/browse/JDK-8049684 > > webrev > http://cr.openjdk.java.net/~kevinw/8049684/webrev.01/ > > I can reproduce this with a script, but it is time-consuming to > copy/unpack different JDKs in place, generate a core, replace the JDK, > run pstack. Does not seem appropriate to add as a regression test > given the simple change. > > Thanks > Kevin > From serguei.spitsyn at oracle.com Fri Jul 18 22:22:24 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Jul 2014 15:22:24 -0700 Subject: RR(S) 8049684: pstack crashes on java core dump In-Reply-To: <53C90CC2.5020602@oracle.com> References: <53C90CC2.5020602@oracle.com> Message-ID: <53C99E20.50804@oracle.com> Hi Kevin, It looks good. Thank you fixing it! Thanks, Serguei On 7/18/14 5:02 AM, Kevin Walls wrote: > Hi, > > May I get a review of this little change: > > pstack can crash on a Java core, where the core is transported from > one machine to another, and they have different JDKs but in the same > directory location. So pstack does find libjvm etc, and does find > libjvm_db.so (but clearly symbols are not going to be good). > libjvm_db.c's parse_vmstructs fails early, after the call to libproc's > ps_pglobal_lookup(), which is before it has cleared its VMStructEntry, > which it will then test for non-null pointers in a few fields, and > free them (bad). > > Seen on Solaris, though the same problem is in the bsd code. > > bug > https://bugs.openjdk.java.net/browse/JDK-8049684 > > webrev > http://cr.openjdk.java.net/~kevinw/8049684/webrev.01/ > > I can reproduce this with a script, but it is time-consuming to > copy/unpack different JDKs in place, generate a core, replace the JDK, > run pstack. Does not seem appropriate to add as a regression test > given the simple change. > > Thanks > Kevin > From serguei.spitsyn at oracle.com Fri Jul 18 22:24:38 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Jul 2014 15:24:38 -0700 Subject: RFR 8035829: [parfait] JNI exception pending in jdk/src/windows/native/sun/tools/attach/WindowsVirtualMachine.c In-Reply-To: <53C908AA.5080800@oracle.com> References: <53C908AA.5080800@oracle.com> Message-ID: <53C99EA6.3080300@oracle.com> Looks good. Thanks, Serguei On 7/18/14 4:44 AM, Jaroslav Bachorik wrote: > Please, review the following fix > > Issue : https://bugs.openjdk.java.net/browse/JDK-8035829 > Webrev: http://cr.openjdk.java.net/~jbachorik/8035829/webrev.00 > > This issue has been identified by Parfait static code analysis tool - > there are missing checks for pending Java exceptions thrown from a > native code. Any time a function can throw an exception the calling > code must check for this eventuality. > > Thanks, > > -JB- From poonam.bajaj at oracle.com Mon Jul 21 09:29:44 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 21 Jul 2014 14:59:44 +0530 Subject: Review Request: JDK-8049881: jstack not working on core files Message-ID: <53CCDD88.90506@oracle.com> The changes for "8046282: SA update" introduced this bug. The following changes fix the failure. Bug: JDK-8049881 : jstack not working on core files Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ With these changes jstack works fine with the core files. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Mon Jul 21 10:01:49 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 21 Jul 2014 11:01:49 +0100 Subject: RR(S) 8049684: pstack crashes on java core dump In-Reply-To: <53C99E20.50804@oracle.com> References: <53C90CC2.5020602@oracle.com> <53C99E20.50804@oracle.com> Message-ID: <53CCE50D.7000102@oracle.com> Thanks Serguei, and thanks Sundar, -- Kevin On 18/07/14 23:22, serguei.spitsyn at oracle.com wrote: > Hi Kevin, > > It looks good. > Thank you fixing it! > > Thanks, > Serguei > > On 7/18/14 5:02 AM, Kevin Walls wrote: >> Hi, >> >> May I get a review of this little change: >> >> pstack can crash on a Java core, where the core is transported from >> one machine to another, and they have different JDKs but in the same >> directory location. So pstack does find libjvm etc, and does find >> libjvm_db.so (but clearly symbols are not going to be good). >> libjvm_db.c's parse_vmstructs fails early, after the call to >> libproc's ps_pglobal_lookup(), which is before it has cleared its >> VMStructEntry, which it will then test for non-null pointers in a few >> fields, and free them (bad). >> >> Seen on Solaris, though the same problem is in the bsd code. >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8049684 >> >> webrev >> http://cr.openjdk.java.net/~kevinw/8049684/webrev.01/ >> >> I can reproduce this with a script, but it is time-consuming to >> copy/unpack different JDKs in place, generate a core, replace the >> JDK, run pstack. Does not seem appropriate to add as a regression >> test given the simple change. >> >> Thanks >> Kevin >> > From david.holmes at oracle.com Mon Jul 21 12:22:30 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jul 2014 22:22:30 +1000 Subject: Review Request: JDK-8049881: jstack not working on core files In-Reply-To: <53CCDD88.90506@oracle.com> References: <53CCDD88.90506@oracle.com> Message-ID: <53CD0606.4050100@oracle.com> Hi Poonam, On 21/07/2014 7:29 PM, Poonam Bajaj wrote: > The changes for "8046282: SA update" introduced this bug. The following > changes fix the failure. > > Bug: JDK-8049881 : > jstack not working on core files > Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ > > With these changes jstack works fine with the core files. Minor nit: 58 try { 59 traceIDField = type.getField("_trace_id"); 60 } catch(Exception e) { 61 traceIDField = null; 62 } Line 61 isn't needed as the field is not assigned if the exception is thrown - hence it remains default initialized to null. Overall though this seems a bit kludgy - a field that doesn't exist in the OpenJDK shouldn't be making it's absence so obvious. David > Thanks, > Poonam From markus.gronlund at oracle.com Mon Jul 21 12:50:29 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Mon, 21 Jul 2014 05:50:29 -0700 (PDT) Subject: Review Request: JDK-8049881: jstack not working on core files In-Reply-To: <53CCDD88.90506@oracle.com> References: <53CCDD88.90506@oracle.com> Message-ID: <3ee0c0cc-1f5b-46f1-a13e-0b361f563d71@default> Hi Poonam, ? I think this looks good. ? Thanks for fixing it. ? Cheers Markus ? From: Poonam Bajaj Sent: den 21 juli 2014 11:30 To: serviceability-dev at openjdk.java.net Subject: Review Request: JDK-8049881: jstack not working on core files ? The changes for "8046282: SA update" introduced this bug. The following changes fix the failure. Bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8049881"JDK-8049881: jstack not working on core files Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ With these changes jstack works fine with the core files. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Mon Jul 21 12:55:20 2014 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Mon, 21 Jul 2014 05:55:20 -0700 (PDT) Subject: Review Request: JDK-8049881: jstack not working on core files In-Reply-To: <53CD0606.4050100@oracle.com> References: <53CCDD88.90506@oracle.com> <53CD0606.4050100@oracle.com> Message-ID: <580ae6b3-558a-4f0c-b3d1-2afae0812239@default> Hi David, I agree with your point about "absence". However, after some attempts by Poonam to do just that - it is apparent that SA does not allow for easy handling of this "absence" :-( This is one lesson learned from these fixes. I think we need to find a way to resolve this moving forward. In the meantime, I think this kludge is ok to fix the pressing problem. Cheers Markus -----Original Message----- From: David Holmes Sent: den 21 juli 2014 14:23 To: Poonam Bajaj; serviceability-dev at openjdk.java.net Subject: Re: Review Request: JDK-8049881: jstack not working on core files Hi Poonam, On 21/07/2014 7:29 PM, Poonam Bajaj wrote: > The changes for "8046282: SA update" introduced this bug. The > following changes fix the failure. > > Bug: JDK-8049881 : > jstack not working on core files > Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ > > With these changes jstack works fine with the core files. Minor nit: 58 try { 59 traceIDField = type.getField("_trace_id"); 60 } catch(Exception e) { 61 traceIDField = null; 62 } Line 61 isn't needed as the field is not assigned if the exception is thrown - hence it remains default initialized to null. Overall though this seems a bit kludgy - a field that doesn't exist in the OpenJDK shouldn't be making it's absence so obvious. David > Thanks, > Poonam From dmitry.samersoff at oracle.com Mon Jul 21 13:59:04 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 21 Jul 2014 17:59:04 +0400 Subject: Review Request: JDK-8049881: jstack not working on core files In-Reply-To: <53CCDD88.90506@oracle.com> References: <53CCDD88.90506@oracle.com> Message-ID: <53CD1CA8.7050703@oracle.com> Poonam, Looks good for me. I prefer to always put brackets after if (l. 117), but it's not required. -Dmitry On 2014-07-21 13:29, Poonam Bajaj wrote: > The changes for "8046282: SA update" introduced this bug. The following > changes fix the failure. > > Bug: JDK-8049881 : > jstack not working on core files > Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ > > With these changes jstack works fine with the core files. > > Thanks, > Poonam -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From david.holmes at oracle.com Mon Jul 21 22:17:36 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jul 2014 08:17:36 +1000 Subject: Review Request: JDK-8049881: jstack not working on core files In-Reply-To: <580ae6b3-558a-4f0c-b3d1-2afae0812239@default> References: <53CCDD88.90506@oracle.com> <53CD0606.4050100@oracle.com> <580ae6b3-558a-4f0c-b3d1-2afae0812239@default> Message-ID: <53CD9180.7080005@oracle.com> On 21/07/2014 10:55 PM, Markus Gr?nlund wrote: > Hi David, > > I agree with your point about "absence". > > However, after some attempts by Poonam to do just that - it is apparent that SA does not allow for easy handling of this "absence" :-( This is one lesson learned from these fixes. > > I think we need to find a way to resolve this moving forward. In the meantime, I think this kludge is ok to fix the pressing problem. Agreed. Thanks, David > Cheers > Markus > > > > > > -----Original Message----- > From: David Holmes > Sent: den 21 juli 2014 14:23 > To: Poonam Bajaj; serviceability-dev at openjdk.java.net > Subject: Re: Review Request: JDK-8049881: jstack not working on core files > > Hi Poonam, > > On 21/07/2014 7:29 PM, Poonam Bajaj wrote: >> The changes for "8046282: SA update" introduced this bug. The >> following changes fix the failure. >> >> Bug: JDK-8049881 : >> jstack not working on core files >> Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ >> >> With these changes jstack works fine with the core files. > > Minor nit: > > 58 try { > 59 traceIDField = type.getField("_trace_id"); > 60 } catch(Exception e) { > 61 traceIDField = null; > 62 } > > Line 61 isn't needed as the field is not assigned if the exception is thrown - hence it remains default initialized to null. > > Overall though this seems a bit kludgy - a field that doesn't exist in the OpenJDK shouldn't be making it's absence so obvious. > > David > >> Thanks, >> Poonam From poonam.bajaj at oracle.com Tue Jul 22 00:44:58 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 22 Jul 2014 06:14:58 +0530 Subject: Review Request: JDK-8049881: jstack not working on core files In-Reply-To: <53CD0606.4050100@oracle.com> References: <53CCDD88.90506@oracle.com> <53CD0606.4050100@oracle.com> Message-ID: <53CDB40A.2090100@oracle.com> Hi David, On 7/21/2014 5:52 PM, David Holmes wrote: > Hi Poonam, > > On 21/07/2014 7:29 PM, Poonam Bajaj wrote: >> The changes for "8046282: SA update" introduced this bug. The following >> changes fix the failure. >> >> Bug: JDK-8049881 : >> jstack not working on core files >> Webrev: http://cr.openjdk.java.net/~poonam/8049881/webrev.00/ >> >> With these changes jstack works fine with the core files. > > Minor nit: > > 58 try { > 59 traceIDField = type.getField("_trace_id"); > 60 } catch(Exception e) { > 61 traceIDField = null; > 62 } > > Line 61 isn't needed as the field is not assigned if the exception is > thrown - hence it remains default initialized to null. > Thanks for the review. I will remove the null assignment in the catch block. > Overall though this seems a bit kludgy - a field that doesn't exist in > the OpenJDK shouldn't be making it's absence so obvious. > Yes, I understand. But given the current infrastructure around the open/closed code for the SA, this looks to be the simple and clean solution for this problem. regards, Poonam > David > >> Thanks, >> Poonam From jaroslav.bachorik at oracle.com Tue Jul 22 10:39:25 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Jul 2014 12:39:25 +0200 Subject: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53BA7336.2000402@oracle.com> References: <53BA7336.2000402@oracle.com> Message-ID: <53CE3F5D.4040001@oracle.com> Hi, might I have a (R)eviewer to take a look at this? The test still fails pretty regularly. Thanks, -JB- On 07/07/2014 12:15 PM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 > Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 > > jdk.testlibrary.ProcessThread was erroneously starting the external > application with timeout of -1 - meaning no waiting for the target > application to initialize. What it should have done was to wait for the > target application indefinitely and let the harness timeout the test. > > The change modifies jdk.testlibrary.ProcessTools.startProcess() methods > to be explicit about the meaning of "-1" and "0" (newly added) timeouts. > It also adds a convenient method where you can start a process waiting > for the warmup indefinitely without actually providing "0" and a dummy > TimeUnit. > > I also took liberty and encapsulated the "test.timeout.factor" system > property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. > > The changes to the test library keep the current semantics (eg. the > timeout of -1 still means no wait etc.) - they are only enhancing it. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Jul 23 11:55:31 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Jul 2014 13:55:31 +0200 Subject: [ping] Re: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53CE3F5D.4040001@oracle.com> References: <53BA7336.2000402@oracle.com> <53CE3F5D.4040001@oracle.com> Message-ID: <53CFA2B3.8020209@oracle.com> On 07/22/2014 12:39 PM, Jaroslav Bachorik wrote: > Hi, > > might I have a (R)eviewer to take a look at this? The test still fails > pretty regularly. > > Thanks, > > -JB- > > On 07/07/2014 12:15 PM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 >> >> jdk.testlibrary.ProcessThread was erroneously starting the external >> application with timeout of -1 - meaning no waiting for the target >> application to initialize. What it should have done was to wait for the >> target application indefinitely and let the harness timeout the test. >> >> The change modifies jdk.testlibrary.ProcessTools.startProcess() methods >> to be explicit about the meaning of "-1" and "0" (newly added) timeouts. >> It also adds a convenient method where you can start a process waiting >> for the warmup indefinitely without actually providing "0" and a dummy >> TimeUnit. >> >> I also took liberty and encapsulated the "test.timeout.factor" system >> property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. >> >> The changes to the test library keep the current semantics (eg. the >> timeout of -1 still means no wait etc.) - they are only enhancing it. >> >> Thanks, >> >> -JB- > From daniel.fuchs at oracle.com Wed Jul 23 12:15:22 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Jul 2014 14:15:22 +0200 Subject: [ping] Re: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53CFA2B3.8020209@oracle.com> References: <53BA7336.2000402@oracle.com> <53CE3F5D.4040001@oracle.com> <53CFA2B3.8020209@oracle.com> Message-ID: <53CFA75A.3090308@oracle.com> Hi Jaroslav, It looks reasonable. I imagine you have run testset svc & core to verify that there's no regression in other tests that use the library? best regards, -- daniel On 7/23/14 1:55 PM, Jaroslav Bachorik wrote: > On 07/22/2014 12:39 PM, Jaroslav Bachorik wrote: >> Hi, >> >> might I have a (R)eviewer to take a look at this? The test still fails >> pretty regularly. >> >> Thanks, >> >> -JB- >> >> On 07/07/2014 12:15 PM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 >>> >>> jdk.testlibrary.ProcessThread was erroneously starting the external >>> application with timeout of -1 - meaning no waiting for the target >>> application to initialize. What it should have done was to wait for the >>> target application indefinitely and let the harness timeout the test. >>> >>> The change modifies jdk.testlibrary.ProcessTools.startProcess() methods >>> to be explicit about the meaning of "-1" and "0" (newly added) timeouts. >>> It also adds a convenient method where you can start a process waiting >>> for the warmup indefinitely without actually providing "0" and a dummy >>> TimeUnit. >>> >>> I also took liberty and encapsulated the "test.timeout.factor" system >>> property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. >>> >>> The changes to the test library keep the current semantics (eg. the >>> timeout of -1 still means no wait etc.) - they are only enhancing it. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Wed Jul 23 12:50:58 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Jul 2014 14:50:58 +0200 Subject: [ping] Re: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53CFA75A.3090308@oracle.com> References: <53BA7336.2000402@oracle.com> <53CE3F5D.4040001@oracle.com> <53CFA2B3.8020209@oracle.com> <53CFA75A.3090308@oracle.com> Message-ID: <53CFAFB2.3070100@oracle.com> On 07/23/2014 02:15 PM, Daniel Fuchs wrote: > Hi Jaroslav, > > It looks reasonable. > I imagine you have run testset svc & core to verify that there's no > regression in other tests that use the library? Yes, I did. And I will do it again before the push to make sure any newly introduced external changes don't collide with this patch. -JB- > > best regards, > > -- daniel > > On 7/23/14 1:55 PM, Jaroslav Bachorik wrote: >> On 07/22/2014 12:39 PM, Jaroslav Bachorik wrote: >>> Hi, >>> >>> might I have a (R)eviewer to take a look at this? The test still fails >>> pretty regularly. >>> >>> Thanks, >>> >>> -JB- >>> >>> On 07/07/2014 12:15 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 >>>> >>>> jdk.testlibrary.ProcessThread was erroneously starting the external >>>> application with timeout of -1 - meaning no waiting for the target >>>> application to initialize. What it should have done was to wait for the >>>> target application indefinitely and let the harness timeout the test. >>>> >>>> The change modifies jdk.testlibrary.ProcessTools.startProcess() methods >>>> to be explicit about the meaning of "-1" and "0" (newly added) >>>> timeouts. >>>> It also adds a convenient method where you can start a process waiting >>>> for the warmup indefinitely without actually providing "0" and a dummy >>>> TimeUnit. >>>> >>>> I also took liberty and encapsulated the "test.timeout.factor" system >>>> property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. >>>> >>>> The changes to the test library keep the current semantics (eg. the >>>> timeout of -1 still means no wait etc.) - they are only enhancing it. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Thu Jul 24 11:07:29 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 24 Jul 2014 13:07:29 +0200 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending Message-ID: <53D0E8F1.4080508@oracle.com> Please, review the change for the fix of the following problem In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is invoked in loop 198 for (i = 0; i < num_providers; ++i) { 199 JVM_DTraceProvider* p = &(jvm_providers[i]); 200 jobject provider = (*env)->GetObjectArrayElement( 201 env, providers, i); 202 readProviderData(env, provider, p); 203 } The first problem is that GetGetObjectArrayElement() call on L200 may throw an exception which is not checked subsequently. On L202 the call to readProviderData() can also raise a Java exception without appropriate after-check. When getting back to the beginning of the loop GetObjectArrayElement() may be called with a pending exception which is deemed unsafe. The fix extracts the inner part of the loop into a separate function where the result of each step is properly checked for pending exceptions. If there is a pending exception the loop will be interrupted, resources cleaned and Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the pending exception recorded in env. Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 Thanks, -JB- From serguei.spitsyn at oracle.com Fri Jul 25 10:56:44 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 25 Jul 2014 03:56:44 -0700 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D0E8F1.4080508@oracle.com> References: <53D0E8F1.4080508@oracle.com> Message-ID: <53D237EC.7020108@oracle.com> Jaroslav, The fix looks good. Thanks, Serguei On 7/24/14 4:07 AM, Jaroslav Bachorik wrote: > Please, review the change for the fix of the following problem > > In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is > invoked in loop > > 198 for (i = 0; i < num_providers; ++i) { > 199 JVM_DTraceProvider* p = &(jvm_providers[i]); > 200 jobject provider = (*env)->GetObjectArrayElement( > 201 env, providers, i); > 202 readProviderData(env, provider, p); > 203 } > > The first problem is that GetGetObjectArrayElement() call on L200 may > throw an exception which is not checked subsequently. On L202 the call > to readProviderData() can also raise a Java exception without > appropriate after-check. When getting back to the beginning of the > loop GetObjectArrayElement() may be called with a pending exception > which is deemed unsafe. > > The fix extracts the inner part of the loop into a separate function > where the result of each step is properly checked for pending > exceptions. If there is a pending exception the loop will be > interrupted, resources cleaned and > Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with > the pending exception recorded in env. > > > Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 > > Thanks, > > -JB- From dmitry.samersoff at oracle.com Fri Jul 25 11:40:04 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Jul 2014 15:40:04 +0400 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D0E8F1.4080508@oracle.com> References: <53D0E8F1.4080508@oracle.com> Message-ID: <53D24214.9020209@oracle.com> Jaroslav, readProviderData already use CHECK So it might be better to: 1. change readProviderData to return 0 on error and 1 on success. 2. add check for exception to ll 201 and abort the loop if at least one of providers is not read. -Dmitry On 2014-07-24 15:07, Jaroslav Bachorik wrote: > Please, review the change for the fix of the following problem > > In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is > invoked in loop > > 198 for (i = 0; i < num_providers; ++i) { > 199 JVM_DTraceProvider* p = &(jvm_providers[i]); > 200 jobject provider = (*env)->GetObjectArrayElement( > 201 env, providers, i); > 202 readProviderData(env, provider, p); > 203 } > > The first problem is that GetGetObjectArrayElement() call on L200 may > throw an exception which is not checked subsequently. On L202 the call > to readProviderData() can also raise a Java exception without > appropriate after-check. When getting back to the beginning of the loop > GetObjectArrayElement() may be called with a pending exception which is > deemed unsafe. > > The fix extracts the inner part of the loop into a separate function > where the result of each step is properly checked for pending > exceptions. If there is a pending exception the loop will be > interrupted, resources cleaned and > Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the > pending exception recorded in env. > > > Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 > > Thanks, > > -JB- -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Fri Jul 25 12:20:14 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 25 Jul 2014 14:20:14 +0200 Subject: [ping] Re: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53CFA75A.3090308@oracle.com> References: <53BA7336.2000402@oracle.com> <53CE3F5D.4040001@oracle.com> <53CFA2B3.8020209@oracle.com> <53CFA75A.3090308@oracle.com> Message-ID: <53D24B7E.9080300@oracle.com> On 07/23/2014 02:15 PM, Daniel Fuchs wrote: > Hi Jaroslav, > > It looks reasonable. > I imagine you have run testset svc & core to verify that there's no > regression in other tests that use the library? Daniel, are you ok with this change? I ran JPRT for svc and core testsets and it didn't encounter any new failures when compared to the runs without this patch applied. Thanks, -JB- > > best regards, > > -- daniel > > On 7/23/14 1:55 PM, Jaroslav Bachorik wrote: >> On 07/22/2014 12:39 PM, Jaroslav Bachorik wrote: >>> Hi, >>> >>> might I have a (R)eviewer to take a look at this? The test still fails >>> pretty regularly. >>> >>> Thanks, >>> >>> -JB- >>> >>> On 07/07/2014 12:15 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 >>>> >>>> jdk.testlibrary.ProcessThread was erroneously starting the external >>>> application with timeout of -1 - meaning no waiting for the target >>>> application to initialize. What it should have done was to wait for the >>>> target application indefinitely and let the harness timeout the test. >>>> >>>> The change modifies jdk.testlibrary.ProcessTools.startProcess() methods >>>> to be explicit about the meaning of "-1" and "0" (newly added) >>>> timeouts. >>>> It also adds a convenient method where you can start a process waiting >>>> for the warmup indefinitely without actually providing "0" and a dummy >>>> TimeUnit. >>>> >>>> I also took liberty and encapsulated the "test.timeout.factor" system >>>> property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. >>>> >>>> The changes to the test library keep the current semantics (eg. the >>>> timeout of -1 still means no wait etc.) - they are only enhancing it. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From daniel.fuchs at oracle.com Fri Jul 25 12:30:35 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 25 Jul 2014 14:30:35 +0200 Subject: [ping] Re: RFR 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 In-Reply-To: <53D24B7E.9080300@oracle.com> References: <53BA7336.2000402@oracle.com> <53CE3F5D.4040001@oracle.com> <53CFA2B3.8020209@oracle.com> <53CFA75A.3090308@oracle.com> <53D24B7E.9080300@oracle.com> Message-ID: <53D24DEB.4080308@oracle.com> On 7/25/14 2:20 PM, Jaroslav Bachorik wrote: > On 07/23/2014 02:15 PM, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> It looks reasonable. >> I imagine you have run testset svc & core to verify that there's no >> regression in other tests that use the library? > > Daniel, are you ok with this change? I ran JPRT for svc and core > testsets and it didn't encounter any new failures when compared to the > runs without this patch applied. Oh yes of course, sorry if it wasn't clear. best regards, -- daniel > > Thanks, > > -JB- > >> >> best regards, >> >> -- daniel >> >> On 7/23/14 1:55 PM, Jaroslav Bachorik wrote: >>> On 07/22/2014 12:39 PM, Jaroslav Bachorik wrote: >>>> Hi, >>>> >>>> might I have a (R)eviewer to take a look at this? The test still fails >>>> pretty regularly. >>>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>> On 07/07/2014 12:15 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8049194 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8049194/webrev.00 >>>>> >>>>> jdk.testlibrary.ProcessThread was erroneously starting the external >>>>> application with timeout of -1 - meaning no waiting for the target >>>>> application to initialize. What it should have done was to wait for >>>>> the >>>>> target application indefinitely and let the harness timeout the test. >>>>> >>>>> The change modifies jdk.testlibrary.ProcessTools.startProcess() >>>>> methods >>>>> to be explicit about the meaning of "-1" and "0" (newly added) >>>>> timeouts. >>>>> It also adds a convenient method where you can start a process waiting >>>>> for the warmup indefinitely without actually providing "0" and a dummy >>>>> TimeUnit. >>>>> >>>>> I also took liberty and encapsulated the "test.timeout.factor" system >>>>> property handling into jdk.testlibrary.Utils.adjustTimeou(to) method. >>>>> >>>>> The changes to the test library keep the current semantics (eg. the >>>>> timeout of -1 still means no wait etc.) - they are only enhancing it. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From jaroslav.bachorik at oracle.com Fri Jul 25 13:04:28 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 25 Jul 2014 15:04:28 +0200 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D24214.9020209@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> Message-ID: <53D255DC.8000402@oracle.com> On 07/25/2014 01:40 PM, Dmitry Samersoff wrote: > Jaroslav, > > readProviderData already use CHECK > > So it might be better to: > > 1. change readProviderData to return 0 on error and 1 on success. > > 2. add check for exception to ll 201 and abort the loop if at least > one of providers is not read. Ok, here is another attempt, now without introducing a new function. http://cr.openjdk.java.net/~jbachorik/8030115/webrev.01 -JB- > > > -Dmitry > > > On 2014-07-24 15:07, Jaroslav Bachorik wrote: >> Please, review the change for the fix of the following problem >> >> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is >> invoked in loop >> >> 198 for (i = 0; i < num_providers; ++i) { >> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >> 200 jobject provider = (*env)->GetObjectArrayElement( >> 201 env, providers, i); >> 202 readProviderData(env, provider, p); >> 203 } >> >> The first problem is that GetGetObjectArrayElement() call on L200 may >> throw an exception which is not checked subsequently. On L202 the call >> to readProviderData() can also raise a Java exception without >> appropriate after-check. When getting back to the beginning of the loop >> GetObjectArrayElement() may be called with a pending exception which is >> deemed unsafe. >> >> The fix extracts the inner part of the loop into a separate function >> where the result of each step is properly checked for pending >> exceptions. If there is a pending exception the loop will be >> interrupted, resources cleaned and >> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the >> pending exception recorded in env. >> >> >> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >> >> Thanks, >> >> -JB- > > From dmitry.samersoff at oracle.com Fri Jul 25 15:00:39 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Jul 2014 19:00:39 +0400 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D255DC.8000402@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> Message-ID: <53D27117.8060303@oracle.com> Jaroslav, Looks good for me. Shouldn't we abort the loop after the first error? -Dmitry On 2014-07-25 17:04, Jaroslav Bachorik wrote: > On 07/25/2014 01:40 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> readProviderData already use CHECK >> >> So it might be better to: >> >> 1. change readProviderData to return 0 on error and 1 on success. >> >> 2. add check for exception to ll 201 and abort the loop if at least >> one of providers is not read. > > Ok, here is another attempt, now without introducing a new function. > > http://cr.openjdk.java.net/~jbachorik/8030115/webrev.01 > > -JB- > >> >> >> -Dmitry >> >> >> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>> Please, review the change for the fix of the following problem >>> >>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is >>> invoked in loop >>> >>> 198 for (i = 0; i < num_providers; ++i) { >>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>> 200 jobject provider = (*env)->GetObjectArrayElement( >>> 201 env, providers, i); >>> 202 readProviderData(env, provider, p); >>> 203 } >>> >>> The first problem is that GetGetObjectArrayElement() call on L200 may >>> throw an exception which is not checked subsequently. On L202 the call >>> to readProviderData() can also raise a Java exception without >>> appropriate after-check. When getting back to the beginning of the loop >>> GetObjectArrayElement() may be called with a pending exception which is >>> deemed unsafe. >>> >>> The fix extracts the inner part of the loop into a separate function >>> where the result of each step is properly checked for pending >>> exceptions. If there is a pending exception the loop will be >>> interrupted, resources cleaned and >>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the >>> pending exception recorded in env. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>> >>> Thanks, >>> >>> -JB- >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Jul 25 21:34:26 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 25 Jul 2014 14:34:26 -0700 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D255DC.8000402@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> Message-ID: <53D2CD62.2030803@oracle.com> Previous fix was more elegant. In fact, I do not like new one. Thanks, Serguei On 7/25/14 6:04 AM, Jaroslav Bachorik wrote: > On 07/25/2014 01:40 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> readProviderData already use CHECK >> >> So it might be better to: >> >> 1. change readProviderData to return 0 on error and 1 on success. >> >> 2. add check for exception to ll 201 and abort the loop if at least >> one of providers is not read. > > Ok, here is another attempt, now without introducing a new function. > > http://cr.openjdk.java.net/~jbachorik/8030115/webrev.01 > > -JB- > >> >> >> -Dmitry >> >> >> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>> Please, review the change for the fix of the following problem >>> >>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is >>> invoked in loop >>> >>> 198 for (i = 0; i < num_providers; ++i) { >>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>> 200 jobject provider = (*env)->GetObjectArrayElement( >>> 201 env, providers, i); >>> 202 readProviderData(env, provider, p); >>> 203 } >>> >>> The first problem is that GetGetObjectArrayElement() call on L200 may >>> throw an exception which is not checked subsequently. On L202 the call >>> to readProviderData() can also raise a Java exception without >>> appropriate after-check. When getting back to the beginning of the loop >>> GetObjectArrayElement() may be called with a pending exception which is >>> deemed unsafe. >>> >>> The fix extracts the inner part of the loop into a separate function >>> where the result of each step is properly checked for pending >>> exceptions. If there is a pending exception the loop will be >>> interrupted, resources cleaned and >>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the >>> pending exception recorded in env. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>> >>> Thanks, >>> >>> -JB- >> >> > From dmitry.samersoff at oracle.com Fri Jul 25 23:16:31 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 26 Jul 2014 03:16:31 +0400 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D2CD62.2030803@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> Message-ID: <53D2E54F.5060500@oracle.com> Serguei, Previous fix get offset to pointer passed as parameter without bounds check. It's safe here, but not the best solution in general and cause a warning. Also readProviderData checks for exceptions, so I see no reason to check it again. *In this version:* we don't need to count errors and can abort after first one. CHECK_(0)L at 204 cause the function to return, but left allocated memory. -Dmitry On 2014-07-26 01:34, serguei.spitsyn at oracle.com wrote: > Previous fix was more elegant. > In fact, I do not like new one. > > Thanks, > Serguei > > On 7/25/14 6:04 AM, Jaroslav Bachorik wrote: >> On 07/25/2014 01:40 PM, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> readProviderData already use CHECK >>> >>> So it might be better to: >>> >>> 1. change readProviderData to return 0 on error and 1 on success. >>> >>> 2. add check for exception to ll 201 and abort the loop if at least >>> one of providers is not read. >> >> Ok, here is another attempt, now without introducing a new function. >> >> http://cr.openjdk.java.net/~jbachorik/8030115/webrev.01 >> >> -JB- >> >>> >>> >>> -Dmitry >>> >>> >>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>> Please, review the change for the fix of the following problem >>>> >>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is >>>> invoked in loop >>>> >>>> 198 for (i = 0; i < num_providers; ++i) { >>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>> 201 env, providers, i); >>>> 202 readProviderData(env, provider, p); >>>> 203 } >>>> >>>> The first problem is that GetGetObjectArrayElement() call on L200 may >>>> throw an exception which is not checked subsequently. On L202 the call >>>> to readProviderData() can also raise a Java exception without >>>> appropriate after-check. When getting back to the beginning of the loop >>>> GetObjectArrayElement() may be called with a pending exception which is >>>> deemed unsafe. >>>> >>>> The fix extracts the inner part of the loop into a separate function >>>> where the result of each step is properly checked for pending >>>> exceptions. If there is a pending exception the loop will be >>>> interrupted, resources cleaned and >>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the >>>> pending exception recorded in env. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>> >>>> Thanks, >>>> >>>> -JB- >>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sat Jul 26 09:46:46 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 26 Jul 2014 13:46:46 +0400 Subject: RFR(S): JDK-8049046 Deprecated Function in hotspot/src/os/solaris/vm/attachListener_solaris.cpp Message-ID: <53D37906.8060803@oracle.com> Please, Review the small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8049046/webrev.01/ door_cred() is deprecated since Solaris 11.2 so replace it to door_ucred() Testing: JPRT -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sat Jul 26 10:31:22 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 26 Jul 2014 14:31:22 +0400 Subject: RFR(XS): JDK-8049049 Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp Message-ID: <53D3837A.8050407@oracle.com> Hi Everybody, Please review an one line fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8049049/webrev.01/ -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Sat Jul 26 10:59:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jul 2014 20:59:38 +1000 Subject: RFR(S): JDK-8049046 Deprecated Function in hotspot/src/os/solaris/vm/attachListener_solaris.cpp In-Reply-To: <53D37906.8060803@oracle.com> References: <53D37906.8060803@oracle.com> Message-ID: <53D38A1A.4020309@oracle.com> Hi Dmitry, On 26/07/2014 7:46 PM, Dmitry Samersoff wrote: > Please, > > Review the small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049046/webrev.01/ > > door_cred() is deprecated since Solaris 11.2 so replace it to door_ucred() 11.2? door_cred has been marked obsolete since before that file started using it (if we can believe the copyright date)! :) The door_cred() function is obsolete. Applications should use the door_ucred(3DOOR) function in place of door_cred(). ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: SunOS 5.10 Last change: 25 Mar 2003 1 ------------- Change looks okay to me. A minor style nit - I dislike int variables that pretend to be booleans, I'd prefer int ok be simply int ret Cheers, David ------ > Testing: > > JPRT > From david.holmes at oracle.com Sat Jul 26 11:03:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jul 2014 21:03:29 +1000 Subject: RFR(XS): JDK-8049049 Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp In-Reply-To: <53D3837A.8050407@oracle.com> References: <53D3837A.8050407@oracle.com> Message-ID: <53D38B01.5010308@oracle.com> Hi Dmitry, On 26/07/2014 8:31 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Please review an one line fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049049/webrev.01/ In the rest of hotspot we've been switching to using INTPTR_FORMAT and applying p2i() on the arg. Is that available here? (The end result might be the same ...) David > From dmitry.samersoff at oracle.com Sat Jul 26 16:26:02 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 26 Jul 2014 20:26:02 +0400 Subject: RFR(S): JDK-8049046 Deprecated Function in hotspot/src/os/solaris/vm/attachListener_solaris.cpp In-Reply-To: <53D38A1A.4020309@oracle.com> References: <53D37906.8060803@oracle.com> <53D38A1A.4020309@oracle.com> Message-ID: <53D3D69A.6050601@oracle.com> David, Thank you for review. Nit fixed in-place. PS: I'd followed Alan Coopersmith blog https://blogs.oracle.com/alanc/entry/solaris_11_2_functional_deprecation So it looks like this time door_cred() is really deprecated :) -Dmitry On 2014-07-26 14:59, David Holmes wrote: > Hi Dmitry, > > On 26/07/2014 7:46 PM, Dmitry Samersoff wrote: >> Please, >> >> Review the small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049046/webrev.01/ >> >> door_cred() is deprecated since Solaris 11.2 so replace it to >> door_ucred() > > 11.2? door_cred has been marked obsolete since before that file started > using it (if we can believe the copyright date)! :) > > The door_cred() function is obsolete. Applications should > use the door_ucred(3DOOR) function in place of door_cred(). > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > SunOS 5.10 Last change: 25 Mar 2003 1 > ------------- > > > Change looks okay to me. A minor style nit - I dislike int variables > that pretend to be booleans, I'd prefer > > int ok > > be simply > > int ret > > Cheers, > David > ------ > >> Testing: >> >> JPRT >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sat Jul 26 16:28:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 26 Jul 2014 20:28:10 +0400 Subject: RFR(XS): JDK-8049049 Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp In-Reply-To: <53D38B01.5010308@oracle.com> References: <53D3837A.8050407@oracle.com> <53D38B01.5010308@oracle.com> Message-ID: <53D3D71A.20400@oracle.com> David, Thank you for review. These macro is not available for agent/src and I would prefer don't introduce it for just one place. -Dmitry On 2014-07-26 15:03, David Holmes wrote: > Hi Dmitry, > > On 26/07/2014 8:31 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review an one line fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8049049/webrev.01/ > > In the rest of hotspot we've been switching to using INTPTR_FORMAT and > applying p2i() on the arg. Is that available here? (The end result might > be the same ...) > > David > >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Sat Jul 26 20:36:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Sun, 27 Jul 2014 06:36:05 +1000 Subject: RFR(XS): JDK-8049049 Unportable format string argument mismatch in hotspot/agent/src/os/solaris/proc/saproc.cpp In-Reply-To: <53D3D71A.20400@oracle.com> References: <53D3837A.8050407@oracle.com> <53D38B01.5010308@oracle.com> <53D3D71A.20400@oracle.com> Message-ID: <53D41135.2010805@oracle.com> On 27/07/2014 2:28 AM, Dmitry Samersoff wrote: > David, > > Thank you for review. > > These macro is not available for agent/src and I would prefer don't > introduce it for just one place. Okay. Net effect is the same modulo leading zero padding. David > -Dmitry > > On 2014-07-26 15:03, David Holmes wrote: >> Hi Dmitry, >> >> On 26/07/2014 8:31 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review an one line fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8049049/webrev.01/ >> >> In the rest of hotspot we've been switching to using INTPTR_FORMAT and >> applying p2i() on the arg. Is that available here? (The end result might >> be the same ...) >> >> David >> >>> > > From serguei.spitsyn at oracle.com Sun Jul 27 06:39:08 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 26 Jul 2014 23:39:08 -0700 Subject: RFR(S): JDK-8049046 Deprecated Function in hotspot/src/os/solaris/vm/attachListener_solaris.cpp In-Reply-To: <53D37906.8060803@oracle.com> References: <53D37906.8060803@oracle.com> Message-ID: <53D49E8C.10804@oracle.com> It looks good. Thanks, Serguei On 7/26/14 2:46 AM, Dmitry Samersoff wrote: > Please, > > Review the small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8049046/webrev.01/ > > door_cred() is deprecated since Solaris 11.2 so replace it to door_ucred() > > Testing: > > JPRT > From serguei.spitsyn at oracle.com Sun Jul 27 06:49:29 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 26 Jul 2014 23:49:29 -0700 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D2E54F.5060500@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> Message-ID: <53D4A0F9.50906@oracle.com> Thanks, Dmitry! I reviewed it again. Now I think the fix is good. Sorry for the wrong opinion and confusion. One nit is about the line: 205 noErrors &= readProviderData(env, provider, p); The ampersand '&' is not necessary here. The loop is stopped as soon as the noErrors is equal to zero, so there is no need to accumulate it. Thanks, Serguei On 7/25/14 4:16 PM, Dmitry Samersoff wrote: > Serguei, > > Previous fix get offset to pointer passed as parameter without bounds > check. It's safe here, but not the best solution in general and cause a > warning. > > Also readProviderData checks for exceptions, so I see no reason to check > it again. > > *In this version:* > > we don't need to count errors and can abort after first one. > > CHECK_(0)L at 204 cause the function to return, but left allocated memory. > > -Dmitry > > On 2014-07-26 01:34, serguei.spitsyn at oracle.com wrote: >> Previous fix was more elegant. >> In fact, I do not like new one. >> >> Thanks, >> Serguei >> >> On 7/25/14 6:04 AM, Jaroslav Bachorik wrote: >>> On 07/25/2014 01:40 PM, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> readProviderData already use CHECK >>>> >>>> So it might be better to: >>>> >>>> 1. change readProviderData to return 0 on error and 1 on success. >>>> >>>> 2. add check for exception to ll 201 and abort the loop if at least >>>> one of providers is not read. >>> Ok, here is another attempt, now without introducing a new function. >>> >>> http://cr.openjdk.java.net/~jbachorik/8030115/webrev.01 >>> >>> -JB- >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>> Please, review the change for the fix of the following problem >>>>> >>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is >>>>> invoked in loop >>>>> >>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>> 201 env, providers, i); >>>>> 202 readProviderData(env, provider, p); >>>>> 203 } >>>>> >>>>> The first problem is that GetGetObjectArrayElement() call on L200 may >>>>> throw an exception which is not checked subsequently. On L202 the call >>>>> to readProviderData() can also raise a Java exception without >>>>> appropriate after-check. When getting back to the beginning of the loop >>>>> GetObjectArrayElement() may be called with a pending exception which is >>>>> deemed unsafe. >>>>> >>>>> The fix extracts the inner part of the loop into a separate function >>>>> where the result of each step is properly checked for pending >>>>> exceptions. If there is a pending exception the loop will be >>>>> interrupted, resources cleaned and >>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the >>>>> pending exception recorded in env. >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Jul 28 13:20:02 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 28 Jul 2014 15:20:02 +0200 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D2E54F.5060500@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> Message-ID: <53D64E02.3060801@oracle.com> On 07/26/2014 01:16 AM, Dmitry Samersoff wrote: > Serguei, > > Previous fix get offset to pointer passed as parameter without bounds > check. It's safe here, but not the best solution in general and cause a > warning. > > Also readProviderData checks for exceptions, so I see no reason to check > it again. > > *In this version:* > > we don't need to count errors and can abort after first one. The loop is aborted as soon as noErrors is set to 0. > > CHECK_(0)L at 204 cause the function to return, but left allocated memory. Obviously, can't use the macro here. I've changed the code to work directly with "(*env)->ExceptionOccurred(env)" here. http://cr.openjdk.java.net/~jbachorik/8030115/webrev.02 -JB- > > -Dmitry > > On 2014-07-26 01:34, serguei.spitsyn at oracle.com wrote: >> Previous fix was more elegant. >> In fact, I do not like new one. >> >> Thanks, >> Serguei >> >> On 7/25/14 6:04 AM, Jaroslav Bachorik wrote: >>> On 07/25/2014 01:40 PM, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> readProviderData already use CHECK >>>> >>>> So it might be better to: >>>> >>>> 1. change readProviderData to return 0 on error and 1 on success. >>>> >>>> 2. add check for exception to ll 201 and abort the loop if at least >>>> one of providers is not read. >>> >>> Ok, here is another attempt, now without introducing a new function. >>> >>> http://cr.openjdk.java.net/~jbachorik/8030115/webrev.01 >>> >>> -JB- >>> >>>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>> Please, review the change for the fix of the following problem >>>>> >>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following code is >>>>> invoked in loop >>>>> >>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>> 201 env, providers, i); >>>>> 202 readProviderData(env, provider, p); >>>>> 203 } >>>>> >>>>> The first problem is that GetGetObjectArrayElement() call on L200 may >>>>> throw an exception which is not checked subsequently. On L202 the call >>>>> to readProviderData() can also raise a Java exception without >>>>> appropriate after-check. When getting back to the beginning of the loop >>>>> GetObjectArrayElement() may be called with a pending exception which is >>>>> deemed unsafe. >>>>> >>>>> The fix extracts the inner part of the loop into a separate function >>>>> where the result of each step is properly checked for pending >>>>> exceptions. If there is a pending exception the loop will be >>>>> interrupted, resources cleaned and >>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 with the >>>>> pending exception recorded in env. >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>>> >>> >> > > From jaroslav.bachorik at oracle.com Mon Jul 28 14:08:21 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 28 Jul 2014 16:08:21 +0200 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D64E02.3060801@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> <53D64E02.3060801@oracle.com> Message-ID: <53D65955.6030003@oracle.com> A few readability improvements suggested by Dmitry http://cr.openjdk.java.net/~jbachorik/8030115/webrev.04 -JB- --- snipped for brevity --- >>>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>>> Please, review the change for the fix of the following problem >>>>>> >>>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following >>>>>> code is >>>>>> invoked in loop >>>>>> >>>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>>> 201 env, providers, i); >>>>>> 202 readProviderData(env, provider, p); >>>>>> 203 } >>>>>> >>>>>> The first problem is that GetGetObjectArrayElement() call on L200 may >>>>>> throw an exception which is not checked subsequently. On L202 the >>>>>> call >>>>>> to readProviderData() can also raise a Java exception without >>>>>> appropriate after-check. When getting back to the beginning of the >>>>>> loop >>>>>> GetObjectArrayElement() may be called with a pending exception >>>>>> which is >>>>>> deemed unsafe. >>>>>> >>>>>> The fix extracts the inner part of the loop into a separate function >>>>>> where the result of each step is properly checked for pending >>>>>> exceptions. If there is a pending exception the loop will be >>>>>> interrupted, resources cleaned and >>>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 >>>>>> with the >>>>>> pending exception recorded in env. >>>>>> >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>>> >>>> >>> >> >> > From dmitry.samersoff at oracle.com Mon Jul 28 14:21:23 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 28 Jul 2014 18:21:23 +0400 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D65955.6030003@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> <53D64E02.3060801@oracle.com> <53D65955.6030003@oracle.com> Message-ID: <53D65C63.4030400@oracle.com> Jaroslav, Looks good for me! -Dmitry On 2014-07-28 18:08, Jaroslav Bachorik wrote: > A few readability improvements suggested by Dmitry > > http://cr.openjdk.java.net/~jbachorik/8030115/webrev.04 > > -JB- > > > --- snipped for brevity --- > >>>>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>>>> Please, review the change for the fix of the following problem >>>>>>> >>>>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following >>>>>>> code is >>>>>>> invoked in loop >>>>>>> >>>>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>>>> 201 env, providers, i); >>>>>>> 202 readProviderData(env, provider, p); >>>>>>> 203 } >>>>>>> >>>>>>> The first problem is that GetGetObjectArrayElement() call on L200 >>>>>>> may >>>>>>> throw an exception which is not checked subsequently. On L202 the >>>>>>> call >>>>>>> to readProviderData() can also raise a Java exception without >>>>>>> appropriate after-check. When getting back to the beginning of the >>>>>>> loop >>>>>>> GetObjectArrayElement() may be called with a pending exception >>>>>>> which is >>>>>>> deemed unsafe. >>>>>>> >>>>>>> The fix extracts the inner part of the loop into a separate function >>>>>>> where the result of each step is properly checked for pending >>>>>>> exceptions. If there is a pending exception the loop will be >>>>>>> interrupted, resources cleaned and >>>>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 >>>>>>> with the >>>>>>> pending exception recorded in env. >>>>>>> >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Jul 28 15:20:05 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 28 Jul 2014 19:20:05 +0400 Subject: RFR(S): Warning from b62 for hotspot.agent.src.os.solaris.proc: use after free Message-ID: <53D66A25.8090209@oracle.com> Hi Everyone, Please review small fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8025667/webrev.01 Move free() call few lines down. It is not necessary at ll. 666, but I move it as well to keep pattern. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Mon Jul 28 19:22:56 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jul 2014 12:22:56 -0700 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D65955.6030003@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> <53D64E02.3060801@oracle.com> <53D65955.6030003@oracle.com> Message-ID: <53D6A310.5030506@oracle.com> Looks good. Thanks, Serguei On 7/28/14 7:08 AM, Jaroslav Bachorik wrote: > A few readability improvements suggested by Dmitry > > http://cr.openjdk.java.net/~jbachorik/8030115/webrev.04 > > -JB- > > > --- snipped for brevity --- > >>>>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>>>> Please, review the change for the fix of the following problem >>>>>>> >>>>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following >>>>>>> code is >>>>>>> invoked in loop >>>>>>> >>>>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>>>> 201 env, providers, i); >>>>>>> 202 readProviderData(env, provider, p); >>>>>>> 203 } >>>>>>> >>>>>>> The first problem is that GetGetObjectArrayElement() call on >>>>>>> L200 may >>>>>>> throw an exception which is not checked subsequently. On L202 the >>>>>>> call >>>>>>> to readProviderData() can also raise a Java exception without >>>>>>> appropriate after-check. When getting back to the beginning of the >>>>>>> loop >>>>>>> GetObjectArrayElement() may be called with a pending exception >>>>>>> which is >>>>>>> deemed unsafe. >>>>>>> >>>>>>> The fix extracts the inner part of the loop into a separate >>>>>>> function >>>>>>> where the result of each step is properly checked for pending >>>>>>> exceptions. If there is a pending exception the loop will be >>>>>>> interrupted, resources cleaned and >>>>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 >>>>>>> with the >>>>>>> pending exception recorded in env. >>>>>>> >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From david.holmes at oracle.com Tue Jul 29 05:13:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jul 2014 15:13:25 +1000 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D65955.6030003@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> <53D64E02.3060801@oracle.com> <53D65955.6030003@oracle.com> Message-ID: <53D72D75.2070604@oracle.com> I'll add my Reviewed to Dmitry and Serguei's reviews. Thanks, David On 29/07/2014 12:08 AM, Jaroslav Bachorik wrote: > A few readability improvements suggested by Dmitry > > http://cr.openjdk.java.net/~jbachorik/8030115/webrev.04 > > -JB- > > > --- snipped for brevity --- > >>>>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>>>> Please, review the change for the fix of the following problem >>>>>>> >>>>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following >>>>>>> code is >>>>>>> invoked in loop >>>>>>> >>>>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>>>> 201 env, providers, i); >>>>>>> 202 readProviderData(env, provider, p); >>>>>>> 203 } >>>>>>> >>>>>>> The first problem is that GetGetObjectArrayElement() call on L200 >>>>>>> may >>>>>>> throw an exception which is not checked subsequently. On L202 the >>>>>>> call >>>>>>> to readProviderData() can also raise a Java exception without >>>>>>> appropriate after-check. When getting back to the beginning of the >>>>>>> loop >>>>>>> GetObjectArrayElement() may be called with a pending exception >>>>>>> which is >>>>>>> deemed unsafe. >>>>>>> >>>>>>> The fix extracts the inner part of the loop into a separate function >>>>>>> where the result of each step is properly checked for pending >>>>>>> exceptions. If there is a pending exception the loop will be >>>>>>> interrupted, resources cleaned and >>>>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 >>>>>>> with the >>>>>>> pending exception recorded in env. >>>>>>> >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From david.holmes at oracle.com Tue Jul 29 05:31:03 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jul 2014 15:31:03 +1000 Subject: RFR(S): Warning from b62 for hotspot.agent.src.os.solaris.proc: use after free In-Reply-To: <53D66A25.8090209@oracle.com> References: <53D66A25.8090209@oracle.com> Message-ID: <53D73197.6040909@oracle.com> Looks good to me. Thanks, David On 29/07/2014 1:20 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review small fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8025667/webrev.01 > > Move free() call few lines down. It is not necessary at ll. 666, but I > move it as well to keep pattern. > > -Dmitry > From jaroslav.bachorik at oracle.com Tue Jul 29 08:08:37 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Jul 2014 10:08:37 +0200 Subject: RFR 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending In-Reply-To: <53D72D75.2070604@oracle.com> References: <53D0E8F1.4080508@oracle.com> <53D24214.9020209@oracle.com> <53D255DC.8000402@oracle.com> <53D2CD62.2030803@oracle.com> <53D2E54F.5060500@oracle.com> <53D64E02.3060801@oracle.com> <53D65955.6030003@oracle.com> <53D72D75.2070604@oracle.com> Message-ID: <53D75685.8070809@oracle.com> On 07/29/2014 07:13 AM, David Holmes wrote: > I'll add my Reviewed to Dmitry and Serguei's reviews. Thank you all! -JB- > > Thanks, > David > > On 29/07/2014 12:08 AM, Jaroslav Bachorik wrote: >> A few readability improvements suggested by Dmitry >> >> http://cr.openjdk.java.net/~jbachorik/8030115/webrev.04 >> >> -JB- >> >> >> --- snipped for brevity --- >> >>>>>>> On 2014-07-24 15:07, Jaroslav Bachorik wrote: >>>>>>>> Please, review the change for the fix of the following problem >>>>>>>> >>>>>>>> In jdk/src/share/native/sun/tracing/dtrace/JVM.c the following >>>>>>>> code is >>>>>>>> invoked in loop >>>>>>>> >>>>>>>> 198 for (i = 0; i < num_providers; ++i) { >>>>>>>> 199 JVM_DTraceProvider* p = &(jvm_providers[i]); >>>>>>>> 200 jobject provider = (*env)->GetObjectArrayElement( >>>>>>>> 201 env, providers, i); >>>>>>>> 202 readProviderData(env, provider, p); >>>>>>>> 203 } >>>>>>>> >>>>>>>> The first problem is that GetGetObjectArrayElement() call on L200 >>>>>>>> may >>>>>>>> throw an exception which is not checked subsequently. On L202 the >>>>>>>> call >>>>>>>> to readProviderData() can also raise a Java exception without >>>>>>>> appropriate after-check. When getting back to the beginning of the >>>>>>>> loop >>>>>>>> GetObjectArrayElement() may be called with a pending exception >>>>>>>> which is >>>>>>>> deemed unsafe. >>>>>>>> >>>>>>>> The fix extracts the inner part of the loop into a separate >>>>>>>> function >>>>>>>> where the result of each step is properly checked for pending >>>>>>>> exceptions. If there is a pending exception the loop will be >>>>>>>> interrupted, resources cleaned and >>>>>>>> Java_sun_tracing_dtrace_JVM_activate0() function will return 0 >>>>>>>> with the >>>>>>>> pending exception recorded in env. >>>>>>>> >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8030115/webrev.00 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> From jaroslav.bachorik at oracle.com Tue Jul 29 13:47:51 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Jul 2014 15:47:51 +0200 Subject: RFR 8052961: Test "com/sun/tools/attach/StartManagementAgent.java" failing intermittently Message-ID: <53D7A607.5030500@oracle.com> Please, review this (hopefully last) change to StartManagementAgent test Issue : https://bugs.openjdk.java.net/browse/JDK-8052961 Webrev: http://cr.openjdk.java.net/~jbachorik/8052961/webrev.00 The test needs a properly registered service for the ServiceLoader - but it fails to compile the provider class explicitly leading to intermittent failures. The fix is to add the "SimpleProvider" to "@run build ..." line. Thanks, -JB- From philip.race at oracle.com Tue Jul 29 18:25:52 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Jul 2014 11:25:52 -0700 Subject: Fix for 8030115 [parfait] warnings .. broke the 9-dev build. Message-ID: <53D7E730.3050301@oracle.com> We have just filed a P1 bug and are testing a fix. -phil. From philip.race at oracle.com Tue Jul 29 18:27:33 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 Jul 2014 11:27:33 -0700 Subject: Fix for 8030115 [parfait] warnings .. broke the 9-dev build. In-Reply-To: <53D7E730.3050301@oracle.com> References: <53D7E730.3050301@oracle.com> Message-ID: <53D7E795.4040606@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8053902 -phil. On 7/29/2014 11:25 AM, Phil Race wrote: > We have just filed a P1 bug and are testing a fix. > > -phil. From maynardj at us.ibm.com Wed Jul 30 17:05:38 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 30 Jul 2014 12:05:38 -0500 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> <53BAAC36.8030507@us.ibm.com> Message-ID: <53D925E2.9040103@us.ibm.com> On 07/07/2014 10:51 AM, Volker Simonis wrote: > Hi Maynard, > > I've opened bug "PPC64: Don't use StubCodeMarks for zero-length stubs" > (https://bugs.openjdk.java.net/browse/JDK-8049441) for this issue. > Until it is resolved in the main code line, you can use the attached > patch to work around the problem. Hi, Volker, Just checking on the status of this bug. Thanks. -Maynard > > Regards, > Volker > > > On Mon, Jul 7, 2014 at 4:18 PM, Maynard Johnson wrote: >> On 07/02/2014 01:21 PM, Volker Simonis wrote: >>> After a quick look I can say that at least for the "flush_icache_stub" >>> and "verify_oop" cases we indeed generate no code. Other platforms >>> like x86 for example generate code for instruction cache flushing. The >>> starting address of this code is saved in a function pointer and >>> called if necessary. On PPC64 we just save the address of a normal >>> C-funtion in this function pointer and implement the cache flush with >>> the help of inline assembler in the C-function. However this saving of >>> the C-function address in the corresponding function pointer is still >>> done in a helper method which triggers the creation of the >>> JvmtiExport::post_dynamic_code_generated_internal event - but with >>> zero size in that case. >>> >>> I agree that it is questionable if we really need to post these events >>> although they didn't hurt until know. Maybe we can remove them - >>> please let me think one more night about it:) >> Any further thoughts on this, Volker? Thanks. >> >> -Maynard >>> >>> Regards, >>> Volker >>> >>> >>> >>> On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: >>>> Hi Maynard, >>>> >>>> I really apologize that I've somehow missed your first message. >>>> ppc-aix-port-dev was the right list to post to. >>>> >>>> I'll analyze this problem instantly and let you know why we post this >>>> zero-code size events. >>>> >>>> Regards, >>>> Volker >>>> >>>> PS: really great to see that somebody is working on oprofile/OpenJDK >>>> integration! >>>> >>>> >>>> On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty >>>> wrote: >>>>> Adding the Serviceability team to the thread since JVM/TI is owned >>>>> by them... >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> On 7/2/14 10:15 AM, Maynard Johnson wrote: >>>>>> >>>>>> Cross-posting to see if Hotspot developers can help. >>>>>> >>>>>> -Maynard >>>>>> >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >>>>>> size of zero >>>>>> Date: Wed, 25 Jun 2014 10:18:17 -0500 >>>>>> From: Maynard Johnson >>>>>> To: ppc-aix-port-dev at openjdk.java.net >>>>>> >>>>>> Hello, PowerPC OpenJDK folks, >>>>>> I am just now starting to get involved in the OpenJDK project. My goal is >>>>>> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >>>>>> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >>>>>> start with since I have some experience from a client perspective with the >>>>>> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >>>>>> provides an agent library that implements the JVMTI API. Using this agent >>>>>> library to profile Java apps on my Intel-based laptop with OpenJDK (using >>>>>> various versions, up to current jdk9-dev) works fine. But the same >>>>>> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >>>>>> miserably. >>>>>> >>>>>> The oprofile agent library registers for callbacks for CompiledMethodLoad, >>>>>> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >>>>>> it writes information about the JVMTI event to a file. After profiling >>>>>> completes, oprofile's post-processing phase involves interpreting the >>>>>> information from the agent library's output file and generating an ELF file >>>>>> to represent the JITed code. When I profile an OpenJDK app on my Power >>>>>> system, the post-processing phase fails while trying to resolve overlapping >>>>>> symbols. The failure is due to the fact that it is unexpectedly finding >>>>>> symbols with code size of zero overlapping at the starting address of some >>>>>> other symbol with non-zero code size. The symbols in question here are from >>>>>> DynamicCodeGenerated events. >>>>>> >>>>>> Are these "code size=0" events valid? If so, I can fix the oprofile code >>>>>> to handle them. If they're not valid, then below is some debug information >>>>>> I've collected so far. >>>>>> >>>>>> ---------------------------- >>>>>> >>>>>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >>>>>> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >>>>>> symbol with code size of zero was detected and then ran the following >>>>>> command: >>>>>> >>>>>> java >>>>>> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >>>>>> -version >>>>>> >>>>>> The debug output from my instrumentation was as follows: >>>>>> >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >>>>>> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >>>>>> openjdk version "1.9.0-internal" >>>>>> OpenJDK Runtime Environment (build >>>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >>>>>> OpenJDK 64-Bit Server VM (build >>>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >>>>>> >>>>>> >>>>>> I don't have access to an AIX system to know if the same issue would be >>>>>> seen there. Let me know if there's any other information I can provide. >>>>>> >>>>>> Thanks for the help. >>>>>> >>>>>> -Maynard >>>>>> >>>>>> >>>>>> >>>>> >>> >> From volker.simonis at gmail.com Wed Jul 30 17:20:48 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Jul 2014 19:20:48 +0200 Subject: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero In-Reply-To: <53D925E2.9040103@us.ibm.com> References: <53AAE839.8050105@us.ibm.com> <53B4300C.7040401@us.ibm.com> <53B43340.6020508@oracle.com> <53BAAC36.8030507@us.ibm.com> <53D925E2.9040103@us.ibm.com> Message-ID: Hi Maynard, as you can see from the bug (https://bugs.openjdk.java.net/browse/JDK-8049441) it was already fixed two weeks ago in http://hg.openjdk.java.net/jdk9/hs-rt. Meanwhile it has also arrived in the jdk9 development code line http://hg.openjdk.java.net/jdk9/dev. Regards, Volker PS: unfortunately it is not possible to add people without OpenJDK "Author" status to the watch list of bugs. So the only chance you have is to manually look at the bug reports you're interested in :( On Wed, Jul 30, 2014 at 7:05 PM, Maynard Johnson wrote: > On 07/07/2014 10:51 AM, Volker Simonis wrote: >> Hi Maynard, >> >> I've opened bug "PPC64: Don't use StubCodeMarks for zero-length stubs" >> (https://bugs.openjdk.java.net/browse/JDK-8049441) for this issue. >> Until it is resolved in the main code line, you can use the attached >> patch to work around the problem. > Hi, Volker, > Just checking on the status of this bug. Thanks. > > -Maynard >> >> Regards, >> Volker >> >> >> On Mon, Jul 7, 2014 at 4:18 PM, Maynard Johnson wrote: >>> On 07/02/2014 01:21 PM, Volker Simonis wrote: >>>> After a quick look I can say that at least for the "flush_icache_stub" >>>> and "verify_oop" cases we indeed generate no code. Other platforms >>>> like x86 for example generate code for instruction cache flushing. The >>>> starting address of this code is saved in a function pointer and >>>> called if necessary. On PPC64 we just save the address of a normal >>>> C-funtion in this function pointer and implement the cache flush with >>>> the help of inline assembler in the C-function. However this saving of >>>> the C-function address in the corresponding function pointer is still >>>> done in a helper method which triggers the creation of the >>>> JvmtiExport::post_dynamic_code_generated_internal event - but with >>>> zero size in that case. >>>> >>>> I agree that it is questionable if we really need to post these events >>>> although they didn't hurt until know. Maybe we can remove them - >>>> please let me think one more night about it:) >>> Any further thoughts on this, Volker? Thanks. >>> >>> -Maynard >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> >>>> On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: >>>>> Hi Maynard, >>>>> >>>>> I really apologize that I've somehow missed your first message. >>>>> ppc-aix-port-dev was the right list to post to. >>>>> >>>>> I'll analyze this problem instantly and let you know why we post this >>>>> zero-code size events. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> PS: really great to see that somebody is working on oprofile/OpenJDK >>>>> integration! >>>>> >>>>> >>>>> On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty >>>>> wrote: >>>>>> Adding the Serviceability team to the thread since JVM/TI is owned >>>>>> by them... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>> On 7/2/14 10:15 AM, Maynard Johnson wrote: >>>>>>> >>>>>>> Cross-posting to see if Hotspot developers can help. >>>>>>> >>>>>>> -Maynard >>>>>>> >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code >>>>>>> size of zero >>>>>>> Date: Wed, 25 Jun 2014 10:18:17 -0500 >>>>>>> From: Maynard Johnson >>>>>>> To: ppc-aix-port-dev at openjdk.java.net >>>>>>> >>>>>>> Hello, PowerPC OpenJDK folks, >>>>>>> I am just now starting to get involved in the OpenJDK project. My goal is >>>>>>> to ensure that the standard serviceability tools and tooling (jdb, JVMTI, >>>>>>> jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to >>>>>>> start with since I have some experience from a client perspective with the >>>>>>> JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) >>>>>>> provides an agent library that implements the JVMTI API. Using this agent >>>>>>> library to profile Java apps on my Intel-based laptop with OpenJDK (using >>>>>>> various versions, up to current jdk9-dev) works fine. But the same >>>>>>> profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails >>>>>>> miserably. >>>>>>> >>>>>>> The oprofile agent library registers for callbacks for CompiledMethodLoad, >>>>>>> CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, >>>>>>> it writes information about the JVMTI event to a file. After profiling >>>>>>> completes, oprofile's post-processing phase involves interpreting the >>>>>>> information from the agent library's output file and generating an ELF file >>>>>>> to represent the JITed code. When I profile an OpenJDK app on my Power >>>>>>> system, the post-processing phase fails while trying to resolve overlapping >>>>>>> symbols. The failure is due to the fact that it is unexpectedly finding >>>>>>> symbols with code size of zero overlapping at the starting address of some >>>>>>> other symbol with non-zero code size. The symbols in question here are from >>>>>>> DynamicCodeGenerated events. >>>>>>> >>>>>>> Are these "code size=0" events valid? If so, I can fix the oprofile code >>>>>>> to handle them. If they're not valid, then below is some debug information >>>>>>> I've collected so far. >>>>>>> >>>>>>> ---------------------------- >>>>>>> >>>>>>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in >>>>>>> hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a >>>>>>> symbol with code size of zero was detected and then ran the following >>>>>>> command: >>>>>>> >>>>>>> java >>>>>>> -agentpath:/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so >>>>>>> -version >>>>>>> >>>>>>> The debug output from my instrumentation was as follows: >>>>>>> >>>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>>> flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080 >>>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>>> throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90 >>>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>>> Code size is ZERO!! Dynamic code generated event sent for >>>>>>> throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600 >>>>>>> Code size is ZERO!! Dynamic code generated event sent for verify_oop; >>>>>>> code begin: 0x3fff6801665c; code end: 0x3fff6801665c >>>>>>> openjdk version "1.9.0-internal" >>>>>>> OpenJDK Runtime Environment (build >>>>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00) >>>>>>> OpenJDK 64-Bit Server VM (build >>>>>>> 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode) >>>>>>> >>>>>>> >>>>>>> I don't have access to an AIX system to know if the same issue would be >>>>>>> seen there. Let me know if there's any other information I can provide. >>>>>>> >>>>>>> Thanks for the help. >>>>>>> >>>>>>> -Maynard >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> > From joe.darcy at oracle.com Thu Jul 31 17:57:40 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 31 Jul 2014 10:57:40 -0700 Subject: JDK 9 RFR of JDK-8054050: Fix stay raw and unchecked lint warnings in core libs Message-ID: <53DA8394.1070203@oracle.com> Hello, There are a few stray raw and unchecked warnings remaining in core libs; please review my fix: JDK-8054050: Fix stay raw and unchecked lint warnings in core libs http://cr.openjdk.java.net/~darcy/8054050.0/ Patch below. Thanks, -Joe --- old/src/share/classes/com/sun/management/GcInfo.java 2014-07-31 10:51:14.000000000 -0700 +++ new/src/share/classes/com/sun/management/GcInfo.java 2014-07-31 10:51:14.000000000 -0700 @@ -267,7 +267,7 @@ return cdata.toString(); } - public Collection values() { + public Collection values() { return cdata.values(); } --- old/src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java 2014-07-31 10:51:14.000000000 -0700 +++ new/src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java 2014-07-31 10:51:14.000000000 -0700 @@ -33,18 +33,18 @@ public class ExpressionParser implements ExpressionParserConstants { - Stack stack = new Stack(); + Stack stack = new Stack<>(); VirtualMachine vm = null; GetFrame frameGetter = null; private static GetFrame lastFrameGetter; private static LValue lastLValue; LValue peek() { - return (LValue)stack.peek(); + return stack.peek(); } LValue pop() { - return (LValue)stack.pop(); + return stack.pop(); } void push(LValue lval) { @@ -915,7 +915,7 @@ } final public void PrimarySuffix() throws ParseException { - List argList; + List argList; switch ((jj_ntk==-1)?jj_ntk():jj_ntk) { case LBRACKET: jj_consume_token(LBRACKET); @@ -993,8 +993,8 @@ jj_consume_token(NULL); } - final public List Arguments() throws ParseException { - List argList = new ArrayList(); + final public List Arguments() throws ParseException { + List argList = new ArrayList<>(); jj_consume_token(LPAREN); switch ((jj_ntk==-1)?jj_ntk():jj_ntk) { case FALSE: @@ -1026,7 +1026,7 @@ throw new Error("Missing return statement in function"); } - final public void ArgumentList(List argList) throws ParseException { + final public void ArgumentList(List argList) throws ParseException { Expression(); argList.add(pop().interiorGetValue()); label_17: @@ -1046,7 +1046,7 @@ } final public void AllocationExpression() throws ParseException { - List argList; String className; + List argList; String className; if (jj_2_7(2)) { jj_consume_token(NEW); PrimitiveType(); --- old/src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java 2014-07-31 10:51:15.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java 2014-07-31 10:51:15.000000000 -0700 @@ -229,9 +229,9 @@ return name.indexOf('[') != -1; } - public Enumeration getInstances(boolean includeSubclasses) { + public Enumeration getInstances(boolean includeSubclasses) { if (includeSubclasses) { - Enumeration res = instances.elements(); + Enumeration res = instances.elements(); for (int i = 0; i < subclasses.length; i++) { res = new CompositeEnumeration(res, subclasses[i].getInstances(true)); --- old/src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java 2014-07-31 10:51:15.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java 2014-07-31 10:51:15.000000000 -0700 @@ -166,11 +166,11 @@ * * @return an Enumeration of JavaHeapObject instances */ - public Enumeration getReferers() { + public Enumeration getReferers() { if (referersLen != -1) { throw new RuntimeException("not resolved: " + getIdString()); } - return new Enumeration() { + return new Enumeration() { private int num = 0; @@ -178,7 +178,7 @@ return referers != null && num < referers.length; } - public Object nextElement() { + public JavaThing nextElement() { return referers[num++]; } }; --- old/src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java 2014-07-31 10:51:16.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java 2014-07-31 10:51:16.000000000 -0700 @@ -54,7 +54,7 @@ private File excludesFile; private long lastModified; - private Hashtable methods; // Hashtable, used as a bag + private Hashtable methods; // Used as a bag /** * Create a new ReachableExcludesImpl over the given file. The file will be --- old/src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java 2014-07-31 10:51:16.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java 2014-07-31 10:51:16.000000000 -0700 @@ -86,7 +86,7 @@ // Now grab the elements into a vector, and sort it in decreasing size JavaThing[] things = new JavaThing[bag.size()]; int i = 0; - for (Enumeration e = bag.elements(); e.hasMoreElements(); ) { + for (Enumeration e = bag.elements(); e.hasMoreElements(); ) { things[i++] = (JavaThing) e.nextElement(); } ArraySorter.sort(things, new Comparer() { @@ -131,7 +131,7 @@ return usedFields; } - private String[] getElements(Hashtable ht) { + private String[] getElements(Hashtable ht) { Object[] keys = ht.keySet().toArray(); int len = keys.length; String[] res = new String[len]; --- old/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java 2014-07-31 10:51:17.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java 2014-07-31 10:51:16.000000000 -0700 @@ -81,7 +81,7 @@ new HashMap(); // soft cache of finalizeable objects - lazily initialized - private SoftReference finalizablesCache; + private SoftReference> finalizablesCache; // represents null reference private JavaThing nullThing; @@ -383,7 +383,7 @@ /** * Return an Iterator of all of the classes in this snapshot. **/ - public Iterator getClasses() { + public Iterator getClasses() { // note that because classes is a TreeMap // classes are already sorted by name return classes.values().iterator(); @@ -395,8 +395,8 @@ return res; } - public synchronized Enumeration getFinalizerObjects() { - Vector obj; + public synchronized Enumeration getFinalizerObjects() { + Vector obj; if (finalizablesCache != null && (obj = finalizablesCache.get()) != null) { return obj.elements(); @@ -418,7 +418,7 @@ finalizables.add(referent); } } - finalizablesCache = new SoftReference(finalizables); + finalizablesCache = new SoftReference>(finalizables); return finalizables.elements(); } @@ -455,7 +455,7 @@ // Even though curr is in the rootset, we want to explore its // referers, because they might be more interesting. } - Enumeration referers = curr.getReferers(); + Enumeration referers = curr.getReferers(); while (referers.hasMoreElements()) { JavaHeapObject t = (JavaHeapObject) referers.nextElement(); if (t != null && !visited.containsKey(t)) { --- old/src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java 2014-07-31 10:51:17.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java 2014-07-31 10:51:17.000000000 -0700 @@ -51,7 +51,7 @@ // create JavaScript engine Method getEngineMethod = managerClass.getMethod("getEngineByName", - new Class[] { String.class }); + new Class[] { String.class }); Object jse = getEngineMethod.invoke(manager, new Object[] {"js"}); oqlSupported = (jse != null); } catch (Exception exp) { @@ -205,9 +205,9 @@ } if (q.className != null) { - Enumeration objects = clazz.getInstances(q.isInstanceOf); + Enumeration objects = clazz.getInstances(q.isInstanceOf); while (objects.hasMoreElements()) { - JavaHeapObject obj = (JavaHeapObject) objects.nextElement(); + JavaHeapObject obj = objects.nextElement(); Object[] args = new Object[] { wrapJavaObject(obj) }; boolean b = (whereCode == null); if (!b) { @@ -265,14 +265,14 @@ // create JavaScript engine Method getEngineMethod = managerClass.getMethod("getEngineByName", - new Class[] { String.class }); + new Class[] { String.class }); engine = getEngineMethod.invoke(manager, new Object[] {"js"}); // initialize engine with init file (hat.js) InputStream strm = getInitStream(); Class engineClass = Class.forName("javax.script.ScriptEngine"); evalMethod = engineClass.getMethod("eval", - new Class[] { Reader.class }); + new Class[] { Reader.class }); evalMethod.invoke(engine, new Object[] {new InputStreamReader(strm)}); // initialize ScriptEngine.eval(String) and @@ -280,13 +280,13 @@ Class invocableClass = Class.forName("javax.script.Invocable"); evalMethod = engineClass.getMethod("eval", - new Class[] { String.class }); + new Class[] { String.class }); invokeMethod = invocableClass.getMethod("invokeFunction", - new Class[] { String.class, Object[].class }); + new Class[] { String.class, Object[].class }); // initialize ScriptEngine.put(String, Object) method Method putMethod = engineClass.getMethod("put", - new Class[] { String.class, Object.class }); + new Class[] { String.class, Object.class }); // call ScriptEngine.put to initialize built-in heap object putMethod.invoke(engine, new Object[] { --- old/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java 2014-07-31 10:51:18.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java 2014-07-31 10:51:17.000000000 -0700 @@ -58,10 +58,10 @@ startHtml("All Classes (including platform)"); } - Iterator classes = snapshot.getClasses(); + Iterator classes = snapshot.getClasses(); String lastPackage = null; while (classes.hasNext()) { - JavaClass clazz = (JavaClass) classes.next(); + JavaClass clazz = classes.next(); if (excludePlatform && PlatformClasses.isPlatformClass(clazz)) { // skip this.. continue; --- old/src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java 2014-07-31 10:51:18.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java 2014-07-31 10:51:18.000000000 -0700 @@ -151,7 +151,7 @@ } out.println("

References to this object:

"); out.flush(); - Enumeration referers = obj.getReferers(); + Enumeration referers = obj.getReferers(); while (referers.hasMoreElements()) { JavaHeapObject ref = (JavaHeapObject) referers.nextElement(); printThing(ref); --- old/src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java 2014-07-31 10:51:19.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java 2014-07-31 10:51:19.000000000 -0700 @@ -37,7 +37,7 @@ public class FinalizerObjectsQuery extends QueryHandler { public void run() { - Enumeration objs = snapshot.getFinalizerObjects(); + Enumeration objs = snapshot.getFinalizerObjects(); startHtml("Objects pending finalization"); out.println("Finalizer summary"); --- old/src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java 2014-07-31 10:51:19.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java 2014-07-31 10:51:19.000000000 -0700 @@ -37,7 +37,7 @@ public class FinalizerSummaryQuery extends QueryHandler { public void run() { - Enumeration objs = snapshot.getFinalizerObjects(); + Enumeration objs = snapshot.getFinalizerObjects(); startHtml("Finalizer Summary"); out.println("

"); @@ -74,7 +74,7 @@ private long count; } - private void printFinalizerSummary(Enumeration objs) { + private void printFinalizerSummary(Enumeration objs) { int count = 0; Map map = new HashMap(); --- old/src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java 2014-07-31 10:51:20.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java 2014-07-31 10:51:20.000000000 -0700 @@ -111,10 +111,10 @@ } out.print(" "); if (snapshot.getHasNewSet()) { - Enumeration objects = clazz.getInstances(false); + Enumeration objects = clazz.getInstances(false); int newInst = 0; while (objects.hasMoreElements()) { - JavaHeapObject obj = (JavaHeapObject)objects.nextElement(); + JavaHeapObject obj = objects.nextElement(); if (obj.isNew()) { newInst++; } --- old/src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java 2014-07-31 10:51:21.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java 2014-07-31 10:51:20.000000000 -0700 @@ -73,11 +73,11 @@ out.print(""); printClass(clazz); out.print("

"); - Enumeration objects = clazz.getInstances(includeSubclasses); + Enumeration objects = clazz.getInstances(includeSubclasses); long totalSize = 0; long instances = 0; while (objects.hasMoreElements()) { - JavaHeapObject obj = (JavaHeapObject) objects.nextElement(); + JavaHeapObject obj = objects.nextElement(); if (newObjects && !obj.isNew()) continue; printThing(obj); --- old/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java 2014-07-31 10:51:21.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java 2014-07-31 10:51:21.000000000 -0700 @@ -47,15 +47,15 @@ } else { Map referrersStat = new HashMap(); final Map refereesStat = new HashMap(); - Enumeration instances = clazz.getInstances(false); + Enumeration instances = clazz.getInstances(false); while (instances.hasMoreElements()) { - JavaHeapObject instance = (JavaHeapObject) instances.nextElement(); + JavaHeapObject instance = instances.nextElement(); if (instance.getId() == -1) { continue; } - Enumeration e = instance.getReferers(); + Enumeration e = instance.getReferers(); while (e.hasMoreElements()) { - JavaHeapObject ref = (JavaHeapObject) e.nextElement(); + JavaHeapObject ref = (JavaHeapObject)e.nextElement(); JavaClass cl = ref.getClazz(); if (cl == null) { System.out.println("null class for " + ref); --- old/src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java 2014-07-31 10:51:22.000000000 -0700 +++ new/src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java 2014-07-31 10:51:21.000000000 -0700 @@ -34,12 +34,13 @@ import java.util.Enumeration; import java.util.NoSuchElementException; +import com.sun.tools.hat.internal.model.JavaHeapObject; -public class CompositeEnumeration implements Enumeration { - Enumeration e1; - Enumeration e2; +public class CompositeEnumeration implements Enumeration { + Enumeration e1; + Enumeration e2; - public CompositeEnumeration(Enumeration e1, Enumeration e2) { + public CompositeEnumeration(Enumeration e1, Enumeration e2) { this.e1 = e1; this.e2 = e2; } @@ -48,7 +49,7 @@ return e1.hasMoreElements() || e2.hasMoreElements(); } - public Object nextElement() { + public JavaHeapObject nextElement() { if (e1.hasMoreElements()) { return e1.nextElement(); } --- old/src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java 2014-07-31 10:51:22.000000000 -0700 +++ new/src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java 2014-07-31 10:51:22.000000000 -0700 @@ -39,7 +39,7 @@ // Warnings from List filters and List[] requestLists is hard to fix. // Remove SuppressWarning when we fix the warnings from List filters // and List[] requestLists. The generic array is not supported. - at SuppressWarnings("unchecked") + at SuppressWarnings({"unchecked", "rawtypes"}) class EventRequestManagerImpl extends MirrorImpl implements EventRequestManager { --- old/src/share/classes/jdk/nio/zipfs/ZipFileAttributeView.java 2014-07-31 10:51:22.000000000 -0700 +++ new/src/share/classes/jdk/nio/zipfs/ZipFileAttributeView.java 2014-07-31 10:51:22.000000000 -0700 @@ -59,6 +59,7 @@ this.isZipView = isZipView; } + @SuppressWarnings("unchecked") // Cast to V static V get(ZipPath path, Class type) { if (type == null) throw new NullPointerException(); --- old/src/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java 2014-07-31 10:51:23.000000000 -0700 +++ new/src/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java 2014-07-31 10:51:23.000000000 -0700 @@ -271,6 +271,7 @@ } @Override + @SuppressWarnings("unchecked") // Cast to A public A readAttributes(Path path, Class type, LinkOption... options) throws IOException --- old/src/solaris/classes/sun/nio/ch/InheritedChannel.java 2014-07-31 10:51:24.000000000 -0700 +++ new/src/solaris/classes/sun/nio/ch/InheritedChannel.java 2014-07-31 10:51:23.000000000 -0700 @@ -165,7 +165,7 @@ // Have to use reflection and also make assumption on how FD // is implemented. - Class paramTypes[] = { int.class }; + Class paramTypes[] = { int.class }; Constructor ctr = Reflect.lookupConstructor("java.io.FileDescriptor", paramTypes); Object args[] = { new Integer(fdVal) }; From lance.andersen at oracle.com Thu Jul 31 18:01:05 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 31 Jul 2014 14:01:05 -0400 Subject: JDK 9 RFR of JDK-8054050: Fix stay raw and unchecked lint warnings in core libs In-Reply-To: <53DA8394.1070203@oracle.com> References: <53DA8394.1070203@oracle.com> Message-ID: <5DC73653-C954-48DA-A616-E401EF754D0B@oracle.com> looks fine joe On Jul 31, 2014, at 1:57 PM, Joe Darcy wrote: > Hello, > > There are a few stray raw and unchecked warnings remaining in core libs; please review my fix: > > JDK-8054050: Fix stay raw and unchecked lint warnings in core libs > http://cr.openjdk.java.net/~darcy/8054050.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/src/share/classes/com/sun/management/GcInfo.java 2014-07-31 10:51:14.000000000 -0700 > +++ new/src/share/classes/com/sun/management/GcInfo.java 2014-07-31 10:51:14.000000000 -0700 > @@ -267,7 +267,7 @@ > return cdata.toString(); > } > > - public Collection values() { > + public Collection values() { > return cdata.values(); > } > > --- old/src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java 2014-07-31 10:51:14.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java 2014-07-31 10:51:14.000000000 -0700 > @@ -33,18 +33,18 @@ > > public class ExpressionParser implements ExpressionParserConstants { > > - Stack stack = new Stack(); > + Stack stack = new Stack<>(); > VirtualMachine vm = null; > GetFrame frameGetter = null; > private static GetFrame lastFrameGetter; > private static LValue lastLValue; > > LValue peek() { > - return (LValue)stack.peek(); > + return stack.peek(); > } > > LValue pop() { > - return (LValue)stack.pop(); > + return stack.pop(); > } > > void push(LValue lval) { > @@ -915,7 +915,7 @@ > } > > final public void PrimarySuffix() throws ParseException { > - List argList; > + List argList; > switch ((jj_ntk==-1)?jj_ntk():jj_ntk) { > case LBRACKET: > jj_consume_token(LBRACKET); > @@ -993,8 +993,8 @@ > jj_consume_token(NULL); > } > > - final public List Arguments() throws ParseException { > - List argList = new ArrayList(); > + final public List Arguments() throws ParseException { > + List argList = new ArrayList<>(); > jj_consume_token(LPAREN); > switch ((jj_ntk==-1)?jj_ntk():jj_ntk) { > case FALSE: > @@ -1026,7 +1026,7 @@ > throw new Error("Missing return statement in function"); > } > > - final public void ArgumentList(List argList) throws ParseException { > + final public void ArgumentList(List argList) throws ParseException { > Expression(); > argList.add(pop().interiorGetValue()); > label_17: > @@ -1046,7 +1046,7 @@ > } > > final public void AllocationExpression() throws ParseException { > - List argList; String className; > + List argList; String className; > if (jj_2_7(2)) { > jj_consume_token(NEW); > PrimitiveType(); > --- old/src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java 2014-07-31 10:51:15.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java 2014-07-31 10:51:15.000000000 -0700 > @@ -229,9 +229,9 @@ > return name.indexOf('[') != -1; > } > > - public Enumeration getInstances(boolean includeSubclasses) { > + public Enumeration getInstances(boolean includeSubclasses) { > if (includeSubclasses) { > - Enumeration res = instances.elements(); > + Enumeration res = instances.elements(); > for (int i = 0; i < subclasses.length; i++) { > res = new CompositeEnumeration(res, > subclasses[i].getInstances(true)); > --- old/src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java 2014-07-31 10:51:15.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java 2014-07-31 10:51:15.000000000 -0700 > @@ -166,11 +166,11 @@ > * > * @return an Enumeration of JavaHeapObject instances > */ > - public Enumeration getReferers() { > + public Enumeration getReferers() { > if (referersLen != -1) { > throw new RuntimeException("not resolved: " + getIdString()); > } > - return new Enumeration() { > + return new Enumeration() { > > private int num = 0; > > @@ -178,7 +178,7 @@ > return referers != null && num < referers.length; > } > > - public Object nextElement() { > + public JavaThing nextElement() { > return referers[num++]; > } > }; > --- old/src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java 2014-07-31 10:51:16.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java 2014-07-31 10:51:16.000000000 -0700 > @@ -54,7 +54,7 @@ > > private File excludesFile; > private long lastModified; > - private Hashtable methods; // Hashtable, used as a bag > + private Hashtable methods; // Used as a bag > > /** > * Create a new ReachableExcludesImpl over the given file. The file will be > --- old/src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java 2014-07-31 10:51:16.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java 2014-07-31 10:51:16.000000000 -0700 > @@ -86,7 +86,7 @@ > // Now grab the elements into a vector, and sort it in decreasing size > JavaThing[] things = new JavaThing[bag.size()]; > int i = 0; > - for (Enumeration e = bag.elements(); e.hasMoreElements(); ) { > + for (Enumeration e = bag.elements(); e.hasMoreElements(); ) { > things[i++] = (JavaThing) e.nextElement(); > } > ArraySorter.sort(things, new Comparer() { > @@ -131,7 +131,7 @@ > return usedFields; > } > > - private String[] getElements(Hashtable ht) { > + private String[] getElements(Hashtable ht) { > Object[] keys = ht.keySet().toArray(); > int len = keys.length; > String[] res = new String[len]; > --- old/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java 2014-07-31 10:51:17.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java 2014-07-31 10:51:16.000000000 -0700 > @@ -81,7 +81,7 @@ > new HashMap(); > > // soft cache of finalizeable objects - lazily initialized > - private SoftReference finalizablesCache; > + private SoftReference> finalizablesCache; > > // represents null reference > private JavaThing nullThing; > @@ -383,7 +383,7 @@ > /** > * Return an Iterator of all of the classes in this snapshot. > **/ > - public Iterator getClasses() { > + public Iterator getClasses() { > // note that because classes is a TreeMap > // classes are already sorted by name > return classes.values().iterator(); > @@ -395,8 +395,8 @@ > return res; > } > > - public synchronized Enumeration getFinalizerObjects() { > - Vector obj; > + public synchronized Enumeration getFinalizerObjects() { > + Vector obj; > if (finalizablesCache != null && > (obj = finalizablesCache.get()) != null) { > return obj.elements(); > @@ -418,7 +418,7 @@ > finalizables.add(referent); > } > } > - finalizablesCache = new SoftReference(finalizables); > + finalizablesCache = new SoftReference>(finalizables); > return finalizables.elements(); > } > > @@ -455,7 +455,7 @@ > // Even though curr is in the rootset, we want to explore its > // referers, because they might be more interesting. > } > - Enumeration referers = curr.getReferers(); > + Enumeration referers = curr.getReferers(); > while (referers.hasMoreElements()) { > JavaHeapObject t = (JavaHeapObject) referers.nextElement(); > if (t != null && !visited.containsKey(t)) { > --- old/src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java 2014-07-31 10:51:17.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java 2014-07-31 10:51:17.000000000 -0700 > @@ -51,7 +51,7 @@ > > // create JavaScript engine > Method getEngineMethod = managerClass.getMethod("getEngineByName", > - new Class[] { String.class }); > + new Class[] { String.class }); > Object jse = getEngineMethod.invoke(manager, new Object[] {"js"}); > oqlSupported = (jse != null); > } catch (Exception exp) { > @@ -205,9 +205,9 @@ > } > > if (q.className != null) { > - Enumeration objects = clazz.getInstances(q.isInstanceOf); > + Enumeration objects = clazz.getInstances(q.isInstanceOf); > while (objects.hasMoreElements()) { > - JavaHeapObject obj = (JavaHeapObject) objects.nextElement(); > + JavaHeapObject obj = objects.nextElement(); > Object[] args = new Object[] { wrapJavaObject(obj) }; > boolean b = (whereCode == null); > if (!b) { > @@ -265,14 +265,14 @@ > > // create JavaScript engine > Method getEngineMethod = managerClass.getMethod("getEngineByName", > - new Class[] { String.class }); > + new Class[] { String.class }); > engine = getEngineMethod.invoke(manager, new Object[] {"js"}); > > // initialize engine with init file (hat.js) > InputStream strm = getInitStream(); > Class engineClass = Class.forName("javax.script.ScriptEngine"); > evalMethod = engineClass.getMethod("eval", > - new Class[] { Reader.class }); > + new Class[] { Reader.class }); > evalMethod.invoke(engine, new Object[] {new InputStreamReader(strm)}); > > // initialize ScriptEngine.eval(String) and > @@ -280,13 +280,13 @@ > Class invocableClass = Class.forName("javax.script.Invocable"); > > evalMethod = engineClass.getMethod("eval", > - new Class[] { String.class }); > + new Class[] { String.class }); > invokeMethod = invocableClass.getMethod("invokeFunction", > - new Class[] { String.class, Object[].class }); > + new Class[] { String.class, Object[].class }); > > // initialize ScriptEngine.put(String, Object) method > Method putMethod = engineClass.getMethod("put", > - new Class[] { String.class, Object.class }); > + new Class[] { String.class, Object.class }); > > // call ScriptEngine.put to initialize built-in heap object > putMethod.invoke(engine, new Object[] { > --- old/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java 2014-07-31 10:51:18.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java 2014-07-31 10:51:17.000000000 -0700 > @@ -58,10 +58,10 @@ > startHtml("All Classes (including platform)"); > } > > - Iterator classes = snapshot.getClasses(); > + Iterator classes = snapshot.getClasses(); > String lastPackage = null; > while (classes.hasNext()) { > - JavaClass clazz = (JavaClass) classes.next(); > + JavaClass clazz = classes.next(); > if (excludePlatform && PlatformClasses.isPlatformClass(clazz)) { > // skip this.. > continue; > --- old/src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java 2014-07-31 10:51:18.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java 2014-07-31 10:51:18.000000000 -0700 > @@ -151,7 +151,7 @@ > } > out.println("

References to this object:

"); > out.flush(); > - Enumeration referers = obj.getReferers(); > + Enumeration referers = obj.getReferers(); > while (referers.hasMoreElements()) { > JavaHeapObject ref = (JavaHeapObject) referers.nextElement(); > printThing(ref); > --- old/src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java 2014-07-31 10:51:19.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java 2014-07-31 10:51:19.000000000 -0700 > @@ -37,7 +37,7 @@ > > public class FinalizerObjectsQuery extends QueryHandler { > public void run() { > - Enumeration objs = snapshot.getFinalizerObjects(); > + Enumeration objs = snapshot.getFinalizerObjects(); > startHtml("Objects pending finalization"); > > out.println("Finalizer summary"); > --- old/src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java 2014-07-31 10:51:19.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java 2014-07-31 10:51:19.000000000 -0700 > @@ -37,7 +37,7 @@ > > public class FinalizerSummaryQuery extends QueryHandler { > public void run() { > - Enumeration objs = snapshot.getFinalizerObjects(); > + Enumeration objs = snapshot.getFinalizerObjects(); > startHtml("Finalizer Summary"); > > out.println("

"); > @@ -74,7 +74,7 @@ > private long count; > } > > - private void printFinalizerSummary(Enumeration objs) { > + private void printFinalizerSummary(Enumeration objs) { > int count = 0; > Map map = new HashMap(); > > --- old/src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java 2014-07-31 10:51:20.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java 2014-07-31 10:51:20.000000000 -0700 > @@ -111,10 +111,10 @@ > } > out.print(" "); > if (snapshot.getHasNewSet()) { > - Enumeration objects = clazz.getInstances(false); > + Enumeration objects = clazz.getInstances(false); > int newInst = 0; > while (objects.hasMoreElements()) { > - JavaHeapObject obj = (JavaHeapObject)objects.nextElement(); > + JavaHeapObject obj = objects.nextElement(); > if (obj.isNew()) { > newInst++; > } > --- old/src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java 2014-07-31 10:51:21.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java 2014-07-31 10:51:20.000000000 -0700 > @@ -73,11 +73,11 @@ > out.print(""); > printClass(clazz); > out.print("

"); > - Enumeration objects = clazz.getInstances(includeSubclasses); > + Enumeration objects = clazz.getInstances(includeSubclasses); > long totalSize = 0; > long instances = 0; > while (objects.hasMoreElements()) { > - JavaHeapObject obj = (JavaHeapObject) objects.nextElement(); > + JavaHeapObject obj = objects.nextElement(); > if (newObjects && !obj.isNew()) > continue; > printThing(obj); > --- old/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java 2014-07-31 10:51:21.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java 2014-07-31 10:51:21.000000000 -0700 > @@ -47,15 +47,15 @@ > } else { > Map referrersStat = new HashMap(); > final Map refereesStat = new HashMap(); > - Enumeration instances = clazz.getInstances(false); > + Enumeration instances = clazz.getInstances(false); > while (instances.hasMoreElements()) { > - JavaHeapObject instance = (JavaHeapObject) instances.nextElement(); > + JavaHeapObject instance = instances.nextElement(); > if (instance.getId() == -1) { > continue; > } > - Enumeration e = instance.getReferers(); > + Enumeration e = instance.getReferers(); > while (e.hasMoreElements()) { > - JavaHeapObject ref = (JavaHeapObject) e.nextElement(); > + JavaHeapObject ref = (JavaHeapObject)e.nextElement(); > JavaClass cl = ref.getClazz(); > if (cl == null) { > System.out.println("null class for " + ref); > --- old/src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java 2014-07-31 10:51:22.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java 2014-07-31 10:51:21.000000000 -0700 > @@ -34,12 +34,13 @@ > > import java.util.Enumeration; > import java.util.NoSuchElementException; > +import com.sun.tools.hat.internal.model.JavaHeapObject; > > -public class CompositeEnumeration implements Enumeration { > - Enumeration e1; > - Enumeration e2; > +public class CompositeEnumeration implements Enumeration { > + Enumeration e1; > + Enumeration e2; > > - public CompositeEnumeration(Enumeration e1, Enumeration e2) { > + public CompositeEnumeration(Enumeration e1, Enumeration e2) { > this.e1 = e1; > this.e2 = e2; > } > @@ -48,7 +49,7 @@ > return e1.hasMoreElements() || e2.hasMoreElements(); > } > > - public Object nextElement() { > + public JavaHeapObject nextElement() { > if (e1.hasMoreElements()) { > return e1.nextElement(); > } > --- old/src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java 2014-07-31 10:51:22.000000000 -0700 > +++ new/src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java 2014-07-31 10:51:22.000000000 -0700 > @@ -39,7 +39,7 @@ > // Warnings from List filters and List[] requestLists is hard to fix. > // Remove SuppressWarning when we fix the warnings from List filters > // and List[] requestLists. The generic array is not supported. > - at SuppressWarnings("unchecked") > + at SuppressWarnings({"unchecked", "rawtypes"}) > class EventRequestManagerImpl extends MirrorImpl > implements EventRequestManager > { > --- old/src/share/classes/jdk/nio/zipfs/ZipFileAttributeView.java 2014-07-31 10:51:22.000000000 -0700 > +++ new/src/share/classes/jdk/nio/zipfs/ZipFileAttributeView.java 2014-07-31 10:51:22.000000000 -0700 > @@ -59,6 +59,7 @@ > this.isZipView = isZipView; > } > > + @SuppressWarnings("unchecked") // Cast to V > static V get(ZipPath path, Class type) { > if (type == null) > throw new NullPointerException(); > --- old/src/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java 2014-07-31 10:51:23.000000000 -0700 > +++ new/src/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java 2014-07-31 10:51:23.000000000 -0700 > @@ -271,6 +271,7 @@ > } > > @Override > + @SuppressWarnings("unchecked") // Cast to A > public A > readAttributes(Path path, Class type, LinkOption... options) > throws IOException > --- old/src/solaris/classes/sun/nio/ch/InheritedChannel.java 2014-07-31 10:51:24.000000000 -0700 > +++ new/src/solaris/classes/sun/nio/ch/InheritedChannel.java 2014-07-31 10:51:23.000000000 -0700 > @@ -165,7 +165,7 @@ > // Have to use reflection and also make assumption on how FD > // is implemented. > > - Class paramTypes[] = { int.class }; > + Class paramTypes[] = { int.class }; > Constructor ctr = Reflect.lookupConstructor("java.io.FileDescriptor", > paramTypes); > Object args[] = { new Integer(fdVal) }; > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Thu Jul 31 18:29:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jul 2014 19:29:31 +0100 Subject: JDK 9 RFR of JDK-8054050: Fix stay raw and unchecked lint warnings in core libs In-Reply-To: <53DA8394.1070203@oracle.com> References: <53DA8394.1070203@oracle.com> Message-ID: <53DA8B0B.2030208@oracle.com> On 31/07/2014 18:57, Joe Darcy wrote: > Hello, > > There are a few stray raw and unchecked warnings remaining in core > libs; please review my fix: > > JDK-8054050: Fix stay raw and unchecked lint warnings in core libs > http://cr.openjdk.java.net/~darcy/8054050.0/ This looks okay to me. -Alan