From david.holmes at oracle.com Sun Mar 1 22:57:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 08:57:13 +1000 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54F0A352.3050809@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> <54F0A352.3050809@oracle.com> Message-ID: <54F39949.9090808@oracle.com> On 28/02/2015 3:03 AM, Mikhailo Seledtsov wrote: > I agree with Staffan that the kind of increase in text execution speed > is worth the effort and risk. Just bear in mind that anyone writing tests needs to be more aware of any assumptions that test makes about the global state of the VM, and what affect the test has on the global state of the VM. My concern with getting this up and running is that the test that fails is not the test that should be being run in othervm - and finding the test that is causing the problem is non-obvious. > Also, the reversal of this change is only a single line of code: > test/Makefile > > JTREG_BASIC_OPTIONS += -agentvm > > The rest of the changes will not harm in any way, and will still be > helpful for people or systems that explicitly specify "-agentvm" option > when running the tests. Perhaps, George could first push all the changes > except for the "-agentvm" change; then run the RBT tests as Staffan > recommends; if that is fine and additional issues resolved, include > "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. I think the slowdown caused by building the test library makes that infeasible. But there's no need to push anything to run it through RBT is there? Also I am still concerned about some of the othervm changes George made that should not be necessary. The CDS tests for example do all their testing by launching other VMs, so the actual CD test should not need to be othervm itself - and indeed with my testing it did not need to be. Thanks, David > Thank you, > Misha > > On 2/27/2015 1:15 AM, Staffan Larsen wrote: >> You are right that this is a risk we are taking. Tests that leave the >> JVM in an un-clean state should be running in main/othervm mode to >> isolate them. It should be noted that if a test fails, then jtreg will >> /not/ reuse that JVM since it can be an unknown state. Still, I?m >> guessing that we will see some initial problems with tests that need >> to be isolated. It would be good to run through the tests in agent >> mode a fair amount of times on all platforms (say 20? - easy to do >> with Remote Build and Test) before we do this change to shake out any >> obvious problems. I think the increased speed of the tests is still >> worth the effort to clean up and isolate some of the tests. >> >> /Staffan >> >>> On 26 feb 2015, at 21:17, David Holmes wrote: >>> >>> I've been thinking more about this change based on Staffan's >>> clarification of how "othervm" is the current default for testing. I >>> think the move to agentvm is very risky and may result in very >>> unpredictable test results. The problem being that tests no longer >>> start out in a clean VM with a pristine state - this can impact many >>> things that might affect how some of the tests execute. And the >>> problems may vary depending on exactly how the tests are run, the >>> concurrency level and number of agent VMs in use. There may not be >>> any guarantee that the same jtreg command line will result in the >>> same tests being executed in the same sequence on the same agent VMs. >>> >>> It may be that the introduction of "main/othervm" in some tests was >>> already an indication of this problem. But the real problem may be >>> the interaction between tests. >>> >>> David >>> >>> On 26/02/2015 6:14 PM, David Holmes wrote: >>>> Hi Staffan, >>>> >>>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thanks for your review. Comments inline: >>>>>> >>>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>>> Please review this fix for JDK-8068685: >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>>> >>>>>>>> >>>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>>> tests, >>>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>>> this, but it seems I was mistaken. :( >>>>>>> >>>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>>> >>>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>> 10:31:03.991071066 -0800 >>>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>> 10:31:03.617052982 -0800 >>>>>>> @@ -35,6 +35,9 @@ >>>>>>> * @test >>>>>>> * @bug 8059624 8064669 >>>>>>> * @library /testlibrary /../../test/lib >>>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>>> + * @ignore 8066998 >>>>>>> + * @library /testlibrary /../../test/lib >>>>>>> * @build ForceNMethodSweepTest >>>>>>> >>>>>>> The second @library shouldn't have been added. >>>>>> Good catch, thanks. Changed. >>>>>> >>>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>> 10:32:28.209143019 -0800 >>>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>> 10:32:27.855125901 -0800 >>>>>>> @@ -22,11 +22,13 @@ >>>>>>> */ >>>>>>> >>>>>>> /* >>>>>>> - * @test TestStringSymbolTableStats.java >>>>>>> + * @test TestStringSymbolTableStats >>>>>>> >>>>>>> Why did you change the @test? I see a lot of unchanged @test >>>>>>> foo.java. >>>>>> According to the jtreg tag >>>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>>> correct. The only tests that were considered for this change >>>>>> included >>>>>> "@library /testlibrary", so I changed this one for consistency with >>>>>> other tests that I've written. I'll change it back if it's a >>>>>> concern. >>>>>>> >>>>>>>> which resulted in longer test execution times. In order to offset >>>>>>>> these >>>>>>>> longer test execution times and to support running jtreg in >>>>>>>> -agentvm >>>>>>>> mode, the following changes were made: >>>>>>>> >>>>>>>> test/Makefile: added -agentvm option >>>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>>> samevm anyway? >>>>>>> >>>>>>> Also does this mean that all VMs will share a single copy of the >>>>>>> testlibrary or will we still have a copy per test that gets built >>>>>>> each time? >>>>>> The jtreg command >>>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>>> >>>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>>> >>>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>>> of this change was to explicitly add "@build >>>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests >>>>>> without >>>>>> increasing test execution times. The analysis below shows decreased >>>>>> test execution times using agentvm. >>>>> Re-reading the documentation, checking the sources and running some >>>>> experiments show that the default mode for jtreg is not samevm, but >>>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs >>>>> will be >>>>> reused for both javac and for the tests. When running in agentmode, >>>>> even >>>>> if a test says ?main/othervm?, the javac invocation of the test will >>>>> happen in the agent. So running in agentvm mode saves time even if all >>>>> tests say ?main/othervm?. >>>> Thanks for clarifying that. It would seem main/othervm is only ever >>>> needed to override -agentvm or -samevm. That makes sense. >>>> >>>> I still wonder how many times the test library gets built per set of >>>> tests ? :) >>>> >>>>> The following passage from the documentation is confusing: >>>>> >>>>> ---- >>>>> Test Mode Options >>>>> >>>>> When the JavaTest harness is used to run tests, two possibly different >>>>> versions of the JDK are used: the JDK version used to run the harness >>>>> and the JDK version used to run the test(s). The following options >>>>> provide a means to specify the JDK version used to run the tests. The >>>>> default is to use the same JDK version (provided by JAVA_HOME) for >>>>> both >>>>> the harness and the tests, and for each test to run in its own JVM. >>>>> ---- >>>>> >>>>> Notice how the last sentence seems to begin by saying samevm mode >>>>> is the >>>>> default, but its really just talking about the version of the JDK used >>>>> to for running the tests. The sentence ends by saying (not very >>>>> explicitly) that othervm is the default mode. I?ll see if we can >>>>> clarify >>>>> that. >>>> It is even more confusing if you take into account that with samevm it >>>> uses the testjdk, but you can also set compilejdk to a different jdk, >>>> which suggests it will run the tests in the same vm as the harness but >>>> launch separate vms to do the compilation. >>>> >>>> Well now I've said that perhaps not so confusing after all :) >>>> >>>> Thanks, >>>> David >>>> >>>>> /Staffan >>>>> >>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: >>>>>>>> added >>>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>>> -othervm >>>>>>>> >>>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>>> >>>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>>> and >>>>>>>> runtime tests were modified with @run so they would run >>>>>>>> successfully >>>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>>> gc, >>>>>>>> runtime, and serviceability teams would be very helpful. >>>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>>> I added @run to some tests, and some of them failed with -agentvm >>>>>> until I added -othervm. >>>>>> >>>>>> -George >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>>> with >>>>>>>> -agentvm. >>>>>>>> >>>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>>> with >>>>>>>> the JPRT hotspot testset.* >>>>>>>> * >>>>>>>> Thanks. >>>>>>>> >>>>>>>> -George > From david.holmes at oracle.com Mon Mar 2 08:27:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Mar 2015 18:27:03 +1000 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F0E791.8020409@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> Message-ID: <54F41ED7.2070208@oracle.com> On 28/02/2015 7:54 AM, Daniel D. Daugherty wrote: > Coleen and David, > > My final attempt to get more acceptable wording for this comment: > > Here's the current wording: > > + // The WatcherThread is not a JavaThread so we do not honor the > + // safepoint protocol for the PeriodicTask_lock. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > How about: > > + // The WatcherThread does not participate in the safepoint protocol > + // for the PeriodicTask_lock because it is not a JavaThread. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > This change would be made in task.cpp: PeriodicTask::real_time_tick() > and thread.cpp: WatcherThread::sleep(). > > Is this acceptable? Fine by me. Thanks, David > Dan > > > On 2/27/15 1:36 PM, Coleen Phillimore wrote: >> >> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>> Coleen, >>> >>> Thanks for the review. Replies embedded below. >>> >>> David, >>> >>> Thanks for jumping in while I was out of the office yesterday. >>> >>> >>> On 2/26/15 12:13 AM, David Holmes wrote: >>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>> >>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>> couple of questions. >>>>>>> >>>>>>> in >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> This comment is really confusing because I think you do in fact >>>>>>> honor >>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>> >>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>> WatcherThread will sometimes acquire locks that potentially check the >>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>> actually taken. Hence we can call the code that will never consider >>>>>> taking them if the only caller of that code (as in this case) is a >>>>>> non-JavaThread. >>>>> >>>>> So you could theoretically have the watcher thread use the regular >>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>> scenes, the safepoint check is elided. >>>> >>>> Yes, internally there is one path for JavaThreads and a different >>>> path for non-JavaThreads. JavaThreads perform thread-state >>>> transitions which form part of the safepoint protocol. >>> >>> So it looks like "honor the safepoint protocol" is bad choice of >>> words. More below. >>> >>> Earlier in this thread, Marcus talked about switching from >>> MutexLockerEx -> MutexLocker and the problem that he ran into >>> with the wait() function. He's planning to explore this idea >>> further using a different bug ID in order to clean up this >>> wart. >>> >>> >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); >> Your explanation makes sense. To be honest, I'm not sure how to >> reword it so it makes more sense, other than to add that the safepoint >> check isn't made anyway for !JavaThreads. >> >> Coleen >>>> >>>>> So the comment really doesn't explain what's going on, and leads >>>>> one to >>>>> believe that you need to be careful _not_ to take a safepoint check >>>>> with >>>>> the Watcher thread. >>>> >>>> I don't read it that way but would it be better if it said "do not >>>> _need to_ honor" instead? >>> >>> Perhaps "does not participate in the safepoint protocol" is >>> better and more clear? >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> I'll stop reading comments again. >>> >>> Please don't. I'm trying to make the comments more clear in an >>> area that is a bit messy. If the comments don't make sense to >>> you, then I need to fix that. >>> >>> >>>>> >>>>> Thanks for the explanation though, the latter part I knew about. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>> honor >>>>>>> the >>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>> >>>>>>> >>>>>>> Because WatcherThread::stop() does safepoint check. >>> >>> WatcherThread::stop() does a safepoint check because it is >>> called by a JavaThread instead of the WatcherThread. I added >>> a new comment that was supposed to make this clear. Is the >>> comment in thread.cpp not clear? >>> >>> >>>>>>> It's unclear >>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>> also. >>>>>>> If so, should they have no_safepoint_check. >>> >>> That's true. It is not clear that the WatcherThread does not call >>> enroll() or disenroll() and I didn't add an assert for this one. >>> As David pointed out earlier in this review thread, the API for >>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>> but we agreed that should be done via another bug ID that is >>> focused on just API cleanup. >>> >>> >>>>>> >>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>> never want to check for safepoints. If the only caller is a >>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>> JavaThread then safepoint checking can only be elided under very >>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>> enrol/disenrol then we should check for safepoints (as the conditions >>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>> methods). >>>>>> >>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>> nervous, but >>>>>>> the comment seems misleading. >>>>>> >>>>>> Hope it is clearer now. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> I honestly don't know enough about the rest to review it. >>> >>> Thanks for taking a look at it anyway. >>> >>> Dan >>> >>> >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>> This should be the last webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>> >>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd like >>>>>>>> to hear from you in this hopefully final round... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, here is the bug's URL: >>>>>>>>> >>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>> >>>>>>>>> Update for testing: I'm taking the new Remote Build and Test (RBT) >>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>> direct >>>>>>>>> Aurora Adhoc jobs... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> My fix for the following bug: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>> >>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>> >>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>> PeriodicTask_lock >>>>>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>>>>> that >>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>> >>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>> PeriodicTask's >>>>>>>>>> execution interval >>>>>>>>>> >>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>> >>>>>>>>>> 2) The reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> Markus G and Coleen >>>>>>>>>> >>>>>>>>>> 3) Alex and Carsten >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here's the webrev URL: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>> will be done with this fix. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > From staffan.larsen at oracle.com Mon Mar 2 08:43:26 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Mar 2015 09:43:26 +0100 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54F39949.9090808@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> <54F0A352.3050809@oracle.com> <54F39949.9090808@oracle.com> Message-ID: > On 1 mar 2015, at 23:57, David Holmes wrote: > > On 28/02/2015 3:03 AM, Mikhailo Seledtsov wrote: >> I agree with Staffan that the kind of increase in text execution speed >> is worth the effort and risk. > > Just bear in mind that anyone writing tests needs to be more aware of any assumptions that test makes about the global state of the VM, and what affect the test has on the global state of the VM. > > My concern with getting this up and running is that the test that fails is not the test that should be being run in othervm - and finding the test that is causing the problem is non-obvious. > >> Also, the reversal of this change is only a single line of code: >> test/Makefile >> >> JTREG_BASIC_OPTIONS += -agentvm >> >> The rest of the changes will not harm in any way, and will still be >> helpful for people or systems that explicitly specify "-agentvm" option >> when running the tests. Perhaps, George could first push all the changes >> except for the "-agentvm" change; then run the RBT tests as Staffan >> recommends; if that is fine and additional issues resolved, include >> "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. > > I think the slowdown caused by building the test library makes that infeasible. But there's no need to push anything to run it through RBT is there? That should be fixed by CODETOOLS-7901315, but we have to wait for the next jtreg promotion. > > Also I am still concerned about some of the othervm changes George made that should not be necessary. The CDS tests for example do all their testing by launching other VMs, so the actual CD test should not need to be othervm itself - and indeed with my testing it did not need to be. I share these concerns. We need to understand better why these changes were needed. /Staffan > > Thanks, > David > >> Thank you, >> Misha >> >> On 2/27/2015 1:15 AM, Staffan Larsen wrote: >>> You are right that this is a risk we are taking. Tests that leave the >>> JVM in an un-clean state should be running in main/othervm mode to >>> isolate them. It should be noted that if a test fails, then jtreg will >>> /not/ reuse that JVM since it can be an unknown state. Still, I?m >>> guessing that we will see some initial problems with tests that need >>> to be isolated. It would be good to run through the tests in agent >>> mode a fair amount of times on all platforms (say 20? - easy to do >>> with Remote Build and Test) before we do this change to shake out any >>> obvious problems. I think the increased speed of the tests is still >>> worth the effort to clean up and isolate some of the tests. >>> >>> /Staffan >>> >>>> On 26 feb 2015, at 21:17, David Holmes wrote: >>>> >>>> I've been thinking more about this change based on Staffan's >>>> clarification of how "othervm" is the current default for testing. I >>>> think the move to agentvm is very risky and may result in very >>>> unpredictable test results. The problem being that tests no longer >>>> start out in a clean VM with a pristine state - this can impact many >>>> things that might affect how some of the tests execute. And the >>>> problems may vary depending on exactly how the tests are run, the >>>> concurrency level and number of agent VMs in use. There may not be >>>> any guarantee that the same jtreg command line will result in the >>>> same tests being executed in the same sequence on the same agent VMs. >>>> >>>> It may be that the introduction of "main/othervm" in some tests was >>>> already an indication of this problem. But the real problem may be >>>> the interaction between tests. >>>> >>>> David >>>> >>>> On 26/02/2015 6:14 PM, David Holmes wrote: >>>>> Hi Staffan, >>>>> >>>>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for your review. Comments inline: >>>>>>> >>>>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>>>> Please review this fix for JDK-8068685: >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>>>> >>>>>>>>> >>>>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>>>> tests, >>>>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>>>> this, but it seems I was mistaken. :( >>>>>>>> >>>>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>>>> >>>>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>> 10:31:03.991071066 -0800 >>>>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>> 10:31:03.617052982 -0800 >>>>>>>> @@ -35,6 +35,9 @@ >>>>>>>> * @test >>>>>>>> * @bug 8059624 8064669 >>>>>>>> * @library /testlibrary /../../test/lib >>>>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>>>> + * @ignore 8066998 >>>>>>>> + * @library /testlibrary /../../test/lib >>>>>>>> * @build ForceNMethodSweepTest >>>>>>>> >>>>>>>> The second @library shouldn't have been added. >>>>>>> Good catch, thanks. Changed. >>>>>>> >>>>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>> 10:32:28.209143019 -0800 >>>>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>> 10:32:27.855125901 -0800 >>>>>>>> @@ -22,11 +22,13 @@ >>>>>>>> */ >>>>>>>> >>>>>>>> /* >>>>>>>> - * @test TestStringSymbolTableStats.java >>>>>>>> + * @test TestStringSymbolTableStats >>>>>>>> >>>>>>>> Why did you change the @test? I see a lot of unchanged @test >>>>>>>> foo.java. >>>>>>> According to the jtreg tag >>>>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>>>> correct. The only tests that were considered for this change >>>>>>> included >>>>>>> "@library /testlibrary", so I changed this one for consistency with >>>>>>> other tests that I've written. I'll change it back if it's a >>>>>>> concern. >>>>>>>> >>>>>>>>> which resulted in longer test execution times. In order to offset >>>>>>>>> these >>>>>>>>> longer test execution times and to support running jtreg in >>>>>>>>> -agentvm >>>>>>>>> mode, the following changes were made: >>>>>>>>> >>>>>>>>> test/Makefile: added -agentvm option >>>>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>>>> samevm anyway? >>>>>>>> >>>>>>>> Also does this mean that all VMs will share a single copy of the >>>>>>>> testlibrary or will we still have a copy per test that gets built >>>>>>>> each time? >>>>>>> The jtreg command >>>>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>>>> >>>>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>>>> >>>>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>>>> of this change was to explicitly add "@build >>>>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests >>>>>>> without >>>>>>> increasing test execution times. The analysis below shows decreased >>>>>>> test execution times using agentvm. >>>>>> Re-reading the documentation, checking the sources and running some >>>>>> experiments show that the default mode for jtreg is not samevm, but >>>>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs >>>>>> will be >>>>>> reused for both javac and for the tests. When running in agentmode, >>>>>> even >>>>>> if a test says ?main/othervm?, the javac invocation of the test will >>>>>> happen in the agent. So running in agentvm mode saves time even if all >>>>>> tests say ?main/othervm?. >>>>> Thanks for clarifying that. It would seem main/othervm is only ever >>>>> needed to override -agentvm or -samevm. That makes sense. >>>>> >>>>> I still wonder how many times the test library gets built per set of >>>>> tests ? :) >>>>> >>>>>> The following passage from the documentation is confusing: >>>>>> >>>>>> ---- >>>>>> Test Mode Options >>>>>> >>>>>> When the JavaTest harness is used to run tests, two possibly different >>>>>> versions of the JDK are used: the JDK version used to run the harness >>>>>> and the JDK version used to run the test(s). The following options >>>>>> provide a means to specify the JDK version used to run the tests. The >>>>>> default is to use the same JDK version (provided by JAVA_HOME) for >>>>>> both >>>>>> the harness and the tests, and for each test to run in its own JVM. >>>>>> ---- >>>>>> >>>>>> Notice how the last sentence seems to begin by saying samevm mode >>>>>> is the >>>>>> default, but its really just talking about the version of the JDK used >>>>>> to for running the tests. The sentence ends by saying (not very >>>>>> explicitly) that othervm is the default mode. I?ll see if we can >>>>>> clarify >>>>>> that. >>>>> It is even more confusing if you take into account that with samevm it >>>>> uses the testjdk, but you can also set compilejdk to a different jdk, >>>>> which suggests it will run the tests in the same vm as the harness but >>>>> launch separate vms to do the compilation. >>>>> >>>>> Well now I've said that perhaps not so confusing after all :) >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: >>>>>>>>> added >>>>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>>>> -othervm >>>>>>>>> >>>>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>>>> >>>>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>>>> and >>>>>>>>> runtime tests were modified with @run so they would run >>>>>>>>> successfully >>>>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>>>> gc, >>>>>>>>> runtime, and serviceability teams would be very helpful. >>>>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>>>> I added @run to some tests, and some of them failed with -agentvm >>>>>>> until I added -othervm. >>>>>>> >>>>>>> -George >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>>>> with >>>>>>>>> -agentvm. >>>>>>>>> >>>>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>>>> with >>>>>>>>> the JPRT hotspot testset.* >>>>>>>>> * >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> -George >> From markus.gronlund at oracle.com Mon Mar 2 12:34:38 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 2 Mar 2015 04:34:38 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Message-ID: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Greetings, Kindly asking for reviews for the following changeset: Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ Description: The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. Analysis: The _wakeup semaphore only allows for a single outstanding operation: CreateSemaphore(NULL, 0, 1, NULL); When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: ::ReleaseSemaphore(wakeup(), 1, NULL); This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. Tests: Jcmd/dcmd test Attach tests Thanks Markus From dmitry.samersoff at oracle.com Mon Mar 2 13:51:35 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 02 Mar 2015 16:51:35 +0300 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <36a97a89-bd11-44b2-8a5f-93202556d574@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Message-ID: <54F46AE7.7040102@oracle.com> Markus, Looks good for me. Excellent finding. Variable 229 BOOL not_exceeding_semaphore_maximum_count = is not used in production and it could lead to a compiler warning. So it might be better to use guarantee instead of assert here. -Dmitry On 2015-03-02 15:34, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus > -- 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 fredrik.arvidsson at oracle.com Mon Mar 2 14:13:28 2015 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Mon, 02 Mar 2015 15:13:28 +0100 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F46AE7.7040102@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F46AE7.7040102@oracle.com> Message-ID: <54F47008.9040103@oracle.com> Hi Markus Looks great. Funny to see that cause of the issue was similar to the things we speculated about the other day :) /Fredrik On 2015-03-02 14:51, Dmitry Samersoff wrote: > Markus, > > Looks good for me. Excellent finding. > > Variable > > 229 BOOL not_exceeding_semaphore_maximum_count = > > is not used in production and it could lead to a compiler warning. > > So it might be better to use guarantee instead of assert here. > > -Dmitry > > On 2015-03-02 15:34, Markus Gronlund wrote: >> Greetings, >> >> >> >> Kindly asking for reviews for the following changeset: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ >> >> >> >> Description: >> >> The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. >> >> >> >> Analysis: >> >> The _wakeup semaphore only allows for a single outstanding operation: >> >> CreateSemaphore(NULL, 0, 1, NULL); >> >> When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 >> >> This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). >> >> >> Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); >> >> This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. >> >> Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... >> This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). >> >> This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. >> >> We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. >> >> >> >> Tests: >> >> >> >> Jcmd/dcmd test >> >> Attach tests >> >> >> >> Thanks >> >> Markus >> > From coleen.phillimore at oracle.com Mon Mar 2 15:02:57 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Mar 2015 10:02:57 -0500 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F0E791.8020409@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> Message-ID: <54F47BA1.80502@oracle.com> Yes, this new comment tells me the secret bit of information I didn't know from looking at that bit of code. thanks, Coleen On 2/27/15, 4:54 PM, Daniel D. Daugherty wrote: > Coleen and David, > > My final attempt to get more acceptable wording for this comment: > > Here's the current wording: > > + // The WatcherThread is not a JavaThread so we do not honor the > + // safepoint protocol for the PeriodicTask_lock. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > How about: > > + // The WatcherThread does not participate in the safepoint protocol > + // for the PeriodicTask_lock because it is not a JavaThread. > MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); > > This change would be made in task.cpp: PeriodicTask::real_time_tick() > and thread.cpp: WatcherThread::sleep(). > > Is this acceptable? > > Dan > > > On 2/27/15 1:36 PM, Coleen Phillimore wrote: >> >> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>> Coleen, >>> >>> Thanks for the review. Replies embedded below. >>> >>> David, >>> >>> Thanks for jumping in while I was out of the office yesterday. >>> >>> >>> On 2/26/15 12:13 AM, David Holmes wrote: >>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>> >>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>> couple of questions. >>>>>>> >>>>>>> in >>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> This comment is really confusing because I think you do in fact >>>>>>> honor >>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>> >>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>> WatcherThread will sometimes acquire locks that potentially check >>>>>> the >>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>> actually taken. Hence we can call the code that will never consider >>>>>> taking them if the only caller of that code (as in this case) is a >>>>>> non-JavaThread. >>>>> >>>>> So you could theoretically have the watcher thread use the regular >>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>> scenes, the safepoint check is elided. >>>> >>>> Yes, internally there is one path for JavaThreads and a different >>>> path for non-JavaThreads. JavaThreads perform thread-state >>>> transitions which form part of the safepoint protocol. >>> >>> So it looks like "honor the safepoint protocol" is bad choice of >>> words. More below. >>> >>> Earlier in this thread, Marcus talked about switching from >>> MutexLockerEx -> MutexLocker and the problem that he ran into >>> with the wait() function. He's planning to explore this idea >>> further using a different bug ID in order to clean up this >>> wart. >>> >>> >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); >> Your explanation makes sense. To be honest, I'm not sure how to >> reword it so it makes more sense, other than to add that the >> safepoint check isn't made anyway for !JavaThreads. >> >> Coleen >>>> >>>>> So the comment really doesn't explain what's going on, and leads >>>>> one to >>>>> believe that you need to be careful _not_ to take a safepoint >>>>> check with >>>>> the Watcher thread. >>>> >>>> I don't read it that way but would it be better if it said "do not >>>> _need to_ honor" instead? >>> >>> Perhaps "does not participate in the safepoint protocol" is >>> better and more clear? >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> I'll stop reading comments again. >>> >>> Please don't. I'm trying to make the comments more clear in an >>> area that is a bit messy. If the comments don't make sense to >>> you, then I need to fix that. >>> >>> >>>>> >>>>> Thanks for the explanation though, the latter part I knew about. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>> honor >>>>>>> the >>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>> >>>>>>> >>>>>>> Because WatcherThread::stop() does safepoint check. >>> >>> WatcherThread::stop() does a safepoint check because it is >>> called by a JavaThread instead of the WatcherThread. I added >>> a new comment that was supposed to make this clear. Is the >>> comment in thread.cpp not clear? >>> >>> >>>>>>> It's unclear >>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>> also. >>>>>>> If so, should they have no_safepoint_check. >>> >>> That's true. It is not clear that the WatcherThread does not call >>> enroll() or disenroll() and I didn't add an assert for this one. >>> As David pointed out earlier in this review thread, the API for >>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>> but we agreed that should be done via another bug ID that is >>> focused on just API cleanup. >>> >>> >>>>>> >>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>> never want to check for safepoints. If the only caller is a >>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>> JavaThread then safepoint checking can only be elided under very >>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>> enrol/disenrol then we should check for safepoints (as the >>>>>> conditions >>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>> methods). >>>>>> >>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>> nervous, but >>>>>>> the comment seems misleading. >>>>>> >>>>>> Hope it is clearer now. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> I honestly don't know enough about the rest to review it. >>> >>> Thanks for taking a look at it anyway. >>> >>> Dan >>> >>> >>>>>>> >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>> This should be the last webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>> >>>>>>>> >>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd >>>>>>>> like >>>>>>>> to hear from you in this hopefully final round... >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Also, here is the bug's URL: >>>>>>>>> >>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>> >>>>>>>>> Update for testing: I'm taking the new Remote Build and Test >>>>>>>>> (RBT) >>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>> direct >>>>>>>>> Aurora Adhoc jobs... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> My fix for the following bug: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>> >>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>> >>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>> PeriodicTask_lock >>>>>>>>>> and some of the surrounding code. This is a targeted review >>>>>>>>>> in that >>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>> >>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>> PeriodicTask's >>>>>>>>>> execution interval >>>>>>>>>> >>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>> >>>>>>>>>> 2) The reviewers for: >>>>>>>>>> >>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>> >>>>>>>>>> Markus G and Coleen >>>>>>>>>> >>>>>>>>>> 3) Alex and Carsten >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here's the webrev URL: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>> will be done with this fix. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > From markus.gronlund at oracle.com Mon Mar 2 15:41:09 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 2 Mar 2015 07:41:09 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F46AE7.7040102@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F46AE7.7040102@oracle.com> Message-ID: <41e88e89-ab52-4868-991c-dc217789c4fb@default> Hi Dmitry, Thanks for taking a look. Also thanks for the hint about using a guarantee instead of an assert - you are right, I will change it accordingly. Cheers Markus -----Original Message----- From: Dmitry Samersoff Sent: den 2 mars 2015 14:52 To: Markus Gronlund; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Markus, Looks good for me. Excellent finding. Variable 229 BOOL not_exceeding_semaphore_maximum_count = is not used in production and it could lead to a compiler warning. So it might be better to use guarantee instead of assert here. -Dmitry On 2015-03-02 15:34, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus > -- 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 markus.gronlund at oracle.com Mon Mar 2 15:49:54 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 2 Mar 2015 07:49:54 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F47008.9040103@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F46AE7.7040102@oracle.com> <54F47008.9040103@oracle.com> Message-ID: Thanks Fredrik for taking a look. Cheers Markus -----Original Message----- From: Fredrik Arvidsson Sent: den 2 mars 2015 15:13 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Hi Markus Looks great. Funny to see that cause of the issue was similar to the things we speculated about the other day :) /Fredrik On 2015-03-02 14:51, Dmitry Samersoff wrote: > Markus, > > Looks good for me. Excellent finding. > > Variable > > 229 BOOL not_exceeding_semaphore_maximum_count = > > is not used in production and it could lead to a compiler warning. > > So it might be better to use guarantee instead of assert here. > > -Dmitry > > On 2015-03-02 15:34, Markus Gronlund wrote: >> Greetings, >> >> >> >> Kindly asking for reviews for the following changeset: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ >> >> >> >> Description: >> >> The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. >> >> >> >> Analysis: >> >> The _wakeup semaphore only allows for a single outstanding operation: >> >> CreateSemaphore(NULL, 0, 1, NULL); >> >> When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the >> semaphore count by 1 >> >> This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). >> >> >> Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); >> >> This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. >> >> Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... >> This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). >> >> This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. >> >> We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. >> >> >> >> Tests: >> >> >> >> Jcmd/dcmd test >> >> Attach tests >> >> >> >> Thanks >> >> Markus >> > From daniel.daugherty at oracle.com Mon Mar 2 15:49:15 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 02 Mar 2015 08:49:15 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F41ED7.2070208@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> <54F41ED7.2070208@oracle.com> Message-ID: <54F4867B.1090704@oracle.com> On 3/2/15 1:27 AM, David Holmes wrote: > On 28/02/2015 7:54 AM, Daniel D. Daugherty wrote: >> Coleen and David, >> >> My final attempt to get more acceptable wording for this comment: >> >> Here's the current wording: >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> How about: >> >> + // The WatcherThread does not participate in the safepoint protocol >> + // for the PeriodicTask_lock because it is not a JavaThread. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> This change would be made in task.cpp: PeriodicTask::real_time_tick() >> and thread.cpp: WatcherThread::sleep(). >> >> Is this acceptable? > > Fine by me. Thanks! Dan > > Thanks, > David > >> Dan >> >> >> On 2/27/15 1:36 PM, Coleen Phillimore wrote: >>> >>> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>>> Coleen, >>>> >>>> Thanks for the review. Replies embedded below. >>>> >>>> David, >>>> >>>> Thanks for jumping in while I was out of the office yesterday. >>>> >>>> >>>> On 2/26/15 12:13 AM, David Holmes wrote: >>>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>>> >>>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>>> couple of questions. >>>>>>>> >>>>>>>> in >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This comment is really confusing because I think you do in fact >>>>>>>> honor >>>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>>> >>>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>>> WatcherThread will sometimes acquire locks that potentially >>>>>>> check the >>>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>>> actually taken. Hence we can call the code that will never consider >>>>>>> taking them if the only caller of that code (as in this case) is a >>>>>>> non-JavaThread. >>>>>> >>>>>> So you could theoretically have the watcher thread use the regular >>>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>>> scenes, the safepoint check is elided. >>>>> >>>>> Yes, internally there is one path for JavaThreads and a different >>>>> path for non-JavaThreads. JavaThreads perform thread-state >>>>> transitions which form part of the safepoint protocol. >>>> >>>> So it looks like "honor the safepoint protocol" is bad choice of >>>> words. More below. >>>> >>>> Earlier in this thread, Marcus talked about switching from >>>> MutexLockerEx -> MutexLocker and the problem that he ran into >>>> with the wait() function. He's planning to explore this idea >>>> further using a different bug ID in order to clean up this >>>> wart. >>>> >>>> >>> >>> + // The WatcherThread is not a JavaThread so we do not honor the >>> + // safepoint protocol for the PeriodicTask_lock. >>> MutexLockerEx ml(PeriodicTask_lock, >>> Mutex::_no_safepoint_check_flag); >>> Your explanation makes sense. To be honest, I'm not sure how to >>> reword it so it makes more sense, other than to add that the safepoint >>> check isn't made anyway for !JavaThreads. >>> >>> Coleen >>>>> >>>>>> So the comment really doesn't explain what's going on, and leads >>>>>> one to >>>>>> believe that you need to be careful _not_ to take a safepoint check >>>>>> with >>>>>> the Watcher thread. >>>>> >>>>> I don't read it that way but would it be better if it said "do not >>>>> _need to_ honor" instead? >>>> >>>> Perhaps "does not participate in the safepoint protocol" is >>>> better and more clear? >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> I'll stop reading comments again. >>>> >>>> Please don't. I'm trying to make the comments more clear in an >>>> area that is a bit messy. If the comments don't make sense to >>>> you, then I need to fix that. >>>> >>>> >>>>>> >>>>>> Thanks for the explanation though, the latter part I knew about. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>>> honor >>>>>>>> the >>>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>>> >>>>>>>> >>>>>>>> Because WatcherThread::stop() does safepoint check. >>>> >>>> WatcherThread::stop() does a safepoint check because it is >>>> called by a JavaThread instead of the WatcherThread. I added >>>> a new comment that was supposed to make this clear. Is the >>>> comment in thread.cpp not clear? >>>> >>>> >>>>>>>> It's unclear >>>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>>> also. >>>>>>>> If so, should they have no_safepoint_check. >>>> >>>> That's true. It is not clear that the WatcherThread does not call >>>> enroll() or disenroll() and I didn't add an assert for this one. >>>> As David pointed out earlier in this review thread, the API for >>>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>>> but we agreed that should be done via another bug ID that is >>>> focused on just API cleanup. >>>> >>>> >>>>>>> >>>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>>> never want to check for safepoints. If the only caller is a >>>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>>> JavaThread then safepoint checking can only be elided under very >>>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>>> enrol/disenrol then we should check for safepoints (as the >>>>>>> conditions >>>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>>> methods). >>>>>>> >>>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>>> nervous, but >>>>>>>> the comment seems misleading. >>>>>>> >>>>>>> Hope it is clearer now. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> I honestly don't know enough about the rest to review it. >>>> >>>> Thanks for taking a look at it anyway. >>>> >>>> Dan >>>> >>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>>> This should be the last webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd >>>>>>>>> like >>>>>>>>> to hear from you in this hopefully final round... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, here is the bug's URL: >>>>>>>>>> >>>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>>> >>>>>>>>>> Update for testing: I'm taking the new Remote Build and Test >>>>>>>>>> (RBT) >>>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>>> direct >>>>>>>>>> Aurora Adhoc jobs... >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> My fix for the following bug: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>>> >>>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>>> >>>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>> and some of the surrounding code. This is a targeted review in >>>>>>>>>>> that >>>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>>> >>>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>>> PeriodicTask's >>>>>>>>>>> execution interval >>>>>>>>>>> >>>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>>> >>>>>>>>>>> 2) The reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> Markus G and Coleen >>>>>>>>>>> >>>>>>>>>>> 3) Alex and Carsten >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here's the webrev URL: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>>> will be done with this fix. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > > From daniel.daugherty at oracle.com Mon Mar 2 15:49:40 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 02 Mar 2015 08:49:40 -0700 Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439) In-Reply-To: <54F47BA1.80502@oracle.com> References: <54E3B646.8050209@oracle.com> <54E4C535.5060506@oracle.com> <54EDFFA5.9070407@oracle.com> <54EE96B6.7050409@oracle.com> <54EE9A25.1050808@oracle.com> <54EEA517.1040708@oracle.com> <54EEC7B3.3070400@oracle.com> <54F0915D.3050700@oracle.com> <54F0D567.8000307@oracle.com> <54F0E791.8020409@oracle.com> <54F47BA1.80502@oracle.com> Message-ID: <54F48694.9070105@oracle.com> Thanks! Dan On 3/2/15 8:02 AM, Coleen Phillimore wrote: > > Yes, this new comment tells me the secret bit of information I didn't > know from looking at that bit of code. > > thanks, > Coleen > > On 2/27/15, 4:54 PM, Daniel D. Daugherty wrote: >> Coleen and David, >> >> My final attempt to get more acceptable wording for this comment: >> >> Here's the current wording: >> >> + // The WatcherThread is not a JavaThread so we do not honor the >> + // safepoint protocol for the PeriodicTask_lock. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> How about: >> >> + // The WatcherThread does not participate in the safepoint protocol >> + // for the PeriodicTask_lock because it is not a JavaThread. >> MutexLockerEx ml(PeriodicTask_lock, >> Mutex::_no_safepoint_check_flag); >> >> This change would be made in task.cpp: PeriodicTask::real_time_tick() >> and thread.cpp: WatcherThread::sleep(). >> >> Is this acceptable? >> >> Dan >> >> >> On 2/27/15 1:36 PM, Coleen Phillimore wrote: >>> >>> On 2/27/15, 10:46 AM, Daniel D. Daugherty wrote: >>>> Coleen, >>>> >>>> Thanks for the review. Replies embedded below. >>>> >>>> David, >>>> >>>> Thanks for jumping in while I was out of the office yesterday. >>>> >>>> >>>> On 2/26/15 12:13 AM, David Holmes wrote: >>>>> On 26/02/2015 2:46 PM, Coleen Phillimore wrote: >>>>>> >>>>>> On 2/25/15, 10:59 PM, David Holmes wrote: >>>>>>> On 26/02/2015 1:44 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi, I think you have better reviewer for this now but I did have a >>>>>>>> couple of questions. >>>>>>>> >>>>>>>> in >>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/src/share/vm/runtime/task.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This comment is really confusing because I think you do in fact >>>>>>>> honor >>>>>>>> the safepoint protocol sometimes for the WatcherThread, true? >>>>>>> >>>>>>> Depends what you mean by "honor the safepoint protocol". The >>>>>>> WatcherThread will sometimes acquire locks that potentially >>>>>>> check the >>>>>>> safepoint state, but as it is not a JavaThread such paths are never >>>>>>> actually taken. Hence we can call the code that will never consider >>>>>>> taking them if the only caller of that code (as in this case) is a >>>>>>> non-JavaThread. >>>>>> >>>>>> So you could theoretically have the watcher thread use the regular >>>>>> MutexLocker, which checks for safepoints, and somewhere behind the >>>>>> scenes, the safepoint check is elided. >>>>> >>>>> Yes, internally there is one path for JavaThreads and a different >>>>> path for non-JavaThreads. JavaThreads perform thread-state >>>>> transitions which form part of the safepoint protocol. >>>> >>>> So it looks like "honor the safepoint protocol" is bad choice of >>>> words. More below. >>>> >>>> Earlier in this thread, Marcus talked about switching from >>>> MutexLockerEx -> MutexLocker and the problem that he ran into >>>> with the wait() function. He's planning to explore this idea >>>> further using a different bug ID in order to clean up this >>>> wart. >>>> >>>> >>> >>> + // The WatcherThread is not a JavaThread so we do not honor the >>> + // safepoint protocol for the PeriodicTask_lock. >>> MutexLockerEx ml(PeriodicTask_lock, Mutex::_no_safepoint_check_flag); >>> Your explanation makes sense. To be honest, I'm not sure how to >>> reword it so it makes more sense, other than to add that the >>> safepoint check isn't made anyway for !JavaThreads. >>> >>> Coleen >>>>> >>>>>> So the comment really doesn't explain what's going on, and leads >>>>>> one to >>>>>> believe that you need to be careful _not_ to take a safepoint >>>>>> check with >>>>>> the Watcher thread. >>>>> >>>>> I don't read it that way but would it be better if it said "do not >>>>> _need to_ honor" instead? >>>> >>>> Perhaps "does not participate in the safepoint protocol" is >>>> better and more clear? >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> I'll stop reading comments again. >>>> >>>> Please don't. I'm trying to make the comments more clear in an >>>> area that is a bit messy. If the comments don't make sense to >>>> you, then I need to fix that. >>>> >>>> >>>>>> >>>>>> Thanks for the explanation though, the latter part I knew about. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>>> 65 // The WatcherThread is not a JavaThread so we do not >>>>>>>> honor >>>>>>>> the >>>>>>>> 66 // safepoint protocol for the PeriodicTask_lock. >>>>>>>> 67 MutexLockerEx ml(PeriodicTask_lock, >>>>>>>> Mutex::_no_safepoint_check_flag); >>>>>>>> >>>>>>>> >>>>>>>> Because WatcherThread::stop() does safepoint check. >>>> >>>> WatcherThread::stop() does a safepoint check because it is >>>> called by a JavaThread instead of the WatcherThread. I added >>>> a new comment that was supposed to make this clear. Is the >>>> comment in thread.cpp not clear? >>>> >>>> >>>>>>>> It's unclear >>>>>>>> whether enroll and disenroll can be called by the WatcherThread >>>>>>>> also. >>>>>>>> If so, should they have no_safepoint_check. >>>> >>>> That's true. It is not clear that the WatcherThread does not call >>>> enroll() or disenroll() and I didn't add an assert for this one. >>>> As David pointed out earlier in this review thread, the API for >>>> the PeriodicTask class needs to be cleaned up a bit. I concur, >>>> but we agreed that should be done via another bug ID that is >>>> focused on just API cleanup. >>>> >>>> >>>>>>> >>>>>>> You can only use MutexLockerEx with _no_safepoint_check_flag if you >>>>>>> never want to check for safepoints. If the only caller is a >>>>>>> non-JavaThread then that is trivially true. If the caller can be a >>>>>>> JavaThread then safepoint checking can only be elided under very >>>>>>> specific circumstances (ie leaf methods with other constraints). If >>>>>>> the lock is to be acquired by JavaThreads, as is the case with >>>>>>> enrol/disenrol then we should check for safepoints (as the >>>>>>> conditions >>>>>>> for eliding safepoint checks for JavaThreads are not met by those >>>>>>> methods). >>>>>>> >>>>>>>> The whole safepoint checking inconsistency still makes me >>>>>>>> nervous, but >>>>>>>> the comment seems misleading. >>>>>>> >>>>>>> Hope it is clearer now. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> I honestly don't know enough about the rest to review it. >>>> >>>> Thanks for taking a look at it anyway. >>>> >>>> Dan >>>> >>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 2/25/15, 12:00 PM, Daniel D. Daugherty wrote: >>>>>>>>> This should be the last webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/2-for_jdk9_hs_rt/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Coleen, since you were one of my reviewers on JDK-8047720, I'd >>>>>>>>> like >>>>>>>>> to hear from you in this hopefully final round... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/18/15 10:00 AM, Daniel D. Daugherty wrote: >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> Here is an updated webrev after addressing David H's comments: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/1-for_jdk9_hs_rt/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, here is the bug's URL: >>>>>>>>>> >>>>>>>>>> JDK-8072439 fix for 8047720 may need more work >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8072439 >>>>>>>>>> >>>>>>>>>> Update for testing: I'm taking the new Remote Build and Test >>>>>>>>>> (RBT) >>>>>>>>>> system for a ride during its beta period so I won't be doing >>>>>>>>>> direct >>>>>>>>>> Aurora Adhoc jobs... >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/17/15 2:44 PM, Daniel D. Daugherty wrote: >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> My fix for the following bug: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> that was pushed to JDK9 last June needs to be cleaned up. >>>>>>>>>>> >>>>>>>>>>> Thanks to Alex Garthwaite (agarthwaite at twitter.com) and Carsten >>>>>>>>>>> Varming (varming at gmail.com) for reporting the mess that I made >>>>>>>>>>> in WatcherThread::stop() and for suggesting fixes. >>>>>>>>>>> >>>>>>>>>>> This code review is for a general cleanup pass on >>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>> and some of the surrounding code. This is a targeted review >>>>>>>>>>> in that >>>>>>>>>>> I would like to hear from three groups of people: >>>>>>>>>>> >>>>>>>>>>> 1) The author and reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-7127792 Add the ability to change an existing >>>>>>>>>>> PeriodicTask's >>>>>>>>>>> execution interval >>>>>>>>>>> >>>>>>>>>>> Rickard, David H, and Markus G. >>>>>>>>>>> >>>>>>>>>>> 2) The reviewers for: >>>>>>>>>>> >>>>>>>>>>> JDK-8047720 Xprof hangs on Solaris >>>>>>>>>>> >>>>>>>>>>> Markus G and Coleen >>>>>>>>>>> >>>>>>>>>>> 3) Alex and Carsten >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here's the webrev URL: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8072439-webrev/0-for_jdk9_hs_rt/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've attached the original RFR for JDK-8047720 that explains >>>>>>>>>>> the original deadlock that was being fixed. Similar testing >>>>>>>>>>> will be done with this fix. >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From george.triantafillou at oracle.com Mon Mar 2 18:07:33 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Mon, 02 Mar 2015 13:07:33 -0500 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> <54F0A352.3050809@oracle.com> <54F39949.9090808@oracle.com> Message-ID: <54F4A6E5.6040501@oracle.com> Staffan and David, Thanks for your comments. Based on your comments and findings, I propose the following changes to the patch: - remove -agentvm - revert changes to tests where -othervm was added in order for the tests to pass I'll wait for the next jtreg promotion with CODETOOLS-7901315 before submitting an updated patch for review. Thanks. -George On 3/2/2015 3:43 AM, Staffan Larsen wrote: >> On 1 mar 2015, at 23:57, David Holmes wrote: >> >> On 28/02/2015 3:03 AM, Mikhailo Seledtsov wrote: >>> I agree with Staffan that the kind of increase in text execution speed >>> is worth the effort and risk. >> Just bear in mind that anyone writing tests needs to be more aware of any assumptions that test makes about the global state of the VM, and what affect the test has on the global state of the VM. >> >> My concern with getting this up and running is that the test that fails is not the test that should be being run in othervm - and finding the test that is causing the problem is non-obvious. >> >>> Also, the reversal of this change is only a single line of code: >>> test/Makefile >>> >>> JTREG_BASIC_OPTIONS += -agentvm >>> >>> The rest of the changes will not harm in any way, and will still be >>> helpful for people or systems that explicitly specify "-agentvm" option >>> when running the tests. Perhaps, George could first push all the changes >>> except for the "-agentvm" change; then run the RBT tests as Staffan >>> recommends; if that is fine and additional issues resolved, include >>> "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. >> I think the slowdown caused by building the test library makes that infeasible. But there's no need to push anything to run it through RBT is there? > That should be fixed by CODETOOLS-7901315, but we have to wait for the next jtreg promotion. > >> Also I am still concerned about some of the othervm changes George made that should not be necessary. The CDS tests for example do all their testing by launching other VMs, so the actual CD test should not need to be othervm itself - and indeed with my testing it did not need to be. > I share these concerns. We need to understand better why these changes were needed. > > /Staffan > >> Thanks, >> David >> >>> Thank you, >>> Misha >>> >>> On 2/27/2015 1:15 AM, Staffan Larsen wrote: >>>> You are right that this is a risk we are taking. Tests that leave the >>>> JVM in an un-clean state should be running in main/othervm mode to >>>> isolate them. It should be noted that if a test fails, then jtreg will >>>> /not/ reuse that JVM since it can be an unknown state. Still, I?m >>>> guessing that we will see some initial problems with tests that need >>>> to be isolated. It would be good to run through the tests in agent >>>> mode a fair amount of times on all platforms (say 20? - easy to do >>>> with Remote Build and Test) before we do this change to shake out any >>>> obvious problems. I think the increased speed of the tests is still >>>> worth the effort to clean up and isolate some of the tests. >>>> >>>> /Staffan >>>> >>>>> On 26 feb 2015, at 21:17, David Holmes wrote: >>>>> >>>>> I've been thinking more about this change based on Staffan's >>>>> clarification of how "othervm" is the current default for testing. I >>>>> think the move to agentvm is very risky and may result in very >>>>> unpredictable test results. The problem being that tests no longer >>>>> start out in a clean VM with a pristine state - this can impact many >>>>> things that might affect how some of the tests execute. And the >>>>> problems may vary depending on exactly how the tests are run, the >>>>> concurrency level and number of agent VMs in use. There may not be >>>>> any guarantee that the same jtreg command line will result in the >>>>> same tests being executed in the same sequence on the same agent VMs. >>>>> >>>>> It may be that the introduction of "main/othervm" in some tests was >>>>> already an indication of this problem. But the real problem may be >>>>> the interaction between tests. >>>>> >>>>> David >>>>> >>>>> On 26/02/2015 6:14 PM, David Holmes wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for your review. Comments inline: >>>>>>>> >>>>>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>>>>> Please review this fix for JDK-8068685: >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>>>>> tests, >>>>>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>>>>> this, but it seems I was mistaken. :( >>>>>>>>> >>>>>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>>>>> >>>>>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>>> 10:31:03.991071066 -0800 >>>>>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>>> 10:31:03.617052982 -0800 >>>>>>>>> @@ -35,6 +35,9 @@ >>>>>>>>> * @test >>>>>>>>> * @bug 8059624 8064669 >>>>>>>>> * @library /testlibrary /../../test/lib >>>>>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>>>>> + * @ignore 8066998 >>>>>>>>> + * @library /testlibrary /../../test/lib >>>>>>>>> * @build ForceNMethodSweepTest >>>>>>>>> >>>>>>>>> The second @library shouldn't have been added. >>>>>>>> Good catch, thanks. Changed. >>>>>>>> >>>>>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>>> 10:32:28.209143019 -0800 >>>>>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>>> 10:32:27.855125901 -0800 >>>>>>>>> @@ -22,11 +22,13 @@ >>>>>>>>> */ >>>>>>>>> >>>>>>>>> /* >>>>>>>>> - * @test TestStringSymbolTableStats.java >>>>>>>>> + * @test TestStringSymbolTableStats >>>>>>>>> >>>>>>>>> Why did you change the @test? I see a lot of unchanged @test >>>>>>>>> foo.java. >>>>>>>> According to the jtreg tag >>>>>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>>>>> correct. The only tests that were considered for this change >>>>>>>> included >>>>>>>> "@library /testlibrary", so I changed this one for consistency with >>>>>>>> other tests that I've written. I'll change it back if it's a >>>>>>>> concern. >>>>>>>>>> which resulted in longer test execution times. In order to offset >>>>>>>>>> these >>>>>>>>>> longer test execution times and to support running jtreg in >>>>>>>>>> -agentvm >>>>>>>>>> mode, the following changes were made: >>>>>>>>>> >>>>>>>>>> test/Makefile: added -agentvm option >>>>>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>>>>> samevm anyway? >>>>>>>>> >>>>>>>>> Also does this mean that all VMs will share a single copy of the >>>>>>>>> testlibrary or will we still have a copy per test that gets built >>>>>>>>> each time? >>>>>>>> The jtreg command >>>>>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>>>>> >>>>>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>>>>> >>>>>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>>>>> of this change was to explicitly add "@build >>>>>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests >>>>>>>> without >>>>>>>> increasing test execution times. The analysis below shows decreased >>>>>>>> test execution times using agentvm. >>>>>>> Re-reading the documentation, checking the sources and running some >>>>>>> experiments show that the default mode for jtreg is not samevm, but >>>>>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>>>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs >>>>>>> will be >>>>>>> reused for both javac and for the tests. When running in agentmode, >>>>>>> even >>>>>>> if a test says ?main/othervm?, the javac invocation of the test will >>>>>>> happen in the agent. So running in agentvm mode saves time even if all >>>>>>> tests say ?main/othervm?. >>>>>> Thanks for clarifying that. It would seem main/othervm is only ever >>>>>> needed to override -agentvm or -samevm. That makes sense. >>>>>> >>>>>> I still wonder how many times the test library gets built per set of >>>>>> tests ? :) >>>>>> >>>>>>> The following passage from the documentation is confusing: >>>>>>> >>>>>>> ---- >>>>>>> Test Mode Options >>>>>>> >>>>>>> When the JavaTest harness is used to run tests, two possibly different >>>>>>> versions of the JDK are used: the JDK version used to run the harness >>>>>>> and the JDK version used to run the test(s). The following options >>>>>>> provide a means to specify the JDK version used to run the tests. The >>>>>>> default is to use the same JDK version (provided by JAVA_HOME) for >>>>>>> both >>>>>>> the harness and the tests, and for each test to run in its own JVM. >>>>>>> ---- >>>>>>> >>>>>>> Notice how the last sentence seems to begin by saying samevm mode >>>>>>> is the >>>>>>> default, but its really just talking about the version of the JDK used >>>>>>> to for running the tests. The sentence ends by saying (not very >>>>>>> explicitly) that othervm is the default mode. I?ll see if we can >>>>>>> clarify >>>>>>> that. >>>>>> It is even more confusing if you take into account that with samevm it >>>>>> uses the testjdk, but you can also set compilejdk to a different jdk, >>>>>> which suggests it will run the tests in the same vm as the harness but >>>>>> launch separate vms to do the compilation. >>>>>> >>>>>> Well now I've said that perhaps not so confusing after all :) >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: >>>>>>>>>> added >>>>>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>>>>> -othervm >>>>>>>>>> >>>>>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>>>>> >>>>>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>>>>> and >>>>>>>>>> runtime tests were modified with @run so they would run >>>>>>>>>> successfully >>>>>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>>>>> gc, >>>>>>>>>> runtime, and serviceability teams would be very helpful. >>>>>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>>>>> I added @run to some tests, and some of them failed with -agentvm >>>>>>>> until I added -othervm. >>>>>>>> >>>>>>>> -George >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>>>>> with >>>>>>>>>> -agentvm. >>>>>>>>>> >>>>>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>>>>> with >>>>>>>>>> the JPRT hotspot testset.* >>>>>>>>>> * >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> -George From poonam.bajaj at oracle.com Mon Mar 2 18:29:30 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Mon, 02 Mar 2015 10:29:30 -0800 Subject: [8u] Request for approval: JDK-8043224: -Xcheck:jni improvements to exception checking and excessive local refs In-Reply-To: <54F0B797.6090700@oracle.com> References: <54F0B797.6090700@oracle.com> Message-ID: <54F4AC0A.4030802@oracle.com> Hello, Could I have reviews and approval for this backport to 8u. Thanks, Poonam On 2/27/2015 10:29 AM, Poonam Bajaj Parhar wrote: > Hello, > > I'd like to backport the fix of 8043224 to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043224 > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/232dbf06eb07 > 8u webrev: http://cr.openjdk.java.net/~poonam/8043224/webrev/ > Build and Test: JPRT > > The fix applies cleanly to 8u. > > Thanks, > Poonam > From staffan.larsen at oracle.com Mon Mar 2 19:36:28 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 2 Mar 2015 20:36:28 +0100 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54F4A6E5.6040501@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> <54F0A352.3050809@oracle.com> <54F39949.9090808@oracle.com> <54F4A6E5.6040501@oracle.com> Message-ID: Thanks George! > On 2 mar 2015, at 19:07, George Triantafillou wrote: > > Staffan and David, > > Thanks for your comments. Based on your comments and findings, I propose the following changes to the patch: > > - remove -agentvm > - revert changes to tests where -othervm was added in order for the tests to pass > > I'll wait for the next jtreg promotion with CODETOOLS-7901315 before submitting an updated patch for review. Thanks. > > -George > > On 3/2/2015 3:43 AM, Staffan Larsen wrote: >>> On 1 mar 2015, at 23:57, David Holmes wrote: >>> >>> On 28/02/2015 3:03 AM, Mikhailo Seledtsov wrote: >>>> I agree with Staffan that the kind of increase in text execution speed >>>> is worth the effort and risk. >>> Just bear in mind that anyone writing tests needs to be more aware of any assumptions that test makes about the global state of the VM, and what affect the test has on the global state of the VM. >>> >>> My concern with getting this up and running is that the test that fails is not the test that should be being run in othervm - and finding the test that is causing the problem is non-obvious. >>> >>>> Also, the reversal of this change is only a single line of code: >>>> test/Makefile >>>> >>>> JTREG_BASIC_OPTIONS += -agentvm >>>> >>>> The rest of the changes will not harm in any way, and will still be >>>> helpful for people or systems that explicitly specify "-agentvm" option >>>> when running the tests. Perhaps, George could first push all the changes >>>> except for the "-agentvm" change; then run the RBT tests as Staffan >>>> recommends; if that is fine and additional issues resolved, include >>>> "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. >>> I think the slowdown caused by building the test library makes that infeasible. But there's no need to push anything to run it through RBT is there? >> That should be fixed by CODETOOLS-7901315, but we have to wait for the next jtreg promotion. >> >>> Also I am still concerned about some of the othervm changes George made that should not be necessary. The CDS tests for example do all their testing by launching other VMs, so the actual CD test should not need to be othervm itself - and indeed with my testing it did not need to be. >> I share these concerns. We need to understand better why these changes were needed. >> >> /Staffan >> >>> Thanks, >>> David >>> >>>> Thank you, >>>> Misha >>>> >>>> On 2/27/2015 1:15 AM, Staffan Larsen wrote: >>>>> You are right that this is a risk we are taking. Tests that leave the >>>>> JVM in an un-clean state should be running in main/othervm mode to >>>>> isolate them. It should be noted that if a test fails, then jtreg will >>>>> /not/ reuse that JVM since it can be an unknown state. Still, I?m >>>>> guessing that we will see some initial problems with tests that need >>>>> to be isolated. It would be good to run through the tests in agent >>>>> mode a fair amount of times on all platforms (say 20? - easy to do >>>>> with Remote Build and Test) before we do this change to shake out any >>>>> obvious problems. I think the increased speed of the tests is still >>>>> worth the effort to clean up and isolate some of the tests. >>>>> >>>>> /Staffan >>>>> >>>>>> On 26 feb 2015, at 21:17, David Holmes wrote: >>>>>> >>>>>> I've been thinking more about this change based on Staffan's >>>>>> clarification of how "othervm" is the current default for testing. I >>>>>> think the move to agentvm is very risky and may result in very >>>>>> unpredictable test results. The problem being that tests no longer >>>>>> start out in a clean VM with a pristine state - this can impact many >>>>>> things that might affect how some of the tests execute. And the >>>>>> problems may vary depending on exactly how the tests are run, the >>>>>> concurrency level and number of agent VMs in use. There may not be >>>>>> any guarantee that the same jtreg command line will result in the >>>>>> same tests being executed in the same sequence on the same agent VMs. >>>>>> >>>>>> It may be that the introduction of "main/othervm" in some tests was >>>>>> already an indication of this problem. But the real problem may be >>>>>> the interaction between tests. >>>>>> >>>>>> David >>>>>> >>>>>> On 26/02/2015 6:14 PM, David Holmes wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>>>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thanks for your review. Comments inline: >>>>>>>>> >>>>>>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>>>>>> Please review this fix for JDK-8068685: >>>>>>>>>>> >>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>>>>>> tests, >>>>>>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>>>>>> this, but it seems I was mistaken. :( >>>>>>>>>> >>>>>>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>>>>>> >>>>>>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>>>> 10:31:03.991071066 -0800 >>>>>>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>>>>>> 10:31:03.617052982 -0800 >>>>>>>>>> @@ -35,6 +35,9 @@ >>>>>>>>>> * @test >>>>>>>>>> * @bug 8059624 8064669 >>>>>>>>>> * @library /testlibrary /../../test/lib >>>>>>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>>>>>> + * @ignore 8066998 >>>>>>>>>> + * @library /testlibrary /../../test/lib >>>>>>>>>> * @build ForceNMethodSweepTest >>>>>>>>>> >>>>>>>>>> The second @library shouldn't have been added. >>>>>>>>> Good catch, thanks. Changed. >>>>>>>>> >>>>>>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>>>> 10:32:28.209143019 -0800 >>>>>>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>>>>>> 10:32:27.855125901 -0800 >>>>>>>>>> @@ -22,11 +22,13 @@ >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> /* >>>>>>>>>> - * @test TestStringSymbolTableStats.java >>>>>>>>>> + * @test TestStringSymbolTableStats >>>>>>>>>> >>>>>>>>>> Why did you change the @test? I see a lot of unchanged @test >>>>>>>>>> foo.java. >>>>>>>>> According to the jtreg tag >>>>>>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>>>>>> correct. The only tests that were considered for this change >>>>>>>>> included >>>>>>>>> "@library /testlibrary", so I changed this one for consistency with >>>>>>>>> other tests that I've written. I'll change it back if it's a >>>>>>>>> concern. >>>>>>>>>>> which resulted in longer test execution times. In order to offset >>>>>>>>>>> these >>>>>>>>>>> longer test execution times and to support running jtreg in >>>>>>>>>>> -agentvm >>>>>>>>>>> mode, the following changes were made: >>>>>>>>>>> >>>>>>>>>>> test/Makefile: added -agentvm option >>>>>>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>>>>>> samevm anyway? >>>>>>>>>> >>>>>>>>>> Also does this mean that all VMs will share a single copy of the >>>>>>>>>> testlibrary or will we still have a copy per test that gets built >>>>>>>>>> each time? >>>>>>>>> The jtreg command >>>>>>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>>>>>> >>>>>>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>>>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>>>>>> >>>>>>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>>>>>> of this change was to explicitly add "@build >>>>>>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests >>>>>>>>> without >>>>>>>>> increasing test execution times. The analysis below shows decreased >>>>>>>>> test execution times using agentvm. >>>>>>>> Re-reading the documentation, checking the sources and running some >>>>>>>> experiments show that the default mode for jtreg is not samevm, but >>>>>>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>>>>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs >>>>>>>> will be >>>>>>>> reused for both javac and for the tests. When running in agentmode, >>>>>>>> even >>>>>>>> if a test says ?main/othervm?, the javac invocation of the test will >>>>>>>> happen in the agent. So running in agentvm mode saves time even if all >>>>>>>> tests say ?main/othervm?. >>>>>>> Thanks for clarifying that. It would seem main/othervm is only ever >>>>>>> needed to override -agentvm or -samevm. That makes sense. >>>>>>> >>>>>>> I still wonder how many times the test library gets built per set of >>>>>>> tests ? :) >>>>>>> >>>>>>>> The following passage from the documentation is confusing: >>>>>>>> >>>>>>>> ---- >>>>>>>> Test Mode Options >>>>>>>> >>>>>>>> When the JavaTest harness is used to run tests, two possibly different >>>>>>>> versions of the JDK are used: the JDK version used to run the harness >>>>>>>> and the JDK version used to run the test(s). The following options >>>>>>>> provide a means to specify the JDK version used to run the tests. The >>>>>>>> default is to use the same JDK version (provided by JAVA_HOME) for >>>>>>>> both >>>>>>>> the harness and the tests, and for each test to run in its own JVM. >>>>>>>> ---- >>>>>>>> >>>>>>>> Notice how the last sentence seems to begin by saying samevm mode >>>>>>>> is the >>>>>>>> default, but its really just talking about the version of the JDK used >>>>>>>> to for running the tests. The sentence ends by saying (not very >>>>>>>> explicitly) that othervm is the default mode. I?ll see if we can >>>>>>>> clarify >>>>>>>> that. >>>>>>> It is even more confusing if you take into account that with samevm it >>>>>>> uses the testjdk, but you can also set compilejdk to a different jdk, >>>>>>> which suggests it will run the tests in the same vm as the harness but >>>>>>> launch separate vms to do the compilation. >>>>>>> >>>>>>> Well now I've said that perhaps not so confusing after all :) >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: >>>>>>>>>>> added >>>>>>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>>>>>> -othervm >>>>>>>>>>> >>>>>>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>>>>>> >>>>>>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>>>>>> and >>>>>>>>>>> runtime tests were modified with @run so they would run >>>>>>>>>>> successfully >>>>>>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>>>>>> gc, >>>>>>>>>>> runtime, and serviceability teams would be very helpful. >>>>>>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>>>>>> I added @run to some tests, and some of them failed with -agentvm >>>>>>>>> until I added -othervm. >>>>>>>>> >>>>>>>>> -George >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>>>>>> with >>>>>>>>>>> -agentvm. >>>>>>>>>>> >>>>>>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>>>>>> with >>>>>>>>>>> the JPRT hotspot testset.* >>>>>>>>>>> * >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> -George > From dean.long at oracle.com Tue Mar 3 01:32:17 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Mar 2015 17:32:17 -0800 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <36a97a89-bd11-44b2-8a5f-93202556d574@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> Message-ID: <54F50F21.5040104@oracle.com> Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. dl On 3/2/2015 4:34 AM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus From markus.gronlund at oracle.com Tue Mar 3 09:15:21 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 3 Mar 2015 01:15:21 -0800 (PST) Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <54F50F21.5040104@oracle.com> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F50F21.5040104@oracle.com> Message-ID: <4abbf698-202a-43cc-8b9b-59926a629e07@default> Hi Dean, Thanks for your input. I think a monitor would be less ideal here: A monitor would introduce blocking in enqueuing operations. The "posters" are (in this case) remotely injected threads (by another process), and the processes injecting those threads are in WaitForSingleObject() on those thread handles. If a monitor is used, it needs to be held by the AttachListener over executing (arbitrary) operations. Granted, each operation today is being executed in serial fashion (but it does not need to be), but I believe we would not like to have each client also block on the monitor as part of enqueuing their operation, just in order to issue the notify. With a Windows Semaphore, clients can act asynchronously in regard to enqueuing. As long as the semaphore's current count is > 0, there is no blocking on the part of the AttachListener thread, WaitForSingleObject() return immediately decrementing the current count. Thanks Markus -----Original Message----- From: Dean Long Sent: den 3 mars 2015 02:32 To: Markus Gronlund; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. dl On 3/2/2015 4:34 AM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ > > > > Description: > > The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. > > > > Analysis: > > The _wakeup semaphore only allows for a single outstanding operation: > > CreateSemaphore(NULL, 0, 1, NULL); > > When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: > > ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore > count by 1 > > This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). > > > Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: > > ::ReleaseSemaphore(wakeup(), 1, NULL); > > This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. > > Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... > This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). > > This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. > > > > Tests: > > > > Jcmd/dcmd test > > Attach tests > > > > Thanks > > Markus From chris.plummer at oracle.com Tue Mar 3 15:33:31 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 03 Mar 2015 07:33:31 -0800 Subject: [9] RFR (S) 8069111: Investigate NMT detail tracking support for 32bit ARM Message-ID: <54F5D44B.8020103@oracle.com> Please help with the review for the changes for JDK-8069111: Webrev: http://cr.openjdk.java.net/~cjplummer/8069111/webrev.06/ Bug: https://bugs.openjdk.java.net/browse/JDK-8069111 Tested with JPRT, including running all NMT tests and vmerror.sh. Many of the changes are in closed code. For the open code, the main changes are to no longer support the PLATFORM_NATIVE_STACK_WALKING_SUPPORTED macro, and no longer allow platforms to include NMT but not include NMT Detail support. The NMT tests have been modified to reflect this. They no longer check if NMT Detail is supported and adjust the testing based on this. The removal of @ignore in some tests is because the cause of these test failures is fixed in the closed changes. thanks, Chris From dean.long at oracle.com Tue Mar 3 19:36:44 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 03 Mar 2015 11:36:44 -0800 Subject: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) In-Reply-To: <4abbf698-202a-43cc-8b9b-59926a629e07@default> References: <36a97a89-bd11-44b2-8a5f-93202556d574@default> <54F50F21.5040104@oracle.com> <4abbf698-202a-43cc-8b9b-59926a629e07@default> Message-ID: <54F60D4C.8010402@oracle.com> Hi Markus. OK, thanks for the explanation. dl On 3/3/2015 1:15 AM, Markus Gronlund wrote: > Hi Dean, > > Thanks for your input. > > I think a monitor would be less ideal here: > > A monitor would introduce blocking in enqueuing operations. > > The "posters" are (in this case) remotely injected threads (by another process), and the processes injecting those threads are in WaitForSingleObject() on those thread handles. If a monitor is used, it needs to be held by the AttachListener over executing (arbitrary) operations. Granted, each operation today is being executed in serial fashion (but it does not need to be), but I believe we would not like to have each client also block on the monitor as part of enqueuing their operation, just in order to issue the notify. > > With a Windows Semaphore, clients can act asynchronously in regard to enqueuing. As long as the semaphore's current count is > 0, there is no blocking on the part of the AttachListener thread, WaitForSingleObject() return immediately decrementing the current count. > > Thanks > Markus > > > -----Original Message----- > From: Dean Long > Sent: den 3 mars 2015 02:32 > To: Markus Gronlund; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows) > > Couldn't you instead treat it like a monitor? Then it's OK if only the first notify wakes up the blocked thread, as long as that thread only blocks when the queue is empty. In other words, when it wakes up, it should process all the items in the queue before blocking again. > > dl > > On 3/2/2015 4:34 AM, Markus Gronlund wrote: >> Greetings, >> >> >> >> Kindly asking for reviews for the following changeset: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8073042 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8073042/webrev01/ >> >> >> >> Description: >> >> The signaling mechanism used to communicate about attaching operations under Windows currently only allows for a single outstanding item to be visible. This leads to issues, such as the one described in this bug, where clients assume their operations are under processing (they have been enqueued after all), but the AttachListener thread does not see, and hence do not process, these operations. >> >> >> >> Analysis: >> >> The _wakeup semaphore only allows for a single outstanding operation: >> >> CreateSemaphore(NULL, 0, 1, NULL); >> >> When a thread has enqueued an operation, it will notify the AttachListener thread through the semaphore, by: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); // this increases the semaphore >> count by 1 >> >> This will signal the semaphore and "wakeup" the AttachListener thread which (most likely) is in WaitForSingleObject() for the semaphore to become signaled. When the semaphore is signaled and AttachListener returns from WaitForSingleObject(), the semaphore's count is decremented, and the semaphore again becomes non-signaled (goes from current count 1 (which is also maximum count) to zero). >> >> >> Problem: multiple client threads will enqueue their operations if they manage to get the list mutex() - if they do, they will insert their op into the queue, and call: >> >> ::ReleaseSemaphore(wakeup(), 1, NULL); >> >> This means we could have two (or more) client threads having posted operations, before the AttachListener thread becomes scheduled. >> >> Since the semaphore created has a maximum count == 1, any subsequent calls to ::ReleaseSemaphore(wakeup(), 1, NULL);, taking the the current count to > maximum count, will have _no_effect - the current count of the semaphore remains at maximum count level AND ::ReleaseSemaphore(wakeup(), 1, NULL); returns FALSE - but currently there is no checking the return value here... >> This means the client thread has managed to enqueue its op (and will move into ConnectPipe()), but the AttachListener will never see more than 1 enqueued op at any one time (hence it does not know it is expected to process another operation and signal the associated pipe). >> >> This is how operations manage to get enqueued, but not processed until another thread eventually signals the semaphore by posting another op. >> >> We must allow the semaphore to stay signaled when multiple ops are enqueued - and since we only allow preallocate_count number of operations to be enqueued, we can ensure the semaphore manages this upper limit as its maximum count. >> >> >> >> Tests: >> >> >> >> Jcmd/dcmd test >> >> Attach tests >> >> >> >> Thanks >> >> Markus From dean.long at oracle.com Tue Mar 3 19:54:51 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 03 Mar 2015 11:54:51 -0800 Subject: RFR(S) 8074010: followup to 8072383 In-Reply-To: <54F0B34C.5020103@oracle.com> References: <54F00174.1060707@oracle.com> <54F00A25.40302@oracle.com> <54F00F8F.2040901@oracle.com> <54F02E3E.8060601@oracle.com> <54F0B34C.5020103@oracle.com> Message-ID: <54F6118B.4070601@oracle.com> Ping. I think I still need another review for this. dl On 2/27/2015 10:11 AM, Dean Long wrote: > Thanks for the review, David. Can I get another review for this, please? > > dl > > On 2/27/2015 12:43 AM, David Holmes wrote: >> Thanks Dean - looks good to me. >> >> David >> >> On 27/02/2015 4:32 PM, Dean Long wrote: >>> Thanks David for looking at this. Round two no longer tries to >>> simplify >>> the >>> makefile logic, but instead keeps existing variables names and >>> minimizes >>> the number of lines changed. >>> >>> dl >>> >>> http://cr.openjdk.java.net/~dlong/8074010/8u60.01/ >>> >>> On 2/26/2015 10:09 PM, David Holmes wrote: >>>> Hi Dean, >>>> >>>> On 27/02/2015 3:32 PM, Dean Long wrote: >>>>> This changeset removes references to closed platforms from gcc.make, >>>>> allows $(HS_ALT_MAKE)/linux/makefiles/gcc.make to override the >>>>> default values, and simplifies the logic a bit. It is targeted for >>>>> 8u60. >>>> >>>> For the benefit of other readers the problem with the existing code is >>>> that we use platform specific variables to define an additional >>>> flag eg: >>>> >>>> DEBUG_CFLAGS/amd64 = -g >>>> >>>> which is then added to the primary flag variable ie: >>>> >>>> DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >>>> >>>> That is all good. The problem is the code used to set a default: >>>> >>>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >>>> ifeq ($(USE_CLANG), true) >>>> # Clang doesn't understand -gstabs >>>> DEBUG_CFLAGS += -g >>>> else >>>> DEBUG_CFLAGS += -gstabs >>>> endif >>>> endif >>>> >>>> Here we check the current value of $(DEBUG_CFLAGS/$(BUILDARCH)) and >>>> use it's emptiness to hard-wire a specific flag onto the primary flag >>>> variable. The problem with that is when we include >>>> $(HS_ALT_MAKE)/linux/makefiles/gcc.make at the end of the file, it >>>> wants to set a value of DEBUG_CFLAGS/$(BUILDARCH) for another >>>> BUILDARCH and consequently the main flags variable will get that value >>>> AND the default that was hard-wired - and we don't won't that. >>>> >>>> However, a cleaner solution that Dean and I have discussed is to >>>> simply adjust the default-setting as follows: >>>> >>>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >>>> ifeq ($(USE_CLANG), true) >>>> # Clang doesn't understand -gstabs >>>> DEBUG_CFLAGS/$(BUILDARCH) = -g >>>> else >>>> DEBUG_CFLAGS/$(BUILDARCH) = -gstabs >>>> endif >>>> endif >>>> >>>> so now if we later set DEBUG_CFLAGS/$(BUILDARCH) for a hitherto unseen >>>> BUILDARCH it will be expanded in the primary flags variable as >>>> expected and the "default" will not be used. >>>> >>>> Note there's also an existing bug in setting of the FASTDEBUG_CFLAGS >>>> which has since been fixed in 9 and is now fixed here as well: >>>> >>>> - FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >>>> + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) >>>> >>>> Thanks, >>>> David >>>> >>>>> dl >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8074010 >>>>> http://cr.openjdk.java.net/~dlong/8074010/8u60.00/ >>>>> >>> > From vladimir.kozlov at oracle.com Tue Mar 3 20:13:38 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Mar 2015 12:13:38 -0800 Subject: RFR(S) 8074010: followup to 8072383 In-Reply-To: <54F6118B.4070601@oracle.com> References: <54F00174.1060707@oracle.com> <54F00A25.40302@oracle.com> <54F00F8F.2040901@oracle.com> <54F02E3E.8060601@oracle.com> <54F0B34C.5020103@oracle.com> <54F6118B.4070601@oracle.com> Message-ID: <54F615F2.4030709@oracle.com> Good. Thanks, Vladimir On 3/3/15 11:54 AM, Dean Long wrote: > Ping. I think I still need another review for this. > > dl > > On 2/27/2015 10:11 AM, Dean Long wrote: >> Thanks for the review, David. Can I get another review for this, please? >> >> dl >> >> On 2/27/2015 12:43 AM, David Holmes wrote: >>> Thanks Dean - looks good to me. >>> >>> David >>> >>> On 27/02/2015 4:32 PM, Dean Long wrote: >>>> Thanks David for looking at this. Round two no longer tries to simplify >>>> the >>>> makefile logic, but instead keeps existing variables names and minimizes >>>> the number of lines changed. >>>> >>>> dl >>>> >>>> http://cr.openjdk.java.net/~dlong/8074010/8u60.01/ >>>> >>>> On 2/26/2015 10:09 PM, David Holmes wrote: >>>>> Hi Dean, >>>>> >>>>> On 27/02/2015 3:32 PM, Dean Long wrote: >>>>>> This changeset removes references to closed platforms from gcc.make, >>>>>> allows $(HS_ALT_MAKE)/linux/makefiles/gcc.make to override the >>>>>> default values, and simplifies the logic a bit. It is targeted for >>>>>> 8u60. >>>>> >>>>> For the benefit of other readers the problem with the existing code is >>>>> that we use platform specific variables to define an additional flag eg: >>>>> >>>>> DEBUG_CFLAGS/amd64 = -g >>>>> >>>>> which is then added to the primary flag variable ie: >>>>> >>>>> DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >>>>> >>>>> That is all good. The problem is the code used to set a default: >>>>> >>>>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >>>>> ifeq ($(USE_CLANG), true) >>>>> # Clang doesn't understand -gstabs >>>>> DEBUG_CFLAGS += -g >>>>> else >>>>> DEBUG_CFLAGS += -gstabs >>>>> endif >>>>> endif >>>>> >>>>> Here we check the current value of $(DEBUG_CFLAGS/$(BUILDARCH)) and >>>>> use it's emptiness to hard-wire a specific flag onto the primary flag >>>>> variable. The problem with that is when we include >>>>> $(HS_ALT_MAKE)/linux/makefiles/gcc.make at the end of the file, it >>>>> wants to set a value of DEBUG_CFLAGS/$(BUILDARCH) for another >>>>> BUILDARCH and consequently the main flags variable will get that value >>>>> AND the default that was hard-wired - and we don't won't that. >>>>> >>>>> However, a cleaner solution that Dean and I have discussed is to >>>>> simply adjust the default-setting as follows: >>>>> >>>>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >>>>> ifeq ($(USE_CLANG), true) >>>>> # Clang doesn't understand -gstabs >>>>> DEBUG_CFLAGS/$(BUILDARCH) = -g >>>>> else >>>>> DEBUG_CFLAGS/$(BUILDARCH) = -gstabs >>>>> endif >>>>> endif >>>>> >>>>> so now if we later set DEBUG_CFLAGS/$(BUILDARCH) for a hitherto unseen >>>>> BUILDARCH it will be expanded in the primary flags variable as >>>>> expected and the "default" will not be used. >>>>> >>>>> Note there's also an existing bug in setting of the FASTDEBUG_CFLAGS >>>>> which has since been fixed in 9 and is now fixed here as well: >>>>> >>>>> - FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >>>>> + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> dl >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8074010 >>>>>> http://cr.openjdk.java.net/~dlong/8074010/8u60.00/ >>>>>> >>>> >> > From dean.long at oracle.com Wed Mar 4 06:19:45 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 03 Mar 2015 22:19:45 -0800 Subject: RFR(S) 8074010: followup to 8072383 In-Reply-To: <54F615F2.4030709@oracle.com> References: <54F00174.1060707@oracle.com> <54F00A25.40302@oracle.com> <54F00F8F.2040901@oracle.com> <54F02E3E.8060601@oracle.com> <54F0B34C.5020103@oracle.com> <54F6118B.4070601@oracle.com> <54F615F2.4030709@oracle.com> Message-ID: <54F6A401.3080006@oracle.com> Thanks Vladimir. dl On 3/3/2015 12:13 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 3/3/15 11:54 AM, Dean Long wrote: >> Ping. I think I still need another review for this. >> >> dl >> >> On 2/27/2015 10:11 AM, Dean Long wrote: >>> Thanks for the review, David. Can I get another review for this, >>> please? >>> >>> dl >>> >>> On 2/27/2015 12:43 AM, David Holmes wrote: >>>> Thanks Dean - looks good to me. >>>> >>>> David >>>> >>>> On 27/02/2015 4:32 PM, Dean Long wrote: >>>>> Thanks David for looking at this. Round two no longer tries to >>>>> simplify >>>>> the >>>>> makefile logic, but instead keeps existing variables names and >>>>> minimizes >>>>> the number of lines changed. >>>>> >>>>> dl >>>>> >>>>> http://cr.openjdk.java.net/~dlong/8074010/8u60.01/ >>>>> >>>>> On 2/26/2015 10:09 PM, David Holmes wrote: >>>>>> Hi Dean, >>>>>> >>>>>> On 27/02/2015 3:32 PM, Dean Long wrote: >>>>>>> This changeset removes references to closed platforms from >>>>>>> gcc.make, >>>>>>> allows $(HS_ALT_MAKE)/linux/makefiles/gcc.make to override the >>>>>>> default values, and simplifies the logic a bit. It is targeted for >>>>>>> 8u60. >>>>>> >>>>>> For the benefit of other readers the problem with the existing >>>>>> code is >>>>>> that we use platform specific variables to define an additional >>>>>> flag eg: >>>>>> >>>>>> DEBUG_CFLAGS/amd64 = -g >>>>>> >>>>>> which is then added to the primary flag variable ie: >>>>>> >>>>>> DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >>>>>> >>>>>> That is all good. The problem is the code used to set a default: >>>>>> >>>>>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >>>>>> ifeq ($(USE_CLANG), true) >>>>>> # Clang doesn't understand -gstabs >>>>>> DEBUG_CFLAGS += -g >>>>>> else >>>>>> DEBUG_CFLAGS += -gstabs >>>>>> endif >>>>>> endif >>>>>> >>>>>> Here we check the current value of $(DEBUG_CFLAGS/$(BUILDARCH)) and >>>>>> use it's emptiness to hard-wire a specific flag onto the primary >>>>>> flag >>>>>> variable. The problem with that is when we include >>>>>> $(HS_ALT_MAKE)/linux/makefiles/gcc.make at the end of the file, it >>>>>> wants to set a value of DEBUG_CFLAGS/$(BUILDARCH) for another >>>>>> BUILDARCH and consequently the main flags variable will get that >>>>>> value >>>>>> AND the default that was hard-wired - and we don't won't that. >>>>>> >>>>>> However, a cleaner solution that Dean and I have discussed is to >>>>>> simply adjust the default-setting as follows: >>>>>> >>>>>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),) >>>>>> ifeq ($(USE_CLANG), true) >>>>>> # Clang doesn't understand -gstabs >>>>>> DEBUG_CFLAGS/$(BUILDARCH) = -g >>>>>> else >>>>>> DEBUG_CFLAGS/$(BUILDARCH) = -gstabs >>>>>> endif >>>>>> endif >>>>>> >>>>>> so now if we later set DEBUG_CFLAGS/$(BUILDARCH) for a hitherto >>>>>> unseen >>>>>> BUILDARCH it will be expanded in the primary flags variable as >>>>>> expected and the "default" will not be used. >>>>>> >>>>>> Note there's also an existing bug in setting of the FASTDEBUG_CFLAGS >>>>>> which has since been fixed in 9 and is now fixed here as well: >>>>>> >>>>>> - FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >>>>>> + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> dl >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074010 >>>>>>> http://cr.openjdk.java.net/~dlong/8074010/8u60.00/ >>>>>>> >>>>> >>> >> From gerald.thornbrugh at oracle.com Wed Mar 4 21:04:10 2015 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 04 Mar 2015 14:04:10 -0700 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." Message-ID: <54F7734A.3090504@oracle.com> Hi, Please review my JDK8 and JDK9 fix for JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." This compiler error occurs when Solaris 11 include files are used to build hotspot and the POSIX version of the DIR structure is used in the build process. The fix forces all Solaris builds to use the same version of the DIR structure. JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ I have completed JPRT bulds and tests on platforms without issues. Thanks, Gerald From daniel.daugherty at oracle.com Wed Mar 4 21:40:43 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 04 Mar 2015 14:40:43 -0700 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F7734A.3090504@oracle.com> References: <54F7734A.3090504@oracle.com> Message-ID: <54F77BDB.2020408@oracle.com> On 3/4/15 2:04 PM, Gerald Thornbrugh wrote: > Hi, > > Please review my JDK8 and JDK9 fix for JDK-8071501 > perfMemory_solaris.cpp failing to compile with > "Error: dd_fd is not a member of DIR." > > This compiler error occurs when Solaris 11 include files are used to > build hotspot and the POSIX > version of the DIR structure is used in the build process. The fix > forces all Solaris builds to use > the same version of the DIR structure. > > JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ > src/os/solaris/vm/jvm_solaris.h No comments. src/share/vm/utilities/globalDefinitions_sparcWorks.hpp No comments. Thumbs up on the JDK8u version. Jerry, your webrev is parented to: http://hg.openjdk.java.net/jdk8/jdk8/hotspot which is not the right place. JDK8u/HSX-25.60 changes should parent to: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot > JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ > src/os/solaris/vm/jvm_solaris.h No comments. src/share/vm/utilities/globalDefinitions_sparcWorks.hpp No comments. Thumbs up on the JDK8u version. Jerry, your webrev is parented to: http://hg.openjdk.java.net/jdk9/jdk9/hotspot and it should be parented to: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot Sometimes we push emergency fixes to Main_Baseline: http://hg.openjdk.java.net/jdk9/hs/hotspot or even to JDK9-dev: http://hg.openjdk.java.net/jdk9/dev/hotspot but those are very rare occasions and require permission from those GKs... Dan > I have completed JPRT bulds and tests on platforms without issues. > > Thanks, > > Gerald From gerald.thornbrugh at oracle.com Wed Mar 4 21:45:19 2015 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 04 Mar 2015 14:45:19 -0700 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F77BDB.2020408@oracle.com> References: <54F7734A.3090504@oracle.com> <54F77BDB.2020408@oracle.com> Message-ID: <54F77CEF.8040506@oracle.com> Hi Dan, Thanks for the review and information. Jerry > On 3/4/15 2:04 PM, Gerald Thornbrugh wrote: >> Hi, >> >> Please review my JDK8 and JDK9 fix for JDK-8071501 >> perfMemory_solaris.cpp failing to compile with >> "Error: dd_fd is not a member of DIR." >> >> This compiler error occurs when Solaris 11 include files are used to >> build hotspot and the POSIX >> version of the DIR structure is used in the build process. The fix >> forces all Solaris builds to use >> the same version of the DIR structure. >> >> JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ >> > > src/os/solaris/vm/jvm_solaris.h > No comments. > > src/share/vm/utilities/globalDefinitions_sparcWorks.hpp > No comments. > > Thumbs up on the JDK8u version. > > Jerry, your webrev is parented to: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot > > which is not the right place. JDK8u/HSX-25.60 changes should > parent to: > > http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot > > >> JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ >> > > src/os/solaris/vm/jvm_solaris.h > No comments. > > src/share/vm/utilities/globalDefinitions_sparcWorks.hpp > No comments. > > Thumbs up on the JDK8u version. > > Jerry, your webrev is parented to: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot > > and it should be parented to: > > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot > > Sometimes we push emergency fixes to Main_Baseline: > > http://hg.openjdk.java.net/jdk9/hs/hotspot > > or even to JDK9-dev: > > http://hg.openjdk.java.net/jdk9/dev/hotspot > > but those are very rare occasions and require permission > from those GKs... > > Dan > > >> I have completed JPRT bulds and tests on platforms without issues. >> >> Thanks, >> >> Gerald > From dmitry.samersoff at oracle.com Wed Mar 4 21:59:32 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 05 Mar 2015 00:59:32 +0300 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F7734A.3090504@oracle.com> References: <54F7734A.3090504@oracle.com> Message-ID: <54F78044.8080405@oracle.com> Gerlad, As the overall direction is be POSIX compatible, it might be better to change the code to use POSIX declaration, and define __XOPEN_OR_POSIX for Solaris 10 compatibility. -Dmitry On 2015-03-05 00:04, Gerald Thornbrugh wrote: > Hi, > > Please review my JDK8 and JDK9 fix for JDK-8071501 > perfMemory_solaris.cpp failing to compile with > "Error: dd_fd is not a member of DIR." > > This compiler error occurs when Solaris 11 include files are used to > build hotspot and the POSIX > version of the DIR structure is used in the build process. The fix > forces all Solaris builds to use > the same version of the DIR structure. > > JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ > > > JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ > > I have completed JPRT bulds and tests on platforms without issues. > > Thanks, > > Gerald -- 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 gerald.thornbrugh at oracle.com Wed Mar 4 22:04:49 2015 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 04 Mar 2015 15:04:49 -0700 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F78044.8080405@oracle.com> References: <54F7734A.3090504@oracle.com> <54F78044.8080405@oracle.com> Message-ID: <54F78181.6080906@oracle.com> Hi Dimitry, We discussed this option and decided to stay with the legacy prototypes for JDK8 and JDK9 for now. We will open up an RFE to move to the POSIX prototypes in the future. Thanks, Jerry > Gerlad, > > As the overall direction is be POSIX compatible, > it might be better to change the code to use POSIX declaration, > and define __XOPEN_OR_POSIX for Solaris 10 compatibility. > > -Dmitry > > > On 2015-03-05 00:04, Gerald Thornbrugh wrote: >> Hi, >> >> Please review my JDK8 and JDK9 fix for JDK-8071501 >> perfMemory_solaris.cpp failing to compile with >> "Error: dd_fd is not a member of DIR." >> >> This compiler error occurs when Solaris 11 include files are used to >> build hotspot and the POSIX >> version of the DIR structure is used in the build process. The fix >> forces all Solaris builds to use >> the same version of the DIR structure. >> >> JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ >> >> >> JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ >> >> I have completed JPRT bulds and tests on platforms without issues. >> >> Thanks, >> >> Gerald > From dmitry.samersoff at oracle.com Wed Mar 4 22:12:42 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 05 Mar 2015 01:12:42 +0300 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F78181.6080906@oracle.com> References: <54F7734A.3090504@oracle.com> <54F78044.8080405@oracle.com> <54F78181.6080906@oracle.com> Message-ID: <54F7835A.3020708@oracle.com> Gerald, OK. Thank you for the explanation! -Dmitry On 2015-03-05 01:04, Gerald Thornbrugh wrote: > Hi Dimitry, > > We discussed this option and decided to stay with the legacy prototypes > for JDK8 and JDK9 for now. We will open up an RFE to move to the POSIX > prototypes in the future. > > Thanks, > > Jerry >> Gerlad, >> >> As the overall direction is be POSIX compatible, >> it might be better to change the code to use POSIX declaration, >> and define __XOPEN_OR_POSIX for Solaris 10 compatibility. >> >> -Dmitry >> >> >> On 2015-03-05 00:04, Gerald Thornbrugh wrote: >>> Hi, >>> >>> Please review my JDK8 and JDK9 fix for JDK-8071501 >>> perfMemory_solaris.cpp failing to compile with >>> "Error: dd_fd is not a member of DIR." >>> >>> This compiler error occurs when Solaris 11 include files are used to >>> build hotspot and the POSIX >>> version of the DIR structure is used in the build process. The fix >>> forces all Solaris builds to use >>> the same version of the DIR structure. >>> >>> JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ >>> >>> >>> JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ >>> >>> I have completed JPRT bulds and tests on platforms without issues. >>> >>> Thanks, >>> >>> Gerald >> > -- 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 Wed Mar 4 22:52:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Mar 2015 08:52:24 +1000 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F7734A.3090504@oracle.com> References: <54F7734A.3090504@oracle.com> Message-ID: <54F78CA8.8080409@oracle.com> Hi Jerry, Looks good to me. Just ensure you push to the forests Dan indicated :) Thanks, David On 5/03/2015 7:04 AM, Gerald Thornbrugh wrote: > Hi, > > Please review my JDK8 and JDK9 fix for JDK-8071501 > perfMemory_solaris.cpp failing to compile with > "Error: dd_fd is not a member of DIR." > > This compiler error occurs when Solaris 11 include files are used to > build hotspot and the POSIX > version of the DIR structure is used in the build process. The fix > forces all Solaris builds to use > the same version of the DIR structure. > > JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ > > > JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ > > I have completed JPRT bulds and tests on platforms without issues. > > Thanks, > > Gerald From gerald.thornbrugh at oracle.com Wed Mar 4 22:55:24 2015 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 04 Mar 2015 15:55:24 -0700 Subject: RFR JDK-8071501 perfMemory_solaris.cpp failing to compile with "Error: dd_fd is not a member of DIR." In-Reply-To: <54F78CA8.8080409@oracle.com> References: <54F7734A.3090504@oracle.com> <54F78CA8.8080409@oracle.com> Message-ID: <54F78D5C.3090602@oracle.com> Hi David, I will and thanks for the review. Jerry > Hi Jerry, > > Looks good to me. > > Just ensure you push to the forests Dan indicated :) > > Thanks, > David > > On 5/03/2015 7:04 AM, Gerald Thornbrugh wrote: >> Hi, >> >> Please review my JDK8 and JDK9 fix for JDK-8071501 >> perfMemory_solaris.cpp failing to compile with >> "Error: dd_fd is not a member of DIR." >> >> This compiler error occurs when Solaris 11 include files are used to >> build hotspot and the POSIX >> version of the DIR structure is used in the build process. The fix >> forces all Solaris builds to use >> the same version of the DIR structure. >> >> JDK8 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk8/webrev/ >> >> >> JDK9 Webrev: http://cr.openjdk.java.net/~gthornbr/fd/jdk9/webrev/ >> >> I have completed JPRT bulds and tests on platforms without issues. >> >> Thanks, >> >> Gerald From yumin.qi at oracle.com Thu Mar 5 21:21:32 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 05 Mar 2015 13:21:32 -0800 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS Message-ID: <54F8C8DC.2030502@oracle.com> Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8074345 webrev: http://cr.openjdk.java.net/~minqi/8074345/ Summary: Currently CDS when is disabled, RewriteBytecodes and RewriteFrequentPairs are disabled due to ConstantMethod in CDS are mapped read only. So memory fault will be triggered when RewriteBytecodes turned on. This also disable all method rewritten, leads interpreter run slower. Observed about 2% regression with C2 on some benchmarks, since interpreter speed is important to C2. By enable RewriteBytecodes and RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for corresponding fast codes at dump time to avoid byte code rewritten at run time, we prevent byte code rewritten and modify the read only shared portion in CDS. Meanwhile other byte codes with fast codes still get speed up. Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported platforms. Interpreter only tests showed about 3% improvement. Thanks Yumin From david.holmes at oracle.com Fri Mar 6 06:22:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Mar 2015 16:22:23 +1000 Subject: [9] RFR (S) 8069111: Investigate NMT detail tracking support for 32bit ARM In-Reply-To: <54F5D44B.8020103@oracle.com> References: <54F5D44B.8020103@oracle.com> Message-ID: <54F9479F.3020105@oracle.com> Hi Chris, On 4/03/2015 1:33 AM, Chris Plummer wrote: > Please help with the review for the changes for JDK-8069111: > > Webrev: http://cr.openjdk.java.net/~cjplummer/8069111/webrev.06/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8069111 > > Tested with JPRT, including running all NMT tests and vmerror.sh. > > Many of the changes are in closed code. For the open code, the main > changes are to no longer support the > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED macro, and no longer allow > platforms to include NMT but not include NMT Detail support. The NMT > tests have been modified to reflect this. They no longer check if NMT > Detail is supported and adjust the testing based on this. The removal of > @ignore in some tests is because the cause of these test failures is > fixed in the closed changes. This all looks good to me. Thanks, David > thanks, > > Chris From bertrand.delsart at oracle.com Fri Mar 6 08:52:28 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 06 Mar 2015 09:52:28 +0100 Subject: [9] RFR (S) 8069111: Investigate NMT detail tracking support for 32bit ARM In-Reply-To: <54F5D44B.8020103@oracle.com> References: <54F5D44B.8020103@oracle.com> Message-ID: <54F96ACC.6080601@oracle.com> On 03/03/2015 16:33, Chris Plummer wrote: > Please help with the review for the changes for JDK-8069111: > > Webrev: http://cr.openjdk.java.net/~cjplummer/8069111/webrev.06/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8069111 > > Tested with JPRT, including running all NMT tests and vmerror.sh. Looks good. Thanks for fixing it (particularly the closed part :-)). Bertrand (not a Reviewer). > > Many of the changes are in closed code. For the open code, the main > changes are to no longer support the > PLATFORM_NATIVE_STACK_WALKING_SUPPORTED macro, and no longer allow > platforms to include NMT but not include NMT Detail support. The NMT > tests have been modified to reflect this. They no longer check if NMT > Detail is supported and adjust the testing based on this. The removal of > @ignore in some tests is because the cause of these test failures is > fixed in the closed changes. > > thanks, > > Chris -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From chris.plummer at oracle.com Fri Mar 6 09:07:20 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 06 Mar 2015 01:07:20 -0800 Subject: [9] RFR (S) 8069111: Investigate NMT detail tracking support for 32bit ARM In-Reply-To: <54F9479F.3020105@oracle.com> References: <54F5D44B.8020103@oracle.com> <54F9479F.3020105@oracle.com> Message-ID: <54F96E48.8040000@oracle.com> On 3/5/15 10:22 PM, David Holmes wrote: > Hi Chris, > > On 4/03/2015 1:33 AM, Chris Plummer wrote: >> Please help with the review for the changes for JDK-8069111: >> >> Webrev: http://cr.openjdk.java.net/~cjplummer/8069111/webrev.06/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8069111 >> >> Tested with JPRT, including running all NMT tests and vmerror.sh. >> >> Many of the changes are in closed code. For the open code, the main >> changes are to no longer support the >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED macro, and no longer allow >> platforms to include NMT but not include NMT Detail support. The NMT >> tests have been modified to reflect this. They no longer check if NMT >> Detail is supported and adjust the testing based on this. The removal of >> @ignore in some tests is because the cause of these test failures is >> fixed in the closed changes. > > This all looks good to me. > > Thanks, > David Thanks David! > >> thanks, >> >> Chris From chris.plummer at oracle.com Fri Mar 6 09:07:37 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 06 Mar 2015 01:07:37 -0800 Subject: [9] RFR (S) 8069111: Investigate NMT detail tracking support for 32bit ARM In-Reply-To: <54F96ACC.6080601@oracle.com> References: <54F5D44B.8020103@oracle.com> <54F96ACC.6080601@oracle.com> Message-ID: <54F96E59.3040003@oracle.com> On 3/6/15 12:52 AM, Bertrand Delsart wrote: > On 03/03/2015 16:33, Chris Plummer wrote: >> Please help with the review for the changes for JDK-8069111: >> >> Webrev: http://cr.openjdk.java.net/~cjplummer/8069111/webrev.06/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8069111 >> >> Tested with JPRT, including running all NMT tests and vmerror.sh. > > Looks good. > > Thanks for fixing it (particularly the closed part :-)). > > Bertrand (not a Reviewer). Thanks Bertrand! > >> >> Many of the changes are in closed code. For the open code, the main >> changes are to no longer support the >> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED macro, and no longer allow >> platforms to include NMT but not include NMT Detail support. The NMT >> tests have been modified to reflect this. They no longer check if NMT >> Detail is supported and adjust the testing based on this. The removal of >> @ignore in some tests is because the cause of these test failures is >> fixed in the closed changes. >> >> thanks, >> >> Chris > > From thomas.stuefe at gmail.com Fri Mar 6 11:15:22 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 6 Mar 2015 12:15:22 +0100 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter Message-ID: Hi all, please review this tiny change to fix a build error when building with the CPP interpreter. webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8074543 bytecodeInterpreter.cpp misses include "objArrayOop.inline.hpp", so the inline definition of this function is missing. Kind Regards, Thomas From stefan.karlsson at oracle.com Fri Mar 6 13:15:37 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 06 Mar 2015 14:15:37 +0100 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: References: Message-ID: <54F9A879.90909@oracle.com> Hi Thomas, On 2015-03-06 12:15, Thomas St?fe wrote: > Hi all, > > please review this tiny change to fix a build error when building with the > CPP interpreter. > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ #include "oops/objArrayKlass.hpp" #include "oops/oop.inline.hpp" +#include "oops/objArrayOop.inline.hpp" I'm fine with the change if the added line is moved up one line so that we keep the includes sorted. Thanks, StefanK > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074543 > > bytecodeInterpreter.cpp misses include "objArrayOop.inline.hpp", so the > inline definition of this function is missing. > > Kind Regards, Thomas From thomas.stuefe at gmail.com Fri Mar 6 13:28:53 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 6 Mar 2015 14:28:53 +0100 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: <54F9A879.90909@oracle.com> References: <54F9A879.90909@oracle.com> Message-ID: Hi Stefan, here you go: http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.02/webrev I also would need a sponsor, because I am no author for the hotspot project. Thanks, Thomas On Fri, Mar 6, 2015 at 2:15 PM, Stefan Karlsson wrote: > Hi Thomas, > > On 2015-03-06 12:15, Thomas St?fe wrote: > >> Hi all, >> >> please review this tiny change to fix a build error when building with the >> CPP interpreter. >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ >> > > #include "oops/objArrayKlass.hpp" > #include "oops/oop.inline.hpp" > +#include "oops/objArrayOop.inline.hpp" > > > I'm fine with the change if the added line is moved up one line so that we > keep the includes sorted. > > Thanks, > StefanK > > > >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8074543 >> >> bytecodeInterpreter.cpp misses include "objArrayOop.inline.hpp", so the >> inline definition of this function is missing. >> >> Kind Regards, Thomas >> > > From thomas.stuefe at gmail.com Fri Mar 6 16:10:42 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 6 Mar 2015 17:10:42 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling Message-ID: Hi all, could someone please review the following fix (I also will need a sponsor): http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8074552 The fix will make SafeFetch[32,N] work in error reporting. At SAP, we use SafeFetch a lot in error reporting to poke around in potentially invalid memory (e.g. writing hex dumps over areas which may be partly unmapped), and we feel that this could be useful for the OpenJDK too. Without this fix, SafeFetch will cause a crash, the current error reporting step will be interrupted and error reporting will continue with the next step; that is not optimal because the interrupted step may have shown valuable information. This fix handles SafeFetch faults during error reporting the same way as they are handled normally. The changes are: - handle safe fetch fault in the various (os_cpu dependend) secondary signal handlers - provide a function to check if it is safe to use SafeFetch: CanUseSafeFetch32(). SafeFetch needs stub routines and will crash when used before stub generation. - set_context_pc() is added which complements the existing get_context_pc() and all instances where the pc in ucontext_t was modified directly are changed to use set_context_pc() - in stubRoutines.cpp, a small test was added to the already existing stub routines tests which run at VM init - in vmError.cpp, a test was added to test SafeFetch during error reporting, similar to the tests introduced for 8065895 - A JTreg test was added Thanks and Kind Regards, Thomas Stuefe From david.holmes at oracle.com Sun Mar 8 23:40:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Mar 2015 09:40:55 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: Message-ID: <54FCDE07.8010604@oracle.com> Hi Thomas, Minor nit: in src/share/vm/runtime/stubRoutines.cpp::test_safefetchN can you use UCONST64 macro instead of explicit ULL - thanks. Otherwise this seems okay, but we will also need the aarch64 component (and I'll look into our internal needs). Thanks, David On 7/03/2015 2:10 AM, Thomas St?fe wrote: > Hi all, > > could someone please review the following fix (I also will need a sponsor): > > http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8074552 > > The fix will make SafeFetch[32,N] work in error reporting. > > At SAP, we use SafeFetch a lot in error reporting to poke around in > potentially invalid memory (e.g. writing hex dumps over areas which may be > partly unmapped), and we feel that this could be useful for the OpenJDK too. > > Without this fix, SafeFetch will cause a crash, the current error reporting > step will be interrupted and error reporting will continue with the next > step; that is not optimal because the interrupted step may have shown > valuable information. > > This fix handles SafeFetch faults during error reporting the same way as > they are handled normally. The changes are: > > - handle safe fetch fault in the various (os_cpu dependend) secondary > signal handlers > > - provide a function to check if it is safe to use SafeFetch: > CanUseSafeFetch32(). SafeFetch needs stub routines and will crash when used > before stub generation. > > - set_context_pc() is added which complements the existing get_context_pc() > and all instances where the pc in ucontext_t was modified directly are > changed to use set_context_pc() > > - in stubRoutines.cpp, a small test was added to the already existing stub > routines tests which run at VM init > > - in vmError.cpp, a test was added to test SafeFetch during error > reporting, similar to the tests introduced for 8065895 > > - A JTreg test was added > > Thanks and Kind Regards, > > Thomas Stuefe > From david.holmes at oracle.com Mon Mar 9 05:56:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Mar 2015 15:56:25 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <54FCDE07.8010604@oracle.com> References: <54FCDE07.8010604@oracle.com> Message-ID: <54FD3609.4020009@oracle.com> Hi Thomas, FYI When I applied this to latest hs-rt forest and ran through JPRT the Windows fastdebug builds were DOA (instant segfault just running "java -version"). Can't see how your changes could do this so running a test on unmodified forest. David On 9/03/2015 9:40 AM, David Holmes wrote: > Hi Thomas, > > Minor nit: in src/share/vm/runtime/stubRoutines.cpp::test_safefetchN can > you use UCONST64 macro instead of explicit ULL - thanks. > > Otherwise this seems okay, but we will also need the aarch64 component > (and I'll look into our internal needs). > > Thanks, > David > > On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> Hi all, >> >> could someone please review the following fix (I also will need a >> sponsor): >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.01/ >> >> https://bugs.openjdk.java.net/browse/JDK-8074552 >> >> The fix will make SafeFetch[32,N] work in error reporting. >> >> At SAP, we use SafeFetch a lot in error reporting to poke around in >> potentially invalid memory (e.g. writing hex dumps over areas which >> may be >> partly unmapped), and we feel that this could be useful for the >> OpenJDK too. >> >> Without this fix, SafeFetch will cause a crash, the current error >> reporting >> step will be interrupted and error reporting will continue with the next >> step; that is not optimal because the interrupted step may have shown >> valuable information. >> >> This fix handles SafeFetch faults during error reporting the same way as >> they are handled normally. The changes are: >> >> - handle safe fetch fault in the various (os_cpu dependend) secondary >> signal handlers >> >> - provide a function to check if it is safe to use SafeFetch: >> CanUseSafeFetch32(). SafeFetch needs stub routines and will crash when >> used >> before stub generation. >> >> - set_context_pc() is added which complements the existing >> get_context_pc() >> and all instances where the pc in ucontext_t was modified directly are >> changed to use set_context_pc() >> >> - in stubRoutines.cpp, a small test was added to the already existing >> stub >> routines tests which run at VM init >> >> - in vmError.cpp, a test was added to test SafeFetch during error >> reporting, similar to the tests introduced for 8065895 >> >> - A JTreg test was added >> >> Thanks and Kind Regards, >> >> Thomas Stuefe >> From thomas.stuefe at gmail.com Mon Mar 9 06:21:33 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 9 Mar 2015 07:21:33 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <54FD3609.4020009@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> Message-ID: Hi David, Ouch. The only thing I can think about are the added initialization tests in stubRoutines.cpp. I will check this. Kind Regards, Thomas On Mon, Mar 9, 2015 at 6:56 AM, David Holmes wrote: > Hi Thomas, > > FYI When I applied this to latest hs-rt forest and ran through JPRT the > Windows fastdebug builds were DOA (instant segfault just running "java > -version"). Can't see how your changes could do this so running a test on > unmodified forest. > > David > > > On 9/03/2015 9:40 AM, David Holmes wrote: > >> Hi Thomas, >> >> Minor nit: in src/share/vm/runtime/stubRoutines.cpp::test_safefetchN can >> you use UCONST64 macro instead of explicit ULL - thanks. >> >> Otherwise this seems okay, but we will also need the aarch64 component >> (and I'll look into our internal needs). >> >> Thanks, >> David >> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> could someone please review the following fix (I also will need a >>> sponsor): >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.01/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8074552 >>> >>> The fix will make SafeFetch[32,N] work in error reporting. >>> >>> At SAP, we use SafeFetch a lot in error reporting to poke around in >>> potentially invalid memory (e.g. writing hex dumps over areas which >>> may be >>> partly unmapped), and we feel that this could be useful for the >>> OpenJDK too. >>> >>> Without this fix, SafeFetch will cause a crash, the current error >>> reporting >>> step will be interrupted and error reporting will continue with the next >>> step; that is not optimal because the interrupted step may have shown >>> valuable information. >>> >>> This fix handles SafeFetch faults during error reporting the same way as >>> they are handled normally. The changes are: >>> >>> - handle safe fetch fault in the various (os_cpu dependend) secondary >>> signal handlers >>> >>> - provide a function to check if it is safe to use SafeFetch: >>> CanUseSafeFetch32(). SafeFetch needs stub routines and will crash when >>> used >>> before stub generation. >>> >>> - set_context_pc() is added which complements the existing >>> get_context_pc() >>> and all instances where the pc in ucontext_t was modified directly are >>> changed to use set_context_pc() >>> >>> - in stubRoutines.cpp, a small test was added to the already existing >>> stub >>> routines tests which run at VM init >>> >>> - in vmError.cpp, a test was added to test SafeFetch during error >>> reporting, similar to the tests introduced for 8065895 >>> >>> - A JTreg test was added >>> >>> Thanks and Kind Regards, >>> >>> Thomas Stuefe >>> >>> From david.holmes at oracle.com Mon Mar 9 06:51:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Mar 2015 16:51:13 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> Message-ID: <54FD42E1.90504@oracle.com> On 9/03/2015 4:21 PM, Thomas St?fe wrote: > Hi David, > > Ouch. The only thing I can think about are the added initialization > tests in stubRoutines.cpp. I will check this. Ah! It hadn't registered with me that this test code was going to be executed. Seems the likely cause as a clean repo has no problems. David > Kind Regards, Thomas > > > > On Mon, Mar 9, 2015 at 6:56 AM, David Holmes > wrote: > > Hi Thomas, > > FYI When I applied this to latest hs-rt forest and ran through JPRT > the Windows fastdebug builds were DOA (instant segfault just running > "java -version"). Can't see how your changes could do this so > running a test on unmodified forest. > > David > > > On 9/03/2015 9:40 AM, David Holmes wrote: > > Hi Thomas, > > Minor nit: in > src/share/vm/runtime/__stubRoutines.cpp::test___safefetchN can > you use UCONST64 macro instead of explicit ULL - thanks. > > Otherwise this seems okay, but we will also need the aarch64 > component > (and I'll look into our internal needs). > > Thanks, > David > > On 7/03/2015 2:10 AM, Thomas St?fe wrote: > > Hi all, > > could someone please review the following fix (I also will > need a > sponsor): > > http://cr.openjdk.java.net/~__stuefe/webrevs/8074552/webrev.__01/ > > > https://bugs.openjdk.java.net/__browse/JDK-8074552 > > > The fix will make SafeFetch[32,N] work in error reporting. > > At SAP, we use SafeFetch a lot in error reporting to poke > around in > potentially invalid memory (e.g. writing hex dumps over > areas which > may be > partly unmapped), and we feel that this could be useful for the > OpenJDK too. > > Without this fix, SafeFetch will cause a crash, the current > error > reporting > step will be interrupted and error reporting will continue > with the next > step; that is not optimal because the interrupted step may > have shown > valuable information. > > This fix handles SafeFetch faults during error reporting the > same way as > they are handled normally. The changes are: > > - handle safe fetch fault in the various (os_cpu dependend) > secondary > signal handlers > > - provide a function to check if it is safe to use SafeFetch: > CanUseSafeFetch32(). SafeFetch needs stub routines and will > crash when > used > before stub generation. > > - set_context_pc() is added which complements the existing > get_context_pc() > and all instances where the pc in ucontext_t was modified > directly are > changed to use set_context_pc() > > - in stubRoutines.cpp, a small test was added to the already > existing > stub > routines tests which run at VM init > > - in vmError.cpp, a test was added to test SafeFetch during > error > reporting, similar to the tests introduced for 8065895 > > - A JTreg test was added > > Thanks and Kind Regards, > > Thomas Stuefe > > From stefan.karlsson at oracle.com Mon Mar 9 07:43:57 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 09 Mar 2015 08:43:57 +0100 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: References: <54F9A879.90909@oracle.com> Message-ID: <54FD4F3D.10201@oracle.com> Hi Thomas, On 06/03/15 14:28, Thomas St?fe wrote: > Hi Stefan, > > here you go: > > http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.02/webrev > > > I also would need a sponsor, because I am no author for the hotspot > project. There's no need for a second reviewer, given the size of the patch. I'll push this to jdk9/hs-gc/hotspot. Thanks, StefanK > > Thanks, Thomas > > > > > On Fri, Mar 6, 2015 at 2:15 PM, Stefan Karlsson > > wrote: > > Hi Thomas, > > On 2015-03-06 12:15, Thomas St?fe wrote: > > Hi all, > > please review this tiny change to fix a build error when > building with the > CPP interpreter. > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ > > > > #include "oops/objArrayKlass.hpp" > #include "oops/oop.inline.hpp" > +#include "oops/objArrayOop.inline.hpp" > > > I'm fine with the change if the added line is moved up one line so > that we keep the includes sorted. > > Thanks, > StefanK > > > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074543 > > bytecodeInterpreter.cpp misses include > "objArrayOop.inline.hpp", so the > inline definition of this function is missing. > > Kind Regards, Thomas > > > From thomas.stuefe at gmail.com Mon Mar 9 15:12:58 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 9 Mar 2015 16:12:58 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <54FD42E1.90504@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> Message-ID: Hi David, I am sorry, but I am unable to reproduce the error. Both slowdebug and fastdebug builds on Windows come up and SafeFetch works (also in error handling). Are you sure the crash is caused by my change? If yes, could you send me an hs-err file or at least the configure line you used for building? Kind Regards, Thomas On Mon, Mar 9, 2015 at 7:51 AM, David Holmes wrote: > On 9/03/2015 4:21 PM, Thomas St?fe wrote: > >> Hi David, >> >> Ouch. The only thing I can think about are the added initialization >> tests in stubRoutines.cpp. I will check this. >> > > Ah! It hadn't registered with me that this test code was going to be > executed. Seems the likely cause as a clean repo has no problems. > > David > > Kind Regards, Thomas >> >> >> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> FYI When I applied this to latest hs-rt forest and ran through JPRT >> the Windows fastdebug builds were DOA (instant segfault just running >> "java -version"). Can't see how your changes could do this so >> running a test on unmodified forest. >> >> David >> >> >> On 9/03/2015 9:40 AM, David Holmes wrote: >> >> Hi Thomas, >> >> Minor nit: in >> src/share/vm/runtime/__stubRoutines.cpp::test___safefetchN can >> you use UCONST64 macro instead of explicit ULL - thanks. >> >> Otherwise this seems okay, but we will also need the aarch64 >> component >> (and I'll look into our internal needs). >> >> Thanks, >> David >> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> >> Hi all, >> >> could someone please review the following fix (I also will >> need a >> sponsor): >> >> http://cr.openjdk.java.net/~__stuefe/webrevs/8074552/webrev. >> __01/ >> > 01/> >> >> https://bugs.openjdk.java.net/__browse/JDK-8074552 >> >> >> >> The fix will make SafeFetch[32,N] work in error reporting. >> >> At SAP, we use SafeFetch a lot in error reporting to poke >> around in >> potentially invalid memory (e.g. writing hex dumps over >> areas which >> may be >> partly unmapped), and we feel that this could be useful for >> the >> OpenJDK too. >> >> Without this fix, SafeFetch will cause a crash, the current >> error >> reporting >> step will be interrupted and error reporting will continue >> with the next >> step; that is not optimal because the interrupted step may >> have shown >> valuable information. >> >> This fix handles SafeFetch faults during error reporting the >> same way as >> they are handled normally. The changes are: >> >> - handle safe fetch fault in the various (os_cpu dependend) >> secondary >> signal handlers >> >> - provide a function to check if it is safe to use SafeFetch: >> CanUseSafeFetch32(). SafeFetch needs stub routines and will >> crash when >> used >> before stub generation. >> >> - set_context_pc() is added which complements the existing >> get_context_pc() >> and all instances where the pc in ucontext_t was modified >> directly are >> changed to use set_context_pc() >> >> - in stubRoutines.cpp, a small test was added to the already >> existing >> stub >> routines tests which run at VM init >> >> - in vmError.cpp, a test was added to test SafeFetch during >> error >> reporting, similar to the tests introduced for 8065895 >> >> - A JTreg test was added >> >> Thanks and Kind Regards, >> >> Thomas Stuefe >> >> >> From christian.tornqvist at oracle.com Mon Mar 9 15:29:58 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 9 Mar 2015 11:29:58 -0400 Subject: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java failing in nightlies In-Reply-To: <54EEA606.9070002@oracle.com> References: <1ad101d050a6$d09cbaf0$71d630d0$@oracle.com> <54ED4B09.7000007@oracle.com> <54EE991C.70605@oracle.com> <54EE9B3C.5090206@oracle.com> <54EEA606.9070002@oracle.com> Message-ID: <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> Changed the long to a uintptr_t and cleaned up the loop a bit. Please see the update webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.02/ Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Wednesday, February 25, 2015 11:50 PM To: David Holmes; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java failing in nightlies On 2/25/15, 11:04 PM, David Holmes wrote: > On 26/02/2015 1:55 PM, Coleen Phillimore wrote: >> >> >> In this case, I think 'long' is chosen because we want to turn >> address into an integral type to create the hashcode and that'll >> cover a 64 bit address. > > Sounds like a job for intptr_t. Or maybe uintptr_t if they're arithmetic. > >> Even if we change the signedness of the value, it's still a useful >> hash code. I don't see a bug here, only unfortunate casts. > > I'm surprised this change doesn't induce further warnings about mixing > signed and unsigned. But the code screams "type confusion" to me. > >> This change looks good to me. It's a really good find, Christian! >> We've been chasing this bug for months. > > The real bug was reading an uninitialized value no? In which case the > change from signed to unsigned seems incidental, unless also guarding > against overflow. There were two bugs. The signed hash value was 0x8000000 and when negated was 0x8000000, so created a negative index into the hash table. Coleen > > David > ----- > >> >> Thanks, >> Coleen >> >> >> On 2/24/15, 11:09 PM, David Holmes wrote: >>> Hi Christian, >>> >>> On 25/02/2015 12:57 PM, Christian Tornqvist wrote: >>>> Hi everyone, >>>> >>>> >>>> >>>> Please review this small fix for an issue with NMT. >>> >>> The use of long in this function looks wrong, particularly as >>> sizeof(long) might equal sizeof(int) and long is signed but now >>> _hash_value is unsigned: >>> >>> 72 // Hash code. Any better algorithm? >>> 73 unsigned int NativeCallStack::hash() const { >>> 74 long hash_val = _hash_value; >>> 75 if (hash_val == 0) { >>> 76 long pc; >>> 77 int index; >>> 78 for (index = 0; index < NMT_TrackingStackDepth; index ++) { >>> 79 pc = (long)_stack[index]; >>> 80 if (pc == 0) break; >>> 81 hash_val += pc; >>> 82 } >>> 83 >>> 84 NativeCallStack* p = const_cast(this); >>> 85 p->_hash_value = (unsigned int)(hash_val & 0xFFFFFFFF); >>> 86 } >>> 87 return _hash_value; >>> 88 } >>> >>> Even with the original code the use of long seems wrong. >>> >>> David >>> >>> >>>> >>>> >>>> The failure was caused by reading random memory from the >>>> uninitialized _hash_value, when this value happened to be >>>> 0x80000000, >>>> hash_to_index() >>>> failed to negate the value and ended up with an index of -16: >>>> >>>> >>>> >>>> # Internal Error >>>> (C:\\jprt\\T\\P1\\130630.ctornqvi\\s\\hotspot\\src\\share\\vm\\serv >>>> ices\\mal >>>> >>>> >>>> locSiteTable.cpp:139), pid=5680, tid=4928 >>>> >>>> # assert(index >= 0) failed: Negative index -16 >>>> >>>> >>>> >>>> Reproduced the issue and verified the fix using a debugger. Ran >>>> vm.quick and hotspot/test/:hotspot_jprt tests on Linux i586/x64 and >>>> Windows >>>> i586/x64 with >>>> -XX:NativeMemoryTracking=detail >>>> >>>> >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.00/ >>>> >>>> >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8069124 >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> >> From coleen.phillimore at oracle.com Mon Mar 9 15:37:38 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 09 Mar 2015 11:37:38 -0400 Subject: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java failing in nightlies In-Reply-To: <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> References: <1ad101d050a6$d09cbaf0$71d630d0$@oracle.com> <54ED4B09.7000007@oracle.com> <54EE991C.70605@oracle.com> <54EE9B3C.5090206@oracle.com> <54EEA606.9070002@oracle.com> <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> Message-ID: <54FDBE42.7090902@oracle.com> Looks great. Coleen On 3/9/15, 11:29 AM, Christian Tornqvist wrote: > Changed the long to a uintptr_t and cleaned up the loop a bit. > > Please see the update webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.02/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen > Phillimore > Sent: Wednesday, February 25, 2015 11:50 PM > To: David Holmes; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java > failing in nightlies > > > On 2/25/15, 11:04 PM, David Holmes wrote: >> On 26/02/2015 1:55 PM, Coleen Phillimore wrote: >>> >>> In this case, I think 'long' is chosen because we want to turn >>> address into an integral type to create the hashcode and that'll >>> cover a 64 bit address. >> Sounds like a job for intptr_t. > Or maybe uintptr_t if they're arithmetic. >>> Even if we change the signedness of the value, it's still a useful >>> hash code. I don't see a bug here, only unfortunate casts. >> I'm surprised this change doesn't induce further warnings about mixing >> signed and unsigned. But the code screams "type confusion" to me. >> >>> This change looks good to me. It's a really good find, Christian! >>> We've been chasing this bug for months. >> The real bug was reading an uninitialized value no? In which case the >> change from signed to unsigned seems incidental, unless also guarding >> against overflow. > There were two bugs. The signed hash value was 0x8000000 and when negated > was 0x8000000, so created a negative index into the hash table. > > Coleen >> David >> ----- >> >>> Thanks, >>> Coleen >>> >>> >>> On 2/24/15, 11:09 PM, David Holmes wrote: >>>> Hi Christian, >>>> >>>> On 25/02/2015 12:57 PM, Christian Tornqvist wrote: >>>>> Hi everyone, >>>>> >>>>> >>>>> >>>>> Please review this small fix for an issue with NMT. >>>> The use of long in this function looks wrong, particularly as >>>> sizeof(long) might equal sizeof(int) and long is signed but now >>>> _hash_value is unsigned: >>>> >>>> 72 // Hash code. Any better algorithm? >>>> 73 unsigned int NativeCallStack::hash() const { >>>> 74 long hash_val = _hash_value; >>>> 75 if (hash_val == 0) { >>>> 76 long pc; >>>> 77 int index; >>>> 78 for (index = 0; index < NMT_TrackingStackDepth; index ++) { >>>> 79 pc = (long)_stack[index]; >>>> 80 if (pc == 0) break; >>>> 81 hash_val += pc; >>>> 82 } >>>> 83 >>>> 84 NativeCallStack* p = const_cast(this); >>>> 85 p->_hash_value = (unsigned int)(hash_val & 0xFFFFFFFF); >>>> 86 } >>>> 87 return _hash_value; >>>> 88 } >>>> >>>> Even with the original code the use of long seems wrong. >>>> >>>> David >>>> >>>> >>>>> >>>>> The failure was caused by reading random memory from the >>>>> uninitialized _hash_value, when this value happened to be >>>>> 0x80000000, >>>>> hash_to_index() >>>>> failed to negate the value and ended up with an index of -16: >>>>> >>>>> >>>>> >>>>> # Internal Error >>>>> (C:\\jprt\\T\\P1\\130630.ctornqvi\\s\\hotspot\\src\\share\\vm\\serv >>>>> ices\\mal >>>>> >>>>> >>>>> locSiteTable.cpp:139), pid=5680, tid=4928 >>>>> >>>>> # assert(index >= 0) failed: Negative index -16 >>>>> >>>>> >>>>> >>>>> Reproduced the issue and verified the fix using a debugger. Ran >>>>> vm.quick and hotspot/test/:hotspot_jprt tests on Linux i586/x64 and >>>>> Windows >>>>> i586/x64 with >>>>> -XX:NativeMemoryTracking=detail >>>>> >>>>> >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.00/ >>>>> >>>>> >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8069124 >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> >>>>> > From coleen.phillimore at oracle.com Mon Mar 9 15:40:28 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 09 Mar 2015 11:40:28 -0400 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: References: Message-ID: <54FDBEEC.80606@oracle.com> Thomas, Did you build the Zero or the CPP interpreter? See: https://bugs.openjdk.java.net/browse/JDK-8074457 Thanks, Coleen On 3/6/15, 6:15 AM, Thomas St?fe wrote: > Hi all, > > please review this tiny change to fix a build error when building with the > CPP interpreter. > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074543 > > bytecodeInterpreter.cpp misses include "objArrayOop.inline.hpp", so the > inline definition of this function is missing. > > Kind Regards, Thomas From thomas.stuefe at gmail.com Mon Mar 9 16:27:31 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 9 Mar 2015 17:27:31 +0100 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: <54FDBEEC.80606@oracle.com> References: <54FDBEEC.80606@oracle.com> Message-ID: Hi Coleen, I did built AIX with the CPP interpreter. I saw the bug report about removing the CPP interpreter but was not sure whether the fix was needed for the Zero CPP interpreter too, Thanks, Thomas On Mon, Mar 9, 2015 at 4:40 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Thomas, Did you build the Zero or the CPP interpreter? See: > > https://bugs.openjdk.java.net/browse/JDK-8074457 > > Thanks, > Coleen > > > On 3/6/15, 6:15 AM, Thomas St?fe wrote: > >> Hi all, >> >> please review this tiny change to fix a build error when building with the >> CPP interpreter. >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8074543 >> >> bytecodeInterpreter.cpp misses include "objArrayOop.inline.hpp", so the >> inline definition of this function is missing. >> >> Kind Regards, Thomas >> > > From thomas.stuefe at gmail.com Mon Mar 9 16:30:34 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 9 Mar 2015 17:30:34 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> Message-ID: Hi David, I see now that only Windows 32bit is broken. I will investigate this. Thomas On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe wrote: > Hi David, > > I am sorry, but I am unable to reproduce the error. Both slowdebug and > fastdebug builds on Windows come up and SafeFetch works (also in error > handling). Are you sure the crash is caused by my change? If yes, could you > send me an hs-err file or at least the configure line you used for building? > > Kind Regards, Thomas > > On Mon, Mar 9, 2015 at 7:51 AM, David Holmes > wrote: > >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >> >>> Hi David, >>> >>> Ouch. The only thing I can think about are the added initialization >>> tests in stubRoutines.cpp. I will check this. >>> >> >> Ah! It hadn't registered with me that this test code was going to be >> executed. Seems the likely cause as a clean repo has no problems. >> >> David >> >> Kind Regards, Thomas >>> >>> >>> >>> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >> > wrote: >>> >>> Hi Thomas, >>> >>> FYI When I applied this to latest hs-rt forest and ran through JPRT >>> the Windows fastdebug builds were DOA (instant segfault just running >>> "java -version"). Can't see how your changes could do this so >>> running a test on unmodified forest. >>> >>> David >>> >>> >>> On 9/03/2015 9:40 AM, David Holmes wrote: >>> >>> Hi Thomas, >>> >>> Minor nit: in >>> src/share/vm/runtime/__stubRoutines.cpp::test___safefetchN can >>> you use UCONST64 macro instead of explicit ULL - thanks. >>> >>> Otherwise this seems okay, but we will also need the aarch64 >>> component >>> (and I'll look into our internal needs). >>> >>> Thanks, >>> David >>> >>> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> could someone please review the following fix (I also will >>> need a >>> sponsor): >>> >>> http://cr.openjdk.java.net/~__stuefe/webrevs/8074552/webrev. >>> __01/ >>> >> 01/> >>> >>> https://bugs.openjdk.java.net/__browse/JDK-8074552 >>> >>> >>> >>> The fix will make SafeFetch[32,N] work in error reporting. >>> >>> At SAP, we use SafeFetch a lot in error reporting to poke >>> around in >>> potentially invalid memory (e.g. writing hex dumps over >>> areas which >>> may be >>> partly unmapped), and we feel that this could be useful for >>> the >>> OpenJDK too. >>> >>> Without this fix, SafeFetch will cause a crash, the current >>> error >>> reporting >>> step will be interrupted and error reporting will continue >>> with the next >>> step; that is not optimal because the interrupted step may >>> have shown >>> valuable information. >>> >>> This fix handles SafeFetch faults during error reporting the >>> same way as >>> they are handled normally. The changes are: >>> >>> - handle safe fetch fault in the various (os_cpu dependend) >>> secondary >>> signal handlers >>> >>> - provide a function to check if it is safe to use SafeFetch: >>> CanUseSafeFetch32(). SafeFetch needs stub routines and will >>> crash when >>> used >>> before stub generation. >>> >>> - set_context_pc() is added which complements the existing >>> get_context_pc() >>> and all instances where the pc in ucontext_t was modified >>> directly are >>> changed to use set_context_pc() >>> >>> - in stubRoutines.cpp, a small test was added to the already >>> existing >>> stub >>> routines tests which run at VM init >>> >>> - in vmError.cpp, a test was added to test SafeFetch during >>> error >>> reporting, similar to the tests introduced for 8065895 >>> >>> - A JTreg test was added >>> >>> Thanks and Kind Regards, >>> >>> Thomas Stuefe >>> >>> >>> > From daniel.daugherty at oracle.com Mon Mar 9 17:11:13 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 09 Mar 2015 11:11:13 -0600 Subject: RFR(S) Contended Locking fast exit bucket (8073165) Message-ID: <54FDD431.7010704@oracle.com> Greetings, I have the Contended Locking fast exit bucket ready for review. The code changes in this bucket are primarily assembly language tweaks that come into play when an inflated ObjectMonitor is in use. There are tweaks that apply to the default code path and there are tweaks that only apply when an experimental flag is set. This code code review is focused on the default code path or the "out of the box" configuration. This work is being tracked by the following bug ID: JDK-8073165 Contended Locking fast exit bucket https://bugs.openjdk.java.net/browse/JDK-8073165 Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8073165-webrev/0-jdk9-hs-rt/ Here is the JEP link: https://bugs.openjdk.java.net/browse/JDK-8046133 Testing: - Aurora Adhoc RT/SVC baseline batch - JPRT test jobs - MonitorExitStresser micro-benchmark (in process) - MonitorEnterExitStresser micro-benchmark (in process) - CallTimerGrid stress testing (in process) - Aurora performance testing: - out of the box for the "promotion" and 32-bit server configs - heavy weight monitors for the "promotion" and 32-bit server configs (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors) (in process) 8073165 summary of changes: macroAssembler_sparc.cpp: MacroAssembler::compiler_unlock_object() - default (OOTB) EmitSync value == 0 - an _owner field optimization is in the non-default path under a (EmitSync & 1024) check - classic lock release without 1-0 support is in the non-default path under a (EmitSync & 512) check - an EntryList, cxq and _succ field optimization is in the non-default path under a (EmitSync & 16384) check - the default path is now the 1-0 form that avoids CAS and membar in the common case; see the "1-0 exit" section in objectMonitor.cpp sharedRuntime_sparc.cpp: - add JavaThread* param for SharedRuntime::complete_monitor_unlocking_C call macroAssembler_x86.cpp: MacroAssembler::fast_unlock() - with all the new/modified comments and all the optional code path updates, it is hard to see that the only real changes to the default code path are 1) the _owner==Self check has been made optional and 2) the optional succ field check for the slow path is now on the default path - default (OOTB) EmitSync value == 0 - remove optional (EmitSync & 8) code - refactor code in MacroAssembler::fast_unlock - remove old mfence() support - an _owner field optimization is in the non-default path under a (EmitSync & 1024) check - an _owner field optimization is in the non-default path under a (EmitSync & 16) check - a barrier optimization is in the non-default path under a (EmitSync & 32) check - remove old AMD optional work around sharedRuntime_x86_32.cpp: sharedRuntime_x86_64.cpp: - add thread param for SharedRuntime::complete_monitor_unlocking_C call macro.[ch]pp: PhaseMacroExpand::make_slow_call() - add param2 and update callers runtime.[ch]pp: OptoRuntime::complete_monitor_exit_Type() - add JavaThread* parameter sharedRuntime.[ch]pp: SharedRuntime::complete_monitor_unlocking_C() - add JavaThread* parameter synchronizer.cpp: ObjectSynchronizer::omRelease() - cleanup in use list traversal - add assert that ObjectMonitor being released was actually found and extracted synchronizer.[ch]pp: - add some comments in various places - rename walk_monitor_list() -> deflate_monitor_list() and update callers - minor logic refactoring thread.hpp: - add _TSelf field for mfence() replacement Thanks, in advance, for any comments, questions or suggestions. Dan From coleen.phillimore at oracle.com Mon Mar 9 17:30:27 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 09 Mar 2015 13:30:27 -0400 Subject: [9] RFR (S) 8069111: Investigate NMT detail tracking support for 32bit ARM In-Reply-To: <54F96E59.3040003@oracle.com> References: <54F5D44B.8020103@oracle.com> <54F96ACC.6080601@oracle.com> <54F96E59.3040003@oracle.com> Message-ID: <54FDD8B3.4060501@oracle.com> Chris, Thank you! This fix looks really good. Coleen On 3/6/15, 4:07 AM, Chris Plummer wrote: > On 3/6/15 12:52 AM, Bertrand Delsart wrote: >> On 03/03/2015 16:33, Chris Plummer wrote: >>> Please help with the review for the changes for JDK-8069111: >>> >>> Webrev: http://cr.openjdk.java.net/~cjplummer/8069111/webrev.06/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069111 >>> >>> Tested with JPRT, including running all NMT tests and vmerror.sh. >> >> Looks good. >> >> Thanks for fixing it (particularly the closed part :-)). >> >> Bertrand (not a Reviewer). > Thanks Bertrand! >> >>> >>> Many of the changes are in closed code. For the open code, the main >>> changes are to no longer support the >>> PLATFORM_NATIVE_STACK_WALKING_SUPPORTED macro, and no longer allow >>> platforms to include NMT but not include NMT Detail support. The NMT >>> tests have been modified to reflect this. They no longer check if NMT >>> Detail is supported and adjust the testing based on this. The >>> removal of >>> @ignore in some tests is because the cause of these test failures is >>> fixed in the closed changes. >>> >>> thanks, >>> >>> Chris >> >> > From coleen.phillimore at oracle.com Mon Mar 9 17:52:22 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 09 Mar 2015 13:52:22 -0400 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: References: <54FDBEEC.80606@oracle.com> Message-ID: <54FDDDD6.9010503@oracle.com> Sorry, I should have asked if you use the C++ interpreter (vs. the Zero interpreter). Both interpreters use the file that you modified. If you replied on this bug thread, that would be great. Thanks, Coleen On 3/9/15, 12:27 PM, Thomas St?fe wrote: > Hi Coleen, > > I did built AIX with the CPP interpreter. > > I saw the bug report about removing the CPP interpreter but was not > sure whether the fix was needed for the Zero CPP interpreter too, > > Thanks, Thomas > > On Mon, Mar 9, 2015 at 4:40 PM, Coleen Phillimore > > > wrote: > > > Thomas, Did you build the Zero or the CPP interpreter? See: > > https://bugs.openjdk.java.net/browse/JDK-8074457 > > Thanks, > Coleen > > > On 3/6/15, 6:15 AM, Thomas St?fe wrote: > > Hi all, > > please review this tiny change to fix a build error when > building with the > CPP interpreter. > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ > > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074543 > > bytecodeInterpreter.cpp misses include > "objArrayOop.inline.hpp", so the > inline definition of this function is missing. > > Kind Regards, Thomas > > > From george.triantafillou at oracle.com Mon Mar 9 20:08:21 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Mon, 09 Mar 2015 16:08:21 -0400 Subject: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java failing in nightlies In-Reply-To: <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> References: <1ad101d050a6$d09cbaf0$71d630d0$@oracle.com> <54ED4B09.7000007@oracle.com> <54EE991C.70605@oracle.com> <54EE9B3C.5090206@oracle.com> <54EEA606.9070002@oracle.com> <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> Message-ID: <54FDFDB5.2090500@oracle.com> Christian, This looks good. -George On 3/9/2015 11:29 AM, Christian Tornqvist wrote: > Changed the long to a uintptr_t and cleaned up the loop a bit. > > Please see the update webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.02/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen > Phillimore > Sent: Wednesday, February 25, 2015 11:50 PM > To: David Holmes; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java > failing in nightlies > > > On 2/25/15, 11:04 PM, David Holmes wrote: >> On 26/02/2015 1:55 PM, Coleen Phillimore wrote: >>> >>> In this case, I think 'long' is chosen because we want to turn >>> address into an integral type to create the hashcode and that'll >>> cover a 64 bit address. >> Sounds like a job for intptr_t. > Or maybe uintptr_t if they're arithmetic. >>> Even if we change the signedness of the value, it's still a useful >>> hash code. I don't see a bug here, only unfortunate casts. >> I'm surprised this change doesn't induce further warnings about mixing >> signed and unsigned. But the code screams "type confusion" to me. >> >>> This change looks good to me. It's a really good find, Christian! >>> We've been chasing this bug for months. >> The real bug was reading an uninitialized value no? In which case the >> change from signed to unsigned seems incidental, unless also guarding >> against overflow. > There were two bugs. The signed hash value was 0x8000000 and when negated > was 0x8000000, so created a negative index into the hash table. > > Coleen >> David >> ----- >> >>> Thanks, >>> Coleen >>> >>> >>> On 2/24/15, 11:09 PM, David Holmes wrote: >>>> Hi Christian, >>>> >>>> On 25/02/2015 12:57 PM, Christian Tornqvist wrote: >>>>> Hi everyone, >>>>> >>>>> >>>>> >>>>> Please review this small fix for an issue with NMT. >>>> The use of long in this function looks wrong, particularly as >>>> sizeof(long) might equal sizeof(int) and long is signed but now >>>> _hash_value is unsigned: >>>> >>>> 72 // Hash code. Any better algorithm? >>>> 73 unsigned int NativeCallStack::hash() const { >>>> 74 long hash_val = _hash_value; >>>> 75 if (hash_val == 0) { >>>> 76 long pc; >>>> 77 int index; >>>> 78 for (index = 0; index < NMT_TrackingStackDepth; index ++) { >>>> 79 pc = (long)_stack[index]; >>>> 80 if (pc == 0) break; >>>> 81 hash_val += pc; >>>> 82 } >>>> 83 >>>> 84 NativeCallStack* p = const_cast(this); >>>> 85 p->_hash_value = (unsigned int)(hash_val & 0xFFFFFFFF); >>>> 86 } >>>> 87 return _hash_value; >>>> 88 } >>>> >>>> Even with the original code the use of long seems wrong. >>>> >>>> David >>>> >>>> >>>>> >>>>> The failure was caused by reading random memory from the >>>>> uninitialized _hash_value, when this value happened to be >>>>> 0x80000000, >>>>> hash_to_index() >>>>> failed to negate the value and ended up with an index of -16: >>>>> >>>>> >>>>> >>>>> # Internal Error >>>>> (C:\\jprt\\T\\P1\\130630.ctornqvi\\s\\hotspot\\src\\share\\vm\\serv >>>>> ices\\mal >>>>> >>>>> >>>>> locSiteTable.cpp:139), pid=5680, tid=4928 >>>>> >>>>> # assert(index >= 0) failed: Negative index -16 >>>>> >>>>> >>>>> >>>>> Reproduced the issue and verified the fix using a debugger. Ran >>>>> vm.quick and hotspot/test/:hotspot_jprt tests on Linux i586/x64 and >>>>> Windows >>>>> i586/x64 with >>>>> -XX:NativeMemoryTracking=detail >>>>> >>>>> >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.00/ >>>>> >>>>> >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8069124 >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> >>>>> > From david.holmes at oracle.com Mon Mar 9 22:06:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 08:06:02 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> Message-ID: <54FE194A.4080205@oracle.com> On 10/03/2015 2:30 AM, Thomas St?fe wrote: > Hi David, > > I see now that only Windows 32bit is broken. I will investigate this. Yes, sorry, I hadn't noticed it was only 32-bit failing. Thanks, David > Thomas > > On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe > wrote: > > Hi David, > > I am sorry, but I am unable to reproduce the error. Both slowdebug > and fastdebug builds on Windows come up and SafeFetch works (also in > error handling). Are you sure the crash is caused by my change? If > yes, could you send me an hs-err file or at least the configure line > you used for building? > > Kind Regards, Thomas > > On Mon, Mar 9, 2015 at 7:51 AM, David Holmes > > wrote: > > On 9/03/2015 4:21 PM, Thomas St?fe wrote: > > Hi David, > > Ouch. The only thing I can think about are the added > initialization > tests in stubRoutines.cpp. I will check this. > > > Ah! It hadn't registered with me that this test code was going > to be executed. Seems the likely cause as a clean repo has no > problems. > > David > > Kind Regards, Thomas > > > > On Mon, Mar 9, 2015 at 6:56 AM, David Holmes > > >> wrote: > > Hi Thomas, > > FYI When I applied this to latest hs-rt forest and ran > through JPRT > the Windows fastdebug builds were DOA (instant segfault > just running > "java -version"). Can't see how your changes could do > this so > running a test on unmodified forest. > > David > > > On 9/03/2015 9:40 AM, David Holmes wrote: > > Hi Thomas, > > Minor nit: in > > src/share/vm/runtime/____stubRoutines.cpp::test_____safefetchN > can > you use UCONST64 macro instead of explicit ULL - > thanks. > > Otherwise this seems okay, but we will also need > the aarch64 > component > (and I'll look into our internal needs). > > Thanks, > David > > On 7/03/2015 2:10 AM, Thomas St?fe wrote: > > Hi all, > > could someone please review the following fix > (I also will > need a > sponsor): > > http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/webrev.____01/ > > > > > > https://bugs.openjdk.java.net/____browse/JDK-8074552 > > > > > > > The fix will make SafeFetch[32,N] work in error > reporting. > > At SAP, we use SafeFetch a lot in error > reporting to poke > around in > potentially invalid memory (e.g. writing hex > dumps over > areas which > may be > partly unmapped), and we feel that this could > be useful for the > OpenJDK too. > > Without this fix, SafeFetch will cause a crash, > the current > error > reporting > step will be interrupted and error reporting > will continue > with the next > step; that is not optimal because the > interrupted step may > have shown > valuable information. > > This fix handles SafeFetch faults during error > reporting the > same way as > they are handled normally. The changes are: > > - handle safe fetch fault in the various > (os_cpu dependend) > secondary > signal handlers > > - provide a function to check if it is safe to > use SafeFetch: > CanUseSafeFetch32(). SafeFetch needs stub > routines and will > crash when > used > before stub generation. > > - set_context_pc() is added which complements > the existing > get_context_pc() > and all instances where the pc in ucontext_t > was modified > directly are > changed to use set_context_pc() > > - in stubRoutines.cpp, a small test was added > to the already > existing > stub > routines tests which run at VM init > > - in vmError.cpp, a test was added to test > SafeFetch during > error > reporting, similar to the tests introduced for > 8065895 > > - A JTreg test was added > > Thanks and Kind Regards, > > Thomas Stuefe > > > > From david.holmes at oracle.com Mon Mar 9 23:48:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 09:48:00 +1000 Subject: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java failing in nightlies In-Reply-To: <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> References: <1ad101d050a6$d09cbaf0$71d630d0$@oracle.com> <54ED4B09.7000007@oracle.com> <54EE991C.70605@oracle.com> <54EE9B3C.5090206@oracle.com> <54EEA606.9070002@oracle.com> <153a01d05a7d$e72fdd70$b58f9850$@oracle.com> Message-ID: <54FE3130.2050301@oracle.com> Looks good. Thanks, David On 10/03/2015 1:29 AM, Christian Tornqvist wrote: > Changed the long to a uintptr_t and cleaned up the loop a bit. > > Please see the update webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.02/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen > Phillimore > Sent: Wednesday, February 25, 2015 11:50 PM > To: David Holmes; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8069124 - runtime/NMT/MallocSiteHashOverflow.java > failing in nightlies > > > On 2/25/15, 11:04 PM, David Holmes wrote: >> On 26/02/2015 1:55 PM, Coleen Phillimore wrote: >>> >>> >>> In this case, I think 'long' is chosen because we want to turn >>> address into an integral type to create the hashcode and that'll >>> cover a 64 bit address. >> >> Sounds like a job for intptr_t. > > Or maybe uintptr_t if they're arithmetic. >> >>> Even if we change the signedness of the value, it's still a useful >>> hash code. I don't see a bug here, only unfortunate casts. >> >> I'm surprised this change doesn't induce further warnings about mixing >> signed and unsigned. But the code screams "type confusion" to me. >> >>> This change looks good to me. It's a really good find, Christian! >>> We've been chasing this bug for months. >> >> The real bug was reading an uninitialized value no? In which case the >> change from signed to unsigned seems incidental, unless also guarding >> against overflow. > > There were two bugs. The signed hash value was 0x8000000 and when negated > was 0x8000000, so created a negative index into the hash table. > > Coleen >> >> David >> ----- >> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 2/24/15, 11:09 PM, David Holmes wrote: >>>> Hi Christian, >>>> >>>> On 25/02/2015 12:57 PM, Christian Tornqvist wrote: >>>>> Hi everyone, >>>>> >>>>> >>>>> >>>>> Please review this small fix for an issue with NMT. >>>> >>>> The use of long in this function looks wrong, particularly as >>>> sizeof(long) might equal sizeof(int) and long is signed but now >>>> _hash_value is unsigned: >>>> >>>> 72 // Hash code. Any better algorithm? >>>> 73 unsigned int NativeCallStack::hash() const { >>>> 74 long hash_val = _hash_value; >>>> 75 if (hash_val == 0) { >>>> 76 long pc; >>>> 77 int index; >>>> 78 for (index = 0; index < NMT_TrackingStackDepth; index ++) { >>>> 79 pc = (long)_stack[index]; >>>> 80 if (pc == 0) break; >>>> 81 hash_val += pc; >>>> 82 } >>>> 83 >>>> 84 NativeCallStack* p = const_cast(this); >>>> 85 p->_hash_value = (unsigned int)(hash_val & 0xFFFFFFFF); >>>> 86 } >>>> 87 return _hash_value; >>>> 88 } >>>> >>>> Even with the original code the use of long seems wrong. >>>> >>>> David >>>> >>>> >>>>> >>>>> >>>>> The failure was caused by reading random memory from the >>>>> uninitialized _hash_value, when this value happened to be >>>>> 0x80000000, >>>>> hash_to_index() >>>>> failed to negate the value and ended up with an index of -16: >>>>> >>>>> >>>>> >>>>> # Internal Error >>>>> (C:\\jprt\\T\\P1\\130630.ctornqvi\\s\\hotspot\\src\\share\\vm\\serv >>>>> ices\\mal >>>>> >>>>> >>>>> locSiteTable.cpp:139), pid=5680, tid=4928 >>>>> >>>>> # assert(index >= 0) failed: Negative index -16 >>>>> >>>>> >>>>> >>>>> Reproduced the issue and verified the fix using a debugger. Ran >>>>> vm.quick and hotspot/test/:hotspot_jprt tests on Linux i586/x64 and >>>>> Windows >>>>> i586/x64 with >>>>> -XX:NativeMemoryTracking=detail >>>>> >>>>> >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8069124/webrev.00/ >>>>> >>>>> >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8069124 >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>> > > From mikael.vidstedt at oracle.com Tue Mar 10 00:57:03 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 09 Mar 2015 17:57:03 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code Message-ID: <54FE415F.10905@oracle.com> Please review this small change which removes the unused/dead frame::native_param_addr function along with the corresponding code in the SA. http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ Cheers, Mikael From david.holmes at oracle.com Tue Mar 10 01:45:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 11:45:25 +1000 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FE415F.10905@oracle.com> References: <54FE415F.10905@oracle.com> Message-ID: <54FE4CB5.6060503@oracle.com> Hi Mikael, On 10/03/2015 10:57 AM, Mikael Vidstedt wrote: > > Please review this small change which removes the unused/dead > frame::native_param_addr function along with the corresponding code in > the SA. > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ Isn't NATIVE_FRAME_INITIAL_PARAM_OFFSET also dead now in the Java code. Similarly native_frame_initial_param_offset in the C code Will you also do the aarch64 changes? Thanks, David > Cheers, > Mikael > From chris.plummer at oracle.com Tue Mar 10 02:22:16 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 09 Mar 2015 19:22:16 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FE415F.10905@oracle.com> References: <54FE415F.10905@oracle.com> Message-ID: <54FE5558.1090103@oracle.com> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: > > Please review this small change which removes the unused/dead > frame::native_param_addr function along with the corresponding code in > the SA. > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ > > Cheers, > Mikael > Since you're removing unused frame APIs, maybe you can also remove frame::set_link(), which is also not used. I have no idea why it's there. Seems to be a very dangerous thing to do since the link (previous frame pointer) is setup by function prologue code, not by the JVM. cheers, Chris From thomas.stuefe at gmail.com Tue Mar 10 09:12:23 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 10 Mar 2015 10:12:23 +0100 Subject: RFR(xxs) 8074543 Missing symbol "objArrayOopDesc::obj_at" when buiding with CPP Interpreter In-Reply-To: <54FDDDD6.9010503@oracle.com> References: <54FDBEEC.80606@oracle.com> <54FDDDD6.9010503@oracle.com> Message-ID: Hi Coleen, We actually do not use the C++ Interpreter anymore (neither the zero one), all our platforms use the template interpreter. I accidentally built AIX with C++ interpreter and wanted to fix that tiny bug anyway. I updated the thread in the bug report. Thomas On Mon, Mar 9, 2015 at 6:52 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Sorry, I should have asked if you use the C++ interpreter (vs. the Zero > interpreter). Both interpreters use the file that you modified. If you > replied on this bug thread, that would be great. > Thanks, > Coleen > > > On 3/9/15, 12:27 PM, Thomas St?fe wrote: > > Hi Coleen, > > I did built AIX with the CPP interpreter. > > I saw the bug report about removing the CPP interpreter but was not sure > whether the fix was needed for the Zero CPP interpreter too, > > Thanks, Thomas > > On Mon, Mar 9, 2015 at 4:40 PM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> Thomas, Did you build the Zero or the CPP interpreter? See: >> >> https://bugs.openjdk.java.net/browse/JDK-8074457 >> >> Thanks, >> Coleen >> >> >> On 3/6/15, 6:15 AM, Thomas St?fe wrote: >> >>> Hi all, >>> >>> please review this tiny change to fix a build error when building with >>> the >>> CPP interpreter. >>> >>> webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/8074543/webrev.01/ >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8074543 >>> >>> bytecodeInterpreter.cpp misses include "objArrayOop.inline.hpp", so the >>> inline definition of this function is missing. >>> >>> Kind Regards, Thomas >>> >> >> > > From david.simms at oracle.com Tue Mar 10 13:49:59 2015 From: david.simms at oracle.com (David Simms) Date: Tue, 10 Mar 2015 14:49:59 +0100 Subject: [8u] Request for approval: JDK-8043224: -Xcheck:jni improvements to exception checking and excessive local refs In-Reply-To: <54F0B797.6090700@oracle.com> References: <54F0B797.6090700@oracle.com> Message-ID: <54FEF687.2040506@oracle.com> Apologies for the late reply (just returned to work today). Looks good ! On 27/02/2015 7:29 p.m., Poonam Bajaj Parhar wrote: > Hello, > > I'd like to backport the fix of 8043224 to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043224 > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/232dbf06eb07 > 8u webrev: http://cr.openjdk.java.net/~poonam/8043224/webrev/ > Build and Test: JPRT > > The fix applies cleanly to 8u. > > Thanks, > Poonam > From andreas.eriksson at oracle.com Tue Mar 10 16:10:29 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 10 Mar 2015 17:10:29 +0100 Subject: RFR (S): 8072588 - JVM crashes in JNI if toString is declared as an interface method Message-ID: <54FF1775.8020308@oracle.com> Hi, Please review this fix for a JNI issue in jni_invoke_nonstatic. The problem is that when toString is declared as an interface method it still has a vtable index, not an itable index as jni_invoke_nonstatic expects. This fix checks for a valid itable index instead of checking if the holder is an interface. I also moved a duplicated check for JNI_VIRTUAL to be done in one check instead. The change has been verified to fix the problem with a small JNI test, and has passed a jprt run with the hotspot testset. Webrev: http://cr.openjdk.java.net/~aeriksso/8072588/webrev.00/ Regards, Andreas From thomas.stuefe at gmail.com Tue Mar 10 17:21:07 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 10 Mar 2015 18:21:07 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <54FE194A.4080205@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> Message-ID: Hi David, see here my new patch: http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ Turns out that SafeFetch32 does not work in 32bit windows during initialization, because there is no SEH exception guard installed at that time (during the call to CreateJavaVM). Neither is there one for 64bit Windows, but there, we register SEH handlers for dynamic code, that hides the error. This is an issue I'd like to address with a separate patch (see https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I deactivated the SafeFetch test during stub routine initialization for Windows 32bit. Other changes in the fix: - as you wished I changed the ULL literals to UCONST64 - I activated the Jtreg test for windows too (SafeFetch works on windows during error handling, only not during initialization). Thomas On Mon, Mar 9, 2015 at 11:06 PM, David Holmes wrote: > On 10/03/2015 2:30 AM, Thomas St?fe wrote: > >> Hi David, >> >> I see now that only Windows 32bit is broken. I will investigate this. >> > > Yes, sorry, I hadn't noticed it was only 32-bit failing. > > Thanks, > David > > Thomas >> >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe > > wrote: >> >> Hi David, >> >> I am sorry, but I am unable to reproduce the error. Both slowdebug >> and fastdebug builds on Windows come up and SafeFetch works (also in >> error handling). Are you sure the crash is caused by my change? If >> yes, could you send me an hs-err file or at least the configure line >> you used for building? >> >> Kind Regards, Thomas >> >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes >> > wrote: >> >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >> >> Hi David, >> >> Ouch. The only thing I can think about are the added >> initialization >> tests in stubRoutines.cpp. I will check this. >> >> >> Ah! It hadn't registered with me that this test code was going >> to be executed. Seems the likely cause as a clean repo has no >> problems. >> >> David >> >> Kind Regards, Thomas >> >> >> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >> >> > >> wrote: >> >> Hi Thomas, >> >> FYI When I applied this to latest hs-rt forest and ran >> through JPRT >> the Windows fastdebug builds were DOA (instant segfault >> just running >> "java -version"). Can't see how your changes could do >> this so >> running a test on unmodified forest. >> >> David >> >> >> On 9/03/2015 9:40 AM, David Holmes wrote: >> >> Hi Thomas, >> >> Minor nit: in >> >> src/share/vm/runtime/____stubRoutines.cpp::test_____ >> safefetchN >> can >> you use UCONST64 macro instead of explicit ULL - >> thanks. >> >> Otherwise this seems okay, but we will also need >> the aarch64 >> component >> (and I'll look into our internal needs). >> >> Thanks, >> David >> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> >> Hi all, >> >> could someone please review the following fix >> (I also will >> need a >> sponsor): >> >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ >> webrev.____01/ >> > webrev.__01/> >> >> > webrev.__01/ >> > 01/>> >> >> https://bugs.openjdk.java.net/____browse/JDK-8074552 >> >> >> >> > >> > >> >> The fix will make SafeFetch[32,N] work in error >> reporting. >> >> At SAP, we use SafeFetch a lot in error >> reporting to poke >> around in >> potentially invalid memory (e.g. writing hex >> dumps over >> areas which >> may be >> partly unmapped), and we feel that this could >> be useful for the >> OpenJDK too. >> >> Without this fix, SafeFetch will cause a crash, >> the current >> error >> reporting >> step will be interrupted and error reporting >> will continue >> with the next >> step; that is not optimal because the >> interrupted step may >> have shown >> valuable information. >> >> This fix handles SafeFetch faults during error >> reporting the >> same way as >> they are handled normally. The changes are: >> >> - handle safe fetch fault in the various >> (os_cpu dependend) >> secondary >> signal handlers >> >> - provide a function to check if it is safe to >> use SafeFetch: >> CanUseSafeFetch32(). SafeFetch needs stub >> routines and will >> crash when >> used >> before stub generation. >> >> - set_context_pc() is added which complements >> the existing >> get_context_pc() >> and all instances where the pc in ucontext_t >> was modified >> directly are >> changed to use set_context_pc() >> >> - in stubRoutines.cpp, a small test was added >> to the already >> existing >> stub >> routines tests which run at VM init >> >> - in vmError.cpp, a test was added to test >> SafeFetch during >> error >> reporting, similar to the tests introduced for >> 8065895 >> >> - A JTreg test was added >> >> Thanks and Kind Regards, >> >> Thomas Stuefe >> >> >> >> >> From markus.gronlund at oracle.com Tue Mar 10 21:02:03 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 10 Mar 2015 14:02:03 -0700 (PDT) Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make Message-ID: Greetings, Please review this small update to the Visual Studio projectcreator.make in order to exclude aarch64 files. Bug: https://bugs.openjdk.java.net/browse/JDK-8074905 Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/ Thanks Markus From jeremymanson at google.com Tue Mar 10 21:08:15 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 10 Mar 2015 14:08:15 -0700 Subject: RFR: 8074895: os::getenv is inadequate Message-ID: Hi, David, I'd like you to do a code review, please. Original discussion: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-March/016851.html Per this discussion, I'm just getting rid of the os::getenv interface, and using straight getenv() everywhere. Bug: https://bugs.openjdk.java.net/browse/JDK-8074895 Webrev: http://cr.openjdk.java.net/~jmanson/8074895/webrev.00/ Jeremy From jeremymanson at google.com Tue Mar 10 21:09:45 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 10 Mar 2015 14:09:45 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: Message-ID: (At some point, there will be a follow-on bug to fix the fact that JAVA_TOOL_OPTIONS doesn't accept things like PrintVMOptions and IgnoreUnrecognizedVMOptions, but that's in the future.) On Tue, Mar 10, 2015 at 2:08 PM, Jeremy Manson wrote: > Hi, David, > > I'd like you to do a code review, please. Original discussion: > > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-March/016851.html > > Per this discussion, I'm just getting rid of the os::getenv interface, and > using straight getenv() everywhere. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8074895 > > Webrev: > http://cr.openjdk.java.net/~jmanson/8074895/webrev.00/ > > Jeremy > From christian.tornqvist at oracle.com Tue Mar 10 21:27:07 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 10 Mar 2015 17:27:07 -0400 Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make In-Reply-To: References: Message-ID: <003701d05b78$f63ab4b0$e2b01e10$@oracle.com> Hi Markus, This looks good, thanks for fixing this. Thanks, Christian From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Markus Gronlund Sent: Tuesday, March 10, 2015 5:02 PM To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make Greetings, Please review this small update to the Visual Studio projectcreator.make in order to exclude aarch64 files. Bug: https://bugs.openjdk.java.net/browse/JDK-8074905 Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/ Thanks Markus From coleen.phillimore at oracle.com Tue Mar 10 21:54:42 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 10 Mar 2015 17:54:42 -0400 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <54F8C8DC.2030502@oracle.com> References: <54F8C8DC.2030502@oracle.com> Message-ID: <54FF6822.5070702@oracle.com> Yumin, The new bytecode approach came out pretty cleanly, or as cleanly as this could be. The file templateTable_x86_32 and 64 have just been merged, so you'll have to make your change in the new version. I also have some comments: http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html Typo "rewirting" In these files, can you break up the long lines into three lines? - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } + if (!is_static && rc == MAY_REWRITE) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html How many bytecodes do we have now? We're limited to 255 (or 256) and there are other new bytecodes being added. What was the performance benefit to this? I think if we wanted to be conservative, we'd turn off RewriteFrequentPairs and only do nofast_getfield and nofast_putfield. I think they were the only bytecodes that actually affected performance. In this file above, can you remove the last block of comments about fast_linearswitch and fast_ldc? I think this confuses rewriting in the interpreter and rewriting in the rewriter, or rather makes the confusion worse. I don't think this comment is helpful. I'd prefer to see the first comment smaller also, like: + // These bytecodes are rewritten at CDS dump time, so that we can prevent them from being + // rewritten at run time. This way, the ConstMethods can be placed in the CDS ReadOnly + // section, and RewriteByteCodes/RewriteFrequentPairs can rewrite non-CDS bytecodes + // at run time. + _nofast_getfield , + _nofast_putfield , + _nofast_aload_0 , + _nofast_iload , + _nofast_invokevirtual , It's sort of obvious which bytecode they rewrite. I don't know how much performance fast_invokevfinal is worth. I thought I deleted it. Can we not rewrite this so we don't waste another bytecode on it? Maybe add a RewriteVFinal option and consider removing it for the future? x86 doesn't use it and I can't see how this would save any significant performance to be worth having! http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // control for fast code under CDS I don't know what our coding standard is but in the templateTable_.cpp files these strings look like macros. I'd rather see them as MayRewrite or MayNotRewrite. http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html I think there's a java_code() function that returns the original bytecode that you could use instead of the case statement in resolve_cache_and_index(). The indentation is odd in the webrev. This probably applies to the other cpu directories. One last question below: On 3/5/15, 4:21 PM, Yumin Qi wrote: > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8074345 > webrev: http://cr.openjdk.java.net/~minqi/8074345/ > > Summary: Currently CDS when is disabled, RewriteBytecodes and > RewriteFrequentPairs are disabled due to ConstantMethod in CDS are > mapped read only. So memory fault will be triggered when > RewriteBytecodes turned on. This also disable all method rewritten, > leads interpreter run slower. Observed about 2% regression with C2 on > some benchmarks, since interpreter speed is important to C2. By enable > RewriteBytecodes and RewriteFrequentPairs under CDS enabled, adding > _nofast_xxxx for corresponding fast codes at dump time to avoid byte > code rewritten at run time, we prevent byte code rewritten and modify > the read only shared portion in CDS. Meanwhile other byte codes with > fast codes still get speed up. > > Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported > platforms. Interpreter only tests showed about 3% improvement. What performance did you measure? Is it -Xint -Xshare:on with and without your patch? It was only 3% better? What was the difference in performance with -Xint -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? I thought this was around 15%. Thanks, Coleen > > Thanks > Yumin > From mikael.vidstedt at oracle.com Tue Mar 10 22:45:09 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 10 Mar 2015 15:45:09 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FE5558.1090103@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> Message-ID: <54FF73F5.3050700@oracle.com> New version: http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ Changes since webrev.00: * Removed native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET * Removed set_link * Made corresponding changes for aarch64 * Removed the vmStruct constant abi_minframe_size, the only usage which was for NATIVE_FRAME_INITIAL_PARAM_OFFSET Cheers, Mikael On 2015-03-09 19:22, Chris Plummer wrote: > On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >> >> Please review this small change which removes the unused/dead >> frame::native_param_addr function along with the corresponding code >> in the SA. >> >> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >> >> Cheers, >> Mikael >> > Since you're removing unused frame APIs, maybe you can also remove > frame::set_link(), which is also not used. I have no idea why it's > there. Seems to be a very dangerous thing to do since the link > (previous frame pointer) is setup by function prologue code, not by > the JVM. > > cheers, > > Chris From chris.plummer at oracle.com Tue Mar 10 22:59:55 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 10 Mar 2015 15:59:55 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FF73F5.3050700@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> <54FF73F5.3050700@oracle.com> Message-ID: <54FF776B.5040007@oracle.com> The set_link() removal looks good (thank you for taking care of this). Copyright year needs updating on all files. cheers, Chris On 3/10/15 3:45 PM, Mikael Vidstedt wrote: > > New version: > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ > > Changes since webrev.00: > > * Removed > native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET > * Removed set_link > * Made corresponding changes for aarch64 > * Removed the vmStruct constant abi_minframe_size, the only usage > which was for NATIVE_FRAME_INITIAL_PARAM_OFFSET > > Cheers, > Mikael > > On 2015-03-09 19:22, Chris Plummer wrote: >> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the unused/dead >>> frame::native_param_addr function along with the corresponding code >>> in the SA. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> >> Since you're removing unused frame APIs, maybe you can also remove >> frame::set_link(), which is also not used. I have no idea why it's >> there. Seems to be a very dangerous thing to do since the link >> (previous frame pointer) is setup by function prologue code, not by >> the JVM. >> >> cheers, >> >> Chris > From david.holmes at oracle.com Wed Mar 11 00:46:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Mar 2015 10:46:30 +1000 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FF73F5.3050700@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> <54FF73F5.3050700@oracle.com> Message-ID: <54FF9066.5030602@oracle.com> Looks good to me Mikael. Just update copyrights as Chris said :) Thanks, David On 11/03/2015 8:45 AM, Mikael Vidstedt wrote: > > New version: > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ > > Changes since webrev.00: > > * Removed > native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET > * Removed set_link > * Made corresponding changes for aarch64 > * Removed the vmStruct constant abi_minframe_size, the only usage which > was for NATIVE_FRAME_INITIAL_PARAM_OFFSET > > Cheers, > Mikael > > On 2015-03-09 19:22, Chris Plummer wrote: >> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the unused/dead >>> frame::native_param_addr function along with the corresponding code >>> in the SA. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> >> Since you're removing unused frame APIs, maybe you can also remove >> frame::set_link(), which is also not used. I have no idea why it's >> there. Seems to be a very dangerous thing to do since the link >> (previous frame pointer) is setup by function prologue code, not by >> the JVM. >> >> cheers, >> >> Chris > From david.holmes at oracle.com Wed Mar 11 01:03:44 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Mar 2015 11:03:44 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> Message-ID: <54FF9470.8040507@oracle.com> On 11/03/2015 3:21 AM, Thomas St?fe wrote: > Hi David, > > see here my new patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ > > Turns out that SafeFetch32 does not work in 32bit windows during > initialization, because there is no SEH exception guard installed at > that time (during the call to CreateJavaVM). Neither is there one for > 64bit Windows, but there, we register SEH handlers for dynamic code, > that hides the error. > > This is an issue I'd like to address with a separate patch (see > https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I > deactivated the SafeFetch test during stub routine initialization for > Windows 32bit. > > Other changes in the fix: > - as you wished I changed the ULL literals to UCONST64 > - I activated the Jtreg test for windows too (SafeFetch works on windows > during error handling, only not during initialization). Okay - this all looks good to me. Running through internal testing now. Need a second reviewer before I can submit this. Thanks, David > Thomas > > > > > > On Mon, Mar 9, 2015 at 11:06 PM, David Holmes > wrote: > > On 10/03/2015 2:30 AM, Thomas St?fe wrote: > > Hi David, > > I see now that only Windows 32bit is broken. I will investigate > this. > > > Yes, sorry, I hadn't noticed it was only 32-bit failing. > > Thanks, > David > > Thomas > > On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe > > >> wrote: > > Hi David, > > I am sorry, but I am unable to reproduce the error. Both > slowdebug > and fastdebug builds on Windows come up and SafeFetch works > (also in > error handling). Are you sure the crash is caused by my > change? If > yes, could you send me an hs-err file or at least the > configure line > you used for building? > > Kind Regards, Thomas > > On Mon, Mar 9, 2015 at 7:51 AM, David Holmes > > >> wrote: > > On 9/03/2015 4:21 PM, Thomas St?fe wrote: > > Hi David, > > Ouch. The only thing I can think about are the added > initialization > tests in stubRoutines.cpp. I will check this. > > > Ah! It hadn't registered with me that this test code > was going > to be executed. Seems the likely cause as a clean repo > has no > problems. > > David > > Kind Regards, Thomas > > > > On Mon, Mar 9, 2015 at 6:56 AM, David Holmes > > > > ____com > >>> wrote: > > Hi Thomas, > > FYI When I applied this to latest hs-rt forest > and ran > through JPRT > the Windows fastdebug builds were DOA (instant > segfault > just running > "java -version"). Can't see how your changes > could do > this so > running a test on unmodified forest. > > David > > > On 9/03/2015 9:40 AM, David Holmes wrote: > > Hi Thomas, > > Minor nit: in > > > src/share/vm/runtime/______stubRoutines.cpp::test_______safefetchN > can > you use UCONST64 macro instead of explicit > ULL - > thanks. > > Otherwise this seems okay, but we will > also need > the aarch64 > component > (and I'll look into our internal needs). > > Thanks, > David > > On 7/03/2015 2:10 AM, Thomas St?fe wrote: > > Hi all, > > could someone please review the > following fix > (I also will > need a > sponsor): > > http://cr.openjdk.java.net/~______stuefe/webrevs/8074552/__webrev.____01/ > > > > > > > > > >> > > https://bugs.openjdk.java.net/______browse/JDK-8074552 > > > > > > > > >> > > The fix will make SafeFetch[32,N] work > in error > reporting. > > At SAP, we use SafeFetch a lot in error > reporting to poke > around in > potentially invalid memory (e.g. > writing hex > dumps over > areas which > may be > partly unmapped), and we feel that > this could > be useful for the > OpenJDK too. > > Without this fix, SafeFetch will cause > a crash, > the current > error > reporting > step will be interrupted and error > reporting > will continue > with the next > step; that is not optimal because the > interrupted step may > have shown > valuable information. > > This fix handles SafeFetch faults > during error > reporting the > same way as > they are handled normally. The changes > are: > > - handle safe fetch fault in the various > (os_cpu dependend) > secondary > signal handlers > > - provide a function to check if it is > safe to > use SafeFetch: > CanUseSafeFetch32(). SafeFetch needs stub > routines and will > crash when > used > before stub generation. > > - set_context_pc() is added which > complements > the existing > get_context_pc() > and all instances where the pc in > ucontext_t > was modified > directly are > changed to use set_context_pc() > > - in stubRoutines.cpp, a small test > was added > to the already > existing > stub > routines tests which run at VM init > > - in vmError.cpp, a test was added to test > SafeFetch during > error > reporting, similar to the tests > introduced for > 8065895 > > - A JTreg test was added > > Thanks and Kind Regards, > > Thomas Stuefe > > > > > From yumin.qi at oracle.com Wed Mar 11 07:02:29 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 11 Mar 2015 00:02:29 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file Message-ID: <54FFE885.3010604@oracle.com> Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8074354 webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ Summary: Tests timed out when VM crashes and dumping core file which in the test case is not needed. To make core not created, the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is only used on Windows and the latter for all platforms. When VM crashes on non Windows, core file generated as default if OS sets core dump allowed. Default value of CreateCoredumpOnCrash set to 'true' to keep same behavior on non Windows platforms, but changed for Windows --- original is false, not create minidump on Windows. With CreateCoredumpOnCrash turned off, no core file will be generated. CreateMinidumpOnCrash still can be used on commandline but only as alias for the new flag. Tests: JPRT, manual tests setting CreateMinidumpOnCrash on commandline to verify flag change as alias. Thanks Yumin From staffan.larsen at oracle.com Wed Mar 11 07:44:55 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 08:44:55 +0100 Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make In-Reply-To: References: Message-ID: <15265D77-FBE5-4B87-99BC-65C688157AC1@oracle.com> Looks good! Thanks, /Staffan > On 10 mar 2015, at 22:02, Markus Gronlund wrote: > > Greetings, > > > > Please review this small update to the Visual Studio projectcreator.make in order to exclude aarch64 files. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074905 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/ > > > > > > Thanks > > Markus From thomas.stuefe at gmail.com Wed Mar 11 10:47:31 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 11:47:31 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <54FFE885.3010604@oracle.com> References: <54FFE885.3010604@oracle.com> Message-ID: Hi Yumin, There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! Beyond that, as I wrote in the bug report comments: "This is also a problem on Windows - MiniDumpWriteDump() may hang infinitly. And on Windows this is worse than under UNIX because we create the Dump before writing the hs-err file, so if the Dump hangs, we get no error log. I would like to revert the order: create the minidump after writing the error log, the same way Unix does it. We did this in our JVM (SAP) because for us, error logs are more useful than minidumps. " So, I would like to see os::abort on Windows call MiniDumpWriteDump(), and thus the mini dump writing moved after the error log writing. This would also make the code way cleaner because the control flow would be the same on all platforms. I understand that this may be out of scope for your change, but I would like to know what others think about this. Kind regards, Thomas On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi wrote: > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8074354 > webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > > Summary: Tests timed out when VM crashes and dumping core file which in > the test case is not needed. To make core not created, the fix changed > CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is only used on > Windows and the latter for all platforms. When VM crashes on non Windows, > core file generated as default if OS sets core dump allowed. Default value > of CreateCoredumpOnCrash set to 'true' to keep same behavior on non Windows > platforms, but changed for Windows --- original is false, not create > minidump on Windows. With CreateCoredumpOnCrash turned off, no core file > will be generated. CreateMinidumpOnCrash still can be used on commandline > but only as alias for the new flag. > > Tests: JPRT, manual tests setting CreateMinidumpOnCrash on commandline to > verify flag change as alias. > > Thanks > Yumin > From staffan.larsen at oracle.com Wed Mar 11 11:18:34 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 12:18:34 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> Message-ID: > On 11 mar 2015, at 11:47, Thomas St?fe wrote: > > Hi Yumin, > > There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - could > you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! > > Beyond that, as I wrote in the bug report comments: > > "This is also a problem on Windows - MiniDumpWriteDump() may hang > infinitly. And on Windows this is worse than under UNIX because we create > the Dump before writing the hs-err file, so if the Dump hangs, we get no > error log. I would like to revert the order: create the minidump after > writing the error log, the same way Unix does it. We did this in our JVM > (SAP) because for us, error logs are more useful than minidumps. ? The reason the order is what it is is for the minidump to have the most relevant context regarding the failure. If we run the error log writing before writing the minidump, then the state of the VM has changed since the failure occurred and the minidump will have less value. Only windows provides the possibility to do this which is why it is only this way on windows. When does MiniDumpWriteDump hang infinitly? /Staffan > > So, I would like to see os::abort on Windows call MiniDumpWriteDump(), and > thus the mini dump writing moved after the error log writing. This would > also make the code way cleaner because the control flow would be the same > on all platforms. > > I understand that this may be out of scope for your change, but I would > like to know what others think about this. > > Kind regards, Thomas > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi wrote: > >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >> >> Summary: Tests timed out when VM crashes and dumping core file which in >> the test case is not needed. To make core not created, the fix changed >> CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is only used on >> Windows and the latter for all platforms. When VM crashes on non Windows, >> core file generated as default if OS sets core dump allowed. Default value >> of CreateCoredumpOnCrash set to 'true' to keep same behavior on non Windows >> platforms, but changed for Windows --- original is false, not create >> minidump on Windows. With CreateCoredumpOnCrash turned off, no core file >> will be generated. CreateMinidumpOnCrash still can be used on commandline >> but only as alias for the new flag. >> >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on commandline to >> verify flag change as alias. >> >> Thanks >> Yumin >> From thomas.stuefe at gmail.com Wed Mar 11 11:39:18 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 12:39:18 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> Message-ID: Hi Staffan, On Wed, Mar 11, 2015 at 12:18 PM, Staffan Larsen wrote: > > > On 11 mar 2015, at 11:47, Thomas St?fe wrote: > > > > Hi Yumin, > > > > There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - could > > you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! > > > > Beyond that, as I wrote in the bug report comments: > > > > "This is also a problem on Windows - MiniDumpWriteDump() may hang > > infinitly. And on Windows this is worse than under UNIX because we create > > the Dump before writing the hs-err file, so if the Dump hangs, we get no > > error log. I would like to revert the order: create the minidump after > > writing the error log, the same way Unix does it. We did this in our JVM > > (SAP) because for us, error logs are more useful than minidumps. ? > > The reason the order is what it is is for the minidump to have the most > relevant context regarding the failure. If we run the error log writing > before writing the minidump, then the state of the VM has changed since the > failure occurred and the minidump will have less value. Only windows > provides the possibility to do this which is why it is only this way on > windows. > > For our support error logs are more important than minidumps. Customers usually send error logs, almost never cores, and if they do, they are difficult to work with. Also on Windows, we found anything but full dumps (including all memory) of little use, but full dumps can get very big. But I can see that this may be different for your work. At some point we decided to just revert the order of error log and mini dump. So we pay the price of MiniDumps being a little more removed from the crash point (like they are on Unix), and get more reliably error logs which are closer to the crash point. And for cases where we really want a good core, we added an option "-XX:+ImmediateCoreOnError", which just cores right away when an error happens instead of calling VmError::report_and_die(). That works on Unix too. A nice side effect about our solution is that all platforms behave identically. > When does MiniDumpWriteDump hang infinitly? > > I do not know. Had several cases of hanging tests on various machines. Process was hanging in MiniDumpWriteDump() and did not return. Debugging revealed nothing in particular. Seems to be a known issue, if you google around, you find reports of MiniDumpWriteDump freezing but no solution. It may depend on the dbghelp.dll version but that is out of our hands at the customer sites. Thomas > /Staffan > > > > > > So, I would like to see os::abort on Windows call MiniDumpWriteDump(), > and > > thus the mini dump writing moved after the error log writing. This would > > also make the code way cleaner because the control flow would be the same > > on all platforms. > > > > I understand that this may be out of scope for your change, but I would > > like to know what others think about this. > > > > Kind regards, Thomas > > > > > > > > > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi wrote: > > > >> Please review: > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 > >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > >> > >> Summary: Tests timed out when VM crashes and dumping core file which in > >> the test case is not needed. To make core not created, the fix changed > >> CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is only used > on > >> Windows and the latter for all platforms. When VM crashes on non > Windows, > >> core file generated as default if OS sets core dump allowed. Default > value > >> of CreateCoredumpOnCrash set to 'true' to keep same behavior on non > Windows > >> platforms, but changed for Windows --- original is false, not create > >> minidump on Windows. With CreateCoredumpOnCrash turned off, no core file > >> will be generated. CreateMinidumpOnCrash still can be used on > commandline > >> but only as alias for the new flag. > >> > >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on commandline > to > >> verify flag change as alias. > >> > >> Thanks > >> Yumin > >> > > From christian.tornqvist at oracle.com Wed Mar 11 11:56:48 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 11 Mar 2015 07:56:48 -0400 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> Message-ID: <008c01d05bf2$74d7b010$5e871030$@oracle.com> Hi Staffan, >When does MiniDumpWriteDump hang infinitly? This can happen if we crash when someone is holding the process wide LdrpLoaderLock lock. Dbghelp.dll will try to load other libraries (version.dll and others) and will end up hanging waiting for the lock to be released. https://bugs.openjdk.java.net/browse/JDK-8051995 has more info on this. Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Staffan Larsen Sent: Wednesday, March 11, 2015 7:19 AM To: Thomas St?fe Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file > On 11 mar 2015, at 11:47, Thomas St?fe wrote: > > Hi Yumin, > > There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - > could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! > > Beyond that, as I wrote in the bug report comments: > > "This is also a problem on Windows - MiniDumpWriteDump() may hang > infinitly. And on Windows this is worse than under UNIX because we > create the Dump before writing the hs-err file, so if the Dump hangs, > we get no error log. I would like to revert the order: create the > minidump after writing the error log, the same way Unix does it. We > did this in our JVM > (SAP) because for us, error logs are more useful than minidumps. ? The reason the order is what it is is for the minidump to have the most relevant context regarding the failure. If we run the error log writing before writing the minidump, then the state of the VM has changed since the failure occurred and the minidump will have less value. Only windows provides the possibility to do this which is why it is only this way on windows. When does MiniDumpWriteDump hang infinitly? /Staffan > > So, I would like to see os::abort on Windows call MiniDumpWriteDump(), > and thus the mini dump writing moved after the error log writing. This > would also make the code way cleaner because the control flow would be > the same on all platforms. > > I understand that this may be out of scope for your change, but I > would like to know what others think about this. > > Kind regards, Thomas > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi wrote: > >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >> >> Summary: Tests timed out when VM crashes and dumping core file which >> in the test case is not needed. To make core not created, the fix >> changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is >> only used on Windows and the latter for all platforms. When VM >> crashes on non Windows, core file generated as default if OS sets >> core dump allowed. Default value of CreateCoredumpOnCrash set to >> 'true' to keep same behavior on non Windows platforms, but changed >> for Windows --- original is false, not create minidump on Windows. >> With CreateCoredumpOnCrash turned off, no core file will be >> generated. CreateMinidumpOnCrash still can be used on commandline but only as alias for the new flag. >> >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >> commandline to verify flag change as alias. >> >> Thanks >> Yumin >> From dmitry.samersoff at oracle.com Wed Mar 11 14:21:38 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Mar 2015 17:21:38 +0300 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FF73F5.3050700@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> <54FF73F5.3050700@oracle.com> Message-ID: <55004F72.2080003@oracle.com> Mikael, SA changes looks OK for me. -Dmitry On 2015-03-11 01:45, Mikael Vidstedt wrote: > > New version: > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ > > Changes since webrev.00: > > * Removed > native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET > * Removed set_link > * Made corresponding changes for aarch64 > * Removed the vmStruct constant abi_minframe_size, the only usage which > was for NATIVE_FRAME_INITIAL_PARAM_OFFSET > > Cheers, > Mikael > > On 2015-03-09 19:22, Chris Plummer wrote: >> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the unused/dead >>> frame::native_param_addr function along with the corresponding code >>> in the SA. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> >> Since you're removing unused frame APIs, maybe you can also remove >> frame::set_link(), which is also not used. I have no idea why it's >> there. Seems to be a very dangerous thing to do since the link >> (previous frame pointer) is setup by function prologue code, not by >> the JVM. >> >> cheers, >> >> Chris > -- 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 thomas.stuefe at gmail.com Wed Mar 11 15:12:08 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 16:12:08 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <008c01d05bf2$74d7b010$5e871030$@oracle.com> References: <54FFE885.3010604@oracle.com> <008c01d05bf2$74d7b010$5e871030$@oracle.com> Message-ID: Hi Christian, thanks for that info! Thomas On Wed, Mar 11, 2015 at 12:56 PM, Christian Tornqvist < christian.tornqvist at oracle.com> wrote: > Hi Staffan, > > >When does MiniDumpWriteDump hang infinitly? > > This can happen if we crash when someone is holding the process wide > LdrpLoaderLock lock. Dbghelp.dll will try to load other libraries > (version.dll and others) and will end up hanging waiting for the lock to be > released. > > https://bugs.openjdk.java.net/browse/JDK-8051995 has more info on this. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev [mailto: > hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Staffan Larsen > Sent: Wednesday, March 11, 2015 7:19 AM > To: Thomas St?fe > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8074354: tests that intentionally crash the VM can > timeout creating a core file > > > > On 11 mar 2015, at 11:47, Thomas St?fe wrote: > > > > Hi Yumin, > > > > There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - > > could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! > > > > Beyond that, as I wrote in the bug report comments: > > > > "This is also a problem on Windows - MiniDumpWriteDump() may hang > > infinitly. And on Windows this is worse than under UNIX because we > > create the Dump before writing the hs-err file, so if the Dump hangs, > > we get no error log. I would like to revert the order: create the > > minidump after writing the error log, the same way Unix does it. We > > did this in our JVM > > (SAP) because for us, error logs are more useful than minidumps. ? > > The reason the order is what it is is for the minidump to have the most > relevant context regarding the failure. If we run the error log writing > before writing the minidump, then the state of the VM has changed since the > failure occurred and the minidump will have less value. Only windows > provides the possibility to do this which is why it is only this way on > windows. > > When does MiniDumpWriteDump hang infinitly? > > /Staffan > > > > > > So, I would like to see os::abort on Windows call MiniDumpWriteDump(), > > and thus the mini dump writing moved after the error log writing. This > > would also make the code way cleaner because the control flow would be > > the same on all platforms. > > > > I understand that this may be out of scope for your change, but I > > would like to know what others think about this. > > > > Kind regards, Thomas > > > > > > > > > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi wrote: > > > >> Please review: > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 > >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > >> > >> Summary: Tests timed out when VM crashes and dumping core file which > >> in the test case is not needed. To make core not created, the fix > >> changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, the former is > >> only used on Windows and the latter for all platforms. When VM > >> crashes on non Windows, core file generated as default if OS sets > >> core dump allowed. Default value of CreateCoredumpOnCrash set to > >> 'true' to keep same behavior on non Windows platforms, but changed > >> for Windows --- original is false, not create minidump on Windows. > >> With CreateCoredumpOnCrash turned off, no core file will be > >> generated. CreateMinidumpOnCrash still can be used on commandline but > only as alias for the new flag. > >> > >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on > >> commandline to verify flag change as alias. > >> > >> Thanks > >> Yumin > >> > > > From goetz.lindenmaier at sap.com Wed Mar 11 15:17:27 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 11 Mar 2015 15:17:27 +0000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> Hi Thomas, I had a look at your change. I'm fine with it, except for two minor things: os_linux_sparc.cpp Why didn't you just replace set_cont_address by ucontext_set_pc on linux_sparc? As it is now, ucontext_set_pc is just a rename of an existing function. stubRoutines.cpp: Why do you test for availability of the stubs when testing them? I would consider it a bug if the stub is not generated at that point, and that would not be seen here as is now. Best regards, Goetz. -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Dienstag, 10. M?rz 2015 18:21 To: David Holmes Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling Hi David, see here my new patch: http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ Turns out that SafeFetch32 does not work in 32bit windows during initialization, because there is no SEH exception guard installed at that time (during the call to CreateJavaVM). Neither is there one for 64bit Windows, but there, we register SEH handlers for dynamic code, that hides the error. This is an issue I'd like to address with a separate patch (see https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I deactivated the SafeFetch test during stub routine initialization for Windows 32bit. Other changes in the fix: - as you wished I changed the ULL literals to UCONST64 - I activated the Jtreg test for windows too (SafeFetch works on windows during error handling, only not during initialization). Thomas On Mon, Mar 9, 2015 at 11:06 PM, David Holmes wrote: > On 10/03/2015 2:30 AM, Thomas St?fe wrote: > >> Hi David, >> >> I see now that only Windows 32bit is broken. I will investigate this. >> > > Yes, sorry, I hadn't noticed it was only 32-bit failing. > > Thanks, > David > > Thomas >> >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe > > wrote: >> >> Hi David, >> >> I am sorry, but I am unable to reproduce the error. Both slowdebug >> and fastdebug builds on Windows come up and SafeFetch works (also in >> error handling). Are you sure the crash is caused by my change? If >> yes, could you send me an hs-err file or at least the configure line >> you used for building? >> >> Kind Regards, Thomas >> >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes >> > wrote: >> >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >> >> Hi David, >> >> Ouch. The only thing I can think about are the added >> initialization >> tests in stubRoutines.cpp. I will check this. >> >> >> Ah! It hadn't registered with me that this test code was going >> to be executed. Seems the likely cause as a clean repo has no >> problems. >> >> David >> >> Kind Regards, Thomas >> >> >> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >> >> > >> wrote: >> >> Hi Thomas, >> >> FYI When I applied this to latest hs-rt forest and ran >> through JPRT >> the Windows fastdebug builds were DOA (instant segfault >> just running >> "java -version"). Can't see how your changes could do >> this so >> running a test on unmodified forest. >> >> David >> >> >> On 9/03/2015 9:40 AM, David Holmes wrote: >> >> Hi Thomas, >> >> Minor nit: in >> >> src/share/vm/runtime/____stubRoutines.cpp::test_____ >> safefetchN >> can >> you use UCONST64 macro instead of explicit ULL - >> thanks. >> >> Otherwise this seems okay, but we will also need >> the aarch64 >> component >> (and I'll look into our internal needs). >> >> Thanks, >> David >> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> >> Hi all, >> >> could someone please review the following fix >> (I also will >> need a >> sponsor): >> >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ >> webrev.____01/ >> > webrev.__01/> >> >> > webrev.__01/ >> > 01/>> >> >> https://bugs.openjdk.java.net/____browse/JDK-8074552 >> >> >> >> > >> > >> >> The fix will make SafeFetch[32,N] work in error >> reporting. >> >> At SAP, we use SafeFetch a lot in error >> reporting to poke >> around in >> potentially invalid memory (e.g. writing hex >> dumps over >> areas which >> may be >> partly unmapped), and we feel that this could >> be useful for the >> OpenJDK too. >> >> Without this fix, SafeFetch will cause a crash, >> the current >> error >> reporting >> step will be interrupted and error reporting >> will continue >> with the next >> step; that is not optimal because the >> interrupted step may >> have shown >> valuable information. >> >> This fix handles SafeFetch faults during error >> reporting the >> same way as >> they are handled normally. The changes are: >> >> - handle safe fetch fault in the various >> (os_cpu dependend) >> secondary >> signal handlers >> >> - provide a function to check if it is safe to >> use SafeFetch: >> CanUseSafeFetch32(). SafeFetch needs stub >> routines and will >> crash when >> used >> before stub generation. >> >> - set_context_pc() is added which complements >> the existing >> get_context_pc() >> and all instances where the pc in ucontext_t >> was modified >> directly are >> changed to use set_context_pc() >> >> - in stubRoutines.cpp, a small test was added >> to the already >> existing >> stub >> routines tests which run at VM init >> >> - in vmError.cpp, a test was added to test >> SafeFetch during >> error >> reporting, similar to the tests introduced for >> 8065895 >> >> - A JTreg test was added >> >> Thanks and Kind Regards, >> >> Thomas Stuefe >> >> >> >> >> From thomas.stuefe at gmail.com Wed Mar 11 15:40:33 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 16:40:33 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows Message-ID: Hi all, please review this smallish change: webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8074860/webrev.01/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8074860 This change adds SEH guards around JNI_CreateJavaVM(). Without the change, on Windows, the VM initialization runs without crash protection: crashes will terminate VM immediately without writing an error log; also, any techniques relying on signals will not work, e.g. SafeFetch(). This was partly solved before on a case-by-case base by wrapping code sections which may crash in their own __try/__except wrappers - e.g. CPU feature probing. The change guards the whole of JNI_CreateJavaVM invocation in __try/__except. Unfortunately, for that to compile, I needed to introduce a wrapper around JNI_CreateJavaVM and move the whole of JNI_CreateJavaVM to a new function "JNI_CreateJavaVM_inner". This fix also gets rid of various workarounds which were used before to guard code sections. Thanks for reviewing! Oh, on a side note: I tried to figure out if threads which are attached from the outside via JNI AttachCurrentThread() are in any way guarded with SEH protection. Newly created threads are guarded because they run thru java_start() in os_windows.cpp, which adds SEH guards to all frames below. But for attached threads, I did not find any SEH guards - or maybe I am blind? What does that mean for java code running inside attached threads? Regards, Thomas Stuefe From yumin.qi at oracle.com Wed Mar 11 16:07:36 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 11 Mar 2015 09:07:36 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> Message-ID: <55006848.2090201@oracle.com> Thomas, Thanks for the review. On 3/11/2015 3:47 AM, Thomas St?fe wrote: > Hi Yumin, > > There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - > could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! > Sure. > Beyond that, as I wrote in the bug report comments: > > "This is also a problem on Windows - MiniDumpWriteDump() may hang > infinitly. And on Windows this is worse than under UNIX because we > create the Dump before writing the hs-err file, so if the Dump hangs, > we get no error log. I would like to revert the order: create the > minidump after writing the error log, the same way Unix does it. We > did this in our JVM (SAP) because for us, error logs are more useful > than minidumps. " > > So, I would like to see os::abort on Windows call MiniDumpWriteDump(), > and thus the mini dump writing moved after the error log writing. This > would also make the code way cleaner because the control flow would be > the same on all platforms. > > I understand that this may be out of scope for your change, but I > would like to know what others think about this. > As in Staffan L's comments, we need to have a discuss and make final decision for it --- tradeoff. Personally I prefer a full dump when VM crashes on Windows, which is more helpful. I found minidump not very helpful in most of the cases. Thanks Yumin > Kind regards, Thomas > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi > wrote: > > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8074354 > webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > > > Summary: Tests timed out when VM crashes and dumping core file > which in the test case is not needed. To make core not created, > the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, > the former is only used on Windows and the latter for all > platforms. When VM crashes on non Windows, core file generated as > default if OS sets core dump allowed. Default value of > CreateCoredumpOnCrash set to 'true' to keep same behavior on non > Windows platforms, but changed for Windows --- original is false, > not create minidump on Windows. With CreateCoredumpOnCrash turned > off, no core file will be generated. CreateMinidumpOnCrash still > can be used on commandline but only as alias for the new flag. > > Tests: JPRT, manual tests setting CreateMinidumpOnCrash on > commandline to verify flag change as alias. > > Thanks > Yumin > > From dmitry.dmitriev at oracle.com Wed Mar 11 16:38:43 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 11 Mar 2015 19:38:43 +0300 Subject: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files Message-ID: <55006F93.90405@oracle.com> Hello, Please review this small fix for JDK-8073990. Also, I need a sponsor for this fix, who can push it, because I'm not have a OpenJDK name. This fix removes deprecated "UseVectoredExceptions" VM option from several header files related to aix_ppc and linux_ppc. Here a list of modified header files: src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp The "UseVectoredExceptions" VM option was deprecated by JDK-7188234 , but was leaved in several header files. Thus, I remove it from remaining header files in hotspot repo. I am not build HotSpot with this fix. Also, one moment about what I am not 100% sure is are copyrights. I update copyright for Oracle and SAP AG to 2015, but I am not sure that I shall update SAP AG copyright. Correct me if I am wrong and SAP AG copyright shall leaved unchanged. Thanks! Open webrev: http://cr.openjdk.java.net/~coleenp/8073990/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8073990 Thanks, Dmitry From thomas.stuefe at gmail.com Wed Mar 11 16:45:30 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 17:45:30 +0100 Subject: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files In-Reply-To: <55006F93.90405@oracle.com> References: <55006F93.90405@oracle.com> Message-ID: Hi Dimitry, looks good to me. Kind Regards, Thomas On Wed, Mar 11, 2015 at 5:38 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for JDK-8073990. Also, I need a sponsor for > this fix, who can push it, because I'm not have a OpenJDK name. > > This fix removes deprecated "UseVectoredExceptions" VM option from several > header files related to aix_ppc and linux_ppc. Here a list of modified > header files: > src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp > src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp > > The "UseVectoredExceptions" VM option was deprecated by JDK-7188234 < > https://bugs.openjdk.java.net/browse/JDK-7188234>, but was leaved in > several header files. Thus, I remove it from remaining header files in > hotspot repo. > > I am not build HotSpot with this fix. > > Also, one moment about what I am not 100% sure is are copyrights. I update > copyright for Oracle and SAP AG to 2015, but I am not sure that I shall > update SAP AG copyright. Correct me if I am wrong and SAP AG copyright > shall leaved unchanged. Thanks! > > Open webrev: http://cr.openjdk.java.net/~coleenp/8073990/ < > http://cr.openjdk.java.net/%7Ecoleenp/8073990/> > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8073990 > > Thanks, > Dmitry > > > From volker.simonis at gmail.com Wed Mar 11 17:04:08 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 11 Mar 2015 18:04:08 +0100 Subject: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files In-Reply-To: <55006F93.90405@oracle.com> References: <55006F93.90405@oracle.com> Message-ID: Hi Dmitry, the change looks good but I think you should also remove the line: { "UseVectoredExceptions", JDK_Version::jdk(8), JDK_Version::jdk(9) }, from arguments.cpp with this change because in JDK9 you'd get an error anyway if you'll try to use "UseVectoredExceptions". Regards, Volker On Wed, Mar 11, 2015 at 5:38 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for JDK-8073990. Also, I need a sponsor for > this fix, who can push it, because I'm not have a OpenJDK name. > > This fix removes deprecated "UseVectoredExceptions" VM option from several > header files related to aix_ppc and linux_ppc. Here a list of modified > header files: > src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp > src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp > > The "UseVectoredExceptions" VM option was deprecated by JDK-7188234 > , but was leaved in > several header files. Thus, I remove it from remaining header files in > hotspot repo. > > I am not build HotSpot with this fix. > > Also, one moment about what I am not 100% sure is are copyrights. I update > copyright for Oracle and SAP AG to 2015, but I am not sure that I shall > update SAP AG copyright. Correct me if I am wrong and SAP AG copyright shall > leaved unchanged. Thanks! > > Open webrev: http://cr.openjdk.java.net/~coleenp/8073990/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8073990 > > Thanks, > Dmitry > > From thomas.stuefe at gmail.com Wed Mar 11 17:10:29 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 18:10:29 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, thanks for reviewing! Here the updated changes: http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.03/webrev/ - I changed os_linux_sparc.cpp to reflect your comments: removed set_cont_address() and replaced it with ucontext_set_pc(). However, I do not have a linux sparc machine to build and test, so the change is made blind. Hope it does not break. - I removed the "CanUseSafeFetch.." calls from the initial test routine. Originally I was afraid there were platforms where there are no implementations for SafeFetch32 or SafeFetchN, but that does not seem to be the case. Hopefully, I cannot speak for arm or whatever other closed platforms are there. Kind Regards, Thomas On Wed, Mar 11, 2015 at 4:17 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > I had a look at your change. I'm fine with it, except for two minor > things: > > os_linux_sparc.cpp > Why didn't you just replace set_cont_address by ucontext_set_pc on > linux_sparc? > As it is now, ucontext_set_pc is just a rename of an existing function. > > stubRoutines.cpp: > Why do you test for availability of the stubs when testing them? I would > consider > it a bug if the stub is not generated at that point, and that would not be > seen here > as is now. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-runtime-dev [mailto: > hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Dienstag, 10. M?rz 2015 18:21 > To: David Holmes > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in > error handling > > Hi David, > > see here my new patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ > > Turns out that SafeFetch32 does not work in 32bit windows during > initialization, because there is no SEH exception guard installed at that > time (during the call to CreateJavaVM). Neither is there one for 64bit > Windows, but there, we register SEH handlers for dynamic code, that hides > the error. > > This is an issue I'd like to address with a separate patch (see > https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I deactivated > the SafeFetch test during stub routine initialization for Windows 32bit. > > Other changes in the fix: > - as you wished I changed the ULL literals to UCONST64 > - I activated the Jtreg test for windows too (SafeFetch works on windows > during error handling, only not during initialization). > > Thomas > > > > > > On Mon, Mar 9, 2015 at 11:06 PM, David Holmes > wrote: > > > On 10/03/2015 2:30 AM, Thomas St?fe wrote: > > > >> Hi David, > >> > >> I see now that only Windows 32bit is broken. I will investigate this. > >> > > > > Yes, sorry, I hadn't noticed it was only 32-bit failing. > > > > Thanks, > > David > > > > Thomas > >> > >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe >> > wrote: > >> > >> Hi David, > >> > >> I am sorry, but I am unable to reproduce the error. Both slowdebug > >> and fastdebug builds on Windows come up and SafeFetch works (also in > >> error handling). Are you sure the crash is caused by my change? If > >> yes, could you send me an hs-err file or at least the configure line > >> you used for building? > >> > >> Kind Regards, Thomas > >> > >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes > >> > wrote: > >> > >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: > >> > >> Hi David, > >> > >> Ouch. The only thing I can think about are the added > >> initialization > >> tests in stubRoutines.cpp. I will check this. > >> > >> > >> Ah! It hadn't registered with me that this test code was going > >> to be executed. Seems the likely cause as a clean repo has no > >> problems. > >> > >> David > >> > >> Kind Regards, Thomas > >> > >> > >> > >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes > >> > >> >> >> wrote: > >> > >> Hi Thomas, > >> > >> FYI When I applied this to latest hs-rt forest and ran > >> through JPRT > >> the Windows fastdebug builds were DOA (instant segfault > >> just running > >> "java -version"). Can't see how your changes could do > >> this so > >> running a test on unmodified forest. > >> > >> David > >> > >> > >> On 9/03/2015 9:40 AM, David Holmes wrote: > >> > >> Hi Thomas, > >> > >> Minor nit: in > >> > >> src/share/vm/runtime/____stubRoutines.cpp::test_____ > >> safefetchN > >> can > >> you use UCONST64 macro instead of explicit ULL - > >> thanks. > >> > >> Otherwise this seems okay, but we will also need > >> the aarch64 > >> component > >> (and I'll look into our internal needs). > >> > >> Thanks, > >> David > >> > >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: > >> > >> Hi all, > >> > >> could someone please review the following fix > >> (I also will > >> need a > >> sponsor): > >> > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ > >> webrev.____01/ > >> >> webrev.__01/> > >> > >> >> webrev.__01/ > >> >> 01/>> > >> > >> https://bugs.openjdk.java.net/____browse/JDK-8074552 > >> > >> > >> > >> >> > >> > > >> > >> The fix will make SafeFetch[32,N] work in error > >> reporting. > >> > >> At SAP, we use SafeFetch a lot in error > >> reporting to poke > >> around in > >> potentially invalid memory (e.g. writing hex > >> dumps over > >> areas which > >> may be > >> partly unmapped), and we feel that this could > >> be useful for the > >> OpenJDK too. > >> > >> Without this fix, SafeFetch will cause a crash, > >> the current > >> error > >> reporting > >> step will be interrupted and error reporting > >> will continue > >> with the next > >> step; that is not optimal because the > >> interrupted step may > >> have shown > >> valuable information. > >> > >> This fix handles SafeFetch faults during error > >> reporting the > >> same way as > >> they are handled normally. The changes are: > >> > >> - handle safe fetch fault in the various > >> (os_cpu dependend) > >> secondary > >> signal handlers > >> > >> - provide a function to check if it is safe to > >> use SafeFetch: > >> CanUseSafeFetch32(). SafeFetch needs stub > >> routines and will > >> crash when > >> used > >> before stub generation. > >> > >> - set_context_pc() is added which complements > >> the existing > >> get_context_pc() > >> and all instances where the pc in ucontext_t > >> was modified > >> directly are > >> changed to use set_context_pc() > >> > >> - in stubRoutines.cpp, a small test was added > >> to the already > >> existing > >> stub > >> routines tests which run at VM init > >> > >> - in vmError.cpp, a test was added to test > >> SafeFetch during > >> error > >> reporting, similar to the tests introduced for > >> 8065895 > >> > >> - A JTreg test was added > >> > >> Thanks and Kind Regards, > >> > >> Thomas Stuefe > >> > >> > >> > >> > >> > From aph at redhat.com Wed Mar 11 17:44:57 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 11 Mar 2015 17:44:57 +0000 Subject: RFR: 8074723: AARCH64: Stray pop in C1 LIR_Assembler::emit_profile_type Message-ID: <55007F19.1020604@redhat.com> There's a pop() in emit_profile_type with no corresponding push(). If we hit that pop we will crash immediately. http://cr.openjdk.java.net/~aph/8074723/ Andrew. From yumin.qi at oracle.com Wed Mar 11 18:04:11 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 11 Mar 2015 11:04:11 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <54FF6822.5070702@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> Message-ID: <5500839B.5030608@oracle.com> Hi, Coleen Thanks for the review. See embedded. On 3/10/2015 2:54 PM, Coleen Phillimore wrote: > > Yumin, > > The new bytecode approach came out pretty cleanly, or as cleanly as > this could be. > > The file templateTable_x86_32 and 64 have just been merged, so you'll > have to make your change in the new version. > > I also have some comments: > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html > > > Typo "rewirting" > Sure. > In these files, can you break up the long lines into three lines? > > - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, > Rscratch); } > + if (!is_static && rc == MAY_REWRITE) { > patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } > Sure. > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html > > > How many bytecodes do we have now? We're limited to 255 (or 256) and > there are other new bytecodes being added. > now total is 234 (after the fix). See below answer. > What was the performance benefit to this? I think if we wanted to be > conservative, we'd turn off RewriteFrequentPairs and only do > nofast_getfield and nofast_putfield. I think they were the only > bytecodes that actually affected performance. > > In this file above, can you remove the last block of comments about > fast_linearswitch and fast_ldc? I think this confuses rewriting in > the interpreter and rewriting in the rewriter, or rather makes the > confusion worse. I don't think this comment is helpful. > > I'd prefer to see the first comment smaller also, like: > > + // These bytecodes are rewritten at CDS dump time, so that we can > prevent them from being > + // rewritten at run time. This way, the ConstMethods can be > placed in the CDS ReadOnly > + // section, and RewriteByteCodes/RewriteFrequentPairs can rewrite > non-CDS bytecodes > + // at run time. > + _nofast_getfield , > + _nofast_putfield , > + _nofast_aload_0 , > + _nofast_iload , > + _nofast_invokevirtual , > > It's sort of obvious which bytecode they rewrite. I don't know how > much performance fast_invokevfinal is worth. I thought I deleted it. > Can we not rewrite this so we don't waste another bytecode on it? > Maybe add a RewriteVFinal option and consider removing it for the > future? x86 doesn't use it and I can't see how this would save any > significant performance to be worth having! > _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, no need to take care for it. For sparc, it does patch code. I am thinking of a way if we need to add _nofast_code as you indicated, we only have 255 codes to use. bool not_rewrite = UseSharedSpaces && RewriteBytecodes && RewriteFrequentPair; Can this boolean decide if we not rewrite the bytecode to fast? If so, I can remove all the _nofast_code and do not patch code when it is on. > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html > > > + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // control > for fast code under CDS > > > I don't know what our coding standard is but in the > templateTable_.cpp files these strings look like macros. I'd > rather see them as MayRewrite or MayNotRewrite. > Agree. > http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html > > > I think there's a java_code() function that returns the original > bytecode that you could use instead of the case statement in > resolve_cache_and_index(). The indentation is odd in the webrev. > This probably applies to the other cpu directories. > > One last question below: > > On 3/5/15, 4:21 PM, Yumin Qi wrote: >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >> >> Summary: Currently CDS when is disabled, RewriteBytecodes and >> RewriteFrequentPairs are disabled due to ConstantMethod in CDS are >> mapped read only. So memory fault will be triggered when >> RewriteBytecodes turned on. This also disable all method rewritten, >> leads interpreter run slower. Observed about 2% regression with C2 on >> some benchmarks, since interpreter speed is important to C2. By >> enable RewriteBytecodes and RewriteFrequentPairs under CDS enabled, >> adding _nofast_xxxx for corresponding fast codes at dump time to >> avoid byte code rewritten at run time, we prevent byte code rewritten >> and modify the read only shared portion in CDS. Meanwhile other byte >> codes with fast codes still get speed up. >> >> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported >> platforms. Interpreter only tests showed about 3% improvement. > > What performance did you measure? Is it -Xint -Xshare:on with and > without your patch? It was only 3% better? > > What was the difference in performance with -Xint > -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? I > thought this was around 15%. > I will send you a separate email of the links which run with CDS/NoCDS/CDS+Int Thanks Yumin > Thanks, > Coleen > >> >> Thanks >> Yumin >> > From staffan.larsen at oracle.com Wed Mar 11 19:31:02 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Mar 2015 20:31:02 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <55006848.2090201@oracle.com> References: <54FFE885.3010604@oracle.com> <55006848.2090201@oracle.com> Message-ID: <9E7B3CE7-6C4F-4937-AFF3-A4B6893CE53E@oracle.com> > On 11 mar 2015, at 17:07, Yumin Qi wrote: > > Thomas, > > Thanks for the review. > > On 3/11/2015 3:47 AM, Thomas St?fe wrote: >> Hi Yumin, >> >> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >> > Sure. >> Beyond that, as I wrote in the bug report comments: >> >> "This is also a problem on Windows - MiniDumpWriteDump() may hang infinitly. And on Windows this is worse than under UNIX because we create the Dump before writing the hs-err file, so if the Dump hangs, we get no error log. I would like to revert the order: create the minidump after writing the error log, the same way Unix does it. We did this in our JVM (SAP) because for us, error logs are more useful than minidumps. " >> >> So, I would like to see os::abort on Windows call MiniDumpWriteDump(), and thus the mini dump writing moved after the error log writing. This would also make the code way cleaner because the control flow would be the same on all platforms. >> >> I understand that this may be out of scope for your change, but I would like to know what others think about this. >> > As in Staffan L's comments, we need to have a discuss and make final decision for it --- tradeoff. Given that core files on other platforms are useful even after we write the hotspot error logs, it would probably make sense to have the same mechanism on all platforms as Thomas points out. I haven?t been debugging many windows failures lately so perhaps someone who does can chime in here? > Personally I prefer a full dump when VM crashes on Windows, which is more helpful. I found minidump not very helpful in most of the cases. Windows calls all crash dumps ?minidumps?. They can however be configured to include more or less information, but even with all the information it is still called a ?minidump? (or at least the API for creating them is called that). /Staffan > > Thanks > Yumin >> Kind regards, Thomas >> >> >> >> >> >> >> >> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >> wrote: >> >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >> > >> >> Summary: Tests timed out when VM crashes and dumping core file >> which in the test case is not needed. To make core not created, >> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >> the former is only used on Windows and the latter for all >> platforms. When VM crashes on non Windows, core file generated as >> default if OS sets core dump allowed. Default value of >> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >> Windows platforms, but changed for Windows --- original is false, >> not create minidump on Windows. With CreateCoredumpOnCrash turned >> off, no core file will be generated. CreateMinidumpOnCrash still >> can be used on commandline but only as alias for the new flag. >> >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >> commandline to verify flag change as alias. >> >> Thanks >> Yumin From dmitry.dmitriev at oracle.com Wed Mar 11 19:40:30 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 11 Mar 2015 12:40:30 -0700 (PDT) Subject: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files Message-ID: Hi Volker, Thank you for review! This is a good point about arguments.cpp. I am not familiar with removing flags from obsolete_jvm_flags. But I think that this option should not removed by this fix. I think that we should up question about that situation and create a unified solution for such flags. I check, there about 50 flags with accept until equal or less than JDK 9. The unified solution can be develop, bug submitted and all these flags can be removed. What you think about that? Regards, Dmitry ----- Original Message ----- From: volker.simonis at gmail.com To: dmitry.dmitriev at oracle.com Cc: hotspot-runtime-dev at openjdk.java.net Sent: Wednesday, 11 March, 2015 8:04:11 PM GMT +03:00 Iraq Subject: Re: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files Hi Dmitry, the change looks good but I think you should also remove the line: { "UseVectoredExceptions", JDK_Version::jdk(8), JDK_Version::jdk(9) }, from arguments.cpp with this change because in JDK9 you'd get an error anyway if you'll try to use "UseVectoredExceptions". Regards, Volker On Wed, Mar 11, 2015 at 5:38 PM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for JDK-8073990. Also, I need a sponsor for > this fix, who can push it, because I'm not have a OpenJDK name. > > This fix removes deprecated "UseVectoredExceptions" VM option from several > header files related to aix_ppc and linux_ppc. Here a list of modified > header files: > src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp > src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp > > The "UseVectoredExceptions" VM option was deprecated by JDK-7188234 > , but was leaved in > several header files. Thus, I remove it from remaining header files in > hotspot repo. > > I am not build HotSpot with this fix. > > Also, one moment about what I am not 100% sure is are copyrights. I update > copyright for Oracle and SAP AG to 2015, but I am not sure that I shall > update SAP AG copyright. Correct me if I am wrong and SAP AG copyright shall > leaved unchanged. Thanks! > > Open webrev: http://cr.openjdk.java.net/~coleenp/8073990/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8073990 > > Thanks, > Dmitry > > From thomas.stuefe at gmail.com Wed Mar 11 19:58:13 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 20:58:13 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <9E7B3CE7-6C4F-4937-AFF3-A4B6893CE53E@oracle.com> References: <54FFE885.3010604@oracle.com> <55006848.2090201@oracle.com> <9E7B3CE7-6C4F-4937-AFF3-A4B6893CE53E@oracle.com> Message-ID: Hi Staffan, As in Staffan L's comments, we need to have a discuss and make final > decision for it --- tradeoff. > > > Given that core files on other platforms are useful even after we write > the hotspot error logs, it would probably make sense to have the same > mechanism on all platforms as Thomas points out. I haven?t been debugging > many windows failures lately so perhaps someone who does can chime in here? > > Personally I prefer a full dump when VM crashes on Windows, which is more > helpful. I found minidump not very helpful in most of the cases. > > > Windows calls all crash dumps ?minidumps?. They can however be configured > to include more or less information, but even with all the information it > is still called a ?minidump? (or at least the API for creating them is > called that). > > Sorry, my sentence was garbled and not very clear. I was referring to the MINIDUMP_TYPE parameter on MiniDumpWriteDump(): in our code base, we used to have a switch to write either full minidumps (with MiniDumpWithFullMemory set) or partial minidumps without full memory info, just the thread stacks. Trade off was minidump size: full memory info made for very large dumps, the partial ones were small. In practice we found the full dumps often too large and unwieldy, and the partial ones were often useless. So in the end we came to rely on the error logs and put lots of work into improving those. Thomas > /Staffan > > > From coleen.phillimore at oracle.com Wed Mar 11 20:11:41 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 Mar 2015 16:11:41 -0400 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <5500839B.5030608@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> Message-ID: <5500A17D.1080809@oracle.com> Hi Yumin, One comment embedded. On 3/11/15, 2:04 PM, Yumin Qi wrote: > Hi, Coleen > > Thanks for the review. See embedded. > > On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >> >> Yumin, >> >> The new bytecode approach came out pretty cleanly, or as cleanly as >> this could be. >> >> The file templateTable_x86_32 and 64 have just been merged, so you'll >> have to make your change in the new version. >> >> I also have some comments: >> >> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >> >> >> Typo "rewirting" >> > Sure. >> In these files, can you break up the long lines into three lines? >> >> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, >> Rscratch); } >> + if (!is_static && rc == MAY_REWRITE) { >> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >> > Sure. >> >> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >> >> >> How many bytecodes do we have now? We're limited to 255 (or 256) and >> there are other new bytecodes being added. >> > now total is 234 (after the fix). See below answer. >> What was the performance benefit to this? I think if we wanted to >> be conservative, we'd turn off RewriteFrequentPairs and only do >> nofast_getfield and nofast_putfield. I think they were the only >> bytecodes that actually affected performance. >> >> In this file above, can you remove the last block of comments about >> fast_linearswitch and fast_ldc? I think this confuses rewriting in >> the interpreter and rewriting in the rewriter, or rather makes the >> confusion worse. I don't think this comment is helpful. >> >> I'd prefer to see the first comment smaller also, like: >> >> + // These bytecodes are rewritten at CDS dump time, so that we >> can prevent them from being >> + // rewritten at run time. This way, the ConstMethods can be >> placed in the CDS ReadOnly >> + // section, and RewriteByteCodes/RewriteFrequentPairs can >> rewrite non-CDS bytecodes >> + // at run time. >> + _nofast_getfield , >> + _nofast_putfield , >> + _nofast_aload_0 , >> + _nofast_iload , >> + _nofast_invokevirtual , >> >> It's sort of obvious which bytecode they rewrite. I don't know how >> much performance fast_invokevfinal is worth. I thought I deleted >> it. Can we not rewrite this so we don't waste another bytecode on >> it? Maybe add a RewriteVFinal option and consider removing it for >> the future? x86 doesn't use it and I can't see how this would save >> any significant performance to be worth having! >> > _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, no > need to take care for it. For sparc, it does patch code. I am thinking > of a way if we need to add _nofast_code as you indicated, we only have > 255 codes to use. PPC isn't removed from the open repository. > > bool not_rewrite = UseSharedSpaces && RewriteBytecodes && > RewriteFrequentPair; I think the conditional would be bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; > > Can this boolean decide if we not rewrite the bytecode to fast? If > so, I can remove all the _nofast_code and do not patch code when it is > on. Yes, this would be nice to not add the bytecode. >> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >> >> >> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // control >> for fast code under CDS >> >> >> I don't know what our coding standard is but in the >> templateTable_.cpp files these strings look like macros. I'd >> rather see them as MayRewrite or MayNotRewrite. >> > Agree. >> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >> >> >> I think there's a java_code() function that returns the original >> bytecode that you could use instead of the case statement in >> resolve_cache_and_index(). The indentation is odd in the webrev. >> This probably applies to the other cpu directories. >> >> One last question below: >> >> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>> Please review: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>> >>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS are >>> mapped read only. So memory fault will be triggered when >>> RewriteBytecodes turned on. This also disable all method rewritten, >>> leads interpreter run slower. Observed about 2% regression with C2 >>> on some benchmarks, since interpreter speed is important to C2. By >>> enable RewriteBytecodes and RewriteFrequentPairs under CDS enabled, >>> adding _nofast_xxxx for corresponding fast codes at dump time to >>> avoid byte code rewritten at run time, we prevent byte code >>> rewritten and modify the read only shared portion in CDS. Meanwhile >>> other byte codes with fast codes still get speed up. >>> >>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported >>> platforms. Interpreter only tests showed about 3% improvement. >> >> What performance did you measure? Is it -Xint -Xshare:on with and >> without your patch? It was only 3% better? >> >> What was the difference in performance with -Xint >> -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? >> I thought this was around 15%. >> > I will send you a separate email of the links which run with > CDS/NoCDS/CDS+Int Thanks for the links. From your experiments, I think your performance improvement with your patch and CDS with -Xmixed is 4%. That's good enough for a couple of bytecodes. Coleen > > Thanks > Yumin >> Thanks, >> Coleen >> >>> >>> Thanks >>> Yumin >>> >> > From yumin.qi at oracle.com Wed Mar 11 20:23:00 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 11 Mar 2015 13:23:00 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <5500A17D.1080809@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> Message-ID: <5500A424.5000401@oracle.com> Thanks, I will have another webrev after build/test/perf test. Yumin On 3/11/2015 1:11 PM, Coleen Phillimore wrote: > > Hi Yumin, One comment embedded. > > On 3/11/15, 2:04 PM, Yumin Qi wrote: >> Hi, Coleen >> >> Thanks for the review. See embedded. >> >> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>> >>> Yumin, >>> >>> The new bytecode approach came out pretty cleanly, or as cleanly as >>> this could be. >>> >>> The file templateTable_x86_32 and 64 have just been merged, so >>> you'll have to make your change in the new version. >>> >>> I also have some comments: >>> >>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>> >>> >>> Typo "rewirting" >>> >> Sure. >>> In these files, can you break up the long lines into three lines? >>> >>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, >>> Rscratch); } >>> + if (!is_static && rc == MAY_REWRITE) { >>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>> >> Sure. >>> >>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>> >>> >>> How many bytecodes do we have now? We're limited to 255 (or 256) >>> and there are other new bytecodes being added. >>> >> now total is 234 (after the fix). See below answer. >>> What was the performance benefit to this? I think if we wanted to >>> be conservative, we'd turn off RewriteFrequentPairs and only do >>> nofast_getfield and nofast_putfield. I think they were the only >>> bytecodes that actually affected performance. >>> >>> In this file above, can you remove the last block of comments about >>> fast_linearswitch and fast_ldc? I think this confuses rewriting in >>> the interpreter and rewriting in the rewriter, or rather makes the >>> confusion worse. I don't think this comment is helpful. >>> >>> I'd prefer to see the first comment smaller also, like: >>> >>> + // These bytecodes are rewritten at CDS dump time, so that we >>> can prevent them from being >>> + // rewritten at run time. This way, the ConstMethods can be >>> placed in the CDS ReadOnly >>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>> rewrite non-CDS bytecodes >>> + // at run time. >>> + _nofast_getfield , >>> + _nofast_putfield , >>> + _nofast_aload_0 , >>> + _nofast_iload , >>> + _nofast_invokevirtual , >>> >>> It's sort of obvious which bytecode they rewrite. I don't know how >>> much performance fast_invokevfinal is worth. I thought I deleted >>> it. Can we not rewrite this so we don't waste another bytecode on >>> it? Maybe add a RewriteVFinal option and consider removing it for >>> the future? x86 doesn't use it and I can't see how this would save >>> any significant performance to be worth having! >>> >> _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, no >> need to take care for it. For sparc, it does patch code. I am >> thinking of a way if we need to add _nofast_code as you indicated, we >> only have 255 codes to use. > > PPC isn't removed from the open repository. >> >> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >> RewriteFrequentPair; > > I think the conditional would be > > bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >> >> Can this boolean decide if we not rewrite the bytecode to fast? If >> so, I can remove all the _nofast_code and do not patch code when it >> is on. > > Yes, this would be nice to not add the bytecode. > >>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>> >>> >>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // control >>> for fast code under CDS >>> >>> >>> I don't know what our coding standard is but in the >>> templateTable_.cpp files these strings look like macros. I'd >>> rather see them as MayRewrite or MayNotRewrite. >>> >> Agree. >>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>> >>> >>> I think there's a java_code() function that returns the original >>> bytecode that you could use instead of the case statement in >>> resolve_cache_and_index(). The indentation is odd in the webrev. >>> This probably applies to the other cpu directories. >>> >>> One last question below: >>> >>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>> Please review: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>> >>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS are >>>> mapped read only. So memory fault will be triggered when >>>> RewriteBytecodes turned on. This also disable all method rewritten, >>>> leads interpreter run slower. Observed about 2% regression with C2 >>>> on some benchmarks, since interpreter speed is important to C2. By >>>> enable RewriteBytecodes and RewriteFrequentPairs under CDS enabled, >>>> adding _nofast_xxxx for corresponding fast codes at dump time to >>>> avoid byte code rewritten at run time, we prevent byte code >>>> rewritten and modify the read only shared portion in CDS. Meanwhile >>>> other byte codes with fast codes still get speed up. >>>> >>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported >>>> platforms. Interpreter only tests showed about 3% improvement. >>> >>> What performance did you measure? Is it -Xint -Xshare:on with and >>> without your patch? It was only 3% better? >>> >>> What was the difference in performance with -Xint >>> -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? >>> I thought this was around 15%. >>> >> I will send you a separate email of the links which run with >> CDS/NoCDS/CDS+Int > > Thanks for the links. From your experiments, I think your performance > improvement with your patch and CDS with -Xmixed is 4%. That's good > enough for a couple of bytecodes. > > Coleen > >> >> Thanks >> Yumin >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks >>>> Yumin >>>> >>> >> > From david.holmes at oracle.com Wed Mar 11 20:43:08 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 06:43:08 +1000 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: Message-ID: <5500A8DC.90600@oracle.com> Hi Thomas, I'm not really familiar with Windows SEH. Won't this break custom launchers that already provide their own try/catch around Crate_JavaVM ? (And I hate seeing the win32 ifdefs in the shared code :( ). Thanks, David On 12/03/2015 1:40 AM, Thomas St?fe wrote: > Hi all, > > please review this smallish change: > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8074860/webrev.01/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8074860 > > This change adds SEH guards around JNI_CreateJavaVM(). Without the change, > on Windows, the VM initialization runs without crash protection: crashes > will terminate VM immediately without writing an error log; also, any > techniques relying on signals will not work, e.g. SafeFetch(). > > This was partly solved before on a case-by-case base by wrapping code > sections which may crash in their own __try/__except wrappers - e.g. CPU > feature probing. > > The change guards the whole of JNI_CreateJavaVM invocation in > __try/__except. Unfortunately, for that to compile, I needed to introduce a > wrapper around JNI_CreateJavaVM and move the whole of JNI_CreateJavaVM to a > new function "JNI_CreateJavaVM_inner". > > This fix also gets rid of various workarounds which were used before to > guard code sections. > > Thanks for reviewing! > > Oh, on a side note: I tried to figure out if threads which are attached > from the outside via JNI AttachCurrentThread() are in any way guarded with > SEH protection. Newly created threads are guarded because they run thru > java_start() in os_windows.cpp, which adds SEH guards to all frames below. > But for attached threads, I did not find any SEH guards - or maybe I am > blind? What does that mean for java code running inside attached threads? > > Regards, > > Thomas Stuefe > From coleen.phillimore at oracle.com Wed Mar 11 21:23:18 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 Mar 2015 17:23:18 -0400 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: Message-ID: <5500B246.6080508@oracle.com> This change looks good to me. Coleen On 3/10/15, 5:08 PM, Jeremy Manson wrote: > Hi, David, > > I'd like you to do a code review, please. Original discussion: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-March/016851.html > > Per this discussion, I'm just getting rid of the os::getenv interface, and > using straight getenv() everywhere. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8074895 > > Webrev: > http://cr.openjdk.java.net/~jmanson/8074895/webrev.00/ > > Jeremy From thomas.stuefe at gmail.com Wed Mar 11 22:03:51 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Mar 2015 23:03:51 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: <5500A8DC.90600@oracle.com> References: <5500A8DC.90600@oracle.com> Message-ID: Hi David, On Wed, Mar 11, 2015 at 9:43 PM, David Holmes wrote: > Hi Thomas, > > I'm not really familiar with Windows SEH. Won't this break custom > launchers that already provide their own try/catch around Crate_JavaVM ? > > No. Windows SEH works stack based: any exception - e.g. a crash - between __try and __except will be handled by the handler given in the __except clause. Because they are stack based, they can be nested. If an exception is raised inside the inner __try/__except, first the inner handler is used, if that one feels not responsible, the next outer one and so on. With my fix, any exception raised inside CreateJavaVM will be handler by our handler topLevelExceptionFilter; only if our handler feels not responsible (returns EXCEPTION_CONTINUE_SEARCH), the user handler will be called. Any exception raised in the launcher itself outside of CreateJavaVM will still be handled by the user handler. > (And I hate seeing the win32 ifdefs in the shared code :( ). > Yes I know, I kind of expected that feedback :( - I did not find a better way of doing this. One could try to hide the __try/__except behind macros, but that would be kind of unwieldy and I don't like abstractiing something which only has meaning on one platform. > > Thanks, > David > > > Kind regards, Thomas > On 12/03/2015 1:40 AM, Thomas St?fe wrote: > >> Hi all, >> >> please review this smallish change: >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8074860/webrev.01/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8074860 >> >> This change adds SEH guards around JNI_CreateJavaVM(). Without the change, >> on Windows, the VM initialization runs without crash protection: crashes >> will terminate VM immediately without writing an error log; also, any >> techniques relying on signals will not work, e.g. SafeFetch(). >> >> This was partly solved before on a case-by-case base by wrapping code >> sections which may crash in their own __try/__except wrappers - e.g. CPU >> feature probing. >> >> The change guards the whole of JNI_CreateJavaVM invocation in >> __try/__except. Unfortunately, for that to compile, I needed to introduce >> a >> wrapper around JNI_CreateJavaVM and move the whole of JNI_CreateJavaVM to >> a >> new function "JNI_CreateJavaVM_inner". >> >> This fix also gets rid of various workarounds which were used before to >> guard code sections. >> >> Thanks for reviewing! >> >> Oh, on a side note: I tried to figure out if threads which are attached >> from the outside via JNI AttachCurrentThread() are in any way guarded with >> SEH protection. Newly created threads are guarded because they run thru >> java_start() in os_windows.cpp, which adds SEH guards to all frames below. >> But for attached threads, I did not find any SEH guards - or maybe I am >> blind? What does that mean for java code running inside attached threads? >> >> Regards, >> >> Thomas Stuefe >> >> From david.holmes at oracle.com Wed Mar 11 22:08:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 08:08:25 +1000 Subject: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files In-Reply-To: <55006F93.90405@oracle.com> References: <55006F93.90405@oracle.com> Message-ID: <5500BCD9.8040403@oracle.com> Hi Dmitry, On 12/03/2015 2:38 AM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix for JDK-8073990. Also, I need a sponsor for > this fix, who can push it, because I'm not have a OpenJDK name. I will sponsor this for you. > This fix removes deprecated "UseVectoredExceptions" VM option from > several header files related to aix_ppc and linux_ppc. Here a list of > modified header files: > src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp > src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp > > The "UseVectoredExceptions" VM option was deprecated by JDK-7188234 > , but was leaved in > several header files. Thus, I remove it from remaining header files in > hotspot repo. Changes look fine. > I am not build HotSpot with this fix. > > Also, one moment about what I am not 100% sure is are copyrights. I > update copyright for Oracle and SAP AG to 2015, but I am not sure that I > shall update SAP AG copyright. Correct me if I am wrong and SAP AG > copyright shall leaved unchanged. Thanks! My understanding is that third-party copyrights should only be updated by the third-party. So I would just update the Oracle copyright date. Thanks, David > > Open webrev: http://cr.openjdk.java.net/~coleenp/8073990/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8073990 > > Thanks, > Dmitry > > From david.holmes at oracle.com Wed Mar 11 22:47:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 08:47:17 +1000 Subject: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files In-Reply-To: References: Message-ID: <5500C5F5.7050006@oracle.com> Hi Dmitry, On 12/03/2015 5:40 AM, Dmitry Dmitriev wrote: > Hi Volker, > > Thank you for review! > > This is a good point about arguments.cpp. I am not familiar with removing flags from obsolete_jvm_flags. But I think that this option should not removed by this fix. I think that we should up question about that situation and create a unified solution for such flags. I check, there about 50 flags with accept until equal or less than JDK 9. The unified solution can be develop, bug submitted and all these flags can be removed. What you think about that? Volker is right. The deprecation entry has no meaning in JDK 9 as it simply reports: Unrecognized VM option 'UseVectoredExceptions' whereas in JDK8u it reports: Java HotSpot(TM) Server VM warning: ignoring option UseVectoredExceptions; support was removed in 8.0 but there are many such cleanups needed so I agree about leaving this to a separate CR. When 9 ships the only deprecation options remaining should be those dropped in 9 and targeted for removal in 10. I will push the current changes as-is. Thanks, David > Regards, > Dmitry > > > ----- Original Message ----- > From: volker.simonis at gmail.com > To: dmitry.dmitriev at oracle.com > Cc: hotspot-runtime-dev at openjdk.java.net > Sent: Wednesday, 11 March, 2015 8:04:11 PM GMT +03:00 Iraq > Subject: Re: RFR(XS) 8073990: Deprecated "UseVectoredExceptions" VM options still defined in several globals files > > Hi Dmitry, > > the change looks good but I think you should also remove the line: > > { "UseVectoredExceptions", JDK_Version::jdk(8), JDK_Version::jdk(9) }, > > from arguments.cpp with this change because in JDK9 you'd get an error > anyway if you'll try to use "UseVectoredExceptions". > > Regards, > Volker > > > On Wed, Mar 11, 2015 at 5:38 PM, Dmitry Dmitriev > wrote: >> Hello, >> >> Please review this small fix for JDK-8073990. Also, I need a sponsor for >> this fix, who can push it, because I'm not have a OpenJDK name. >> >> This fix removes deprecated "UseVectoredExceptions" VM option from several >> header files related to aix_ppc and linux_ppc. Here a list of modified >> header files: >> src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp >> src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp >> >> The "UseVectoredExceptions" VM option was deprecated by JDK-7188234 >> , but was leaved in >> several header files. Thus, I remove it from remaining header files in >> hotspot repo. >> >> I am not build HotSpot with this fix. >> >> Also, one moment about what I am not 100% sure is are copyrights. I update >> copyright for Oracle and SAP AG to 2015, but I am not sure that I shall >> update SAP AG copyright. Correct me if I am wrong and SAP AG copyright shall >> leaved unchanged. Thanks! >> >> Open webrev: http://cr.openjdk.java.net/~coleenp/8073990/ >> >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8073990 >> >> Thanks, >> Dmitry >> >> From david.holmes at oracle.com Thu Mar 12 02:39:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 12:39:04 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: Message-ID: <5500FC48.50503@oracle.com> Hi Jeremy, On 11/03/2015 7:08 AM, Jeremy Manson wrote: > Hi, David, > > I'd like you to do a code review, please. Original discussion: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-March/016851.html > > Per this discussion, I'm just getting rid of the os::getenv interface, > and using straight getenv() everywhere. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8074895 > > Webrev: > http://cr.openjdk.java.net/~jmanson/8074895/webrev.00/ In arguments.cpp the headless property setting could have been left using a local buffer rather than introducing NEW_C_HEAP_ARRAY. The value should only be true or false so there's no size issue regarding the local buffer. 3566 if ((buffer = os::strdup(buffer)) == NULL) { 3567 return JNI_OK; 3568 } So this silently hides failures? The only minor concern I have is whether os::print_environment_variables is now susceptible to any issues caused by arbitrarily long environment variables? But I suspect there is already a maximum permitted length for environment variables. Also you could now do the same for os::unsetenv :) Thanks, David > Jeremy From david.holmes at oracle.com Thu Mar 12 02:45:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 12:45:45 +1000 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> Message-ID: <5500FDD9.3060801@oracle.com> On 12/03/2015 8:03 AM, Thomas St?fe wrote: > Hi David, > > On Wed, Mar 11, 2015 at 9:43 PM, David Holmes > wrote: > > Hi Thomas, > > I'm not really familiar with Windows SEH. Won't this break custom > launchers that already provide their own try/catch around Crate_JavaVM ? > > > No. Windows SEH works stack based: any exception - e.g. a crash - > between __try and __except will be handled by the handler given in the > __except clause. Because they are stack based, they can be nested. If an > exception is raised inside the inner __try/__except, first the inner > handler is used, if that one feels not responsible, the next outer one > and so on. > > With my fix, any exception raised inside CreateJavaVM will be handler by > our handler topLevelExceptionFilter; only if our handler feels not > responsible (returns EXCEPTION_CONTINUE_SEARCH), the user handler will > be called. My lack of knowledge about when our handler "feels responsible" still leaves me a little nervous here. :) > Any exception raised in the launcher itself outside of CreateJavaVM will > still be handled by the user handler. > > (And I hate seeing the win32 ifdefs in the shared code :( ). > > > Yes I know, I kind of expected that feedback :( - I did not find a > better way of doing this. One could try to hide the __try/__except > behind macros, but that would be kind of unwieldy and I don't like > abstractiing something which only has meaning on one platform. Does it help if we make the caller responsible for SEH and then put the try/catch in the launcher code (hopefully in a windows specific part thereof) ? Thanks, David > > Thanks, > David > > > > Kind regards, Thomas > > On 12/03/2015 1:40 AM, Thomas St?fe wrote: > > Hi all, > > please review this smallish change: > > webrev: > http://cr.openjdk.java.net/~__stuefe/webrevs/8074860/webrev.__01/webrev/ > > bug: https://bugs.openjdk.java.net/__browse/JDK-8074860 > > > This change adds SEH guards around JNI_CreateJavaVM(). Without > the change, > on Windows, the VM initialization runs without crash protection: > crashes > will terminate VM immediately without writing an error log; > also, any > techniques relying on signals will not work, e.g. SafeFetch(). > > This was partly solved before on a case-by-case base by wrapping > code > sections which may crash in their own __try/__except wrappers - > e.g. CPU > feature probing. > > The change guards the whole of JNI_CreateJavaVM invocation in > __try/__except. Unfortunately, for that to compile, I needed to > introduce a > wrapper around JNI_CreateJavaVM and move the whole of > JNI_CreateJavaVM to a > new function "JNI_CreateJavaVM_inner". > > This fix also gets rid of various workarounds which were used > before to > guard code sections. > > Thanks for reviewing! > > Oh, on a side note: I tried to figure out if threads which are > attached > from the outside via JNI AttachCurrentThread() are in any way > guarded with > SEH protection. Newly created threads are guarded because they > run thru > java_start() in os_windows.cpp, which adds SEH guards to all > frames below. > But for attached threads, I did not find any SEH guards - or > maybe I am > blind? What does that mean for java code running inside attached > threads? > > Regards, > > Thomas Stuefe > > From staffan.larsen at oracle.com Thu Mar 12 07:33:24 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Mar 2015 08:33:24 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> <55006848.2090201@oracle.com> <9E7B3CE7-6C4F-4937-AFF3-A4B6893CE53E@oracle.com> Message-ID: <96ADE742-DAE5-4C7E-8D46-EB6011B1B173@oracle.com> > On 11 mar 2015, at 20:58, Thomas St?fe wrote: > > Hi Staffan, > >> As in Staffan L's comments, we need to have a discuss and make final decision for it --- tradeoff. > > Given that core files on other platforms are useful even after we write the hotspot error logs, it would probably make sense to have the same mechanism on all platforms as Thomas points out. I haven?t been debugging many windows failures lately so perhaps someone who does can chime in here? > >> Personally I prefer a full dump when VM crashes on Windows, which is more helpful. I found minidump not very helpful in most of the cases. > > Windows calls all crash dumps ?minidumps?. They can however be configured to include more or less information, but even with all the information it is still called a ?minidump? (or at least the API for creating them is called that). > > > Sorry, my sentence was garbled and not very clear. > > I was referring to the MINIDUMP_TYPE parameter on MiniDumpWriteDump(): in our code base, we used to have a switch to write either full minidumps (with MiniDumpWithFullMemory set) or partial minidumps without full memory info, just the thread stacks. Trade off was minidump size: full memory info made for very large dumps, the partial ones were small. > > In practice we found the full dumps often too large and unwieldy, and the partial ones were often useless. So in the end we came to rely on the error logs and put lots of work into improving those. That sounds great - something you are planning to contribute? /Staffan > > Thomas > > > /Staffan > >> > From thomas.stuefe at gmail.com Thu Mar 12 08:35:12 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Mar 2015 09:35:12 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <96ADE742-DAE5-4C7E-8D46-EB6011B1B173@oracle.com> References: <54FFE885.3010604@oracle.com> <55006848.2090201@oracle.com> <9E7B3CE7-6C4F-4937-AFF3-A4B6893CE53E@oracle.com> <96ADE742-DAE5-4C7E-8D46-EB6011B1B173@oracle.com> Message-ID: Hi Staffan, you mean the ability to switch between full and partial dumps on windows? Sure, I can do that :) Of course, you would have to add a windows-only switch in addition to Yumins 'CreateCoredumpOnCrash', something like "MiniDumpType=full/partial" or similar, and I can see people objecting because it adds complexity. Also, I think we are quite OT by now. We should move these discussions (about order of dumping and whether to allow partial dumps on windows) to a new thread. Thomas On Thu, Mar 12, 2015 at 8:33 AM, Staffan Larsen wrote: > > On 11 mar 2015, at 20:58, Thomas St?fe wrote: > > Hi Staffan, > > As in Staffan L's comments, we need to have a discuss and make final >> decision for it --- tradeoff. >> >> >> Given that core files on other platforms are useful even after we write >> the hotspot error logs, it would probably make sense to have the same >> mechanism on all platforms as Thomas points out. I haven?t been debugging >> many windows failures lately so perhaps someone who does can chime in here? >> >> Personally I prefer a full dump when VM crashes on Windows, which is more >> helpful. I found minidump not very helpful in most of the cases. >> >> >> Windows calls all crash dumps ?minidumps?. They can however be configured >> to include more or less information, but even with all the information it >> is still called a ?minidump? (or at least the API for creating them is >> called that). >> >> > Sorry, my sentence was garbled and not very clear. > > I was referring to the MINIDUMP_TYPE parameter on MiniDumpWriteDump(): in > our code base, we used to have a switch to write either full minidumps > (with MiniDumpWithFullMemory set) or partial minidumps without full memory > info, just the thread stacks. Trade off was minidump size: full memory info > made for very large dumps, the partial ones were small. > > In practice we found the full dumps often too large and unwieldy, and the > partial ones were often useless. So in the end we came to rely on the error > logs and put lots of work into improving those. > > > That sounds great - something you are planning to contribute? > > /Staffan > > > Thomas > > > >> /Staffan >> >> >> > > From staffan.larsen at oracle.com Thu Mar 12 08:38:08 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Mar 2015 09:38:08 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> <55006848.2090201@oracle.com> <9E7B3CE7-6C4F-4937-AFF3-A4B6893CE53E@oracle.com> <96ADE742-DAE5-4C7E-8D46-EB6011B1B173@oracle.com> Message-ID: <4F771BFD-7A1B-4111-B9FB-04AA1DAFD55C@oracle.com> > On 12 mar 2015, at 09:35, Thomas St?fe wrote: > > Hi Staffan, > > you mean the ability to switch between full and partial dumps on windows? I actually meant the error log improvements :-) But as you say we are off-topic, so let?s leave it. /Staffan > > Sure, I can do that :) > > Of course, you would have to add a windows-only switch in addition to Yumins 'CreateCoredumpOnCrash', something like "MiniDumpType=full/partial" or similar, and I can see people objecting because it adds complexity. > > Also, I think we are quite OT by now. We should move these discussions (about order of dumping and whether to allow partial dumps on windows) to a new thread. > > Thomas > > > > > > On Thu, Mar 12, 2015 at 8:33 AM, Staffan Larsen > wrote: > >> On 11 mar 2015, at 20:58, Thomas St?fe > wrote: >> >> Hi Staffan, >> >>> As in Staffan L's comments, we need to have a discuss and make final decision for it --- tradeoff. >> >> Given that core files on other platforms are useful even after we write the hotspot error logs, it would probably make sense to have the same mechanism on all platforms as Thomas points out. I haven?t been debugging many windows failures lately so perhaps someone who does can chime in here? >> >>> Personally I prefer a full dump when VM crashes on Windows, which is more helpful. I found minidump not very helpful in most of the cases. >> >> Windows calls all crash dumps ?minidumps?. They can however be configured to include more or less information, but even with all the information it is still called a ?minidump? (or at least the API for creating them is called that). >> >> >> Sorry, my sentence was garbled and not very clear. >> >> I was referring to the MINIDUMP_TYPE parameter on MiniDumpWriteDump(): in our code base, we used to have a switch to write either full minidumps (with MiniDumpWithFullMemory set) or partial minidumps without full memory info, just the thread stacks. Trade off was minidump size: full memory info made for very large dumps, the partial ones were small. >> >> In practice we found the full dumps often too large and unwieldy, and the partial ones were often useless. So in the end we came to rely on the error logs and put lots of work into improving those. > > That sounds great - something you are planning to contribute? > > /Staffan > >> >> Thomas >> >> >> /Staffan >> >>> >> > > From thomas.stuefe at gmail.com Thu Mar 12 09:18:10 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Mar 2015 10:18:10 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: <5500FDD9.3060801@oracle.com> References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> Message-ID: Hi David, On Thu, Mar 12, 2015 at 3:45 AM, David Holmes wrote: > On 12/03/2015 8:03 AM, Thomas St?fe wrote: > >> Hi David, >> >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes > > wrote: >> >> Hi Thomas, >> >> I'm not really familiar with Windows SEH. Won't this break custom >> launchers that already provide their own try/catch around >> Crate_JavaVM ? >> >> >> No. Windows SEH works stack based: any exception - e.g. a crash - >> between __try and __except will be handled by the handler given in the >> __except clause. Because they are stack based, they can be nested. If an >> exception is raised inside the inner __try/__except, first the inner >> handler is used, if that one feels not responsible, the next outer one >> and so on. >> >> With my fix, any exception raised inside CreateJavaVM will be handler by >> our handler topLevelExceptionFilter; only if our handler feels not >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user handler will >> be called. >> > > My lack of knowledge about when our handler "feels responsible" still > leaves me a little nervous here. :) > > I think the patch is quite safe. I added this patch to our code base in 2011 and since then this is active in productive code for SAP customers. The SAP jvm gets heavily used with custom launchers which do their own error handling, so this is a well tested scenario. I would like to get a similar signal handling coverage as on UNIX: On Unix, we have global signal handling. The moment signal handling is established early in os::init(), every signal from everywhere is covered, even user code. We even have to take care that user handlers get also in the loop via signal chaining, libjsig.so etc. On Windows, it is the other way around: we have stack based signal handling , so we need __try/__except on every thread, and this means there are parts of jvm code which run without signal handling: - the whole initialization - attached threads (I think?) which means that on those cases, user handler gets signals which the libjvm should handle. This was "fixed" partly by surrounding small code which we know beforehand causes signals - how convenient - with __try/__except. For example, the code which handles "-XX:ErrorHandlerTest" to trigger a crash. But you want error handling to always work. I also do not know if stuff like polling pages, implicit nulltests etc could be used in unprotected code. As a side note, there is a UNIX-like signal handling mode on Windows too, "vectored exception handling", which was used in the jvm but removed some time ago for reasons I do not really know. > Any exception raised in the launcher itself outside of CreateJavaVM will >> still be handled by the user handler. >> >> (And I hate seeing the win32 ifdefs in the shared code :( ). >> >> >> Yes I know, I kind of expected that feedback :( - I did not find a >> better way of doing this. One could try to hide the __try/__except >> behind macros, but that would be kind of unwieldy and I don't like >> abstractiing something which only has meaning on one platform. >> > > Does it help if we make the caller responsible for SEH and then put the > try/catch in the launcher code (hopefully in a windows specific part > thereof) ? > > No, because the caller would need access to "topLevelExceptionFilter" - you would need to export that function from the libjvm and then tell the caller "always call topLevelExceptionFilter() if a signal happens on Windows", which is quite awkward and different than on UNIX. Thomas > Thanks, > David > > >> Thanks, >> David >> >> >> >> Kind regards, Thomas >> >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please review this smallish change: >> >> webrev: >> http://cr.openjdk.java.net/~__stuefe/webrevs/8074860/webrev. >> __01/webrev/ >> > 01/webrev/> >> bug: https://bugs.openjdk.java.net/__browse/JDK-8074860 >> >> >> >> This change adds SEH guards around JNI_CreateJavaVM(). Without >> the change, >> on Windows, the VM initialization runs without crash protection: >> crashes >> will terminate VM immediately without writing an error log; >> also, any >> techniques relying on signals will not work, e.g. SafeFetch(). >> >> This was partly solved before on a case-by-case base by wrapping >> code >> sections which may crash in their own __try/__except wrappers - >> e.g. CPU >> feature probing. >> >> The change guards the whole of JNI_CreateJavaVM invocation in >> __try/__except. Unfortunately, for that to compile, I needed to >> introduce a >> wrapper around JNI_CreateJavaVM and move the whole of >> JNI_CreateJavaVM to a >> new function "JNI_CreateJavaVM_inner". >> >> This fix also gets rid of various workarounds which were used >> before to >> guard code sections. >> >> Thanks for reviewing! >> >> Oh, on a side note: I tried to figure out if threads which are >> attached >> from the outside via JNI AttachCurrentThread() are in any way >> guarded with >> SEH protection. Newly created threads are guarded because they >> run thru >> java_start() in os_windows.cpp, which adds SEH guards to all >> frames below. >> But for attached threads, I did not find any SEH guards - or >> maybe I am >> blind? What does that mean for java code running inside attached >> threads? >> >> Regards, >> >> Thomas Stuefe >> >> >> From goetz.lindenmaier at sap.com Thu Mar 12 09:31:56 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 12 Mar 2015 09:31:56 +0000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CFACD6D@DEWDFEMB12A.global.corp.sap> Hi Thomas, Thanks for fixing these issues. Looks good now! Best regards, Goetz. From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Mittwoch, 11. M?rz 2015 18:10 To: Lindenmaier, Goetz Cc: David Holmes; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling Hi Goetz, thanks for reviewing! Here the updated changes: http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.03/webrev/ - I changed os_linux_sparc.cpp to reflect your comments: removed set_cont_address() and replaced it with ucontext_set_pc(). However, I do not have a linux sparc machine to build and test, so the change is made blind. Hope it does not break. - I removed the "CanUseSafeFetch.." calls from the initial test routine. Originally I was afraid there were platforms where there are no implementations for SafeFetch32 or SafeFetchN, but that does not seem to be the case. Hopefully, I cannot speak for arm or whatever other closed platforms are there. Kind Regards, Thomas On Wed, Mar 11, 2015 at 4:17 PM, Lindenmaier, Goetz > wrote: Hi Thomas, I had a look at your change. I'm fine with it, except for two minor things: os_linux_sparc.cpp Why didn't you just replace set_cont_address by ucontext_set_pc on linux_sparc? As it is now, ucontext_set_pc is just a rename of an existing function. stubRoutines.cpp: Why do you test for availability of the stubs when testing them? I would consider it a bug if the stub is not generated at that point, and that would not be seen here as is now. Best regards, Goetz. -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe Sent: Dienstag, 10. M?rz 2015 18:21 To: David Holmes Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling Hi David, see here my new patch: http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ Turns out that SafeFetch32 does not work in 32bit windows during initialization, because there is no SEH exception guard installed at that time (during the call to CreateJavaVM). Neither is there one for 64bit Windows, but there, we register SEH handlers for dynamic code, that hides the error. This is an issue I'd like to address with a separate patch (see https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I deactivated the SafeFetch test during stub routine initialization for Windows 32bit. Other changes in the fix: - as you wished I changed the ULL literals to UCONST64 - I activated the Jtreg test for windows too (SafeFetch works on windows during error handling, only not during initialization). Thomas On Mon, Mar 9, 2015 at 11:06 PM, David Holmes > wrote: > On 10/03/2015 2:30 AM, Thomas St?fe wrote: > >> Hi David, >> >> I see now that only Windows 32bit is broken. I will investigate this. >> > > Yes, sorry, I hadn't noticed it was only 32-bit failing. > > Thanks, > David > > Thomas >> >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe >> >> wrote: >> >> Hi David, >> >> I am sorry, but I am unable to reproduce the error. Both slowdebug >> and fastdebug builds on Windows come up and SafeFetch works (also in >> error handling). Are you sure the crash is caused by my change? If >> yes, could you send me an hs-err file or at least the configure line >> you used for building? >> >> Kind Regards, Thomas >> >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes >> >> wrote: >> >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >> >> Hi David, >> >> Ouch. The only thing I can think about are the added >> initialization >> tests in stubRoutines.cpp. I will check this. >> >> >> Ah! It hadn't registered with me that this test code was going >> to be executed. Seems the likely cause as a clean repo has no >> problems. >> >> David >> >> Kind Regards, Thomas >> >> >> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >> > >> __com >> >>> wrote: >> >> Hi Thomas, >> >> FYI When I applied this to latest hs-rt forest and ran >> through JPRT >> the Windows fastdebug builds were DOA (instant segfault >> just running >> "java -version"). Can't see how your changes could do >> this so >> running a test on unmodified forest. >> >> David >> >> >> On 9/03/2015 9:40 AM, David Holmes wrote: >> >> Hi Thomas, >> >> Minor nit: in >> >> src/share/vm/runtime/____stubRoutines.cpp::test_____ >> safefetchN >> can >> you use UCONST64 macro instead of explicit ULL - >> thanks. >> >> Otherwise this seems okay, but we will also need >> the aarch64 >> component >> (and I'll look into our internal needs). >> >> Thanks, >> David >> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> >> Hi all, >> >> could someone please review the following fix >> (I also will >> need a >> sponsor): >> >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ >> webrev.____01/ >> > webrev.__01/> >> >> > webrev.__01/ >> > 01/>> >> >> https://bugs.openjdk.java.net/____browse/JDK-8074552 >> >> >> >> > >> > >> >> The fix will make SafeFetch[32,N] work in error >> reporting. >> >> At SAP, we use SafeFetch a lot in error >> reporting to poke >> around in >> potentially invalid memory (e.g. writing hex >> dumps over >> areas which >> may be >> partly unmapped), and we feel that this could >> be useful for the >> OpenJDK too. >> >> Without this fix, SafeFetch will cause a crash, >> the current >> error >> reporting >> step will be interrupted and error reporting >> will continue >> with the next >> step; that is not optimal because the >> interrupted step may >> have shown >> valuable information. >> >> This fix handles SafeFetch faults during error >> reporting the >> same way as >> they are handled normally. The changes are: >> >> - handle safe fetch fault in the various >> (os_cpu dependend) >> secondary >> signal handlers >> >> - provide a function to check if it is safe to >> use SafeFetch: >> CanUseSafeFetch32(). SafeFetch needs stub >> routines and will >> crash when >> used >> before stub generation. >> >> - set_context_pc() is added which complements >> the existing >> get_context_pc() >> and all instances where the pc in ucontext_t >> was modified >> directly are >> changed to use set_context_pc() >> >> - in stubRoutines.cpp, a small test was added >> to the already >> existing >> stub >> routines tests which run at VM init >> >> - in vmError.cpp, a test was added to test >> SafeFetch during >> error >> reporting, similar to the tests introduced for >> 8065895 >> >> - A JTreg test was added >> >> Thanks and Kind Regards, >> >> Thomas Stuefe >> >> >> >> >> From david.holmes at oracle.com Thu Mar 12 09:41:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 19:41:46 +1000 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> Message-ID: <55015F5A.60507@oracle.com> Hi Thomas, Thanks for the added info. I have no further comments. Hopefully someone with SEH knowledge will also respond. David On 12/03/2015 7:18 PM, Thomas St?fe wrote: > Hi David, > > On Thu, Mar 12, 2015 at 3:45 AM, David Holmes > wrote: > > On 12/03/2015 8:03 AM, Thomas St?fe wrote: > > Hi David, > > On Wed, Mar 11, 2015 at 9:43 PM, David Holmes > > >> wrote: > > Hi Thomas, > > I'm not really familiar with Windows SEH. Won't this break > custom > launchers that already provide their own try/catch around > Crate_JavaVM ? > > > No. Windows SEH works stack based: any exception - e.g. a crash - > between __try and __except will be handled by the handler given > in the > __except clause. Because they are stack based, they can be > nested. If an > exception is raised inside the inner __try/__except, first the inner > handler is used, if that one feels not responsible, the next > outer one > and so on. > > With my fix, any exception raised inside CreateJavaVM will be > handler by > our handler topLevelExceptionFilter; only if our handler feels not > responsible (returns EXCEPTION_CONTINUE_SEARCH), the user > handler will > be called. > > > My lack of knowledge about when our handler "feels responsible" > still leaves me a little nervous here. :) > > > I think the patch is quite safe. I added this patch to our code base in > 2011 and since then this is active in productive code for SAP customers. > The SAP jvm gets heavily used with custom launchers which do their own > error handling, so this is a well tested scenario. > > I would like to get a similar signal handling coverage as on UNIX: > > On Unix, we have global signal handling. The moment signal handling is > established early in os::init(), every signal from everywhere is > covered, even user code. We even have to take care that user handlers > get also in the loop via signal chaining, libjsig.so etc. > > On Windows, it is the other way around: we have stack based signal > handling , so we need __try/__except on every thread, and this means > there are parts of jvm code which run without signal handling: > - the whole initialization > - attached threads (I think?) > which means that on those cases, user handler gets signals which the > libjvm should handle. > > This was "fixed" partly by surrounding small code which we know > beforehand causes signals - how convenient - with __try/__except. For > example, the code which handles "-XX:ErrorHandlerTest" to trigger a > crash. But you want error handling to always work. I also do not know if > stuff like polling pages, implicit nulltests etc could be used in > unprotected code. > > As a side note, there is a UNIX-like signal handling mode on Windows > too, "vectored exception handling", which was used in the jvm but > removed some time ago for reasons I do not really know. > > Any exception raised in the launcher itself outside of > CreateJavaVM will > still be handled by the user handler. > > (And I hate seeing the win32 ifdefs in the shared code :( ). > > > Yes I know, I kind of expected that feedback :( - I did not find a > better way of doing this. One could try to hide the __try/__except > behind macros, but that would be kind of unwieldy and I don't like > abstractiing something which only has meaning on one platform. > > > Does it help if we make the caller responsible for SEH and then put > the try/catch in the launcher code (hopefully in a windows specific > part thereof) ? > > > No, because the caller would need access to "topLevelExceptionFilter" - > you would need to export that function from the libjvm and then tell the > caller "always call topLevelExceptionFilter() if a signal happens on > Windows", which is quite awkward and different than on UNIX. > > Thomas > > Thanks, > David > > > Thanks, > David > > > > Kind regards, Thomas > > On 12/03/2015 1:40 AM, Thomas St?fe wrote: > > Hi all, > > please review this smallish change: > > webrev: > http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/webrev.____01/webrev/ > > > > > bug: > https://bugs.openjdk.java.net/____browse/JDK-8074860 > > > > > > This change adds SEH guards around JNI_CreateJavaVM(). > Without > the change, > on Windows, the VM initialization runs without crash > protection: > crashes > will terminate VM immediately without writing an error log; > also, any > techniques relying on signals will not work, e.g. > SafeFetch(). > > This was partly solved before on a case-by-case base by > wrapping > code > sections which may crash in their own __try/__except > wrappers - > e.g. CPU > feature probing. > > The change guards the whole of JNI_CreateJavaVM > invocation in > __try/__except. Unfortunately, for that to compile, I > needed to > introduce a > wrapper around JNI_CreateJavaVM and move the whole of > JNI_CreateJavaVM to a > new function "JNI_CreateJavaVM_inner". > > This fix also gets rid of various workarounds which > were used > before to > guard code sections. > > Thanks for reviewing! > > Oh, on a side note: I tried to figure out if threads > which are > attached > from the outside via JNI AttachCurrentThread() are in > any way > guarded with > SEH protection. Newly created threads are guarded > because they > run thru > java_start() in os_windows.cpp, which adds SEH guards > to all > frames below. > But for attached threads, I did not find any SEH guards > - or > maybe I am > blind? What does that mean for java code running inside > attached > threads? > > Regards, > > Thomas Stuefe > > > From yasuenag at gmail.com Thu Mar 12 11:58:15 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 12 Mar 2015 20:58:15 +0900 Subject: inlining AllocateHeap() Message-ID: Hi all, I tried to use NMT with details option on OpenJDK7 on RHEL6.6, but I got address at AllocateHeap() as malloc() caller. I checked symbol in libjvm.so in OracleJDK8u40 Linux x64, it has AllocateHeap() symbol. AllocateHeap() is defined as inline function, and it gives CURRENT_PC to os::malloc(). I guess that implementation expects AllocateHeap() will be inlined. It may occur with GCC (g++) optimization only, however I want to fix it to analyze native memory with NMT on Linux. I applied patch as below. This patch makes AllocateHeap() as inline function. -------------- diff -r af3b0db91659 src/share/vm/memory/allocation.inline.hpp --- a/src/share/vm/memory/allocation.inline.hpp Mon Mar 09 09:30:16 2015 -0700 +++ b/src/share/vm/memory/allocation.inline.hpp Thu Mar 12 20:45:57 2015 +0900 @@ -62,11 +62,18 @@ } return p; } + +#ifdef __GNUC__ +__attribute__((always_inline)) +#endif inline char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); } +#ifdef __GNUC__ +__attribute__((always_inline)) +#endif inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); -------------- If this patch is accepted, I will file it to JBS and will upload webrev. Thanks, Yasumasa From david.holmes at oracle.com Thu Mar 12 12:22:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 22:22:03 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> Message-ID: <550184EB.8020905@oracle.com> Hi Thomas, I'll try to re-test this internally in the morning. Sorry for the delay. David On 12/03/2015 3:10 AM, Thomas St?fe wrote: > Hi Goetz, > > thanks for reviewing! > > Here the updated changes: > > http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.03/webrev/ > > - I changed os_linux_sparc.cpp to reflect your comments: removed > set_cont_address() and replaced it with ucontext_set_pc(). However, I do > not have a linux sparc machine to build and test, so the change is made > blind. Hope it does not break. > > - I removed the "CanUseSafeFetch.." calls from the initial test routine. > Originally I was afraid there were platforms where there are no > implementations for SafeFetch32 or SafeFetchN, but that does not seem to > be the case. Hopefully, I cannot speak for arm or whatever other closed > platforms are there. > > Kind Regards, Thomas > > > > On Wed, Mar 11, 2015 at 4:17 PM, Lindenmaier, Goetz > > wrote: > > Hi Thomas, > > I had a look at your change. I'm fine with it, except for two minor > things: > > os_linux_sparc.cpp > Why didn't you just replace set_cont_address by ucontext_set_pc on > linux_sparc? > As it is now, ucontext_set_pc is just a rename of an existing function. > > stubRoutines.cpp: > Why do you test for availability of the stubs when testing them? I > would consider > it a bug if the stub is not generated at that point, and that would > not be seen here > as is now. > > Best regards, > Goetz. > > > > -----Original Message----- > From: hotspot-runtime-dev > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net > ] On Behalf Of > Thomas St?fe > Sent: Dienstag, 10. M?rz 2015 18:21 > To: David Holmes > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work > in error handling > > Hi David, > > see here my new patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ > > Turns out that SafeFetch32 does not work in 32bit windows during > initialization, because there is no SEH exception guard installed at > that > time (during the call to CreateJavaVM). Neither is there one for 64bit > Windows, but there, we register SEH handlers for dynamic code, that > hides > the error. > > This is an issue I'd like to address with a separate patch (see > https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I > deactivated > the SafeFetch test during stub routine initialization for Windows 32bit. > > Other changes in the fix: > - as you wished I changed the ULL literals to UCONST64 > - I activated the Jtreg test for windows too (SafeFetch works on windows > during error handling, only not during initialization). > > Thomas > > > > > > On Mon, Mar 9, 2015 at 11:06 PM, David Holmes > > > wrote: > > > On 10/03/2015 2:30 AM, Thomas St?fe wrote: > > > >> Hi David, > >> > >> I see now that only Windows 32bit is broken. I will investigate > this. > >> > > > > Yes, sorry, I hadn't noticed it was only 32-bit failing. > > > > Thanks, > > David > > > > Thomas > >> > >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe > > >> >> wrote: > >> > >> Hi David, > >> > >> I am sorry, but I am unable to reproduce the error. Both > slowdebug > >> and fastdebug builds on Windows come up and SafeFetch works > (also in > >> error handling). Are you sure the crash is caused by my > change? If > >> yes, could you send me an hs-err file or at least the > configure line > >> you used for building? > >> > >> Kind Regards, Thomas > >> > >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes > >> > >> > wrote: > >> > >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: > >> > >> Hi David, > >> > >> Ouch. The only thing I can think about are the added > >> initialization > >> tests in stubRoutines.cpp. I will check this. > >> > >> > >> Ah! It hadn't registered with me that this test code was > going > >> to be executed. Seems the likely cause as a clean repo > has no > >> problems. > >> > >> David > >> > >> Kind Regards, Thomas > >> > >> > >> > >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes > >> > > >> __com > >> >>> wrote: > >> > >> Hi Thomas, > >> > >> FYI When I applied this to latest hs-rt forest > and ran > >> through JPRT > >> the Windows fastdebug builds were DOA (instant > segfault > >> just running > >> "java -version"). Can't see how your changes > could do > >> this so > >> running a test on unmodified forest. > >> > >> David > >> > >> > >> On 9/03/2015 9:40 AM, David Holmes wrote: > >> > >> Hi Thomas, > >> > >> Minor nit: in > >> > >> src/share/vm/runtime/____stubRoutines.cpp::test_____ > >> safefetchN > >> can > >> you use UCONST64 macro instead of explicit > ULL - > >> thanks. > >> > >> Otherwise this seems okay, but we will also > need > >> the aarch64 > >> component > >> (and I'll look into our internal needs). > >> > >> Thanks, > >> David > >> > >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: > >> > >> Hi all, > >> > >> could someone please review the > following fix > >> (I also will > >> need a > >> sponsor): > >> > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ > >> webrev.____01/ > >> >> webrev.__01/> > >> > >> >> webrev.__01/ > >> > >> 01/>> > >> > >> https://bugs.openjdk.java.net/____browse/JDK-8074552 > >> > >> > >> > >> >> > >> > > >> > >> The fix will make SafeFetch[32,N] work > in error > >> reporting. > >> > >> At SAP, we use SafeFetch a lot in error > >> reporting to poke > >> around in > >> potentially invalid memory (e.g. > writing hex > >> dumps over > >> areas which > >> may be > >> partly unmapped), and we feel that this > could > >> be useful for the > >> OpenJDK too. > >> > >> Without this fix, SafeFetch will cause > a crash, > >> the current > >> error > >> reporting > >> step will be interrupted and error > reporting > >> will continue > >> with the next > >> step; that is not optimal because the > >> interrupted step may > >> have shown > >> valuable information. > >> > >> This fix handles SafeFetch faults > during error > >> reporting the > >> same way as > >> they are handled normally. The changes are: > >> > >> - handle safe fetch fault in the various > >> (os_cpu dependend) > >> secondary > >> signal handlers > >> > >> - provide a function to check if it is > safe to > >> use SafeFetch: > >> CanUseSafeFetch32(). SafeFetch needs stub > >> routines and will > >> crash when > >> used > >> before stub generation. > >> > >> - set_context_pc() is added which > complements > >> the existing > >> get_context_pc() > >> and all instances where the pc in > ucontext_t > >> was modified > >> directly are > >> changed to use set_context_pc() > >> > >> - in stubRoutines.cpp, a small test was > added > >> to the already > >> existing > >> stub > >> routines tests which run at VM init > >> > >> - in vmError.cpp, a test was added to test > >> SafeFetch during > >> error > >> reporting, similar to the tests > introduced for > >> 8065895 > >> > >> - A JTreg test was added > >> > >> Thanks and Kind Regards, > >> > >> Thomas Stuefe > >> > >> > >> > >> > >> > > From david.holmes at oracle.com Thu Mar 12 12:29:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Mar 2015 22:29:20 +1000 Subject: RFR: 8074723: AARCH64: Stray pop in C1 LIR_Assembler::emit_profile_type In-Reply-To: <55007F19.1020604@redhat.com> References: <55007F19.1020604@redhat.com> Message-ID: <550186A0.8050801@oracle.com> On 12/03/2015 3:44 AM, Andrew Haley wrote: > There's a pop() in emit_profile_type with no corresponding push(). If we hit that pop > we will crash immediately. > > http://cr.openjdk.java.net/~aph/8074723/ Interesting that testing to date did not hit this. Change looks okay and as it only affects Aarch64 code it can be pushed directly. Thanks, David > Andrew. > From thomas.stuefe at gmail.com Thu Mar 12 12:50:07 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Mar 2015 13:50:07 +0100 Subject: RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time Message-ID: Hi all, please take a look at this tiny change: webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8075044/webrev.01/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8075044 This changes the version number query for dbghelp.dll from a compile time check to a run time check. Thanks! Thomas Stuefe From staffan.larsen at oracle.com Thu Mar 12 12:58:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Mar 2015 13:58:53 +0100 Subject: RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time In-Reply-To: References: Message-ID: <11E1660C-0038-4297-92EC-2B1F41C973C6@oracle.com> Looks good! Thanks, /Staffan > On 12 mar 2015, at 13:50, Thomas St?fe wrote: > > Hi all, > > please take a look at this tiny change: > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8075044/webrev.01/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8075044 > > This changes the version number query for dbghelp.dll from a compile time > check to a run time check. > > Thanks! > > Thomas Stuefe From yumin.qi at oracle.com Thu Mar 12 18:42:29 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 12 Mar 2015 11:42:29 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> Message-ID: <5501DE15.3040700@oracle.com> Hi, Thomas and all The second version of the change: webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ In this version: 1) switch order on Windows to first print log file as other platform, then dump core file if needed. When VMError created after crash, siginfo and context which are ExceptionRecord and ContextRecord on Windows are recorded, mini (or full, due to 'or' used so type will be mini anyway) dump creates dump file based on those two as before. 2) to make os::abort to get above two pointers, added two more fields to the function parameters: 3) changes for test/runtime/ErrorHandling/SecondaryError.java --- added "-XX:-CreateCoredumpOnCrash" - static void abort(bool dump_core = true); + static void abort(bool dump_core = true, void *siginfo = NULL, void *context = NULL); Tests: JPRT and manually. Thanks Yumin On 3/11/2015 3:47 AM, Thomas St?fe wrote: > Hi Yumin, > > There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - > could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! > > Beyond that, as I wrote in the bug report comments: > > "This is also a problem on Windows - MiniDumpWriteDump() may hang > infinitly. And on Windows this is worse than under UNIX because we > create the Dump before writing the hs-err file, so if the Dump hangs, > we get no error log. I would like to revert the order: create the > minidump after writing the error log, the same way Unix does it. We > did this in our JVM (SAP) because for us, error logs are more useful > than minidumps. " > > So, I would like to see os::abort on Windows call MiniDumpWriteDump(), > and thus the mini dump writing moved after the error log writing. This > would also make the code way cleaner because the control flow would be > the same on all platforms. > > I understand that this may be out of scope for your change, but I > would like to know what others think about this. > > Kind regards, Thomas > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi > wrote: > > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8074354 > webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > > > Summary: Tests timed out when VM crashes and dumping core file > which in the test case is not needed. To make core not created, > the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, > the former is only used on Windows and the latter for all > platforms. When VM crashes on non Windows, core file generated as > default if OS sets core dump allowed. Default value of > CreateCoredumpOnCrash set to 'true' to keep same behavior on non > Windows platforms, but changed for Windows --- original is false, > not create minidump on Windows. With CreateCoredumpOnCrash turned > off, no core file will be generated. CreateMinidumpOnCrash still > can be used on commandline but only as alias for the new flag. > > Tests: JPRT, manual tests setting CreateMinidumpOnCrash on > commandline to verify flag change as alias. > > Thanks > Yumin > > From daniel.daugherty at oracle.com Thu Mar 12 19:29:04 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Mar 2015 13:29:04 -0600 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5501DE15.3040700@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> Message-ID: <5501E900.7040301@oracle.com> Yumin, There are some error handler tests. You should find those and make sure that you run them on Windows since you're changing the order there... Dan On 3/12/15 12:42 PM, Yumin Qi wrote: > Hi, Thomas and all > > The second version of the change: > webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ > > In this version: > 1) switch order on Windows to first print log file as other > platform, then dump core file if needed. When VMError created after > crash, siginfo and context which are ExceptionRecord and ContextRecord > on Windows are recorded, mini (or full, due to 'or' used so type will > be mini anyway) dump creates dump file based on those two as before. > 2) to make os::abort to get above two pointers, added two more > fields to the function parameters: > 3) changes for test/runtime/ErrorHandling/SecondaryError.java --- > added "-XX:-CreateCoredumpOnCrash" > > - static void abort(bool dump_core = true); > + static void abort(bool dump_core = true, void *siginfo = NULL, > void *context = NULL); > > Tests: JPRT and manually. > > Thanks > Yumin > > On 3/11/2015 3:47 AM, Thomas St?fe wrote: >> Hi Yumin, >> >> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - >> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >> >> Beyond that, as I wrote in the bug report comments: >> >> "This is also a problem on Windows - MiniDumpWriteDump() may hang >> infinitly. And on Windows this is worse than under UNIX because we >> create the Dump before writing the hs-err file, so if the Dump hangs, >> we get no error log. I would like to revert the order: create the >> minidump after writing the error log, the same way Unix does it. We >> did this in our JVM (SAP) because for us, error logs are more useful >> than minidumps. " >> >> So, I would like to see os::abort on Windows call >> MiniDumpWriteDump(), and thus the mini dump writing moved after the >> error log writing. This would also make the code way cleaner because >> the control flow would be the same on all platforms. >> >> I understand that this may be out of scope for your change, but I >> would like to know what others think about this. >> >> Kind regards, Thomas >> >> >> >> >> >> >> >> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi > > wrote: >> >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >> >> >> Summary: Tests timed out when VM crashes and dumping core file >> which in the test case is not needed. To make core not created, >> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >> the former is only used on Windows and the latter for all >> platforms. When VM crashes on non Windows, core file generated as >> default if OS sets core dump allowed. Default value of >> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >> Windows platforms, but changed for Windows --- original is false, >> not create minidump on Windows. With CreateCoredumpOnCrash turned >> off, no core file will be generated. CreateMinidumpOnCrash still >> can be used on commandline but only as alias for the new flag. >> >> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >> commandline to verify flag change as alias. >> >> Thanks >> Yumin >> >> > From yumin.qi at oracle.com Thu Mar 12 19:50:40 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 12 Mar 2015 12:50:40 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5501E900.7040301@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> Message-ID: <5501EE10.9040208@oracle.com> Thanks, Dan Will look at and run those tests. Are they under nsk? Yumin On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: > Yumin, > > There are some error handler tests. You should find those and make > sure that you run them on Windows since you're changing the order > there... > > Dan > > > On 3/12/15 12:42 PM, Yumin Qi wrote: >> Hi, Thomas and all >> >> The second version of the change: >> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >> >> In this version: >> 1) switch order on Windows to first print log file as other >> platform, then dump core file if needed. When VMError created after >> crash, siginfo and context which are ExceptionRecord and >> ContextRecord on Windows are recorded, mini (or full, due to 'or' >> used so type will be mini anyway) dump creates dump file based on >> those two as before. >> 2) to make os::abort to get above two pointers, added two more >> fields to the function parameters: >> 3) changes for test/runtime/ErrorHandling/SecondaryError.java --- >> added "-XX:-CreateCoredumpOnCrash" >> >> - static void abort(bool dump_core = true); >> + static void abort(bool dump_core = true, void *siginfo = NULL, >> void *context = NULL); >> >> Tests: JPRT and manually. >> >> Thanks >> Yumin >> >> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>> Hi Yumin, >>> >>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - >>> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>> >>> Beyond that, as I wrote in the bug report comments: >>> >>> "This is also a problem on Windows - MiniDumpWriteDump() may hang >>> infinitly. And on Windows this is worse than under UNIX because we >>> create the Dump before writing the hs-err file, so if the Dump >>> hangs, we get no error log. I would like to revert the order: create >>> the minidump after writing the error log, the same way Unix does it. >>> We did this in our JVM (SAP) because for us, error logs are more >>> useful than minidumps. " >>> >>> So, I would like to see os::abort on Windows call >>> MiniDumpWriteDump(), and thus the mini dump writing moved after the >>> error log writing. This would also make the code way cleaner because >>> the control flow would be the same on all platforms. >>> >>> I understand that this may be out of scope for your change, but I >>> would like to know what others think about this. >>> >>> Kind regards, Thomas >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >> > wrote: >>> >>> Please review: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>> >>> >>> Summary: Tests timed out when VM crashes and dumping core file >>> which in the test case is not needed. To make core not created, >>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>> the former is only used on Windows and the latter for all >>> platforms. When VM crashes on non Windows, core file generated as >>> default if OS sets core dump allowed. Default value of >>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>> Windows platforms, but changed for Windows --- original is false, >>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>> off, no core file will be generated. CreateMinidumpOnCrash still >>> can be used on commandline but only as alias for the new flag. >>> >>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>> commandline to verify flag change as alias. >>> >>> Thanks >>> Yumin >>> >>> >> > From daniel.daugherty at oracle.com Thu Mar 12 19:59:19 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Mar 2015 13:59:19 -0600 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5501EE10.9040208@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> Message-ID: <5501F017.1000900@oracle.com> I believe there are both JavaTest/JTREG tests in the hotspot repo and there are VM/NSK tests from back when we did phone home... Check with Christian or Misha... Dan On 3/12/15 1:50 PM, Yumin Qi wrote: > Thanks, Dan > > Will look at and run those tests. Are they under nsk? > > Yumin > > On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >> Yumin, >> >> There are some error handler tests. You should find those and make >> sure that you run them on Windows since you're changing the order >> there... >> >> Dan >> >> >> On 3/12/15 12:42 PM, Yumin Qi wrote: >>> Hi, Thomas and all >>> >>> The second version of the change: >>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>> >>> In this version: >>> 1) switch order on Windows to first print log file as other >>> platform, then dump core file if needed. When VMError created after >>> crash, siginfo and context which are ExceptionRecord and >>> ContextRecord on Windows are recorded, mini (or full, due to 'or' >>> used so type will be mini anyway) dump creates dump file based on >>> those two as before. >>> 2) to make os::abort to get above two pointers, added two more >>> fields to the function parameters: >>> 3) changes for test/runtime/ErrorHandling/SecondaryError.java >>> --- added "-XX:-CreateCoredumpOnCrash" >>> >>> - static void abort(bool dump_core = true); >>> + static void abort(bool dump_core = true, void *siginfo = NULL, >>> void *context = NULL); >>> >>> Tests: JPRT and manually. >>> >>> Thanks >>> Yumin >>> >>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>>> Hi Yumin, >>>> >>>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - >>>> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>>> >>>> Beyond that, as I wrote in the bug report comments: >>>> >>>> "This is also a problem on Windows - MiniDumpWriteDump() may hang >>>> infinitly. And on Windows this is worse than under UNIX because we >>>> create the Dump before writing the hs-err file, so if the Dump >>>> hangs, we get no error log. I would like to revert the order: >>>> create the minidump after writing the error log, the same way Unix >>>> does it. We did this in our JVM (SAP) because for us, error logs >>>> are more useful than minidumps. " >>>> >>>> So, I would like to see os::abort on Windows call >>>> MiniDumpWriteDump(), and thus the mini dump writing moved after the >>>> error log writing. This would also make the code way cleaner >>>> because the control flow would be the same on all platforms. >>>> >>>> I understand that this may be out of scope for your change, but I >>>> would like to know what others think about this. >>>> >>>> Kind regards, Thomas >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >>> > wrote: >>>> >>>> Please review: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>> >>>> >>>> Summary: Tests timed out when VM crashes and dumping core file >>>> which in the test case is not needed. To make core not created, >>>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>>> the former is only used on Windows and the latter for all >>>> platforms. When VM crashes on non Windows, core file generated as >>>> default if OS sets core dump allowed. Default value of >>>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>>> Windows platforms, but changed for Windows --- original is false, >>>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>>> off, no core file will be generated. CreateMinidumpOnCrash still >>>> can be used on commandline but only as alias for the new flag. >>>> >>>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>>> commandline to verify flag change as alias. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>> >> > From jeremymanson at google.com Thu Mar 12 20:31:39 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 12 Mar 2015 13:31:39 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5500FC48.50503@oracle.com> References: <5500FC48.50503@oracle.com> Message-ID: On Wed, Mar 11, 2015 at 7:39 PM, David Holmes wrote: > Hi Jeremy, > > > On 11/03/2015 7:08 AM, Jeremy Manson wrote: > >> Hi, David, >> >> I'd like you to do a code review, please. Original discussion: >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/ >> 2015-March/016851.html >> >> Per this discussion, I'm just getting rid of the os::getenv interface, >> and using straight getenv() everywhere. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8074895 >> >> Webrev: >> http://cr.openjdk.java.net/~jmanson/8074895/webrev.00/ >> > > In arguments.cpp the headless property setting could have been left using > a local buffer rather than introducing NEW_C_HEAP_ARRAY. The value should > only be true or false so there's no size issue regarding the local buffer. > Will do, but I won't bother with the rev until you tell me what to do with: > 3566 if ((buffer = os::strdup(buffer)) == NULL) { > 3567 return JNI_OK; > 3568 } > > So this silently hides failures? > Yes. Is there a best practice in Hotspot when you fail to allocate memory? I haven't noticed it, but I'm happy to, for example, die horribly. > The only minor concern I have is whether os::print_environment_variables > is now susceptible to any issues caused by arbitrarily long environment > variables? But I suspect there is already a maximum permitted length for > environment variables. > Which issues did you have in mind? I guess if you were printing to a string, the string would have to use extra memory. But the getenv() was being called anyway, so that's not much of an issue. > Also you could now do the same for os::unsetenv :) > Sadly, that really *does* seem undefined on Windows, AFAICT. Jeremy > > Thanks, > David > > Jeremy >> > From david.holmes at oracle.com Thu Mar 12 23:36:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 09:36:22 +1000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <550184EB.8020905@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> Message-ID: <550222F6.7020503@oracle.com> All looking good so pushing now. Thanks, David On 12/03/2015 10:22 PM, David Holmes wrote: > Hi Thomas, > > I'll try to re-test this internally in the morning. Sorry for the delay. > > David > > On 12/03/2015 3:10 AM, Thomas St?fe wrote: >> Hi Goetz, >> >> thanks for reviewing! >> >> Here the updated changes: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.03/webrev/ >> >> - I changed os_linux_sparc.cpp to reflect your comments: removed >> set_cont_address() and replaced it with ucontext_set_pc(). However, I do >> not have a linux sparc machine to build and test, so the change is made >> blind. Hope it does not break. >> >> - I removed the "CanUseSafeFetch.." calls from the initial test routine. >> Originally I was afraid there were platforms where there are no >> implementations for SafeFetch32 or SafeFetchN, but that does not seem to >> be the case. Hopefully, I cannot speak for arm or whatever other closed >> platforms are there. >> >> Kind Regards, Thomas >> >> >> >> On Wed, Mar 11, 2015 at 4:17 PM, Lindenmaier, Goetz >> > wrote: >> >> Hi Thomas, >> >> I had a look at your change. I'm fine with it, except for two minor >> things: >> >> os_linux_sparc.cpp >> Why didn't you just replace set_cont_address by ucontext_set_pc on >> linux_sparc? >> As it is now, ucontext_set_pc is just a rename of an existing >> function. >> >> stubRoutines.cpp: >> Why do you test for availability of the stubs when testing them? I >> would consider >> it a bug if the stub is not generated at that point, and that would >> not be seen here >> as is now. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: hotspot-runtime-dev >> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net >> ] On Behalf Of >> Thomas St?fe >> Sent: Dienstag, 10. M?rz 2015 18:21 >> To: David Holmes >> Cc: hotspot-runtime-dev at openjdk.java.net >> >> Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work >> in error handling >> >> Hi David, >> >> see here my new patch: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ >> >> Turns out that SafeFetch32 does not work in 32bit windows during >> initialization, because there is no SEH exception guard installed at >> that >> time (during the call to CreateJavaVM). Neither is there one for >> 64bit >> Windows, but there, we register SEH handlers for dynamic code, that >> hides >> the error. >> >> This is an issue I'd like to address with a separate patch (see >> https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I >> deactivated >> the SafeFetch test during stub routine initialization for Windows >> 32bit. >> >> Other changes in the fix: >> - as you wished I changed the ULL literals to UCONST64 >> - I activated the Jtreg test for windows too (SafeFetch works on >> windows >> during error handling, only not during initialization). >> >> Thomas >> >> >> >> >> >> On Mon, Mar 9, 2015 at 11:06 PM, David Holmes >> > >> wrote: >> >> > On 10/03/2015 2:30 AM, Thomas St?fe wrote: >> > >> >> Hi David, >> >> >> >> I see now that only Windows 32bit is broken. I will investigate >> this. >> >> >> > >> > Yes, sorry, I hadn't noticed it was only 32-bit failing. >> > >> > Thanks, >> > David >> > >> > Thomas >> >> >> >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe >> >> >> > >> wrote: >> >> >> >> Hi David, >> >> >> >> I am sorry, but I am unable to reproduce the error. Both >> slowdebug >> >> and fastdebug builds on Windows come up and SafeFetch works >> (also in >> >> error handling). Are you sure the crash is caused by my >> change? If >> >> yes, could you send me an hs-err file or at least the >> configure line >> >> you used for building? >> >> >> >> Kind Regards, Thomas >> >> >> >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes >> >> >> >> >> wrote: >> >> >> >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >> >> >> >> Hi David, >> >> >> >> Ouch. The only thing I can think about are the added >> >> initialization >> >> tests in stubRoutines.cpp. I will check this. >> >> >> >> >> >> Ah! It hadn't registered with me that this test code was >> going >> >> to be executed. Seems the likely cause as a clean repo >> has no >> >> problems. >> >> >> >> David >> >> >> >> Kind Regards, Thomas >> >> >> >> >> >> >> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >> >> > > > >> >> > __com >> >> > >>> wrote: >> >> >> >> Hi Thomas, >> >> >> >> FYI When I applied this to latest hs-rt forest >> and ran >> >> through JPRT >> >> the Windows fastdebug builds were DOA (instant >> segfault >> >> just running >> >> "java -version"). Can't see how your changes >> could do >> >> this so >> >> running a test on unmodified forest. >> >> >> >> David >> >> >> >> >> >> On 9/03/2015 9:40 AM, David Holmes wrote: >> >> >> >> Hi Thomas, >> >> >> >> Minor nit: in >> >> >> >> src/share/vm/runtime/____stubRoutines.cpp::test_____ >> >> safefetchN >> >> can >> >> you use UCONST64 macro instead of explicit >> ULL - >> >> thanks. >> >> >> >> Otherwise this seems okay, but we will also >> need >> >> the aarch64 >> >> component >> >> (and I'll look into our internal needs). >> >> >> >> Thanks, >> >> David >> >> >> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >> >> >> >> Hi all, >> >> >> >> could someone please review the >> following fix >> >> (I also will >> >> need a >> >> sponsor): >> >> >> >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ >> >> webrev.____01/ >> >> >> > >> webrev.__01/> >> >> >> >> >> > >> webrev.__01/ >> >> >> > >> 01/>> >> >> >> >> https://bugs.openjdk.java.net/____browse/JDK-8074552 >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >> The fix will make SafeFetch[32,N] work >> in error >> >> reporting. >> >> >> >> At SAP, we use SafeFetch a lot in error >> >> reporting to poke >> >> around in >> >> potentially invalid memory (e.g. >> writing hex >> >> dumps over >> >> areas which >> >> may be >> >> partly unmapped), and we feel that this >> could >> >> be useful for the >> >> OpenJDK too. >> >> >> >> Without this fix, SafeFetch will cause >> a crash, >> >> the current >> >> error >> >> reporting >> >> step will be interrupted and error >> reporting >> >> will continue >> >> with the next >> >> step; that is not optimal because the >> >> interrupted step may >> >> have shown >> >> valuable information. >> >> >> >> This fix handles SafeFetch faults >> during error >> >> reporting the >> >> same way as >> >> they are handled normally. The >> changes are: >> >> >> >> - handle safe fetch fault in the various >> >> (os_cpu dependend) >> >> secondary >> >> signal handlers >> >> >> >> - provide a function to check if it is >> safe to >> >> use SafeFetch: >> >> CanUseSafeFetch32(). SafeFetch needs >> stub >> >> routines and will >> >> crash when >> >> used >> >> before stub generation. >> >> >> >> - set_context_pc() is added which >> complements >> >> the existing >> >> get_context_pc() >> >> and all instances where the pc in >> ucontext_t >> >> was modified >> >> directly are >> >> changed to use set_context_pc() >> >> >> >> - in stubRoutines.cpp, a small test was >> added >> >> to the already >> >> existing >> >> stub >> >> routines tests which run at VM init >> >> >> >> - in vmError.cpp, a test was added to >> test >> >> SafeFetch during >> >> error >> >> reporting, similar to the tests >> introduced for >> >> 8065895 >> >> >> >> - A JTreg test was added >> >> >> >> Thanks and Kind Regards, >> >> >> >> Thomas Stuefe >> >> >> >> >> >> >> >> >> >> >> >> From vladimir.kozlov at oracle.com Fri Mar 13 00:09:28 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Mar 2015 17:09:28 -0700 Subject: RFR(S): 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: References: Message-ID: <55022AB8.6020705@oracle.com> Fix looks correct. I CC to runtime group. They may know answers for your questions. Thanks, Vladimir On 3/12/15 6:31 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8069263/webrev.00/ > > In the test case, I1.m1() is a default method that is added by default methods processing to the list of default methods of class C2. The call at line 54 triggers CHA. It finds m1 in class C2 but with holder I1 as unique target. The assert fires because m1?s holder is not C2 but m1 is in the list of C2?s methods. > > I fixed this by returning no unique method in that case because: > > 1) we seem to still not expect that we can handle default methods properly in CHA even though we?ve added code in dependencies.cpp to support them. ciMethod::find_monomorphic_target) has this code: > > // Disable CHA for default methods for now > if (root_m->get_Method()->is_default_method()) { > return NULL; > } > > Or maybe that code should be removed? > > 2) a proper fix would require that we record the method, its actual holder (C2) in the dependency which would require more extensive changes. I wonder if the extra complexity would make sense. > > Roland. > > From david.holmes at oracle.com Fri Mar 13 00:12:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 10:12:31 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> Message-ID: <55022B6F.5090104@oracle.com> On 13/03/2015 6:31 AM, Jeremy Manson wrote: > On Wed, Mar 11, 2015 at 7:39 PM, David Holmes > wrote: > On 11/03/2015 7:08 AM, Jeremy Manson wrote: > I'd like you to do a code review, please. Original discussion: > > http://mail.openjdk.java.net/__pipermail/serviceability-dev/__2015-March/016851.html > > > Per this discussion, I'm just getting rid of the os::getenv > interface, and using straight getenv() everywhere. > > Bug: > https://bugs.openjdk.java.net/__browse/JDK-8074895 > > > Webrev: > http://cr.openjdk.java.net/~__jmanson/8074895/webrev.00/ > > > > In arguments.cpp the headless property setting could have been left > using a local buffer rather than introducing NEW_C_HEAP_ARRAY. The > value should only be true or false so there's no size issue > regarding the local buffer. > > > Will do, but I won't bother with the rev until you tell me what to do with: > > 3566 if ((buffer = os::strdup(buffer)) == NULL) { > 3567 return JNI_OK; > 3568 } > > So this silently hides failures? > > > Yes. Is there a best practice in Hotspot when you fail to allocate > memory? I haven't noticed it, but I'm happy to, for example, die horribly. At this stage of the VM initialization we should be trying to be a good citizen and simply return JNI_ENOMEM, which will eventually make its way back to the caller of CreateJavaVM. Which also means your use of NEW_C_HEAP_ARRAY also needs changing as it will abort the VM. You want to use NEW_C_HEAP_ARRAY_RETURN_NULL and if NULL then return JNI_ENOMEM. > The only minor concern I have is whether > os::print_environment___variables is now susceptible to any issues > caused by arbitrarily long environment variables? But I suspect > there is already a maximum permitted length for environment variables. > > > Which issues did you have in mind? I guess if you were printing to a > string, the string would have to use extra memory. But the getenv() was > being called anyway, so that's not much of an issue. I was wondering if an absurdly long environment variable value could overflow some other internal buffer somewhere. > Also you could now do the same for os::unsetenv :) > > Sadly, that really *does* seem undefined on Windows, AFAICT. Yeah they use _putenv with an empty value to remove the variable. Thanks, David > Jeremy > > > Thanks, > David > > Jeremy > > From yumin.qi at oracle.com Fri Mar 13 01:55:42 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 12 Mar 2015 18:55:42 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5501F017.1000900@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> Message-ID: <5502439E.2080803@oracle.com> I have tested and without finding new problem, but I do find one problem on Windows: The output message is not right due to changes of check_or_create_dump => check_create_dump_limit : on Windows, it is empty, but it gets called in STEP(63, "(printing core file information)") So whatever the message is, it will be printed out here. The correct way is keeping the checking code in the function and the dump code in abort(). I will revise the code and post next webrev soon. Thanks Yumin On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: > I believe there are both JavaTest/JTREG tests in the hotspot repo > and there are VM/NSK tests from back when we did phone home... > > Check with Christian or Misha... > > Dan > > > On 3/12/15 1:50 PM, Yumin Qi wrote: >> Thanks, Dan >> >> Will look at and run those tests. Are they under nsk? >> >> Yumin >> >> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >>> Yumin, >>> >>> There are some error handler tests. You should find those and make >>> sure that you run them on Windows since you're changing the order >>> there... >>> >>> Dan >>> >>> >>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>> Hi, Thomas and all >>>> >>>> The second version of the change: >>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>> >>>> In this version: >>>> 1) switch order on Windows to first print log file as other >>>> platform, then dump core file if needed. When VMError created after >>>> crash, siginfo and context which are ExceptionRecord and >>>> ContextRecord on Windows are recorded, mini (or full, due to 'or' >>>> used so type will be mini anyway) dump creates dump file based on >>>> those two as before. >>>> 2) to make os::abort to get above two pointers, added two more >>>> fields to the function parameters: >>>> 3) changes for test/runtime/ErrorHandling/SecondaryError.java >>>> --- added "-XX:-CreateCoredumpOnCrash" >>>> >>>> - static void abort(bool dump_core = true); >>>> + static void abort(bool dump_core = true, void *siginfo = >>>> NULL, void *context = NULL); >>>> >>>> Tests: JPRT and manually. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>>>> Hi Yumin, >>>>> >>>>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - >>>>> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>>>> >>>>> Beyond that, as I wrote in the bug report comments: >>>>> >>>>> "This is also a problem on Windows - MiniDumpWriteDump() may hang >>>>> infinitly. And on Windows this is worse than under UNIX because we >>>>> create the Dump before writing the hs-err file, so if the Dump >>>>> hangs, we get no error log. I would like to revert the order: >>>>> create the minidump after writing the error log, the same way Unix >>>>> does it. We did this in our JVM (SAP) because for us, error logs >>>>> are more useful than minidumps. " >>>>> >>>>> So, I would like to see os::abort on Windows call >>>>> MiniDumpWriteDump(), and thus the mini dump writing moved after >>>>> the error log writing. This would also make the code way cleaner >>>>> because the control flow would be the same on all platforms. >>>>> >>>>> I understand that this may be out of scope for your change, but I >>>>> would like to know what others think about this. >>>>> >>>>> Kind regards, Thomas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >>>> > wrote: >>>>> >>>>> Please review: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>> >>>>> >>>>> Summary: Tests timed out when VM crashes and dumping core file >>>>> which in the test case is not needed. To make core not created, >>>>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>>>> the former is only used on Windows and the latter for all >>>>> platforms. When VM crashes on non Windows, core file generated as >>>>> default if OS sets core dump allowed. Default value of >>>>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>>>> Windows platforms, but changed for Windows --- original is false, >>>>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>>>> off, no core file will be generated. CreateMinidumpOnCrash still >>>>> can be used on commandline but only as alias for the new flag. >>>>> >>>>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>>>> commandline to verify flag change as alias. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Fri Mar 13 04:50:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 14:50:09 +1000 Subject: RFR(S) Contended Locking fast exit bucket (8073165) In-Reply-To: <54FDD431.7010704@oracle.com> References: <54FDD431.7010704@oracle.com> Message-ID: <55026C81.4030207@oracle.com> Hi Dan, Well that was fun ... :) On 10/03/2015 3:11 AM, Daniel D. Daugherty wrote: > Greetings, > > I have the Contended Locking fast exit bucket ready for review. > > The code changes in this bucket are primarily assembly language > tweaks that come into play when an inflated ObjectMonitor is in > use. There are tweaks that apply to the default code path and > there are tweaks that only apply when an experimental flag is > set. This code code review is focused on the default code path > or the "out of the box" configuration. > > This work is being tracked by the following bug ID: > > JDK-8073165 Contended Locking fast exit bucket > https://bugs.openjdk.java.net/browse/JDK-8073165 > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8073165-webrev/0-jdk9-hs-rt/ > > Here is the JEP link: > > https://bugs.openjdk.java.net/browse/JDK-8046133 > > Testing: > > - Aurora Adhoc RT/SVC baseline batch > - JPRT test jobs > - MonitorExitStresser micro-benchmark (in process) > - MonitorEnterExitStresser micro-benchmark (in process) > - CallTimerGrid stress testing (in process) > - Aurora performance testing: > - out of the box for the "promotion" and 32-bit server configs > - heavy weight monitors for the "promotion" and 32-bit server configs > (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors) > (in process) > > > 8073165 summary of changes: > > macroAssembler_sparc.cpp: MacroAssembler::compiler_unlock_object() > > - default (OOTB) EmitSync value == 0 > - an _owner field optimization is in the non-default path under > a (EmitSync & 1024) check > > - classic lock release without 1-0 support is in the non-default > path under a (EmitSync & 512) check > > - an EntryList, cxq and _succ field optimization is in the > non-default path under a (EmitSync & 16384) check > > - the default path is now the 1-0 form that avoids CAS and membar > in the common case; see the "1-0 exit" section in objectMonitor.cpp I don't pretend that I could follow all these changes (I don't read sparc very well) - the main thing of interest is the EmitSync==0 path - everything else is just experimental (did you actually test to any great extent with all these different possible EmitSync values?). So looking at the default path ... I could not figure out what logic this (pre-existing) code is effecting: 3071 ld_ptr(Address(Rmark, OM_OFFSET_NO_MONITOR_VALUE_TAG(recursions)), Rbox); 3072 orcc(Rbox, G0, G0); 3073 brx(Assembler::notZero, false, Assembler::pn, done); It seems to be a check for: if (recursions != 0) return; which would be fine except where is recursions decremented ?? But that aside the description seems reasonable. > sharedRuntime_sparc.cpp: > > - add JavaThread* param for > SharedRuntime::complete_monitor_unlocking_C call Ok. > macroAssembler_x86.cpp: MacroAssembler::fast_unlock() > > - with all the new/modified comments and all the optional > code path updates, it is hard to see that the only real > changes to the default code path are 1) the _owner==Self > check has been made optional and 2) the optional succ > field check for the slow path is now on the default path > > - default (OOTB) EmitSync value == 0 > - remove optional (EmitSync & 8) code > - refactor code in MacroAssembler::fast_unlock > - remove old mfence() support So I had expected to see this change conditional on the runtime processor type. But then I checked Dave's blog and saw this was determined 5+ years ago (!!!) so those older processors are no longer a consideration. I do hope the performance tests have been re-run since then though ;-) > - an _owner field optimization is in the non-default path under > a (EmitSync & 1024) check Doesn't the comment: 2163 if (EmitSync & 1024) { 2164 // Don't bother to ratify that m_Owner==Self apply to else part? > - an _owner field optimization is in the non-default path under > a (EmitSync & 16) check > - a barrier optimization is in the non-default path under a > (EmitSync & 32) check > - remove old AMD optional work around 2229 // box is really RAX -- the following CMPXCHG depends on that binding 2230 // cmpxchg R,[M] is equivalent to rax = CAS(M,rax,R) 2231 2232 movptr(boxReg, (int32_t)NULL_WORD); // box is really RAX You've repeated the comment about box. > sharedRuntime_x86_32.cpp: > sharedRuntime_x86_64.cpp: > > - add thread param for SharedRuntime::complete_monitor_unlocking_C > call Ok. > macro.[ch]pp: PhaseMacroExpand::make_slow_call() > > - add param2 and update callers Ok. > runtime.[ch]pp: OptoRuntime::complete_monitor_exit_Type() > > - add JavaThread* parameter Ok > sharedRuntime.[ch]pp: SharedRuntime::complete_monitor_unlocking_C() > > - add JavaThread* parameter Ok. So all that passing through of the Thread was just to avoid a call to JavaThread::current()? I thought that was already optimized to just be a register load (at least on some platforms) ? > synchronizer.cpp: ObjectSynchronizer::omRelease() > > - cleanup in use list traversal > - add assert that ObjectMonitor being released was > actually found and extracted > > synchronizer.[ch]pp: > > - add some comments in various places > - rename walk_monitor_list() -> deflate_monitor_list() > and update callers > - minor logic refactoring Generally okay. Minor nit: you changed inuse to "in use" but for the "inuse list" it should really be "in-use list" (and not in-use-list as appears in a couple of existing places) 1507 // if deflate_monitor succeeded,/moribund Not sure what that comment is supposed to mean :) > thread.hpp: > > - add _TSelf field for mfence() replacement Hmmmm, so we add a new pointer field to the Thread structure purely for use on x86 if running with a particular experimental option set ? That doesn't seem like it fits with our normal considerations for space/time trade-offs. Maybe the xchg T,T->TSelf stuff should be under a compile-flag instead? > > Thanks, in advance, for any comments, questions or suggestions. Cheers, David > Dan From david.holmes at oracle.com Fri Mar 13 05:40:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 15:40:02 +1000 Subject: inlining AllocateHeap() In-Reply-To: References: Message-ID: <55027832.8030203@oracle.com> Hi Yasumasa, On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: > Hi all, > > I tried to use NMT with details option on OpenJDK7 on RHEL6.6, but I got > address at AllocateHeap() as malloc() caller. > > I checked symbol in libjvm.so in OracleJDK8u40 Linux > x64, it has AllocateHeap() > symbol. > > AllocateHeap() is defined as inline function, and it gives CURRENT_PC to > os::malloc(). I guess that implementation expects AllocateHeap() will be > inlined. It seems so. > It may occur with GCC (g++) optimization only, however I want to fix it to > analyze native memory with NMT on Linux. According to the docs [1]: "GCC does not inline any functions when not optimizing unless you specify the ?always_inline? attribute for the function" > I applied patch as below. This patch makes AllocateHeap() as inline > function. > -------------- > diff -r af3b0db91659 src/share/vm/memory/allocation.inline.hpp > --- a/src/share/vm/memory/allocation.inline.hpp Mon Mar 09 09:30:16 2015 > -0700 > +++ b/src/share/vm/memory/allocation.inline.hpp Thu Mar 12 20:45:57 2015 > +0900 > @@ -62,11 +62,18 @@ > } > return p; > } > + > +#ifdef __GNUC__ > +__attribute__((always_inline)) > +#endif I dislike seeing the gcc specific directives in common code. I'm wondering whether we should perhaps only use CURRENT_PC in product (and optimized?) builds and use CALLER_PC otherwise. That would be imperfect of course It also makes me wonder whether the inlining is occurring as expected on other platforms. I'd like to get other people's views on this. Thanks, David [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html > inline char* AllocateHeap(size_t size, MEMFLAGS flags, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); > } > > +#ifdef __GNUC__ > +__attribute__((always_inline)) > +#endif > inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); > -------------- > > If this patch is accepted, I will file it to JBS and will upload webrev. > > Thanks, > > Yasumasa > From staffan.larsen at oracle.com Fri Mar 13 07:49:56 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 13 Mar 2015 08:49:56 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5502439E.2080803@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <5502439E.2080803@oracle.com> Message-ID: Yumin, I haven?t looked in detail at the changes, but it is a bit strange to do this changes under a bug that has to do with tests timing out. Would you mind filing a new bug for the changes to command line arguments and core/minidump handling? Or just change the Summary of the existing bug. Thanks, /Staffan > On 13 mar 2015, at 02:55, Yumin Qi wrote: > > I have tested and without finding new problem, but I do find one problem on Windows: The output message is not right due to changes of > > check_or_create_dump => check_create_dump_limit : on Windows, it is empty, but it gets called in > > STEP(63, "(printing core file information)") > > So whatever the message is, it will be printed out here. > > The correct way is keeping the checking code in the function and the dump code in abort(). > I will revise the code and post next webrev soon. > > Thanks > Yumin > > On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >> I believe there are both JavaTest/JTREG tests in the hotspot repo >> and there are VM/NSK tests from back when we did phone home... >> >> Check with Christian or Misha... >> >> Dan >> >> >> On 3/12/15 1:50 PM, Yumin Qi wrote: >>> Thanks, Dan >>> >>> Will look at and run those tests. Are they under nsk? >>> >>> Yumin >>> >>> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >>>> Yumin, >>>> >>>> There are some error handler tests. You should find those and make >>>> sure that you run them on Windows since you're changing the order >>>> there... >>>> >>>> Dan >>>> >>>> >>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>>> Hi, Thomas and all >>>>> >>>>> The second version of the change: >>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>>> >>>>> In this version: >>>>> 1) switch order on Windows to first print log file as other platform, then dump core file if needed. When VMError created after crash, siginfo and context which are ExceptionRecord and ContextRecord on Windows are recorded, mini (or full, due to 'or' used so type will be mini anyway) dump creates dump file based on those two as before. >>>>> 2) to make os::abort to get above two pointers, added two more fields to the function parameters: >>>>> 3) changes for test/runtime/ErrorHandling/SecondaryError.java --- added "-XX:-CreateCoredumpOnCrash" >>>>> >>>>> - static void abort(bool dump_core = true); >>>>> + static void abort(bool dump_core = true, void *siginfo = NULL, void *context = NULL); >>>>> >>>>> Tests: JPRT and manually. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>>>>> >>>>>> Beyond that, as I wrote in the bug report comments: >>>>>> >>>>>> "This is also a problem on Windows - MiniDumpWriteDump() may hang infinitly. And on Windows this is worse than under UNIX because we create the Dump before writing the hs-err file, so if the Dump hangs, we get no error log. I would like to revert the order: create the minidump after writing the error log, the same way Unix does it. We did this in our JVM (SAP) because for us, error logs are more useful than minidumps. " >>>>>> >>>>>> So, I would like to see os::abort on Windows call MiniDumpWriteDump(), and thus the mini dump writing moved after the error log writing. This would also make the code way cleaner because the control flow would be the same on all platforms. >>>>>> >>>>>> I understand that this may be out of scope for your change, but I would like to know what others think about this. >>>>>> >>>>>> Kind regards, Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi > wrote: >>>>>> >>>>>> Please review: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>>> >>>>>> >>>>>> Summary: Tests timed out when VM crashes and dumping core file >>>>>> which in the test case is not needed. To make core not created, >>>>>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>>>>> the former is only used on Windows and the latter for all >>>>>> platforms. When VM crashes on non Windows, core file generated as >>>>>> default if OS sets core dump allowed. Default value of >>>>>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>>>>> Windows platforms, but changed for Windows --- original is false, >>>>>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>>>>> off, no core file will be generated. CreateMinidumpOnCrash still >>>>>> can be used on commandline but only as alias for the new flag. >>>>>> >>>>>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>>>>> commandline to verify flag change as alias. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.stuefe at gmail.com Fri Mar 13 08:13:19 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 13 Mar 2015 09:13:19 +0100 Subject: inlining AllocateHeap() In-Reply-To: <55027832.8030203@oracle.com> References: <55027832.8030203@oracle.com> Message-ID: Hi Yasumasa, David, Maybe it would make sense to make the number-of-frames-to-skip-parameter configurable? Because the direct caller of AllocateHeap or os::malloc may also not be interesting but still a generic wrapper. So, the user doing the allocation trace could finetune this parameter to fit his needs. Thomas On Fri, Mar 13, 2015 at 6:40 AM, David Holmes wrote: > Hi Yasumasa, > > On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: > >> Hi all, >> >> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, but I got >> address at AllocateHeap() as malloc() caller. >> >> I checked symbol in libjvm.so in OracleJDK8u40 Linux >> x64, it has AllocateHeap() >> symbol. >> >> AllocateHeap() is defined as inline function, and it gives CURRENT_PC to >> os::malloc(). I guess that implementation expects AllocateHeap() will be >> inlined. >> > > It seems so. > > It may occur with GCC (g++) optimization only, however I want to fix it to >> analyze native memory with NMT on Linux. >> > > According to the docs [1]: > > "GCC does not inline any functions when not optimizing unless you specify > the ?always_inline? attribute for the function" > > I applied patch as below. This patch makes AllocateHeap() as inline >> function. >> -------------- >> diff -r af3b0db91659 src/share/vm/memory/allocation.inline.hpp >> --- a/src/share/vm/memory/allocation.inline.hpp Mon Mar 09 09:30:16 2015 >> -0700 >> +++ b/src/share/vm/memory/allocation.inline.hpp Thu Mar 12 20:45:57 2015 >> +0900 >> @@ -62,11 +62,18 @@ >> } >> return p; >> } >> + >> +#ifdef __GNUC__ >> +__attribute__((always_inline)) >> +#endif >> > > I dislike seeing the gcc specific directives in common code. I'm wondering > whether we should perhaps only use CURRENT_PC in product (and optimized?) > builds and use CALLER_PC otherwise. That would be imperfect of course It > also makes me wonder whether the inlining is occurring as expected on other > platforms. > > I'd like to get other people's views on this. > > Thanks, > David > > [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html > > > inline char* AllocateHeap(size_t size, MEMFLAGS flags, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); >> } >> >> +#ifdef __GNUC__ >> +__attribute__((always_inline)) >> +#endif >> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); >> -------------- >> >> If this patch is accepted, I will file it to JBS and will upload webrev. >> >> Thanks, >> >> Yasumasa >> >> From david.holmes at oracle.com Fri Mar 13 08:35:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Mar 2015 18:35:14 +1000 Subject: inlining AllocateHeap() In-Reply-To: References: <55027832.8030203@oracle.com> Message-ID: <5502A142.90403@oracle.com> On 13/03/2015 6:13 PM, Thomas St?fe wrote: > Hi Yasumasa, David, > > Maybe it would make sense to make the number-of-frames-to-skip-parameter > configurable? That would require more significant changes to NMT I think - plus I don't see how it will help if you have to know a-priori whether inlining has occurred or not. ?? Thanks, David > Because the direct caller of AllocateHeap or os::malloc may also not be > interesting but still a generic wrapper. So, the user doing the > allocation trace could finetune this parameter to fit his needs. > > Thomas > > > > On Fri, Mar 13, 2015 at 6:40 AM, David Holmes > wrote: > > Hi Yasumasa, > > On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to use NMT with details option on OpenJDK7 on RHEL6.6, > but I got > address at AllocateHeap() as malloc() caller. > > I checked symbol in libjvm.so in > OracleJDK8u40 Linux > x64, it has AllocateHeap() > symbol. > > AllocateHeap() is defined as inline function, and it gives > CURRENT_PC to > os::malloc(). I guess that implementation expects AllocateHeap() > will be > inlined. > > > It seems so. > > It may occur with GCC (g++) optimization only, however I want to > fix it to > analyze native memory with NMT on Linux. > > > According to the docs [1]: > > "GCC does not inline any functions when not optimizing unless you > specify the ?always_inline? attribute for the function" > > I applied patch as below. This patch makes AllocateHeap() as inline > function. > -------------- > diff -r af3b0db91659 src/share/vm/memory/__allocation.inline.hpp > --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 > 09:30:16 2015 > -0700 > +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 > 20:45:57 2015 > +0900 > @@ -62,11 +62,18 @@ > } > return p; > } > + > +#ifdef __GNUC__ > +__attribute__((always_inline)__) > +#endif > > > I dislike seeing the gcc specific directives in common code. I'm > wondering whether we should perhaps only use CURRENT_PC in product > (and optimized?) builds and use CALLER_PC otherwise. That would be > imperfect of course It also makes me wonder whether the inlining is > occurring as expected on other platforms. > > I'd like to get other people's views on this. > > Thanks, > David > > [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html > > > > inline char* AllocateHeap(size_t size, MEMFLAGS flags, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); > } > > +#ifdef __GNUC__ > +__attribute__((always_inline)__) > +#endif > inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, > AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { > char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); > -------------- > > If this patch is accepted, I will file it to JBS and will upload > webrev. > > Thanks, > > Yasumasa > > From roland.westrelin at oracle.com Fri Mar 13 09:43:23 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 13 Mar 2015 10:43:23 +0100 Subject: RFR(S): 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: <55022AB8.6020705@oracle.com> References: <55022AB8.6020705@oracle.com> Message-ID: <76A01490-93E7-412A-9A91-E2A809A4B108@oracle.com> > Fix looks correct. I CC to runtime group. They may know answers for your questions. Thanks for the review. We?ve been the ones making changes to dependencies.cpp for default methods, not sure the runtime team can help. I tried removing: // Disable CHA for default methods for now if (root_m->get_Method()->is_default_method()) { return NULL; } and the test case that comes with that change crashes. So it looks like it?s still needed. Roland. > > Thanks, > Vladimir > > On 3/12/15 6:31 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8069263/webrev.00/ >> >> In the test case, I1.m1() is a default method that is added by default methods processing to the list of default methods of class C2. The call at line 54 triggers CHA. It finds m1 in class C2 but with holder I1 as unique target. The assert fires because m1?s holder is not C2 but m1 is in the list of C2?s methods. >> >> I fixed this by returning no unique method in that case because: >> >> 1) we seem to still not expect that we can handle default methods properly in CHA even though we?ve added code in dependencies.cpp to support them. ciMethod::find_monomorphic_target) has this code: >> >> // Disable CHA for default methods for now >> if (root_m->get_Method()->is_default_method()) { >> return NULL; >> } >> >> Or maybe that code should be removed? >> >> 2) a proper fix would require that we record the method, its actual holder (C2) in the dependency which would require more extensive changes. I wonder if the extra complexity would make sense. >> >> Roland. >> >> From yasuenag at gmail.com Fri Mar 13 13:16:14 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 13 Mar 2015 22:16:14 +0900 Subject: inlining AllocateHeap() In-Reply-To: <5502A142.90403@oracle.com> References: <55027832.8030203@oracle.com> <5502A142.90403@oracle.com> Message-ID: <5502E31E.10005@gmail.com> Hi, > That would require more significant changes to NMT I think I think two changes: 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . I think that caller of AllocateHeap() and ReallocateHeap() should give PC to them. However, it is significant changes. Thus I proposed to add always_inline . > I don't see how it will help if you have to know a-priori whether inlining has occurred or not. ?? I think we can use SA. In case of Linux, sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() can lookup symbol from target process - we can check whether the function has been inlined (cannot lookup) or not (can lookup). So I think that we can write jtreg testcase. BTW, should I file it to JBS? Thanks, Yasumasa On 2015/03/13 17:35, David Holmes wrote: > On 13/03/2015 6:13 PM, Thomas St?fe wrote: >> Hi Yasumasa, David, >> >> Maybe it would make sense to make the number-of-frames-to-skip-parameter >> configurable? > > That would require more significant changes to NMT I think - plus I don't see how it will help if you have to know a-priori whether inlining has occurred or not. ?? > > Thanks, > David > >> Because the direct caller of AllocateHeap or os::malloc may also not be >> interesting but still a generic wrapper. So, the user doing the >> allocation trace could finetune this parameter to fit his needs. >> >> Thomas >> >> >> >> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes > > wrote: >> >> Hi Yasumasa, >> >> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, >> but I got >> address at AllocateHeap() as malloc() caller. >> >> I checked symbol in libjvm.so in >> OracleJDK8u40 Linux >> x64, it has AllocateHeap() >> symbol. >> >> AllocateHeap() is defined as inline function, and it gives >> CURRENT_PC to >> os::malloc(). I guess that implementation expects AllocateHeap() >> will be >> inlined. >> >> >> It seems so. >> >> It may occur with GCC (g++) optimization only, however I want to >> fix it to >> analyze native memory with NMT on Linux. >> >> >> According to the docs [1]: >> >> "GCC does not inline any functions when not optimizing unless you >> specify the ?always_inline? attribute for the function" >> >> I applied patch as below. This patch makes AllocateHeap() as inline >> function. >> -------------- >> diff -r af3b0db91659 src/share/vm/memory/__allocation.inline.hpp >> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 >> 09:30:16 2015 >> -0700 >> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 >> 20:45:57 2015 >> +0900 >> @@ -62,11 +62,18 @@ >> } >> return p; >> } >> + >> +#ifdef __GNUC__ >> +__attribute__((always_inline)__) >> +#endif >> >> >> I dislike seeing the gcc specific directives in common code. I'm >> wondering whether we should perhaps only use CURRENT_PC in product >> (and optimized?) builds and use CALLER_PC otherwise. That would be >> imperfect of course It also makes me wonder whether the inlining is >> occurring as expected on other platforms. >> >> I'd like to get other people's views on this. >> >> Thanks, >> David >> >> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >> >> >> >> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> return AllocateHeap(size, flags, CURRENT_PC, alloc_failmode); >> } >> >> +#ifdef __GNUC__ >> +__attribute__((always_inline)__) >> +#endif >> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, >> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM) { >> char* p = (char*) os::realloc(old, size, flag, CURRENT_PC); >> -------------- >> >> If this patch is accepted, I will file it to JBS and will upload >> webrev. >> >> Thanks, >> >> Yasumasa >> >> From daniel.daugherty at oracle.com Fri Mar 13 13:53:08 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 13 Mar 2015 07:53:08 -0600 Subject: RFR(S) Contended Locking fast exit bucket (8073165) In-Reply-To: <55026C81.4030207@oracle.com> References: <54FDD431.7010704@oracle.com> <55026C81.4030207@oracle.com> Message-ID: <5502EBC4.5040609@oracle.com> David, Thanks for the thorough review! It will take me some time to read through and address your comments so please look for another reply early next week. Dan On 3/12/15 10:50 PM, David Holmes wrote: > Hi Dan, > > Well that was fun ... :) > > On 10/03/2015 3:11 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have the Contended Locking fast exit bucket ready for review. >> >> The code changes in this bucket are primarily assembly language >> tweaks that come into play when an inflated ObjectMonitor is in >> use. There are tweaks that apply to the default code path and >> there are tweaks that only apply when an experimental flag is >> set. This code code review is focused on the default code path >> or the "out of the box" configuration. >> >> This work is being tracked by the following bug ID: >> >> JDK-8073165 Contended Locking fast exit bucket >> https://bugs.openjdk.java.net/browse/JDK-8073165 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8073165-webrev/0-jdk9-hs-rt/ >> >> Here is the JEP link: >> >> https://bugs.openjdk.java.net/browse/JDK-8046133 >> >> Testing: >> >> - Aurora Adhoc RT/SVC baseline batch >> - JPRT test jobs >> - MonitorExitStresser micro-benchmark (in process) >> - MonitorEnterExitStresser micro-benchmark (in process) >> - CallTimerGrid stress testing (in process) >> - Aurora performance testing: >> - out of the box for the "promotion" and 32-bit server configs >> - heavy weight monitors for the "promotion" and 32-bit server configs >> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors) >> (in process) >> >> >> 8073165 summary of changes: >> >> macroAssembler_sparc.cpp: MacroAssembler::compiler_unlock_object() >> >> - default (OOTB) EmitSync value == 0 >> - an _owner field optimization is in the non-default path under >> a (EmitSync & 1024) check >> >> - classic lock release without 1-0 support is in the non-default >> path under a (EmitSync & 512) check >> >> - an EntryList, cxq and _succ field optimization is in the >> non-default path under a (EmitSync & 16384) check >> >> - the default path is now the 1-0 form that avoids CAS and membar >> in the common case; see the "1-0 exit" section in objectMonitor.cpp > > I don't pretend that I could follow all these changes (I don't read > sparc very well) - the main thing of interest is the EmitSync==0 path > - everything else is just experimental (did you actually test to any > great extent with all these different possible EmitSync values?). > > So looking at the default path ... I could not figure out what logic > this (pre-existing) code is effecting: > > 3071 ld_ptr(Address(Rmark, > OM_OFFSET_NO_MONITOR_VALUE_TAG(recursions)), Rbox); > 3072 orcc(Rbox, G0, G0); > 3073 brx(Assembler::notZero, false, Assembler::pn, done); > > It seems to be a check for: > > if (recursions != 0) return; > > which would be fine except where is recursions decremented ?? > > But that aside the description seems reasonable. > >> sharedRuntime_sparc.cpp: >> >> - add JavaThread* param for >> SharedRuntime::complete_monitor_unlocking_C call > > Ok. > >> macroAssembler_x86.cpp: MacroAssembler::fast_unlock() >> >> - with all the new/modified comments and all the optional >> code path updates, it is hard to see that the only real >> changes to the default code path are 1) the _owner==Self >> check has been made optional and 2) the optional succ >> field check for the slow path is now on the default path >> >> - default (OOTB) EmitSync value == 0 >> - remove optional (EmitSync & 8) code >> - refactor code in MacroAssembler::fast_unlock >> - remove old mfence() support > > So I had expected to see this change conditional on the runtime > processor type. But then I checked Dave's blog and saw this was > determined 5+ years ago (!!!) so those older processors are no longer > a consideration. I do hope the performance tests have been re-run > since then though ;-) > >> - an _owner field optimization is in the non-default path under >> a (EmitSync & 1024) check > > Doesn't the comment: > > 2163 if (EmitSync & 1024) { > 2164 // Don't bother to ratify that m_Owner==Self > > apply to else part? > >> - an _owner field optimization is in the non-default path under >> a (EmitSync & 16) check >> - a barrier optimization is in the non-default path under a >> (EmitSync & 32) check >> - remove old AMD optional work around > > 2229 // box is really RAX -- the following CMPXCHG depends on > that binding > 2230 // cmpxchg R,[M] is equivalent to rax = CAS(M,rax,R) > 2231 > 2232 movptr(boxReg, (int32_t)NULL_WORD); // box is really RAX > > You've repeated the comment about box. > >> sharedRuntime_x86_32.cpp: >> sharedRuntime_x86_64.cpp: >> >> - add thread param for SharedRuntime::complete_monitor_unlocking_C >> call > > Ok. > >> macro.[ch]pp: PhaseMacroExpand::make_slow_call() >> >> - add param2 and update callers > > Ok. > >> runtime.[ch]pp: OptoRuntime::complete_monitor_exit_Type() >> >> - add JavaThread* parameter > > Ok > >> sharedRuntime.[ch]pp: SharedRuntime::complete_monitor_unlocking_C() >> >> - add JavaThread* parameter > > Ok. So all that passing through of the Thread was just to avoid a call > to JavaThread::current()? I thought that was already optimized to just > be a register load (at least on some platforms) ? > >> synchronizer.cpp: ObjectSynchronizer::omRelease() >> >> - cleanup in use list traversal >> - add assert that ObjectMonitor being released was >> actually found and extracted >> >> synchronizer.[ch]pp: >> >> - add some comments in various places >> - rename walk_monitor_list() -> deflate_monitor_list() >> and update callers >> - minor logic refactoring > > Generally okay. > > Minor nit: you changed inuse to "in use" but for the "inuse list" it > should really be "in-use list" (and not in-use-list as appears in a > couple of existing places) > > 1507 // if deflate_monitor succeeded,/moribund > > Not sure what that comment is supposed to mean :) > >> thread.hpp: >> >> - add _TSelf field for mfence() replacement > > Hmmmm, so we add a new pointer field to the Thread structure purely > for use on x86 if running with a particular experimental option set ? > That doesn't seem like it fits with our normal considerations for > space/time trade-offs. Maybe the xchg T,T->TSelf stuff should be under > a compile-flag instead? > >> >> Thanks, in advance, for any comments, questions or suggestions. > > Cheers, > David > >> Dan From aleksey.shipilev at oracle.com Fri Mar 13 14:05:25 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 13 Mar 2015 17:05:25 +0300 Subject: RFR(S) Contended Locking fast exit bucket (8073165) In-Reply-To: <55026C81.4030207@oracle.com> References: <54FDD431.7010704@oracle.com> <55026C81.4030207@oracle.com> Message-ID: <5502EEA5.4050202@oracle.com> On 03/13/2015 07:50 AM, David Holmes wrote: >> - remove old mfence() support > > So I had expected to see this change conditional on the runtime > processor type. But then I checked Dave's blog and saw this was > determined 5+ years ago (!!!) so those older processors are no longer a > consideration. I do hope the performance tests have been re-run since > then though ;-) MFENCE still has stronger ordering guarantees, and LOCK'ed instructions are faster for regular accesses. Note that we also observed the performance effects when doing blind "lock addl %(rsp), 0": https://bugs.openjdk.java.net/browse/JDK-8050147 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51e474c55d20 http://shipilev.net/blog/2014/on-the-fence-with-dependencies/ Thanks, -Aleksey. From daniel.daugherty at oracle.com Fri Mar 13 15:39:00 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 13 Mar 2015 09:39:00 -0600 Subject: RFR(S) Contended Locking fast exit bucket (8073165) In-Reply-To: <5502EEA5.4050202@oracle.com> References: <54FDD431.7010704@oracle.com> <55026C81.4030207@oracle.com> <5502EEA5.4050202@oracle.com> Message-ID: <55030494.3070709@oracle.com> Aleksey, Thanks for chiming in on the thread and for the links... I'll likely roll my reply to this e-mail up with my reply to David H early next week... Dan On 3/13/15 8:05 AM, Aleksey Shipilev wrote: > On 03/13/2015 07:50 AM, David Holmes wrote: >>> - remove old mfence() support >> So I had expected to see this change conditional on the runtime >> processor type. But then I checked Dave's blog and saw this was >> determined 5+ years ago (!!!) so those older processors are no longer a >> consideration. I do hope the performance tests have been re-run since >> then though ;-) > MFENCE still has stronger ordering guarantees, and LOCK'ed instructions > are faster for regular accesses. Note that we also observed the > performance effects when doing blind "lock addl %(rsp), 0": > https://bugs.openjdk.java.net/browse/JDK-8050147 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51e474c55d20 > http://shipilev.net/blog/2014/on-the-fence-with-dependencies/ > > Thanks, > -Aleksey. > From jeremymanson at google.com Fri Mar 13 17:00:35 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 13 Mar 2015 10:00:35 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <55022B6F.5090104@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> Message-ID: Thanks, David! New rev: http://cr.openjdk.java.net/~jmanson/8074895/webrev.01/ On Thu, Mar 12, 2015 at 5:12 PM, David Holmes wrote: > On 13/03/2015 6:31 AM, Jeremy Manson wrote: > >> On Wed, Mar 11, 2015 at 7:39 PM, David Holmes > > wrote: >> On 11/03/2015 7:08 AM, Jeremy Manson wrote: >> I'd like you to do a code review, please. Original discussion: >> >> http://mail.openjdk.java.net/__pipermail/serviceability-dev/ >> __2015-March/016851.html >> > 2015-March/016851.html> >> >> Per this discussion, I'm just getting rid of the os::getenv >> interface, and using straight getenv() everywhere. >> >> Bug: >> https://bugs.openjdk.java.net/__browse/JDK-8074895 >> >> >> Webrev: >> http://cr.openjdk.java.net/~__jmanson/8074895/webrev.00/ >> >> >> >> In arguments.cpp the headless property setting could have been left >> using a local buffer rather than introducing NEW_C_HEAP_ARRAY. The >> value should only be true or false so there's no size issue >> regarding the local buffer. >> >> >> Will do, but I won't bother with the rev until you tell me what to do >> with: >> >> 3566 if ((buffer = os::strdup(buffer)) == NULL) { >> 3567 return JNI_OK; >> 3568 } >> >> So this silently hides failures? >> >> >> Yes. Is there a best practice in Hotspot when you fail to allocate >> memory? I haven't noticed it, but I'm happy to, for example, die >> horribly. >> > > At this stage of the VM initialization we should be trying to be a good > citizen and simply return JNI_ENOMEM, which will eventually make its way > back to the caller of CreateJavaVM. > > Which also means your use of NEW_C_HEAP_ARRAY also needs changing as it > will abort the VM. You want to use NEW_C_HEAP_ARRAY_RETURN_NULL and if NULL > then return JNI_ENOMEM. > Done. > > The only minor concern I have is whether >> os::print_environment___variables is now susceptible to any issues >> caused by arbitrarily long environment variables? But I suspect >> there is already a maximum permitted length for environment variables. >> >> >> Which issues did you have in mind? I guess if you were printing to a >> string, the string would have to use extra memory. But the getenv() was >> being called anyway, so that's not much of an issue. >> > > I was wondering if an absurdly long environment variable value could > overflow some other internal buffer somewhere. Not sure why that would be different from the old approach, which also called getenv(), just underneath a layer of abstraction. I'm *trying* to do the right checking on everything above that, but I haven't run anything like valgrind to make sure. > Also you could now do the same for os::unsetenv :) >> >> Sadly, that really *does* seem undefined on Windows, AFAICT. >> > > Yeah they use _putenv with an empty value to remove the variable > Ah, well. Jeremy From yumin.qi at oracle.com Fri Mar 13 17:48:58 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 13 Mar 2015 10:48:58 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <5502439E.2080803@oracle.com> Message-ID: <5503230A.3040904@oracle.com> Staffan, I have changed the synopsis to: Make CreateMinidumpOnCrash a new name and available on all platforms and made some comment in description. Thanks Yumin On 3/13/2015 12:49 AM, Staffan Larsen wrote: > Yumin, > > I haven?t looked in detail at the changes, but it is a bit strange to do this changes under a bug that has to do with tests timing out. Would you mind filing a new bug for the changes to command line arguments and core/minidump handling? Or just change the Summary of the existing bug. > > Thanks, > /Staffan > >> On 13 mar 2015, at 02:55, Yumin Qi wrote: >> >> I have tested and without finding new problem, but I do find one problem on Windows: The output message is not right due to changes of >> >> check_or_create_dump => check_create_dump_limit : on Windows, it is empty, but it gets called in >> >> STEP(63, "(printing core file information)") >> >> So whatever the message is, it will be printed out here. >> >> The correct way is keeping the checking code in the function and the dump code in abort(). >> I will revise the code and post next webrev soon. >> >> Thanks >> Yumin >> >> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>> I believe there are both JavaTest/JTREG tests in the hotspot repo >>> and there are VM/NSK tests from back when we did phone home... >>> >>> Check with Christian or Misha... >>> >>> Dan >>> >>> >>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>>> Thanks, Dan >>>> >>>> Will look at and run those tests. Are they under nsk? >>>> >>>> Yumin >>>> >>>> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >>>>> Yumin, >>>>> >>>>> There are some error handler tests. You should find those and make >>>>> sure that you run them on Windows since you're changing the order >>>>> there... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>>>> Hi, Thomas and all >>>>>> >>>>>> The second version of the change: >>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>>>> >>>>>> In this version: >>>>>> 1) switch order on Windows to first print log file as other platform, then dump core file if needed. When VMError created after crash, siginfo and context which are ExceptionRecord and ContextRecord on Windows are recorded, mini (or full, due to 'or' used so type will be mini anyway) dump creates dump file based on those two as before. >>>>>> 2) to make os::abort to get above two pointers, added two more fields to the function parameters: >>>>>> 3) changes for test/runtime/ErrorHandling/SecondaryError.java --- added "-XX:-CreateCoredumpOnCrash" >>>>>> >>>>>> - static void abort(bool dump_core = true); >>>>>> + static void abort(bool dump_core = true, void *siginfo = NULL, void *context = NULL); >>>>>> >>>>>> Tests: JPRT and manually. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>>>>>> >>>>>>> Beyond that, as I wrote in the bug report comments: >>>>>>> >>>>>>> "This is also a problem on Windows - MiniDumpWriteDump() may hang infinitly. And on Windows this is worse than under UNIX because we create the Dump before writing the hs-err file, so if the Dump hangs, we get no error log. I would like to revert the order: create the minidump after writing the error log, the same way Unix does it. We did this in our JVM (SAP) because for us, error logs are more useful than minidumps." >>>>>>> >>>>>>> So, I would like to see os::abort on Windows call MiniDumpWriteDump(), and thus the mini dump writing moved after the error log writing. This would also make the code way cleaner because the control flow would be the same on all platforms. >>>>>>> >>>>>>> I understand that this may be out of scope for your change, but I would like to know what others think about this. >>>>>>> >>>>>>> Kind regards, Thomas >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi > wrote: >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>>>> >>>>>>> >>>>>>> Summary: Tests timed out when VM crashes and dumping core file >>>>>>> which in the test case is not needed. To make core not created, >>>>>>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>>>>>> the former is only used on Windows and the latter for all >>>>>>> platforms. When VM crashes on non Windows, core file generated as >>>>>>> default if OS sets core dump allowed. Default value of >>>>>>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>>>>>> Windows platforms, but changed for Windows --- original is false, >>>>>>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>>>>>> off, no core file will be generated. CreateMinidumpOnCrash still >>>>>>> can be used on commandline but only as alias for the new flag. >>>>>>> >>>>>>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>>>>>> commandline to verify flag change as alias. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> From harold.seigel at oracle.com Fri Mar 13 18:06:46 2015 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 13 Mar 2015 14:06:46 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file Message-ID: <55032736.90402@oracle.com> Hi, Please review this fix for bug JDK-7127066. The fix applies to astore* bytecodes because, when inside an exception handler, they can reference the thrown object and modify the number of stack locals, enabling the incorrect stack match. Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, java/lang, java/io, and java/util tests, and testbase quick and split verifier tests, and with the test case provided in the bug. Thanks! Harold From coleen.phillimore at oracle.com Fri Mar 13 23:29:55 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 Mar 2015 19:29:55 -0400 Subject: inlining AllocateHeap() In-Reply-To: <5502E31E.10005@gmail.com> References: <55027832.8030203@oracle.com> <5502A142.90403@oracle.com> <5502E31E.10005@gmail.com> Message-ID: <550372F3.3090701@oracle.com> There are other inline and noinline directives in allocation.hpp. We always assume that AllocateHeap and others are inlined. NMT is touchy with respect to how it walks the stack and it took a bit of work and testing to get just the most useful frames saved. I don't really want to risk this breaking! I think the gcc directive is acceptable in this case. Coleen On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: > Hi, > >> That would require more significant changes to NMT I think > > I think two changes: > > 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . > 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . > > I think that caller of AllocateHeap() and ReallocateHeap() should give > PC to them. > However, it is significant changes. > Thus I proposed to add always_inline . > > >> I don't see how it will help if you have to know a-priori whether >> inlining has occurred or not. ?? > > I think we can use SA. > In case of Linux, > sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() > can lookup symbol from target process - we can check whether the > function has been > inlined (cannot lookup) or not (can lookup). > So I think that we can write jtreg testcase. > > BTW, should I file it to JBS? > > > Thanks, > > Yasumasa > > > On 2015/03/13 17:35, David Holmes wrote: >> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>> Hi Yasumasa, David, >>> >>> Maybe it would make sense to make the >>> number-of-frames-to-skip-parameter >>> configurable? >> >> That would require more significant changes to NMT I think - plus I >> don't see how it will help if you have to know a-priori whether >> inlining has occurred or not. ?? >> >> Thanks, >> David >> >>> Because the direct caller of AllocateHeap or os::malloc may also not be >>> interesting but still a generic wrapper. So, the user doing the >>> allocation trace could finetune this parameter to fit his needs. >>> >>> Thomas >>> >>> >>> >>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >> > wrote: >>> >>> Hi Yasumasa, >>> >>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, >>> but I got >>> address at AllocateHeap() as malloc() caller. >>> >>> I checked symbol in libjvm.so in >>> OracleJDK8u40 Linux >>> x64, it has AllocateHeap() >>> symbol. >>> >>> AllocateHeap() is defined as inline function, and it gives >>> CURRENT_PC to >>> os::malloc(). I guess that implementation expects >>> AllocateHeap() >>> will be >>> inlined. >>> >>> >>> It seems so. >>> >>> It may occur with GCC (g++) optimization only, however I >>> want to >>> fix it to >>> analyze native memory with NMT on Linux. >>> >>> >>> According to the docs [1]: >>> >>> "GCC does not inline any functions when not optimizing unless you >>> specify the ?always_inline? attribute for the function" >>> >>> I applied patch as below. This patch makes AllocateHeap() as >>> inline >>> function. >>> -------------- >>> diff -r af3b0db91659 >>> src/share/vm/memory/__allocation.inline.hpp >>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 >>> 09:30:16 2015 >>> -0700 >>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 >>> 20:45:57 2015 >>> +0900 >>> @@ -62,11 +62,18 @@ >>> } >>> return p; >>> } >>> + >>> +#ifdef __GNUC__ >>> +__attribute__((always_inline)__) >>> +#endif >>> >>> >>> I dislike seeing the gcc specific directives in common code. I'm >>> wondering whether we should perhaps only use CURRENT_PC in product >>> (and optimized?) builds and use CALLER_PC otherwise. That would be >>> imperfect of course It also makes me wonder whether the inlining is >>> occurring as expected on other platforms. >>> >>> I'd like to get other people's views on this. >>> >>> Thanks, >>> David >>> >>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>> >>> >>> >>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>> AllocFailType alloc_failmode = >>> AllocFailStrategy::EXIT_OOM) { >>> return AllocateHeap(size, flags, CURRENT_PC, >>> alloc_failmode); >>> } >>> >>> +#ifdef __GNUC__ >>> +__attribute__((always_inline)__) >>> +#endif >>> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS >>> flag, >>> AllocFailType alloc_failmode = >>> AllocFailStrategy::EXIT_OOM) { >>> char* p = (char*) os::realloc(old, size, flag, >>> CURRENT_PC); >>> -------------- >>> >>> If this patch is accepted, I will file it to JBS and will >>> upload >>> webrev. >>> >>> Thanks, >>> >>> Yasumasa >>> >>> From david.holmes at oracle.com Mon Mar 16 00:44:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 10:44:43 +1000 Subject: inlining AllocateHeap() In-Reply-To: <550372F3.3090701@oracle.com> References: <55027832.8030203@oracle.com> <5502A142.90403@oracle.com> <5502E31E.10005@gmail.com> <550372F3.3090701@oracle.com> Message-ID: <5506277B.4000902@oracle.com> On 14/03/2015 9:29 AM, Coleen Phillimore wrote: > > There are other inline and noinline directives in allocation.hpp. We > always assume that AllocateHeap and others are inlined. NMT is touchy > with respect to how it walks the stack and it took a bit of work and > testing to get just the most useful frames saved. I don't really want > to risk this breaking! > > I think the gcc directive is acceptable in this case. Okay I'll follow Coleen's guidance on this. The original patch is fine. Yasumasa you will need to file a CR and you will need a sponsor to push your changeset through JPRT once you have created it. I can do the latter, just email me the final changeset directly. Thanks, David > Coleen > > > On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >> Hi, >> >>> That would require more significant changes to NMT I think >> >> I think two changes: >> >> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >> >> I think that caller of AllocateHeap() and ReallocateHeap() should give >> PC to them. >> However, it is significant changes. >> Thus I proposed to add always_inline . >> >> >>> I don't see how it will help if you have to know a-priori whether >>> inlining has occurred or not. ?? >> >> I think we can use SA. >> In case of Linux, >> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >> can lookup symbol from target process - we can check whether the >> function has been >> inlined (cannot lookup) or not (can lookup). >> So I think that we can write jtreg testcase. >> >> BTW, should I file it to JBS? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/03/13 17:35, David Holmes wrote: >>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>> Hi Yasumasa, David, >>>> >>>> Maybe it would make sense to make the >>>> number-of-frames-to-skip-parameter >>>> configurable? >>> >>> That would require more significant changes to NMT I think - plus I >>> don't see how it will help if you have to know a-priori whether >>> inlining has occurred or not. ?? >>> >>> Thanks, >>> David >>> >>>> Because the direct caller of AllocateHeap or os::malloc may also not be >>>> interesting but still a generic wrapper. So, the user doing the >>>> allocation trace could finetune this parameter to fit his needs. >>>> >>>> Thomas >>>> >>>> >>>> >>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>> > wrote: >>>> >>>> Hi Yasumasa, >>>> >>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, >>>> but I got >>>> address at AllocateHeap() as malloc() caller. >>>> >>>> I checked symbol in libjvm.so in >>>> OracleJDK8u40 Linux >>>> x64, it has AllocateHeap() >>>> symbol. >>>> >>>> AllocateHeap() is defined as inline function, and it gives >>>> CURRENT_PC to >>>> os::malloc(). I guess that implementation expects >>>> AllocateHeap() >>>> will be >>>> inlined. >>>> >>>> >>>> It seems so. >>>> >>>> It may occur with GCC (g++) optimization only, however I >>>> want to >>>> fix it to >>>> analyze native memory with NMT on Linux. >>>> >>>> >>>> According to the docs [1]: >>>> >>>> "GCC does not inline any functions when not optimizing unless you >>>> specify the ?always_inline? attribute for the function" >>>> >>>> I applied patch as below. This patch makes AllocateHeap() as >>>> inline >>>> function. >>>> -------------- >>>> diff -r af3b0db91659 >>>> src/share/vm/memory/__allocation.inline.hpp >>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 >>>> 09:30:16 2015 >>>> -0700 >>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 >>>> 20:45:57 2015 >>>> +0900 >>>> @@ -62,11 +62,18 @@ >>>> } >>>> return p; >>>> } >>>> + >>>> +#ifdef __GNUC__ >>>> +__attribute__((always_inline)__) >>>> +#endif >>>> >>>> >>>> I dislike seeing the gcc specific directives in common code. I'm >>>> wondering whether we should perhaps only use CURRENT_PC in product >>>> (and optimized?) builds and use CALLER_PC otherwise. That would be >>>> imperfect of course It also makes me wonder whether the inlining is >>>> occurring as expected on other platforms. >>>> >>>> I'd like to get other people's views on this. >>>> >>>> Thanks, >>>> David >>>> >>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>> >>>> >>>> >>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>> AllocFailType alloc_failmode = >>>> AllocFailStrategy::EXIT_OOM) { >>>> return AllocateHeap(size, flags, CURRENT_PC, >>>> alloc_failmode); >>>> } >>>> >>>> +#ifdef __GNUC__ >>>> +__attribute__((always_inline)__) >>>> +#endif >>>> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS >>>> flag, >>>> AllocFailType alloc_failmode = >>>> AllocFailStrategy::EXIT_OOM) { >>>> char* p = (char*) os::realloc(old, size, flag, >>>> CURRENT_PC); >>>> -------------- >>>> >>>> If this patch is accepted, I will file it to JBS and will >>>> upload >>>> webrev. >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> > From david.holmes at oracle.com Mon Mar 16 00:58:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 10:58:59 +1000 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <55032736.90402@oracle.com> References: <55032736.90402@oracle.com> Message-ID: <55062AD3.4030506@oracle.com> Hi Harold, On 14/03/2015 4:06 AM, harold seigel wrote: > Hi, > > Please review this fix for bug JDK-7127066. The fix applies to astore* > bytecodes because, when inside an exception handler, they can reference > the thrown object and modify the number of stack locals, enabling the > incorrect stack match. > > Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 > > The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, > java/lang, java/io, and java/util tests, and testbase quick and split > verifier tests, and with the test case provided in the bug. The new check looks okay, though I can't verify the exact placement of it. Thanks, David > > Thanks! Harold From david.holmes at oracle.com Mon Mar 16 05:04:28 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 15:04:28 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> Message-ID: <5506645C.4050201@oracle.com> Hi Jeremy, On 14/03/2015 3:00 AM, Jeremy Manson wrote: > Thanks, David! New rev: > > http://cr.openjdk.java.net/~jmanson/8074895/webrev.01/ Looks good. Please update copyright dates in memTracker.cpp and vmError.cpp. Further response below ... > On Thu, Mar 12, 2015 at 5:12 PM, David Holmes > wrote: > > On 13/03/2015 6:31 AM, Jeremy Manson wrote: > > On Wed, Mar 11, 2015 at 7:39 PM, David Holmes > > >> wrote: > On 11/03/2015 7:08 AM, Jeremy Manson wrote: > I'd like you to do a code review, please. Original > discussion: > > http://mail.openjdk.java.net/____pipermail/serviceability-dev/____2015-March/016851.html > > > > > > Per this discussion, I'm just getting rid of the os::getenv > interface, and using straight getenv() everywhere. > > Bug: > https://bugs.openjdk.java.net/____browse/JDK-8074895 > > > > > Webrev: > http://cr.openjdk.java.net/~____jmanson/8074895/webrev.00/ > > > > > > > In arguments.cpp the headless property setting could have > been left > using a local buffer rather than introducing > NEW_C_HEAP_ARRAY. The > value should only be true or false so there's no size issue > regarding the local buffer. > > > Will do, but I won't bother with the rev until you tell me what > to do with: > > 3566 if ((buffer = os::strdup(buffer)) == NULL) { > 3567 return JNI_OK; > 3568 } > > So this silently hides failures? > > > Yes. Is there a best practice in Hotspot when you fail to allocate > memory? I haven't noticed it, but I'm happy to, for example, > die horribly. > > > At this stage of the VM initialization we should be trying to be a > good citizen and simply return JNI_ENOMEM, which will eventually > make its way back to the caller of CreateJavaVM. > > Which also means your use of NEW_C_HEAP_ARRAY also needs changing as > it will abort the VM. You want to use NEW_C_HEAP_ARRAY_RETURN_NULL > and if NULL then return JNI_ENOMEM. > > > Done. > > > The only minor concern I have is whether > os::print_environment_____variables is now susceptible to > any issues > caused by arbitrarily long environment variables? But I suspect > there is already a maximum permitted length for environment > variables. > > > Which issues did you have in mind? I guess if you were printing > to a > string, the string would have to use extra memory. But the > getenv() was > being called anyway, so that's not much of an issue. > > > I was wondering if an absurdly long environment variable value could > overflow some other internal buffer somewhere. > > > Not sure why that would be different from the old approach, which also > called getenv(), just underneath a layer of abstraction. I'm *trying* > to do the right checking on everything above that, but I haven't run > anything like valgrind to make sure. The old approach limited the size of anything that getenv returned before passing it further into the VM. The new approach doesn't. But following through the code to see how the variables get used I can't see anything that makes any assumptions about the potential length of the variable's value. So this looks okay. Thanks, David > > Also you could now do the same for os::unsetenv :) > > Sadly, that really *does* seem undefined on Windows, AFAICT. > > > Yeah they use _putenv with an empty value to remove the variable > > > Ah, well. > > Jeremy From dmitry.samersoff at oracle.com Mon Mar 16 07:25:10 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 16 Mar 2015 10:25:10 +0300 Subject: inlining AllocateHeap() In-Reply-To: <5506277B.4000902@oracle.com> References: <55027832.8030203@oracle.com> <5502A142.90403@oracle.com> <5502E31E.10005@gmail.com> <550372F3.3090701@oracle.com> <5506277B.4000902@oracle.com> Message-ID: <55068556.1010908@oracle.com> David, There are many cases when we might need compiler pragmas (e.g. to suppress warnings) So It might be a time to develop more generic solution rather than muddle a code with pragma-related ifdefs. *Can we create something like compiler_pragmas.hpp* and put there #define ALWAYS_INLINE() #ifdef __GNUC__ #undef ALWAYS_INLINE #define ALWAYS_INLINE() __attribute__((always_inline)) #endif etc. than use ALWAYS_INLINE in the code when necessary. -Dmitry On 2015-03-16 03:44, David Holmes wrote: > On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >> >> There are other inline and noinline directives in allocation.hpp. We >> always assume that AllocateHeap and others are inlined. NMT is touchy >> with respect to how it walks the stack and it took a bit of work and >> testing to get just the most useful frames saved. I don't really want >> to risk this breaking! >> >> I think the gcc directive is acceptable in this case. > > Okay I'll follow Coleen's guidance on this. The original patch is fine. > > Yasumasa you will need to file a CR and you will need a sponsor to push > your changeset through JPRT once you have created it. I can do the > latter, just email me the final changeset directly. > > Thanks, > David > >> Coleen >> >> >> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>> Hi, >>> >>>> That would require more significant changes to NMT I think >>> >>> I think two changes: >>> >>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>> >>> I think that caller of AllocateHeap() and ReallocateHeap() should give >>> PC to them. >>> However, it is significant changes. >>> Thus I proposed to add always_inline . >>> >>> >>>> I don't see how it will help if you have to know a-priori whether >>>> inlining has occurred or not. ?? >>> >>> I think we can use SA. >>> In case of Linux, >>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>> can lookup symbol from target process - we can check whether the >>> function has been >>> inlined (cannot lookup) or not (can lookup). >>> So I think that we can write jtreg testcase. >>> >>> BTW, should I file it to JBS? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/03/13 17:35, David Holmes wrote: >>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>> Hi Yasumasa, David, >>>>> >>>>> Maybe it would make sense to make the >>>>> number-of-frames-to-skip-parameter >>>>> configurable? >>>> >>>> That would require more significant changes to NMT I think - plus I >>>> don't see how it will help if you have to know a-priori whether >>>> inlining has occurred or not. ?? >>>> >>>> Thanks, >>>> David >>>> >>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>> not be >>>>> interesting but still a generic wrapper. So, the user doing the >>>>> allocation trace could finetune this parameter to fit his needs. >>>>> >>>>> Thomas >>>>> >>>>> >>>>> >>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>> > wrote: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, >>>>> but I got >>>>> address at AllocateHeap() as malloc() caller. >>>>> >>>>> I checked symbol in libjvm.so in >>>>> OracleJDK8u40 Linux >>>>> x64, it has AllocateHeap() >>>>> symbol. >>>>> >>>>> AllocateHeap() is defined as inline function, and it gives >>>>> CURRENT_PC to >>>>> os::malloc(). I guess that implementation expects >>>>> AllocateHeap() >>>>> will be >>>>> inlined. >>>>> >>>>> >>>>> It seems so. >>>>> >>>>> It may occur with GCC (g++) optimization only, however I >>>>> want to >>>>> fix it to >>>>> analyze native memory with NMT on Linux. >>>>> >>>>> >>>>> According to the docs [1]: >>>>> >>>>> "GCC does not inline any functions when not optimizing unless you >>>>> specify the ?always_inline? attribute for the function" >>>>> >>>>> I applied patch as below. This patch makes AllocateHeap() as >>>>> inline >>>>> function. >>>>> -------------- >>>>> diff -r af3b0db91659 >>>>> src/share/vm/memory/__allocation.inline.hpp >>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 >>>>> 09:30:16 2015 >>>>> -0700 >>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 >>>>> 20:45:57 2015 >>>>> +0900 >>>>> @@ -62,11 +62,18 @@ >>>>> } >>>>> return p; >>>>> } >>>>> + >>>>> +#ifdef __GNUC__ >>>>> +__attribute__((always_inline)__) >>>>> +#endif >>>>> >>>>> >>>>> I dislike seeing the gcc specific directives in common code. I'm >>>>> wondering whether we should perhaps only use CURRENT_PC in product >>>>> (and optimized?) builds and use CALLER_PC otherwise. That would be >>>>> imperfect of course It also makes me wonder whether the >>>>> inlining is >>>>> occurring as expected on other platforms. >>>>> >>>>> I'd like to get other people's views on this. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>> >>>>> >>>>> >>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>> AllocFailType alloc_failmode = >>>>> AllocFailStrategy::EXIT_OOM) { >>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>> alloc_failmode); >>>>> } >>>>> >>>>> +#ifdef __GNUC__ >>>>> +__attribute__((always_inline)__) >>>>> +#endif >>>>> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS >>>>> flag, >>>>> AllocFailType alloc_failmode = >>>>> AllocFailStrategy::EXIT_OOM) { >>>>> char* p = (char*) os::realloc(old, size, flag, >>>>> CURRENT_PC); >>>>> -------------- >>>>> >>>>> If this patch is accepted, I will file it to JBS and will >>>>> upload >>>>> webrev. >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >> -- 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 Mon Mar 16 07:32:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Mar 2015 17:32:16 +1000 Subject: inlining AllocateHeap() In-Reply-To: <55068556.1010908@oracle.com> References: <55027832.8030203@oracle.com> <5502A142.90403@oracle.com> <5502E31E.10005@gmail.com> <550372F3.3090701@oracle.com> <5506277B.4000902@oracle.com> <55068556.1010908@oracle.com> Message-ID: <55068700.2090401@oracle.com> Hi Dmitry, On 16/03/2015 5:25 PM, Dmitry Samersoff wrote: > David, > > There are many cases when we might need compiler pragmas (e.g. to > suppress warnings) > > So It might be a time to develop more generic solution rather than > muddle a code with pragma-related ifdefs. > > *Can we create something like compiler_pragmas.hpp* > > and put there > > #define ALWAYS_INLINE() > > #ifdef __GNUC__ > #undef ALWAYS_INLINE > #define ALWAYS_INLINE() __attribute__((always_inline)) > #endif > > etc. > > than use ALWAYS_INLINE in the code when necessary. Perhaps, but that seems a clear project in and of itself that would need to be resourced and prioritized (are you volunteering? :) ) It might be suitable for inclusion in the ./share/vm/utilities/globalDefinitions_.hpp headers. David > -Dmitry > > > > > On 2015-03-16 03:44, David Holmes wrote: >> On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >>> >>> There are other inline and noinline directives in allocation.hpp. We >>> always assume that AllocateHeap and others are inlined. NMT is touchy >>> with respect to how it walks the stack and it took a bit of work and >>> testing to get just the most useful frames saved. I don't really want >>> to risk this breaking! >>> >>> I think the gcc directive is acceptable in this case. >> >> Okay I'll follow Coleen's guidance on this. The original patch is fine. >> >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. >> >> Thanks, >> David >> >>> Coleen >>> >>> >>> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>>> That would require more significant changes to NMT I think >>>> >>>> I think two changes: >>>> >>>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>>> >>>> I think that caller of AllocateHeap() and ReallocateHeap() should give >>>> PC to them. >>>> However, it is significant changes. >>>> Thus I proposed to add always_inline . >>>> >>>> >>>>> I don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>> >>>> I think we can use SA. >>>> In case of Linux, >>>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>>> can lookup symbol from target process - we can check whether the >>>> function has been >>>> inlined (cannot lookup) or not (can lookup). >>>> So I think that we can write jtreg testcase. >>>> >>>> BTW, should I file it to JBS? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/03/13 17:35, David Holmes wrote: >>>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>>> Hi Yasumasa, David, >>>>>> >>>>>> Maybe it would make sense to make the >>>>>> number-of-frames-to-skip-parameter >>>>>> configurable? >>>>> >>>>> That would require more significant changes to NMT I think - plus I >>>>> don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>>> not be >>>>>> interesting but still a generic wrapper. So, the user doing the >>>>>> allocation trace could finetune this parameter to fit his needs. >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>>> > wrote: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I tried to use NMT with details option on OpenJDK7 on RHEL6.6, >>>>>> but I got >>>>>> address at AllocateHeap() as malloc() caller. >>>>>> >>>>>> I checked symbol in libjvm.so in >>>>>> OracleJDK8u40 Linux >>>>>> x64, it has AllocateHeap() >>>>>> symbol. >>>>>> >>>>>> AllocateHeap() is defined as inline function, and it gives >>>>>> CURRENT_PC to >>>>>> os::malloc(). I guess that implementation expects >>>>>> AllocateHeap() >>>>>> will be >>>>>> inlined. >>>>>> >>>>>> >>>>>> It seems so. >>>>>> >>>>>> It may occur with GCC (g++) optimization only, however I >>>>>> want to >>>>>> fix it to >>>>>> analyze native memory with NMT on Linux. >>>>>> >>>>>> >>>>>> According to the docs [1]: >>>>>> >>>>>> "GCC does not inline any functions when not optimizing unless you >>>>>> specify the ?always_inline? attribute for the function" >>>>>> >>>>>> I applied patch as below. This patch makes AllocateHeap() as >>>>>> inline >>>>>> function. >>>>>> -------------- >>>>>> diff -r af3b0db91659 >>>>>> src/share/vm/memory/__allocation.inline.hpp >>>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar 09 >>>>>> 09:30:16 2015 >>>>>> -0700 >>>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar 12 >>>>>> 20:45:57 2015 >>>>>> +0900 >>>>>> @@ -62,11 +62,18 @@ >>>>>> } >>>>>> return p; >>>>>> } >>>>>> + >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> >>>>>> >>>>>> I dislike seeing the gcc specific directives in common code. I'm >>>>>> wondering whether we should perhaps only use CURRENT_PC in product >>>>>> (and optimized?) builds and use CALLER_PC otherwise. That would be >>>>>> imperfect of course It also makes me wonder whether the >>>>>> inlining is >>>>>> occurring as expected on other platforms. >>>>>> >>>>>> I'd like to get other people's views on this. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>>> >>>>>> >>>>>> >>>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>>> alloc_failmode); >>>>>> } >>>>>> >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> inline char* ReallocateHeap(char *old, size_t size, MEMFLAGS >>>>>> flag, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> char* p = (char*) os::realloc(old, size, flag, >>>>>> CURRENT_PC); >>>>>> -------------- >>>>>> >>>>>> If this patch is accepted, I will file it to JBS and will >>>>>> upload >>>>>> webrev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>> > > From thomas.stuefe at gmail.com Mon Mar 16 11:31:57 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 16 Mar 2015 12:31:57 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: <55015F5A.60507@oracle.com> References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> Message-ID: Hi, I still need one or two reviewers and a sponsor. Thank you! Thomas On Thu, Mar 12, 2015 at 10:41 AM, David Holmes wrote: > Hi Thomas, > > Thanks for the added info. I have no further comments. Hopefully someone > with SEH knowledge will also respond. > > David > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: > >> Hi David, >> >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes > > wrote: >> >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: >> >> Hi David, >> >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >> >> > >> >> wrote: >> >> Hi Thomas, >> >> I'm not really familiar with Windows SEH. Won't this break >> custom >> launchers that already provide their own try/catch around >> Crate_JavaVM ? >> >> >> No. Windows SEH works stack based: any exception - e.g. a crash - >> between __try and __except will be handled by the handler given >> in the >> __except clause. Because they are stack based, they can be >> nested. If an >> exception is raised inside the inner __try/__except, first the >> inner >> handler is used, if that one feels not responsible, the next >> outer one >> and so on. >> >> With my fix, any exception raised inside CreateJavaVM will be >> handler by >> our handler topLevelExceptionFilter; only if our handler feels not >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >> handler will >> be called. >> >> >> My lack of knowledge about when our handler "feels responsible" >> still leaves me a little nervous here. :) >> >> >> I think the patch is quite safe. I added this patch to our code base in >> 2011 and since then this is active in productive code for SAP customers. >> The SAP jvm gets heavily used with custom launchers which do their own >> error handling, so this is a well tested scenario. >> >> I would like to get a similar signal handling coverage as on UNIX: >> >> On Unix, we have global signal handling. The moment signal handling is >> established early in os::init(), every signal from everywhere is >> covered, even user code. We even have to take care that user handlers >> get also in the loop via signal chaining, libjsig.so etc. >> >> On Windows, it is the other way around: we have stack based signal >> handling , so we need __try/__except on every thread, and this means >> there are parts of jvm code which run without signal handling: >> - the whole initialization >> - attached threads (I think?) >> which means that on those cases, user handler gets signals which the >> libjvm should handle. >> >> This was "fixed" partly by surrounding small code which we know >> beforehand causes signals - how convenient - with __try/__except. For >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >> crash. But you want error handling to always work. I also do not know if >> stuff like polling pages, implicit nulltests etc could be used in >> unprotected code. >> >> As a side note, there is a UNIX-like signal handling mode on Windows >> too, "vectored exception handling", which was used in the jvm but >> removed some time ago for reasons I do not really know. >> >> Any exception raised in the launcher itself outside of >> CreateJavaVM will >> still be handled by the user handler. >> >> (And I hate seeing the win32 ifdefs in the shared code :( ). >> >> >> Yes I know, I kind of expected that feedback :( - I did not find a >> better way of doing this. One could try to hide the __try/__except >> behind macros, but that would be kind of unwieldy and I don't like >> abstractiing something which only has meaning on one platform. >> >> >> Does it help if we make the caller responsible for SEH and then put >> the try/catch in the launcher code (hopefully in a windows specific >> part thereof) ? >> >> >> No, because the caller would need access to "topLevelExceptionFilter" - >> you would need to export that function from the libjvm and then tell the >> caller "always call topLevelExceptionFilter() if a signal happens on >> Windows", which is quite awkward and different than on UNIX. >> >> Thomas >> >> Thanks, >> David >> >> >> Thanks, >> David >> >> >> >> Kind regards, Thomas >> >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please review this smallish change: >> >> webrev: >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >> webrev.____01/webrev/ >> > webrev.__01/webrev/> >> >> > webrev.__01/webrev/ >> > 01/webrev/>> >> bug: >> https://bugs.openjdk.java.net/____browse/JDK-8074860 >> >> >> > >> > >> >> This change adds SEH guards around JNI_CreateJavaVM(). >> Without >> the change, >> on Windows, the VM initialization runs without crash >> protection: >> crashes >> will terminate VM immediately without writing an error >> log; >> also, any >> techniques relying on signals will not work, e.g. >> SafeFetch(). >> >> This was partly solved before on a case-by-case base by >> wrapping >> code >> sections which may crash in their own __try/__except >> wrappers - >> e.g. CPU >> feature probing. >> >> The change guards the whole of JNI_CreateJavaVM >> invocation in >> __try/__except. Unfortunately, for that to compile, I >> needed to >> introduce a >> wrapper around JNI_CreateJavaVM and move the whole of >> JNI_CreateJavaVM to a >> new function "JNI_CreateJavaVM_inner". >> >> This fix also gets rid of various workarounds which >> were used >> before to >> guard code sections. >> >> Thanks for reviewing! >> >> Oh, on a side note: I tried to figure out if threads >> which are >> attached >> from the outside via JNI AttachCurrentThread() are in >> any way >> guarded with >> SEH protection. Newly created threads are guarded >> because they >> run thru >> java_start() in os_windows.cpp, which adds SEH guards >> to all >> frames below. >> But for attached threads, I did not find any SEH guards >> - or >> maybe I am >> blind? What does that mean for java code running inside >> attached >> threads? >> >> Regards, >> >> Thomas Stuefe >> >> >> >> From thomas.stuefe at gmail.com Mon Mar 16 11:32:43 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 16 Mar 2015 12:32:43 +0100 Subject: RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time In-Reply-To: <11E1660C-0038-4297-92EC-2B1F41C973C6@oracle.com> References: <11E1660C-0038-4297-92EC-2B1F41C973C6@oracle.com> Message-ID: Hi all, still need a second reviewer and also a sponsor. Thanks! Thomas On Thu, Mar 12, 2015 at 1:58 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > > On 12 mar 2015, at 13:50, Thomas St?fe wrote: > > > > Hi all, > > > > please take a look at this tiny change: > > > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8075044/webrev.01/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8075044 > > > > This changes the version number query for dbghelp.dll from a compile time > > check to a run time check. > > > > Thanks! > > > > Thomas Stuefe > > From harold.seigel at oracle.com Mon Mar 16 18:48:02 2015 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 16 Mar 2015 14:48:02 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <55062AD3.4030506@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> Message-ID: <55072562.90800@oracle.com> Hi David, Thanks for the review! Harold On 3/15/2015 8:58 PM, David Holmes wrote: > Hi Harold, > On 14/03/2015 4:06 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for bug JDK-7127066. The fix applies to astore* >> bytecodes because, when inside an exception handler, they can reference >> the thrown object and modify the number of stack locals, enabling the >> incorrect stack match. >> >> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >> >> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >> java/lang, java/io, and java/util tests, and testbase quick and split >> verifier tests, and with the test case provided in the bug. > > The new check looks okay, though I can't verify the exact placement of > it. > > Thanks, > David > >> >> Thanks! Harold From markus.gronlund at oracle.com Mon Mar 16 19:04:04 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 16 Mar 2015 12:04:04 -0700 (PDT) Subject: RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time In-Reply-To: References: <11E1660C-0038-4297-92EC-2B1F41C973C6@oracle.com> Message-ID: Hi Thomas, I am a bit worried about the changes from the API_VERSION constant which is defined in ImageHlp.h as: #define API_VERSION_NUMBER 11 to using the runtime values returned in the API_VERSION struct from calling dbghelp::ImagehlpApiVersion() without any conversions: This is what I get on my laptop (win7 x86 /32-bit) dbghelp::ImagehlpApiVersion() // function pointer via C:\Windows\System32\dbghelp.dll (some old version: 6.1.7061.17514): +0x000 MajorVersion : 4 +0x002 MinorVersion : 0 +0x004 Revision : 5 +0x006 Reserved : 0 I thought this might be due to the fact of an older version of dbghelp.dll - I therefore set the function pointer to the Windows SDK 8.1 version of dbghelp.dll (6.3.9600.16384): +0x000 MajorVersion : 4 +0x002 MinorVersion : 0 +0x004 Revision : 5 +0x006 Reserved : 0 Same data. I also queried Imagehlp.dll (6.1.7601.18288) using the same API: +0x000 MajorVersion : 4 +0x002 MinorVersion : 0 +0x004 Revision : 5 +0x006 Reserved : 0 I am not sure if "MajorVersion == 4" is the same as / should be interpreted the same as "#define API_VERSION_NUMBER 11" ? In any case, only looking at the MajorVersion number returned with no adaptation changes behavior: // Older versions of dbghelp.h doesn't contain all the dumptypes we want, dbghelp.h with // API_VERSION_NUMBER 11 or higher contains the ones we want though if (version->MajorVersion >= 11) { dumpType = (MINIDUMP_TYPE)(dumpType | MiniDumpWithFullMemoryInfo | MiniDumpWithThreadInfo | MiniDumpWithUnloadedModules); } I previously go the 11 from the constant, but now as I described above, I am getting 4, and therefore, less information in the .mdmp. Are you pulling out a 11 from MajorVersion? /Markus -----Original Message----- From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: den 16 mars 2015 12:33 To: Staffan Larsen Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time Hi all, still need a second reviewer and also a sponsor. Thanks! Thomas On Thu, Mar 12, 2015 at 1:58 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > > On 12 mar 2015, at 13:50, Thomas St?fe wrote: > > > > Hi all, > > > > please take a look at this tiny change: > > > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8075044/webrev.01/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8075044 > > > > This changes the version number query for dbghelp.dll from a compile > > time check to a run time check. > > > > Thanks! > > > > Thomas Stuefe > > From karen.kinnear at oracle.com Mon Mar 16 19:49:45 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 16 Mar 2015 15:49:45 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <55062AD3.4030506@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> Message-ID: Harold, Thanks for helping me walk through this in more detail. The way I read this, the fix would apply to all bytecodes - except for invokespecial - which is handled I believe correctly inside the verify_invoke_init. So if you could possibly experiment with some additional instructions - I suspect you can make a conditional check where you put the beginning check and remove the check at the end. thanks, Karen On Mar 15, 2015, at 8:58 PM, David Holmes wrote: > Hi Harold, > On 14/03/2015 4:06 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for bug JDK-7127066. The fix applies to astore* >> bytecodes because, when inside an exception handler, they can reference >> the thrown object and modify the number of stack locals, enabling the >> incorrect stack match. >> >> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >> >> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >> java/lang, java/io, and java/util tests, and testbase quick and split >> verifier tests, and with the test case provided in the bug. > > The new check looks okay, though I can't verify the exact placement of it. > > Thanks, > David > >> >> Thanks! Harold From harold.seigel at oracle.com Mon Mar 16 21:26:08 2015 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 16 Mar 2015 17:26:08 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> Message-ID: <55074A70.7040200@oracle.com> Hi Karen, Thanks for reviewing this. I'll look into other bytecodes and let you know what I find out. Harold On 3/16/2015 3:49 PM, Karen Kinnear wrote: > Harold, > > Thanks for helping me walk through this in more detail. > > The way I read this, the fix would apply to all bytecodes - except for > invokespecial - which is handled I believe correctly inside the > verify_invoke_init. > > So if you could possibly experiment with some additional instructions - I suspect > you can make a conditional check where you put the beginning check and remove > the check at the end. > > thanks, > Karen > > On Mar 15, 2015, at 8:58 PM, David Holmes wrote: > >> Hi Harold, >> On 14/03/2015 4:06 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for bug JDK-7127066. The fix applies to astore* >>> bytecodes because, when inside an exception handler, they can reference >>> the thrown object and modify the number of stack locals, enabling the >>> incorrect stack match. >>> >>> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>> >>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>> java/lang, java/io, and java/util tests, and testbase quick and split >>> verifier tests, and with the test case provided in the bug. >> The new check looks okay, though I can't verify the exact placement of it. >> >> Thanks, >> David >> >>> Thanks! Harold From yumin.qi at oracle.com Tue Mar 17 01:04:23 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 16 Mar 2015 18:04:23 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5501F017.1000900@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> Message-ID: <55077D97.2070402@oracle.com> Hi, Dan and all I have updated webrev at: http://cr.openjdk.java.net/~minqi/8074354/webrev03/ 1) bug changed synopsis 8074354: Make CreateMinidumpOnCrash a new name and available on all platforms 2) tests: JPRT, vm.runtime.quick.testlist (on Windows), jtreg on Windows and Linux/Unix. Thanks Yumin On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: > I believe there are both JavaTest/JTREG tests in the hotspot repo > and there are VM/NSK tests from back when we did phone home... > > Check with Christian or Misha... > > Dan > > > On 3/12/15 1:50 PM, Yumin Qi wrote: >> Thanks, Dan >> >> Will look at and run those tests. Are they under nsk? >> >> Yumin >> >> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >>> Yumin, >>> >>> There are some error handler tests. You should find those and make >>> sure that you run them on Windows since you're changing the order >>> there... >>> >>> Dan >>> >>> >>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>> Hi, Thomas and all >>>> >>>> The second version of the change: >>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>> >>>> In this version: >>>> 1) switch order on Windows to first print log file as other >>>> platform, then dump core file if needed. When VMError created after >>>> crash, siginfo and context which are ExceptionRecord and >>>> ContextRecord on Windows are recorded, mini (or full, due to 'or' >>>> used so type will be mini anyway) dump creates dump file based on >>>> those two as before. >>>> 2) to make os::abort to get above two pointers, added two more >>>> fields to the function parameters: >>>> 3) changes for test/runtime/ErrorHandling/SecondaryError.java >>>> --- added "-XX:-CreateCoredumpOnCrash" >>>> >>>> - static void abort(bool dump_core = true); >>>> + static void abort(bool dump_core = true, void *siginfo = >>>> NULL, void *context = NULL); >>>> >>>> Tests: JPRT and manually. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>>>> Hi Yumin, >>>>> >>>>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - >>>>> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>>>> >>>>> Beyond that, as I wrote in the bug report comments: >>>>> >>>>> "This is also a problem on Windows - MiniDumpWriteDump() may hang >>>>> infinitly. And on Windows this is worse than under UNIX because we >>>>> create the Dump before writing the hs-err file, so if the Dump >>>>> hangs, we get no error log. I would like to revert the order: >>>>> create the minidump after writing the error log, the same way Unix >>>>> does it. We did this in our JVM (SAP) because for us, error logs >>>>> are more useful than minidumps. " >>>>> >>>>> So, I would like to see os::abort on Windows call >>>>> MiniDumpWriteDump(), and thus the mini dump writing moved after >>>>> the error log writing. This would also make the code way cleaner >>>>> because the control flow would be the same on all platforms. >>>>> >>>>> I understand that this may be out of scope for your change, but I >>>>> would like to know what others think about this. >>>>> >>>>> Kind regards, Thomas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >>>> > wrote: >>>>> >>>>> Please review: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>> >>>>> >>>>> Summary: Tests timed out when VM crashes and dumping core file >>>>> which in the test case is not needed. To make core not created, >>>>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>>>> the former is only used on Windows and the latter for all >>>>> platforms. When VM crashes on non Windows, core file generated as >>>>> default if OS sets core dump allowed. Default value of >>>>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>>>> Windows platforms, but changed for Windows --- original is false, >>>>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>>>> off, no core file will be generated. CreateMinidumpOnCrash still >>>>> can be used on commandline but only as alias for the new flag. >>>>> >>>>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>>>> commandline to verify flag change as alias. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>> >>> >> > From markus.gronlund at oracle.com Tue Mar 17 08:24:07 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 17 Mar 2015 01:24:07 -0700 (PDT) Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> Message-ID: <1ddc090f-0196-4d53-a755-c81bf12c662e@default> Hi Thomas, This looks good, thank you for fixing this! I didn't know that the entire Threads::create_vm() routine is currently unguarded - interesting. Small point: I agree with David about the annoyance of having platform specific #ifdefs in the shared code, but I can't find any other position where we could solve this better (we still need to reach through to the ExceptionFilter). Let me know when you start to dig into the SEH (or lack of) for attaching threads :-) Thanks again Markus -----Original Message----- From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: den 16 mars 2015 12:32 To: David Holmes Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows Hi, I still need one or two reviewers and a sponsor. Thank you! Thomas On Thu, Mar 12, 2015 at 10:41 AM, David Holmes wrote: > Hi Thomas, > > Thanks for the added info. I have no further comments. Hopefully > someone with SEH knowledge will also respond. > > David > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: > >> Hi David, >> >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes >> > wrote: >> >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: >> >> Hi David, >> >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >> >> > >> >> wrote: >> >> Hi Thomas, >> >> I'm not really familiar with Windows SEH. Won't this break >> custom >> launchers that already provide their own try/catch around >> Crate_JavaVM ? >> >> >> No. Windows SEH works stack based: any exception - e.g. a crash - >> between __try and __except will be handled by the handler given >> in the >> __except clause. Because they are stack based, they can be >> nested. If an >> exception is raised inside the inner __try/__except, first >> the inner >> handler is used, if that one feels not responsible, the next >> outer one >> and so on. >> >> With my fix, any exception raised inside CreateJavaVM will be >> handler by >> our handler topLevelExceptionFilter; only if our handler feels not >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >> handler will >> be called. >> >> >> My lack of knowledge about when our handler "feels responsible" >> still leaves me a little nervous here. :) >> >> >> I think the patch is quite safe. I added this patch to our code base >> in >> 2011 and since then this is active in productive code for SAP customers. >> The SAP jvm gets heavily used with custom launchers which do their >> own error handling, so this is a well tested scenario. >> >> I would like to get a similar signal handling coverage as on UNIX: >> >> On Unix, we have global signal handling. The moment signal handling >> is established early in os::init(), every signal from everywhere is >> covered, even user code. We even have to take care that user handlers >> get also in the loop via signal chaining, libjsig.so etc. >> >> On Windows, it is the other way around: we have stack based signal >> handling , so we need __try/__except on every thread, and this means >> there are parts of jvm code which run without signal handling: >> - the whole initialization >> - attached threads (I think?) >> which means that on those cases, user handler gets signals which the >> libjvm should handle. >> >> This was "fixed" partly by surrounding small code which we know >> beforehand causes signals - how convenient - with __try/__except. For >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >> crash. But you want error handling to always work. I also do not know >> if stuff like polling pages, implicit nulltests etc could be used in >> unprotected code. >> >> As a side note, there is a UNIX-like signal handling mode on Windows >> too, "vectored exception handling", which was used in the jvm but >> removed some time ago for reasons I do not really know. >> >> Any exception raised in the launcher itself outside of >> CreateJavaVM will >> still be handled by the user handler. >> >> (And I hate seeing the win32 ifdefs in the shared code :( ). >> >> >> Yes I know, I kind of expected that feedback :( - I did not find a >> better way of doing this. One could try to hide the __try/__except >> behind macros, but that would be kind of unwieldy and I don't like >> abstractiing something which only has meaning on one platform. >> >> >> Does it help if we make the caller responsible for SEH and then put >> the try/catch in the launcher code (hopefully in a windows specific >> part thereof) ? >> >> >> No, because the caller would need access to "topLevelExceptionFilter" >> - you would need to export that function from the libjvm and then >> tell the caller "always call topLevelExceptionFilter() if a signal >> happens on Windows", which is quite awkward and different than on UNIX. >> >> Thomas >> >> Thanks, >> David >> >> >> Thanks, >> David >> >> >> >> Kind regards, Thomas >> >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please review this smallish change: >> >> webrev: >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >> webrev.____01/webrev/ >> > webrev.__01/webrev/> >> >> > webrev.__01/webrev/ >> > 01/webrev/>> >> bug: >> https://bugs.openjdk.java.net/____browse/JDK-8074860 >> >> >> > >> > >> >> This change adds SEH guards around JNI_CreateJavaVM(). >> Without >> the change, >> on Windows, the VM initialization runs without crash >> protection: >> crashes >> will terminate VM immediately without writing an >> error log; >> also, any >> techniques relying on signals will not work, e.g. >> SafeFetch(). >> >> This was partly solved before on a case-by-case base by >> wrapping >> code >> sections which may crash in their own __try/__except >> wrappers - >> e.g. CPU >> feature probing. >> >> The change guards the whole of JNI_CreateJavaVM >> invocation in >> __try/__except. Unfortunately, for that to compile, I >> needed to >> introduce a >> wrapper around JNI_CreateJavaVM and move the whole of >> JNI_CreateJavaVM to a >> new function "JNI_CreateJavaVM_inner". >> >> This fix also gets rid of various workarounds which >> were used >> before to >> guard code sections. >> >> Thanks for reviewing! >> >> Oh, on a side note: I tried to figure out if threads >> which are >> attached >> from the outside via JNI AttachCurrentThread() are in >> any way >> guarded with >> SEH protection. Newly created threads are guarded >> because they >> run thru >> java_start() in os_windows.cpp, which adds SEH guards >> to all >> frames below. >> But for attached threads, I did not find any SEH guards >> - or >> maybe I am >> blind? What does that mean for java code running inside >> attached >> threads? >> >> Regards, >> >> Thomas Stuefe >> >> >> >> From thomas.stuefe at gmail.com Tue Mar 17 08:33:41 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Mar 2015 09:33:41 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: <1ddc090f-0196-4d53-a755-c81bf12c662e@default> References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> Message-ID: Hi Markus, David, thanks for reviewing this! yes, I also do not like the #ifdefs _WIN32. We could pretty it up a bit with macros: #define GUARD_SEH_START __try { #define GUARD_SEH_END } __except... and defining those empty on non-windows platforms? What do you think? Kind Regards, Thomas On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund wrote: > Hi Thomas, > > This looks good, thank you for fixing this! > > I didn't know that the entire Threads::create_vm() routine is currently > unguarded - interesting. > > Small point: I agree with David about the annoyance of having platform > specific #ifdefs in the shared code, but I can't find any other position > where we could solve this better (we still need to reach through to the > ExceptionFilter). > > Let me know when you start to dig into the SEH (or lack of) for attaching > threads :-) > > Thanks again > Markus > > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: den 16 mars 2015 12:32 > To: David Holmes > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing around > CreateJavaVM on Windows > > Hi, > > I still need one or two reviewers and a sponsor. > > Thank you! > > Thomas > > On Thu, Mar 12, 2015 at 10:41 AM, David Holmes > wrote: > > > Hi Thomas, > > > > Thanks for the added info. I have no further comments. Hopefully > > someone with SEH knowledge will also respond. > > > > David > > > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: > > > >> Hi David, > >> > >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes > >> > wrote: > >> > >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: > >> > >> Hi David, > >> > >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes > >> > >> >> > >> >> wrote: > >> > >> Hi Thomas, > >> > >> I'm not really familiar with Windows SEH. Won't this break > >> custom > >> launchers that already provide their own try/catch around > >> Crate_JavaVM ? > >> > >> > >> No. Windows SEH works stack based: any exception - e.g. a crash > - > >> between __try and __except will be handled by the handler given > >> in the > >> __except clause. Because they are stack based, they can be > >> nested. If an > >> exception is raised inside the inner __try/__except, first > >> the inner > >> handler is used, if that one feels not responsible, the next > >> outer one > >> and so on. > >> > >> With my fix, any exception raised inside CreateJavaVM will be > >> handler by > >> our handler topLevelExceptionFilter; only if our handler feels > not > >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user > >> handler will > >> be called. > >> > >> > >> My lack of knowledge about when our handler "feels responsible" > >> still leaves me a little nervous here. :) > >> > >> > >> I think the patch is quite safe. I added this patch to our code base > >> in > >> 2011 and since then this is active in productive code for SAP customers. > >> The SAP jvm gets heavily used with custom launchers which do their > >> own error handling, so this is a well tested scenario. > >> > >> I would like to get a similar signal handling coverage as on UNIX: > >> > >> On Unix, we have global signal handling. The moment signal handling > >> is established early in os::init(), every signal from everywhere is > >> covered, even user code. We even have to take care that user handlers > >> get also in the loop via signal chaining, libjsig.so etc. > >> > >> On Windows, it is the other way around: we have stack based signal > >> handling , so we need __try/__except on every thread, and this means > >> there are parts of jvm code which run without signal handling: > >> - the whole initialization > >> - attached threads (I think?) > >> which means that on those cases, user handler gets signals which the > >> libjvm should handle. > >> > >> This was "fixed" partly by surrounding small code which we know > >> beforehand causes signals - how convenient - with __try/__except. For > >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a > >> crash. But you want error handling to always work. I also do not know > >> if stuff like polling pages, implicit nulltests etc could be used in > >> unprotected code. > >> > >> As a side note, there is a UNIX-like signal handling mode on Windows > >> too, "vectored exception handling", which was used in the jvm but > >> removed some time ago for reasons I do not really know. > >> > >> Any exception raised in the launcher itself outside of > >> CreateJavaVM will > >> still be handled by the user handler. > >> > >> (And I hate seeing the win32 ifdefs in the shared code :( > ). > >> > >> > >> Yes I know, I kind of expected that feedback :( - I did not > find a > >> better way of doing this. One could try to hide the > __try/__except > >> behind macros, but that would be kind of unwieldy and I don't > like > >> abstractiing something which only has meaning on one platform. > >> > >> > >> Does it help if we make the caller responsible for SEH and then put > >> the try/catch in the launcher code (hopefully in a windows specific > >> part thereof) ? > >> > >> > >> No, because the caller would need access to "topLevelExceptionFilter" > >> - you would need to export that function from the libjvm and then > >> tell the caller "always call topLevelExceptionFilter() if a signal > >> happens on Windows", which is quite awkward and different than on UNIX. > >> > >> Thomas > >> > >> Thanks, > >> David > >> > >> > >> Thanks, > >> David > >> > >> > >> > >> Kind regards, Thomas > >> > >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: > >> > >> Hi all, > >> > >> please review this smallish change: > >> > >> webrev: > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ > >> webrev.____01/webrev/ > >> >> webrev.__01/webrev/> > >> > >> >> webrev.__01/webrev/ > >> >> 01/webrev/>> > >> bug: > >> https://bugs.openjdk.java.net/____browse/JDK-8074860 > >> > >> > >> >> > >> > > >> > >> This change adds SEH guards around JNI_CreateJavaVM(). > >> Without > >> the change, > >> on Windows, the VM initialization runs without crash > >> protection: > >> crashes > >> will terminate VM immediately without writing an > >> error log; > >> also, any > >> techniques relying on signals will not work, e.g. > >> SafeFetch(). > >> > >> This was partly solved before on a case-by-case base by > >> wrapping > >> code > >> sections which may crash in their own __try/__except > >> wrappers - > >> e.g. CPU > >> feature probing. > >> > >> The change guards the whole of JNI_CreateJavaVM > >> invocation in > >> __try/__except. Unfortunately, for that to compile, I > >> needed to > >> introduce a > >> wrapper around JNI_CreateJavaVM and move the whole of > >> JNI_CreateJavaVM to a > >> new function "JNI_CreateJavaVM_inner". > >> > >> This fix also gets rid of various workarounds which > >> were used > >> before to > >> guard code sections. > >> > >> Thanks for reviewing! > >> > >> Oh, on a side note: I tried to figure out if threads > >> which are > >> attached > >> from the outside via JNI AttachCurrentThread() are in > >> any way > >> guarded with > >> SEH protection. Newly created threads are guarded > >> because they > >> run thru > >> java_start() in os_windows.cpp, which adds SEH guards > >> to all > >> frames below. > >> But for attached threads, I did not find any SEH guards > >> - or > >> maybe I am > >> blind? What does that mean for java code running inside > >> attached > >> threads? > >> > >> Regards, > >> > >> Thomas Stuefe > >> > >> > >> > >> > From markus.gronlund at oracle.com Tue Mar 17 08:40:10 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 17 Mar 2015 01:40:10 -0700 (PDT) Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> Message-ID: <5c66c663-9106-427e-830a-2585f45ab906@default> I don?t think it is worth it. But thanks for thinking about it. ? I was thinking if we could maybe do some callback trickery to set up the SEH in Windows specific code only inside Threads::create_vm() ? but again, probably not worth it. ? I am ok with the suggestion as it stands. ? /Markus ? ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: den 17 mars 2015 09:34 To: Markus Gronlund Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows ? Hi Markus, David, ? thanks for reviewing this! ? yes, I also do not like the #ifdefs _WIN32. ? We could pretty it up a bit with macros: ? #define GUARD_SEH_START ? ?__try { #define GUARD_SEH_END ? ? ? ?} __except... ? and defining those empty on non-windows platforms? ? What do you think?? ? Kind Regards, Thomas ? ? ? ? ? ? ? ? ? On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund wrote: Hi Thomas, This looks good, thank you for fixing this! I didn't know that the entire Threads::create_vm() routine is currently unguarded - interesting. Small point: I agree with David about the annoyance of having platform specific #ifdefs in the shared code, but I can't find any other position where we could solve this better (we still need to reach through to the ExceptionFilter). Let me know when you start to dig into the SEH (or lack of) for attaching threads :-) Thanks again Markus -----Original Message----- From: Thomas St?fe [mailto:HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com] Sent: den 16 mars 2015 12:32 To: David Holmes Cc: HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows Hi, I still need one or two reviewers and a sponsor. Thank you! Thomas On Thu, Mar 12, 2015 at 10:41 AM, David Holmes wrote: > Hi Thomas, > > Thanks for the added info. I have no further comments. Hopefully > someone with SEH knowledge will also respond. > > David > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: > >> Hi David, >> >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes >> > wrote: >> >>? ? ?On 12/03/2015 8:03 AM, Thomas St?fe wrote: >> >>? ? ? ? ?Hi David, >> >>? ? ? ? ?On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >>? ? ? ? ? >>? ? ? ? ?> >>? ? ? ? ?>> wrote: >> >>? ? ? ? ? ? ? Hi Thomas, >> >>? ? ? ? ? ? ? I'm not really familiar with Windows SEH. Won't this break >>? ? ? ? ?custom >>? ? ? ? ? ? ? launchers that already provide their own try/catch around >>? ? ? ? ?Crate_JavaVM ? >> >> >>? ? ? ? ?No. Windows SEH works stack based: any exception - e.g. a crash - >>? ? ? ? ?between __try and __except will be handled by the handler given >>? ? ? ? ?in the >>? ? ? ? ?__except clause. Because they are stack based, they can be >>? ? ? ? ?nested. If an >>? ? ? ? ?exception is raised inside the inner __try/__except, first >> the inner >>? ? ? ? ?handler is used, if that one feels not responsible, the next >>? ? ? ? ?outer one >>? ? ? ? ?and so on. >> >>? ? ? ? ?With my fix, any exception raised inside CreateJavaVM will be >>? ? ? ? ?handler by >>? ? ? ? ?our handler topLevelExceptionFilter; only if our handler feels not >>? ? ? ? ?responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >>? ? ? ? ?handler will >>? ? ? ? ?be called. >> >> >>? ? ?My lack of knowledge about when our handler "feels responsible" >>? ? ?still leaves me a little nervous here. :) >> >> >> I think the patch is quite safe. I added this patch to our code base >> in >> 2011 and since then this is active in productive code for SAP customers. >> The SAP jvm gets heavily used with custom launchers which do their >> own error handling, so this is a well tested scenario. >> >> I would like to get a similar signal handling coverage as on UNIX: >> >> On Unix, we have global signal handling. The moment signal handling >> is established early in os::init(), every signal from everywhere is >> covered, even user code. We even have to take care that user handlers >> get also in the loop via signal chaining, libjsig.so etc. >> >> On Windows, it is the other way around: we have stack based signal >> handling , so we need __try/__except on every thread, and this means >> there are parts of jvm code which run without signal handling: >> - the whole initialization >> - attached threads (I think?) >> which means that on those cases, user handler gets signals which the >> libjvm should handle. >> >> This was "fixed" partly by surrounding small code which we know >> beforehand causes signals - how convenient - with __try/__except. For >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >> crash. But you want error handling to always work. I also do not know >> if stuff like polling pages, implicit nulltests etc could be used in >> unprotected code. >> >> As a side note, there is a UNIX-like signal handling mode on Windows >> too, "vectored exception handling", which was used in the jvm but >> removed some time ago for reasons I do not really know. >> >>? ? ? ? ?Any exception raised in the launcher itself outside of >>? ? ? ? ?CreateJavaVM will >>? ? ? ? ?still be handled by the user handler. >> >>? ? ? ? ? ? ? (And I hate seeing the win32 ifdefs in the shared code :( ). >> >> >>? ? ? ? ?Yes I know, I kind of expected that feedback :( - I did not find a >>? ? ? ? ?better way of doing this. One could try to hide the __try/__except >>? ? ? ? ?behind macros, but that would be kind of unwieldy and I don't like >>? ? ? ? ?abstractiing something which only has meaning on one platform. >> >> >>? ? ?Does it help if we make the caller responsible for SEH and then put >>? ? ?the try/catch in the launcher code (hopefully in a windows specific >>? ? ?part thereof) ? >> >> >> No, because the caller would need access to "topLevelExceptionFilter" >> - you would need to export that function from the libjvm and then >> tell the caller "always call topLevelExceptionFilter() if a signal >> happens on Windows", which is quite awkward and different than on UNIX. >> >> Thomas >> >>? ? ?Thanks, >>? ? ?David >> >> >>? ? ? ? ? ? ? Thanks, >>? ? ? ? ? ? ? David >> >> >> >>? ? ? ? ?Kind regards, Thomas >> >>? ? ? ? ? ? ? On 12/03/2015 1:40 AM, Thomas St?fe wrote: >> >>? ? ? ? ? ? ? ? ? Hi all, >> >>? ? ? ? ? ? ? ? ? please review this smallish change: >> >>? ? ? ? ? ? ? ? ? webrev: >>? ? ? ? ?http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >> webrev.____01/webrev/ >>? ? ? ? ?> webrev.__01/webrev/> >> >>? ? ? ? ?> webrev.__01/webrev/ >>? ? ? ? ?> 01/webrev/>> >>? ? ? ? ? ? ? ? ? bug: >>? ? ? ? ?https://bugs.openjdk.java.net/____browse/JDK-8074860 >>? ? ? ? ? >> >>? ? ? ? ? ? ? ? ? > >>? ? ? ? ?> >> >>? ? ? ? ? ? ? ? ? This change adds SEH guards around JNI_CreateJavaVM(). >>? ? ? ? ?Without >>? ? ? ? ? ? ? ? ? the change, >>? ? ? ? ? ? ? ? ? on Windows, the VM initialization runs without crash >>? ? ? ? ?protection: >>? ? ? ? ? ? ? ? ? crashes >>? ? ? ? ? ? ? ? ? will terminate VM immediately without writing an >> error log; >>? ? ? ? ? ? ? ? ? also, any >>? ? ? ? ? ? ? ? ? techniques relying on signals will not work, e.g. >>? ? ? ? ?SafeFetch(). >> >>? ? ? ? ? ? ? ? ? This was partly solved before on a case-by-case base by >>? ? ? ? ?wrapping >>? ? ? ? ? ? ? ? ? code >>? ? ? ? ? ? ? ? ? sections which may crash in their own __try/__except >>? ? ? ? ?wrappers - >>? ? ? ? ? ? ? ? ? e.g. CPU >>? ? ? ? ? ? ? ? ? feature probing. >> >>? ? ? ? ? ? ? ? ? The change guards the whole of JNI_CreateJavaVM >>? ? ? ? ?invocation in >>? ? ? ? ? ? ? ? ? __try/__except. Unfortunately, for that to compile, I >>? ? ? ? ?needed to >>? ? ? ? ? ? ? ? ? introduce a >>? ? ? ? ? ? ? ? ? wrapper around JNI_CreateJavaVM and move the whole of >>? ? ? ? ? ? ? ? ? JNI_CreateJavaVM to a >>? ? ? ? ? ? ? ? ? new function "JNI_CreateJavaVM_inner". >> >>? ? ? ? ? ? ? ? ? This fix also gets rid of various workarounds which >>? ? ? ? ?were used >>? ? ? ? ? ? ? ? ? before to >>? ? ? ? ? ? ? ? ? guard code sections. >> >>? ? ? ? ? ? ? ? ? Thanks for reviewing! >> >>? ? ? ? ? ? ? ? ? Oh, on a side note: I tried to figure out if threads >>? ? ? ? ?which are >>? ? ? ? ? ? ? ? ? attached >>? ? ? ? ? ? ? ? ? from the outside via JNI AttachCurrentThread() are in >>? ? ? ? ?any way >>? ? ? ? ? ? ? ? ? guarded with >>? ? ? ? ? ? ? ? ? SEH protection. Newly created threads are guarded >>? ? ? ? ?because they >>? ? ? ? ? ? ? ? ? run thru >>? ? ? ? ? ? ? ? ? java_start() in os_windows.cpp, which adds SEH guards >>? ? ? ? ?to all >>? ? ? ? ? ? ? ? ? frames below. >>? ? ? ? ? ? ? ? ? But for attached threads, I did not find any SEH guards >>? ? ? ? ?- or >>? ? ? ? ? ? ? ? ? maybe I am >>? ? ? ? ? ? ? ? ? blind? What does that mean for java code running inside >>? ? ? ? ?attached >>? ? ? ? ? ? ? ? ? threads? >> >>? ? ? ? ? ? ? ? ? Regards, >> >>? ? ? ? ? ? ? ? ? Thomas Stuefe >> >> >> >> ? From harold.seigel at oracle.com Tue Mar 17 13:39:59 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 17 Mar 2015 09:39:59 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <55032736.90402@oracle.com> References: <55032736.90402@oracle.com> Message-ID: <55082EAF.8030007@oracle.com> Hi, Here is the actual open webrev for this RFR: http://cr.openjdk.java.net/~hseigel/bug_7127066/ I mistakenly put the wrong URL for the webrev. (Thanks Volker!) Harold On 3/13/2015 2:06 PM, harold seigel wrote: > Hi, > > Please review this fix for bug JDK-7127066. The fix applies to > astore* bytecodes because, when inside an exception handler, they can > reference the thrown object and modify the number of stack locals, > enabling the incorrect stack match. > > Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 > > The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, > java/lang, java/io, and java/util tests, and testbase quick and split > verifier tests, and with the test case provided in the bug. > > Thanks! Harold From dmitry.dmitriev at oracle.com Tue Mar 17 16:03:06 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Tue, 17 Mar 2015 19:03:06 +0300 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags Message-ID: <5508503A.8080101@oracle.com> Hello, Please review this small fix which remove old deprecated options(regarding to JDK 9) from obsolete_jvm_flags table. Also, I need a sponsor for this fix, who can push it, because I'm not have a OpenJDK name. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 Thank you, Dmitry From thomas.stuefe at gmail.com Tue Mar 17 16:22:28 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Mar 2015 17:22:28 +0100 Subject: RFR(xs): 8075044 : Query dbghelp.dll version number at run time, not at compile time In-Reply-To: References: <11E1660C-0038-4297-92EC-2B1F41C973C6@oracle.com> Message-ID: Hi Markus, you are right :( When I originally posted the fix, I had looked at the resulting minidump in a debugger, but I didn't notice that the thread information dumped with MiniDumpWithThreadInfo were missing. When I checked, I saw exactly the same behaviour you see on your machine. I tested on a windows 7 box and on an old win2003 server. ImageHlpApiVersion() does not seem to return anything usable. Always returns 4.0.5 for all dbghelp.dll versions I tested. MSDN was fooling me ("Retrieves the version information of the DbgHelp library installed on the system."). API_VERSION_NUMBER, as a compile time constant, is only useful to guard against compile errors when using too old header files. However, it is completely undocumented. Another way to determine dbghelp.dll version would be to probe for APIs which are tied to dbghelp.dll versions (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms679294%28v=vs.85%29.aspx). I tried this and found also an inconsistent picture. On windows 2003 the dbghelp.dll only exported some APIs introduced for certain dbghelp.dll versions, but not all of them (so, e.g., it exported all APIs introduced with version 6.1, but "EnumDirTree()", which is available since 5.2, was missing). Bottomline, I now do not see a reliable way to determine the dbghelp.dll version at runtime nor at compile time. Microsoft itself recommends to ship the dbghelp.dll from the debugging kit together with the application. So the best way to deal with an unknown dbghelp.dll would be to just call MiniDumpWriteDump() with all dumptype flags - if that fails, to fall back to a subset of those flags. Which is what the old code already does. In the light of this, I think I close the bug report without fixing, because the code cannot really be improved. Thank you for reviewing and testing this, and sorry for the bad patch. Thomas On Mon, Mar 16, 2015 at 8:04 PM, Markus Gronlund wrote: > Hi Thomas, > > I am a bit worried about the changes from the API_VERSION constant which > is defined in ImageHlp.h as: > > #define API_VERSION_NUMBER 11 > > to using the runtime values returned in the API_VERSION struct from > calling dbghelp::ImagehlpApiVersion() without any conversions: > > This is what I get on my laptop (win7 x86 /32-bit) > > dbghelp::ImagehlpApiVersion() // function pointer via > C:\Windows\System32\dbghelp.dll (some old version: 6.1.7061.17514): > > +0x000 MajorVersion : 4 > +0x002 MinorVersion : 0 > +0x004 Revision : 5 > +0x006 Reserved : 0 > > > I thought this might be due to the fact of an older version of dbghelp.dll > - I therefore set the function pointer to the Windows SDK 8.1 version of > dbghelp.dll (6.3.9600.16384): > > +0x000 MajorVersion : 4 > +0x002 MinorVersion : 0 > +0x004 Revision : 5 > +0x006 Reserved : 0 > > Same data. > > I also queried Imagehlp.dll (6.1.7601.18288) using the same API: > > +0x000 MajorVersion : 4 > +0x002 MinorVersion : 0 > +0x004 Revision : 5 > +0x006 Reserved : 0 > > I am not sure if "MajorVersion == 4" is the same as / should be > interpreted the same as "#define API_VERSION_NUMBER 11" ? > > In any case, only looking at the MajorVersion number returned with no > adaptation changes behavior: > > // Older versions of dbghelp.h doesn't contain all the dumptypes we > want, dbghelp.h with > // API_VERSION_NUMBER 11 or higher contains the ones we want though > > if (version->MajorVersion >= 11) { > dumpType = (MINIDUMP_TYPE)(dumpType | MiniDumpWithFullMemoryInfo | > MiniDumpWithThreadInfo | > MiniDumpWithUnloadedModules); > } > > I previously go the 11 from the constant, but now as I described above, I > am getting 4, and therefore, less information in the .mdmp. > > Are you pulling out a 11 from MajorVersion? > > /Markus > > > > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: den 16 mars 2015 12:33 > To: Staffan Larsen > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(xs): 8075044 : Query dbghelp.dll version number at run > time, not at compile time > > Hi all, > > still need a second reviewer and also a sponsor. Thanks! > > Thomas > > On Thu, Mar 12, 2015 at 1:58 PM, Staffan Larsen > > wrote: > > > Looks good! > > > > Thanks, > > /Staffan > > > > > On 12 mar 2015, at 13:50, Thomas St?fe > wrote: > > > > > > Hi all, > > > > > > please take a look at this tiny change: > > > > > > webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8075044/webrev.01/webrev/ > > > bug: https://bugs.openjdk.java.net/browse/JDK-8075044 > > > > > > This changes the version number query for dbghelp.dll from a compile > > > time check to a run time check. > > > > > > Thanks! > > > > > > Thomas Stuefe > > > > > From jeremymanson at google.com Tue Mar 17 18:13:47 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 17 Mar 2015 11:13:47 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5506645C.4050201@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> Message-ID: On Sun, Mar 15, 2015 at 10:04 PM, David Holmes wrote: > Hi Jeremy, > > On 14/03/2015 3:00 AM, Jeremy Manson wrote: > >> Thanks, David! New rev: >> >> http://cr.openjdk.java.net/~jmanson/8074895/webrev.01/ >> > > Looks good. Please update copyright dates in memTracker.cpp and > vmError.cpp. > Done. Thanks for the review, and for feeding it through the other platforms! http://cr.openjdk.java.net/~jmanson/8074895/webrev.02/ Jeremy From harold.seigel at oracle.com Tue Mar 17 18:37:47 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 17 Mar 2015 14:37:47 -0400 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification Message-ID: <5508747B.7000602@oracle.com> Hi, Please review this fix for bug JDK-8075118. The code being verified contained a TRY block whose catch handler was inside the TRY block. Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY block and then scans the bytecodes in the TRY block's handler and then scans the bytecodes of its handler's handler, etc. Since, the bytecodes in the handler and the bytecode's handler's handler were the same, it just kept scanning the same bytecodes over and over. The fix prevents re-scanning a handler's bytecodes if they are contained in the TRY block. Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 The fix was tested with the test program provided by the bug, the JCK Lang, VM, and API tests, the testbase quick and split verifier tests, and with the JTREG hotspot tests. Thanks! Harold From dean.long at oracle.com Tue Mar 17 19:06:25 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 17 Mar 2015 12:06:25 -0700 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <5508747B.7000602@oracle.com> References: <5508747B.7000602@oracle.com> Message-ID: <55087B31.2030203@oracle.com> Hi Harold. How does this change guarantee that the catch handler is always scanned? If it was an island of code surrounded by gotos, so that it is only reachable through the handler, then it looks like it will now be skipped entirely. dl On 3/17/2015 11:37 AM, harold seigel wrote: > Hi, > > Please review this fix for bug JDK-8075118. The code being verified > contained a TRY block whose catch handler was inside the TRY block. > Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY > block and then scans the bytecodes in the TRY block's handler and then > scans the bytecodes of its handler's handler, etc. Since, the > bytecodes in the handler and the bytecode's handler's handler were the > same, it just kept scanning the same bytecodes over and over. > > The fix prevents re-scanning a handler's bytecodes if they are > contained in the TRY block. > > Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 > > The fix was tested with the test program provided by the bug, the JCK > Lang, VM, and API tests, the testbase quick and split verifier tests, > and with the JTREG hotspot tests. > > Thanks! Harold From harold.seigel at oracle.com Tue Mar 17 19:13:53 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 17 Mar 2015 15:13:53 -0400 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <55087B31.2030203@oracle.com> References: <5508747B.7000602@oracle.com> <55087B31.2030203@oracle.com> Message-ID: <55087CF1.2090106@oracle.com> Hi Dean, I see your point. Instead of this fix, I may try instead keeping a separate list of handlers that have been scanned and not push a handler on the stack if it has already been scanned. Harold On 3/17/2015 3:06 PM, Dean Long wrote: > Hi Harold. How does this change guarantee that the catch handler is > always scanned? If it was an island of code surrounded by gotos, so > that it is only reachable through the handler, then it looks like it > will now be skipped entirely. > > dl > > On 3/17/2015 11:37 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for bug JDK-8075118. The code being verified >> contained a TRY block whose catch handler was inside the TRY block. >> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY >> block and then scans the bytecodes in the TRY block's handler and >> then scans the bytecodes of its handler's handler, etc. Since, the >> bytecodes in the handler and the bytecode's handler's handler were >> the same, it just kept scanning the same bytecodes over and over. >> >> The fix prevents re-scanning a handler's bytecodes if they are >> contained in the TRY block. >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 >> >> The fix was tested with the test program provided by the bug, the JCK >> Lang, VM, and API tests, the testbase quick and split verifier tests, >> and with the JTREG hotspot tests. >> >> Thanks! Harold > From david.holmes at oracle.com Wed Mar 18 00:50:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 10:50:22 +1000 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: <5508503A.8080101@oracle.com> References: <5508503A.8080101@oracle.com> Message-ID: <5508CBCE.9070600@oracle.com> Hi Dmitry, On 18/03/2015 2:03 AM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix which remove old deprecated > options(regarding to JDK 9) from obsolete_jvm_flags table. We could completely re-do the obsolete option mechanism now that hsx is not an issue, but simply deleting all the already invalid options is fine. Though some additional commentary we be useful: 241 * limit, we flatly refuse to admit the existence of the flag. This allows 242 * a flag to die correctly over JDK releases using HSX. + * But now that HSX is no longer supported only options + * with a future accept_until value need to be listed, and + * the list can be pruned on each major release. > Also, I need a sponsor for this fix, who can push it, because I'm not > have a OpenJDK name. I can sponsor this. Thanks, David > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ > > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 > > Thank you, > Dmitry From david.holmes at oracle.com Wed Mar 18 02:01:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 12:01:59 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> Message-ID: <5508DC97.8040508@oracle.com> Submitting via JPRT. Thanks, David On 18/03/2015 4:13 AM, Jeremy Manson wrote: > > > On Sun, Mar 15, 2015 at 10:04 PM, David Holmes > wrote: > > Hi Jeremy, > > On 14/03/2015 3:00 AM, Jeremy Manson wrote: > > Thanks, David! New rev: > > http://cr.openjdk.java.net/~__jmanson/8074895/webrev.01/ > > > > Looks good. Please update copyright dates in memTracker.cpp and > vmError.cpp. > > > Done. Thanks for the review, and for feeding it through the other > platforms! > > http://cr.openjdk.java.net/~jmanson/8074895/webrev.02/ > > Jeremy From david.holmes at oracle.com Wed Mar 18 04:09:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 14:09:13 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5508DC97.8040508@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> Message-ID: <5508FA69.7040004@oracle.com> Sorry Jeremy, the patch failed on Windows as there is another usage in os_windows.cpp: void os::init_system_properties_values() { // sysclasspath, java_home, dll_dir { char *home_path; char *dll_path; char *pslash; char *bin = "\\bin"; char home_dir[MAX_PATH]; if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, MAX_PATH)) { David On 18/03/2015 12:01 PM, David Holmes wrote: > Submitting via JPRT. > > Thanks, > David > > On 18/03/2015 4:13 AM, Jeremy Manson wrote: >> >> >> On Sun, Mar 15, 2015 at 10:04 PM, David Holmes > > wrote: >> >> Hi Jeremy, >> >> On 14/03/2015 3:00 AM, Jeremy Manson wrote: >> >> Thanks, David! New rev: >> >> http://cr.openjdk.java.net/~__jmanson/8074895/webrev.01/ >> >> >> >> Looks good. Please update copyright dates in memTracker.cpp and >> vmError.cpp. >> >> >> Done. Thanks for the review, and for feeding it through the other >> platforms! >> >> http://cr.openjdk.java.net/~jmanson/8074895/webrev.02/ >> >> Jeremy From jeremymanson at google.com Wed Mar 18 06:15:04 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 17 Mar 2015 23:15:04 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5508FA69.7040004@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> Message-ID: Oops... Should I fix it, post a patch, and hope it compiles? On Tue, Mar 17, 2015 at 9:09 PM, David Holmes wrote: > Sorry Jeremy, the patch failed on Windows as there is another usage in > os_windows.cpp: > > void os::init_system_properties_values() { > // sysclasspath, java_home, dll_dir > { > char *home_path; > char *dll_path; > char *pslash; > char *bin = "\\bin"; > char home_dir[MAX_PATH]; > > if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, MAX_PATH)) { > > David > > > On 18/03/2015 12:01 PM, David Holmes wrote: > >> Submitting via JPRT. >> >> Thanks, >> David >> >> On 18/03/2015 4:13 AM, Jeremy Manson wrote: >> >>> >>> >>> On Sun, Mar 15, 2015 at 10:04 PM, David Holmes >> > wrote: >>> >>> Hi Jeremy, >>> >>> On 14/03/2015 3:00 AM, Jeremy Manson wrote: >>> >>> Thanks, David! New rev: >>> >>> http://cr.openjdk.java.net/~__jmanson/8074895/webrev.01/ >>> >>> >>> >>> Looks good. Please update copyright dates in memTracker.cpp and >>> vmError.cpp. >>> >>> >>> Done. Thanks for the review, and for feeding it through the other >>> platforms! >>> >>> http://cr.openjdk.java.net/~jmanson/8074895/webrev.02/ >>> >>> Jeremy >>> >> From david.holmes at oracle.com Wed Mar 18 07:31:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Mar 2015 17:31:34 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> Message-ID: <550929D6.2050509@oracle.com> On 18/03/2015 4:15 PM, Jeremy Manson wrote: > Oops... Should I fix it, post a patch, and hope it compiles? Please :) I can check the compiles part. David > On Tue, Mar 17, 2015 at 9:09 PM, David Holmes > wrote: > > Sorry Jeremy, the patch failed on Windows as there is another usage > in os_windows.cpp: > > void os::init_system_properties___values() { > // sysclasspath, java_home, dll_dir > { > char *home_path; > char *dll_path; > char *pslash; > char *bin = "\\bin"; > char home_dir[MAX_PATH]; > > if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, MAX_PATH)) { > > David > > > On 18/03/2015 12:01 PM, David Holmes wrote: > > Submitting via JPRT. > > Thanks, > David > > On 18/03/2015 4:13 AM, Jeremy Manson wrote: > > > > On Sun, Mar 15, 2015 at 10:04 PM, David Holmes > > >> wrote: > > Hi Jeremy, > > On 14/03/2015 3:00 AM, Jeremy Manson wrote: > > Thanks, David! New rev: > > http://cr.openjdk.java.net/~____jmanson/8074895/webrev.01/ > > > > > > > Looks good. Please update copyright dates in > memTracker.cpp and > vmError.cpp. > > > Done. Thanks for the review, and for feeding it through the > other > platforms! > > http://cr.openjdk.java.net/~__jmanson/8074895/webrev.02/ > > > Jeremy > > From thomas.stuefe at gmail.com Wed Mar 18 10:13:25 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Mar 2015 11:13:25 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: <5c66c663-9106-427e-830a-2585f45ab906@default> References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> <5c66c663-9106-427e-830a-2585f45ab906@default> Message-ID: Hi Markus, the way to do this cleanly would be to use Vectored Exceptions, which would give us the same control flow as on Unix signal. However, Vectored Exception handling was explicitly removed from the hotspot ages ago. I guess because too many third party libraries install their own VE handlers. To all: I still need one more reviewer and a sponsor. Thanks! Thomas On Tue, Mar 17, 2015 at 9:40 AM, Markus Gronlund wrote: > > I don?t think it is worth it. But thanks for thinking about it. > > > > I was thinking if we could maybe do some callback trickery to set up the SEH in Windows specific code only inside Threads::create_vm() ? but again, probably not worth it. > > > > I am ok with the suggestion as it stands. > > > > /Markus > > > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: den 17 mars 2015 09:34 > To: Markus Gronlund > Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes > > > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > > > > Hi Markus, David, > > > > thanks for reviewing this! > > > > yes, I also do not like the #ifdefs _WIN32. > > > > We could pretty it up a bit with macros: > > > > #define GUARD_SEH_START __try { > > #define GUARD_SEH_END } __except... > > > > and defining those empty on non-windows platforms? > > > > What do you think? > > > > Kind Regards, Thomas > > > > > > > > > > > > > > > > > > > > On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund < markus.gronlund at oracle.com> wrote: > > Hi Thomas, > > This looks good, thank you for fixing this! > > I didn't know that the entire Threads::create_vm() routine is currently unguarded - interesting. > > Small point: I agree with David about the annoyance of having platform specific #ifdefs in the shared code, but I can't find any other position where we could solve this better (we still need to reach through to the ExceptionFilter). > > Let me know when you start to dig into the SEH (or lack of) for attaching threads :-) > > Thanks again > Markus > > > -----Original Message----- > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: den 16 mars 2015 12:32 > To: David Holmes > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows > > Hi, > > I still need one or two reviewers and a sponsor. > > Thank you! > > Thomas > > On Thu, Mar 12, 2015 at 10:41 AM, David Holmes > wrote: > > > Hi Thomas, > > > > Thanks for the added info. I have no further comments. Hopefully > > someone with SEH knowledge will also respond. > > > > David > > > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: > > > >> Hi David, > >> > >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes > >> > wrote: > >> > >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: > >> > >> Hi David, > >> > >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes > >> > >> >> > >> >> wrote: > >> > >> Hi Thomas, > >> > >> I'm not really familiar with Windows SEH. Won't this break > >> custom > >> launchers that already provide their own try/catch around > >> Crate_JavaVM ? > >> > >> > >> No. Windows SEH works stack based: any exception - e.g. a crash - > >> between __try and __except will be handled by the handler given > >> in the > >> __except clause. Because they are stack based, they can be > >> nested. If an > >> exception is raised inside the inner __try/__except, first > >> the inner > >> handler is used, if that one feels not responsible, the next > >> outer one > >> and so on. > >> > >> With my fix, any exception raised inside CreateJavaVM will be > >> handler by > >> our handler topLevelExceptionFilter; only if our handler feels not > >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user > >> handler will > >> be called. > >> > >> > >> My lack of knowledge about when our handler "feels responsible" > >> still leaves me a little nervous here. :) > >> > >> > >> I think the patch is quite safe. I added this patch to our code base > >> in > >> 2011 and since then this is active in productive code for SAP customers. > >> The SAP jvm gets heavily used with custom launchers which do their > >> own error handling, so this is a well tested scenario. > >> > >> I would like to get a similar signal handling coverage as on UNIX: > >> > >> On Unix, we have global signal handling. The moment signal handling > >> is established early in os::init(), every signal from everywhere is > >> covered, even user code. We even have to take care that user handlers > >> get also in the loop via signal chaining, libjsig.so etc. > >> > >> On Windows, it is the other way around: we have stack based signal > >> handling , so we need __try/__except on every thread, and this means > >> there are parts of jvm code which run without signal handling: > >> - the whole initialization > >> - attached threads (I think?) > >> which means that on those cases, user handler gets signals which the > >> libjvm should handle. > >> > >> This was "fixed" partly by surrounding small code which we know > >> beforehand causes signals - how convenient - with __try/__except. For > >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a > >> crash. But you want error handling to always work. I also do not know > >> if stuff like polling pages, implicit nulltests etc could be used in > >> unprotected code. > >> > >> As a side note, there is a UNIX-like signal handling mode on Windows > >> too, "vectored exception handling", which was used in the jvm but > >> removed some time ago for reasons I do not really know. > >> > >> Any exception raised in the launcher itself outside of > >> CreateJavaVM will > >> still be handled by the user handler. > >> > >> (And I hate seeing the win32 ifdefs in the shared code :( ). > >> > >> > >> Yes I know, I kind of expected that feedback :( - I did not find a > >> better way of doing this. One could try to hide the __try/__except > >> behind macros, but that would be kind of unwieldy and I don't like > >> abstractiing something which only has meaning on one platform. > >> > >> > >> Does it help if we make the caller responsible for SEH and then put > >> the try/catch in the launcher code (hopefully in a windows specific > >> part thereof) ? > >> > >> > >> No, because the caller would need access to "topLevelExceptionFilter" > >> - you would need to export that function from the libjvm and then > >> tell the caller "always call topLevelExceptionFilter() if a signal > >> happens on Windows", which is quite awkward and different than on UNIX. > >> > >> Thomas > >> > >> Thanks, > >> David > >> > >> > >> Thanks, > >> David > >> > >> > >> > >> Kind regards, Thomas > >> > >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: > >> > >> Hi all, > >> > >> please review this smallish change: > >> > >> webrev: > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ > >> webrev.____01/webrev/ > >> >> webrev.__01/webrev/> > >> > >> >> webrev.__01/webrev/ > >> >> 01/webrev/>> > >> bug: > >> https://bugs.openjdk.java.net/____browse/JDK-8074860 > >> > >> > >> >> > >> > > >> > >> This change adds SEH guards around JNI_CreateJavaVM(). > >> Without > >> the change, > >> on Windows, the VM initialization runs without crash > >> protection: > >> crashes > >> will terminate VM immediately without writing an > >> error log; > >> also, any > >> techniques relying on signals will not work, e.g. > >> SafeFetch(). > >> > >> This was partly solved before on a case-by-case base by > >> wrapping > >> code > >> sections which may crash in their own __try/__except > >> wrappers - > >> e.g. CPU > >> feature probing. > >> > >> The change guards the whole of JNI_CreateJavaVM > >> invocation in > >> __try/__except. Unfortunately, for that to compile, I > >> needed to > >> introduce a > >> wrapper around JNI_CreateJavaVM and move the whole of > >> JNI_CreateJavaVM to a > >> new function "JNI_CreateJavaVM_inner". > >> > >> This fix also gets rid of various workarounds which > >> were used > >> before to > >> guard code sections. > >> > >> Thanks for reviewing! > >> > >> Oh, on a side note: I tried to figure out if threads > >> which are > >> attached > >> from the outside via JNI AttachCurrentThread() are in > >> any way > >> guarded with > >> SEH protection. Newly created threads are guarded > >> because they > >> run thru > >> java_start() in os_windows.cpp, which adds SEH guards > >> to all > >> frames below. > >> But for attached threads, I did not find any SEH guards > >> - or > >> maybe I am > >> blind? What does that mean for java code running inside > >> attached > >> threads? > >> > >> Regards, > >> > >> Thomas Stuefe > >> > >> > >> > >> > > From thomas.stuefe at gmail.com Wed Mar 18 11:26:21 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Mar 2015 12:26:21 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <55077D97.2070402@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> Message-ID: Hi Yumin, - just aesthetics, but on all implementations of os_abort(), at least on the UNIX variants, maybe we could consistently rename the parameters to be "siginfo" and "context" instead of using Windows terms? - On check_create_dump_limit(), you do not need exceptionRecord, contextRecord parameters anymore. The only parameters now needed are buffer and buffer size, which is not even an output parameter, just a scratch buffer for this function to use for printf. For output, it calls VMError::report_coredump_status(...) at the end to provide information about the core file. - I would rename that function from check_create_dump_limit() to check_dump_limit() - nothing is created anymore. - on Windows, in os::abort(), there is no point anymore in calling VMError::report_coredump_status(...) because that information is only used during error log writing which already happened. It only makes sense to call this function in check_create_dump_limit(), which happens before error log writing. Instead, maybe error messages like "Call to MiniDumpWriteDump() failed" should just be written to stderr? This would be consistent with Unix, where the OS writes a short message on stderr if core file writing fails. - there is now a new test, test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java - could you please also add "-XX:-CreateCoredumpOnCrash" ? I just added the test and did not want to add the option before it was available. Thanks for your work! Thomas On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi wrote: > Hi, Dan and all > > I have updated webrev at: > http://cr.openjdk.java.net/~minqi/8074354/webrev03/ > > 1) bug changed synopsis > 8074354: Make CreateMinidumpOnCrash a new name and available on all > platforms > 2) tests: JPRT, vm.runtime.quick.testlist (on Windows), jtreg on Windows > and Linux/Unix. > > Thanks > Yumin > > > On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: > >> I believe there are both JavaTest/JTREG tests in the hotspot repo >> and there are VM/NSK tests from back when we did phone home... >> >> Check with Christian or Misha... >> >> Dan >> >> >> On 3/12/15 1:50 PM, Yumin Qi wrote: >> >>> Thanks, Dan >>> >>> Will look at and run those tests. Are they under nsk? >>> >>> Yumin >>> >>> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >>> >>>> Yumin, >>>> >>>> There are some error handler tests. You should find those and make >>>> sure that you run them on Windows since you're changing the order >>>> there... >>>> >>>> Dan >>>> >>>> >>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>> >>>>> Hi, Thomas and all >>>>> >>>>> The second version of the change: >>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>>> >>>>> In this version: >>>>> 1) switch order on Windows to first print log file as other >>>>> platform, then dump core file if needed. When VMError created after crash, >>>>> siginfo and context which are ExceptionRecord and ContextRecord on Windows >>>>> are recorded, mini (or full, due to 'or' used so type will be mini anyway) >>>>> dump creates dump file based on those two as before. >>>>> 2) to make os::abort to get above two pointers, added two more >>>>> fields to the function parameters: >>>>> 3) changes for test/runtime/ErrorHandling/SecondaryError.java --- >>>>> added "-XX:-CreateCoredumpOnCrash" >>>>> >>>>> - static void abort(bool dump_core = true); >>>>> + static void abort(bool dump_core = true, void *siginfo = NULL, >>>>> void *context = NULL); >>>>> >>>>> Tests: JPRT and manually. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>>>> >>>>>> Hi Yumin, >>>>>> >>>>>> There is also test/runtime/ErrorHandling/SecondaryErrorTest.java - >>>>>> could you please add "-XX:-CreateCoredumpOnCrash" ? Thank you! >>>>>> >>>>>> Beyond that, as I wrote in the bug report comments: >>>>>> >>>>>> "This is also a problem on Windows - MiniDumpWriteDump() may hang >>>>>> infinitly. And on Windows this is worse than under UNIX because we create >>>>>> the Dump before writing the hs-err file, so if the Dump hangs, we get no >>>>>> error log. I would like to revert the order: create the minidump after >>>>>> writing the error log, the same way Unix does it. We did this in our JVM >>>>>> (SAP) because for us, error logs are more useful than minidumps. " >>>>>> >>>>>> So, I would like to see os::abort on Windows call >>>>>> MiniDumpWriteDump(), and thus the mini dump writing moved after the error >>>>>> log writing. This would also make the code way cleaner because the control >>>>>> flow would be the same on all platforms. >>>>>> >>>>>> I understand that this may be out of scope for your change, but I >>>>>> would like to know what others think about this. >>>>>> >>>>>> Kind regards, Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >>>>> > wrote: >>>>>> >>>>>> Please review: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>>> >>>>>> >>>>>> Summary: Tests timed out when VM crashes and dumping core file >>>>>> which in the test case is not needed. To make core not created, >>>>>> the fix changed CreateMinidumpOnCrash to CreateCoredumpOnCrash, >>>>>> the former is only used on Windows and the latter for all >>>>>> platforms. When VM crashes on non Windows, core file generated as >>>>>> default if OS sets core dump allowed. Default value of >>>>>> CreateCoredumpOnCrash set to 'true' to keep same behavior on non >>>>>> Windows platforms, but changed for Windows --- original is false, >>>>>> not create minidump on Windows. With CreateCoredumpOnCrash turned >>>>>> off, no core file will be generated. CreateMinidumpOnCrash still >>>>>> can be used on commandline but only as alias for the new flag. >>>>>> >>>>>> Tests: JPRT, manual tests setting CreateMinidumpOnCrash on >>>>>> commandline to verify flag change as alias. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From dmitry.dmitriev at oracle.com Wed Mar 18 13:47:25 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 18 Mar 2015 16:47:25 +0300 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: <5508CBCE.9070600@oracle.com> References: <5508503A.8080101@oracle.com> <5508CBCE.9070600@oracle.com> Message-ID: <550981ED.2080606@oracle.com> Hello David, Thank you for review and sponsorship! I add suggested comment: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.01/ Regards, Dmitry On 18.03.2015 3:50, David Holmes wrote: > Hi Dmitry, > > On 18/03/2015 2:03 AM, Dmitry Dmitriev wrote: >> Hello, >> >> Please review this small fix which remove old deprecated >> options(regarding to JDK 9) from obsolete_jvm_flags table. > > We could completely re-do the obsolete option mechanism now that hsx > is not an issue, but simply deleting all the already invalid options > is fine. Though some additional commentary we be useful: > > 241 * limit, we flatly refuse to admit the existence of the flag. > This allows > 242 * a flag to die correctly over JDK releases using HSX. > + * But now that HSX is no longer supported only options > + * with a future accept_until value need to be listed, and > + * the list can be pruned on each major release. > >> Also, I need a sponsor for this fix, who can push it, because I'm not >> have a OpenJDK name. > > I can sponsor this. > > Thanks, > David > >> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ >> >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 >> >> Thank you, >> Dmitry From harold.seigel at oracle.com Wed Mar 18 14:32:11 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 18 Mar 2015 10:32:11 -0400 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <55087B31.2030203@oracle.com> References: <5508747B.7000602@oracle.com> <55087B31.2030203@oracle.com> Message-ID: <55098C6B.5080409@oracle.com> Hi, Please review this new fix for JDK-8075118. This fix keeps a list of catch handlers that have been scanned to prevent the infinite loop described below. This change removes the previous fix's check if the catch handler is inside the TRY block, preventing the problem that Dean brought up. The webrev includes 2 tests, HandlerInTry.jasm, that is based on the test case provided in the bug, that caused the infinite loop. And, IsolatedHandlerInTry.jasm, that tests a catch handler that is inside its TRY block but only reachable as a handler. Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/ The new fix was tested with the test program provided by the bug, the JCK Lang, VM, and API tests, the testbase quick and split verifier tests, the JTREG hotspot tests, and with the two tests described above. Thanks, Harold On 3/17/2015 3:06 PM, Dean Long wrote: > Hi Harold. How does this change guarantee that the catch handler is > always scanned? If it was an island of code surrounded by gotos, so > that it is only reachable through the handler, then it looks like it > will now be skipped entirely. > > dl > > On 3/17/2015 11:37 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for bug JDK-8075118. The code being verified >> contained a TRY block whose catch handler was inside the TRY block. >> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY >> block and then scans the bytecodes in the TRY block's handler and >> then scans the bytecodes of its handler's handler, etc. Since, the >> bytecodes in the handler and the bytecode's handler's handler were >> the same, it just kept scanning the same bytecodes over and over. >> >> The fix prevents re-scanning a handler's bytecodes if they are >> contained in the TRY block. >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 >> >> The fix was tested with the test program provided by the bug, the JCK >> Lang, VM, and API tests, the testbase quick and split verifier tests, >> and with the JTREG hotspot tests. >> >> Thanks! Harold > From gerard.ziemski at oracle.com Wed Mar 18 14:42:47 2015 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 18 Mar 2015 09:42:47 -0500 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: <5508503A.8080101@oracle.com> References: <5508503A.8080101@oracle.com> Message-ID: <55098EE7.4010003@oracle.com> Looks good to me - a reviewer with small "r". cheers On 3/17/2015 11:03 AM, Dmitry Dmitriev wrote: > Hello, > > Please review this small fix which remove old deprecated > options(regarding to JDK 9) from obsolete_jvm_flags table. > > Also, I need a sponsor for this fix, who can push it, because I'm not > have a OpenJDK name. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ > > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 > > Thank you, > Dmitry > > From volker.simonis at gmail.com Wed Mar 18 15:01:21 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Mar 2015 16:01:21 +0100 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: <550981ED.2080606@oracle.com> References: <5508503A.8080101@oracle.com> <5508CBCE.9070600@oracle.com> <550981ED.2080606@oracle.com> Message-ID: Hi Dmitry, can you please make sure that none of these options which you will remove is still used anywhere else in the sources. I've just cherry-picked some of the options and saw that for example UseVectoredExceptions is still present in ../hotspot/src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp and ../hotspot/src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp for example. Thanks, Volker On Wed, Mar 18, 2015 at 2:47 PM, Dmitry Dmitriev wrote: > Hello David, > > Thank you for review and sponsorship! > > I add suggested comment: > http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.01/ > > > Regards, > Dmitry > > > On 18.03.2015 3:50, David Holmes wrote: >> >> Hi Dmitry, >> >> On 18/03/2015 2:03 AM, Dmitry Dmitriev wrote: >>> >>> Hello, >>> >>> Please review this small fix which remove old deprecated >>> options(regarding to JDK 9) from obsolete_jvm_flags table. >> >> >> We could completely re-do the obsolete option mechanism now that hsx is >> not an issue, but simply deleting all the already invalid options is fine. >> Though some additional commentary we be useful: >> >> 241 * limit, we flatly refuse to admit the existence of the flag. This >> allows >> 242 * a flag to die correctly over JDK releases using HSX. >> + * But now that HSX is no longer supported only options >> + * with a future accept_until value need to be listed, and >> + * the list can be pruned on each major release. >> >>> Also, I need a sponsor for this fix, who can push it, because I'm not >>> have a OpenJDK name. >> >> >> I can sponsor this. >> >> Thanks, >> David >> >>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ >>> >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 >>> >>> Thank you, >>> Dmitry > > From dmitry.dmitriev at oracle.com Wed Mar 18 15:27:27 2015 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Wed, 18 Mar 2015 18:27:27 +0300 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: References: <5508503A.8080101@oracle.com> <5508CBCE.9070600@oracle.com> <550981ED.2080606@oracle.com> Message-ID: <5509995F.60601@oracle.com> Hi Volker, Recently I perform analysis of these flags and results are below: UseVectoredExceptions option was removed from specified files by https://bugs.openjdk.java.net/browse/JDK-8073990 but fix is not propagated to the jdk9/dev. All other options are not exists in the sources except for DesiredMethodLimit. DesiredMethodLimit option exist and used in source code, but it defined as "develop" option. This option was added to the obsolete_jvm_flags to eliminate difference between options in oracle and openjdk builds(https://bugs.openjdk.java.net/browse/JDK-7061192). There are no reasons to keep it in obsolete_jvm_flags because accept_until for this option is JDK8 and for JDK9 this option will be skipped in obsolete_jvm_flags. Regards, Dmitry On 18.03.2015 18:01, Volker Simonis wrote: > Hi Dmitry, > > can you please make sure that none of these options which you will > remove is still used anywhere else in the sources. I've just > cherry-picked some of the options and saw that for example > UseVectoredExceptions is still present in > ../hotspot/src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp and > ../hotspot/src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp for example. > > > Thanks, > Volker > > > On Wed, Mar 18, 2015 at 2:47 PM, Dmitry Dmitriev > wrote: >> Hello David, >> >> Thank you for review and sponsorship! >> >> I add suggested comment: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.01/ >> >> >> Regards, >> Dmitry >> >> >> On 18.03.2015 3:50, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 18/03/2015 2:03 AM, Dmitry Dmitriev wrote: >>>> Hello, >>>> >>>> Please review this small fix which remove old deprecated >>>> options(regarding to JDK 9) from obsolete_jvm_flags table. >>> >>> We could completely re-do the obsolete option mechanism now that hsx is >>> not an issue, but simply deleting all the already invalid options is fine. >>> Though some additional commentary we be useful: >>> >>> 241 * limit, we flatly refuse to admit the existence of the flag. This >>> allows >>> 242 * a flag to die correctly over JDK releases using HSX. >>> + * But now that HSX is no longer supported only options >>> + * with a future accept_until value need to be listed, and >>> + * the list can be pruned on each major release. >>> >>>> Also, I need a sponsor for this fix, who can push it, because I'm not >>>> have a OpenJDK name. >>> >>> I can sponsor this. >>> >>> Thanks, >>> David >>> >>>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ >>>> >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 >>>> >>>> Thank you, >>>> Dmitry >> From volker.simonis at gmail.com Wed Mar 18 16:04:32 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Mar 2015 17:04:32 +0100 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: <5509995F.60601@oracle.com> References: <5508503A.8080101@oracle.com> <5508CBCE.9070600@oracle.com> <550981ED.2080606@oracle.com> <5509995F.60601@oracle.com> Message-ID: Hi Dmitry, sorry, you're right. I looked in the wrong repository. I'm fine with your change now. Regards, Volker On Wed, Mar 18, 2015 at 4:27 PM, Dmitry Dmitriev wrote: > Hi Volker, > > Recently I perform analysis of these flags and results are below: > UseVectoredExceptions option was removed from specified files by > https://bugs.openjdk.java.net/browse/JDK-8073990 but fix is not propagated > to the jdk9/dev. > > All other options are not exists in the sources except for > DesiredMethodLimit. DesiredMethodLimit option exist and used in source code, > but it defined as "develop" option. This option was added to the > obsolete_jvm_flags to eliminate difference between options in oracle and > openjdk builds(https://bugs.openjdk.java.net/browse/JDK-7061192). There are > no reasons to keep it in obsolete_jvm_flags because accept_until for this > option is JDK8 and for JDK9 this option will be skipped in > obsolete_jvm_flags. > > Regards, > Dmitry > > > On 18.03.2015 18:01, Volker Simonis wrote: >> >> Hi Dmitry, >> >> can you please make sure that none of these options which you will >> remove is still used anywhere else in the sources. I've just >> cherry-picked some of the options and saw that for example >> UseVectoredExceptions is still present in >> ../hotspot/src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp and >> ../hotspot/src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp for example. >> >> >> Thanks, >> Volker >> >> >> On Wed, Mar 18, 2015 at 2:47 PM, Dmitry Dmitriev >> wrote: >>> >>> Hello David, >>> >>> Thank you for review and sponsorship! >>> >>> I add suggested comment: >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.01/ >>> >>> >>> Regards, >>> Dmitry >>> >>> >>> On 18.03.2015 3:50, David Holmes wrote: >>>> >>>> Hi Dmitry, >>>> >>>> On 18/03/2015 2:03 AM, Dmitry Dmitriev wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review this small fix which remove old deprecated >>>>> options(regarding to JDK 9) from obsolete_jvm_flags table. >>>> >>>> >>>> We could completely re-do the obsolete option mechanism now that hsx is >>>> not an issue, but simply deleting all the already invalid options is >>>> fine. >>>> Though some additional commentary we be useful: >>>> >>>> 241 * limit, we flatly refuse to admit the existence of the flag. This >>>> allows >>>> 242 * a flag to die correctly over JDK releases using HSX. >>>> + * But now that HSX is no longer supported only options >>>> + * with a future accept_until value need to be listed, and >>>> + * the list can be pruned on each major release. >>>> >>>>> Also, I need a sponsor for this fix, who can push it, because I'm not >>>>> have a OpenJDK name. >>>> >>>> >>>> I can sponsor this. >>>> >>>> Thanks, >>>> David >>>> >>>>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ >>>>> >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 >>>>> >>>>> Thank you, >>>>> Dmitry >>> >>> > From yumin.qi at oracle.com Wed Mar 18 17:06:27 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 18 Mar 2015 10:06:27 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> Message-ID: <5509B093.30904@oracle.com> On 3/18/2015 4:26 AM, Thomas St?fe wrote: > Hi Yumin, > > - just aesthetics, but on all implementations of os_abort(), at least > on the UNIX variants, maybe we could consistently rename the > parameters to be "siginfo" and "context" instead of using Windows terms? > Sure. > - On check_create_dump_limit(), you do not need exceptionRecord, > contextRecord parameters anymore. The only parameters now needed are > buffer and buffer size, which is not even an output parameter, just a > scratch buffer for this function to use for printf. For output, it > calls VMError::report_coredump_status(...) at the end to provide > information about the core file. > > - I would rename that function from check_create_dump_limit() to > check_dump_limit() - nothing is created anymore. > Yes, no need to carry those two parameters. I tried to keep less changes, but decided to change now. > - on Windows, in os::abort(), there is no point anymore in calling > VMError::report_coredump_status(...) because that information is only > used during error log writing which already happened. It only makes > sense to call this function in check_create_dump_limit(), which > happens before error log writing. > Instead, maybe error messages like "Call to MiniDumpWriteDump() > failed" should just be written to stderr? This would be consistent > with Unix, where the OS writes a short message on stderr if core file > writing fails. > Sure, will direct output to stderr. > - there is now a new test, > test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java - could > you please also add "-XX:-CreateCoredumpOnCrash" ? I just added the > test and did not want to add the option before it was available. > OK Thanks Yumin > Thanks for your work! > > Thomas > > > On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi > wrote: > > Hi, Dan and all > > I have updated webrev at: > http://cr.openjdk.java.net/~minqi/8074354/webrev03/ > > > 1) bug changed synopsis > 8074354: Make CreateMinidumpOnCrash a new name and > available on all platforms > 2) tests: JPRT, vm.runtime.quick.testlist (on Windows), jtreg on > Windows and Linux/Unix. > > Thanks > Yumin > > > On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: > > I believe there are both JavaTest/JTREG tests in the hotspot repo > and there are VM/NSK tests from back when we did phone home... > > Check with Christian or Misha... > > Dan > > > On 3/12/15 1:50 PM, Yumin Qi wrote: > > Thanks, Dan > > Will look at and run those tests. Are they under nsk? > > Yumin > > On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: > > Yumin, > > There are some error handler tests. You should find > those and make > sure that you run them on Windows since you're > changing the order > there... > > Dan > > > On 3/12/15 12:42 PM, Yumin Qi wrote: > > Hi, Thomas and all > > The second version of the change: > webrev: > http://cr.openjdk.java.net/~minqi/8074354/webrev02/ > > In this version: > 1) switch order on Windows to first print log > file as other platform, then dump core file if > needed. When VMError created after crash, siginfo > and context which are ExceptionRecord and > ContextRecord on Windows are recorded, mini (or > full, due to 'or' used so type will be mini > anyway) dump creates dump file based on those two > as before. > 2) to make os::abort to get above two pointers, > added two more fields to the function parameters: > 3) changes for > test/runtime/ErrorHandling/SecondaryError.java --- > added "-XX:-CreateCoredumpOnCrash" > > - static void abort(bool dump_core = true); > + static void abort(bool dump_core = true, > void *siginfo = NULL, void *context = NULL); > > Tests: JPRT and manually. > > Thanks > Yumin > > On 3/11/2015 3:47 AM, Thomas St?fe wrote: > > Hi Yumin, > > There is also > test/runtime/ErrorHandling/SecondaryErrorTest.java > - could you please add > "-XX:-CreateCoredumpOnCrash" ? Thank you! > > Beyond that, as I wrote in the bug report > comments: > > "This is also a problem on Windows - > MiniDumpWriteDump() may hang infinitly. And on > Windows this is worse than under UNIX because > we create the Dump before writing the hs-err > file, so if the Dump hangs, we get no error > log. I would like to revert the order: create > the minidump after writing the error log, the > same way Unix does it. We did this in our JVM > (SAP) because for us, error logs are more > useful than minidumps. " > > So, I would like to see os::abort on Windows > call MiniDumpWriteDump(), and thus the mini > dump writing moved after the error log > writing. This would also make the code way > cleaner because the control flow would be the > same on all platforms. > > I understand that this may be out of scope for > your change, but I would like to know what > others think about this. > > Kind regards, Thomas > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi > > >> wrote: > > Please review: > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074354 > webrev: > http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > > > > Summary: Tests timed out when VM crashes > and dumping core file > which in the test case is not needed. To > make core not created, > the fix changed CreateMinidumpOnCrash to > CreateCoredumpOnCrash, > the former is only used on Windows and the > latter for all > platforms. When VM crashes on non Windows, > core file generated as > default if OS sets core dump allowed. > Default value of > CreateCoredumpOnCrash set to 'true' to > keep same behavior on non > Windows platforms, but changed for Windows > --- original is false, > not create minidump on Windows. With > CreateCoredumpOnCrash turned > off, no core file will be generated. > CreateMinidumpOnCrash still > can be used on commandline but only as > alias for the new flag. > > Tests: JPRT, manual tests setting > CreateMinidumpOnCrash on > commandline to verify flag change as alias. > > Thanks > Yumin > > > > > > > > From jeremymanson at google.com Wed Mar 18 17:04:47 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 18 Mar 2015 10:04:47 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <550929D6.2050509@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> Message-ID: Okay. Here you go: http://cr.openjdk.java.net/~jmanson/8074895/webrev.03/index.html Jeremy On Wed, Mar 18, 2015 at 12:31 AM, David Holmes wrote: > On 18/03/2015 4:15 PM, Jeremy Manson wrote: > >> Oops... Should I fix it, post a patch, and hope it compiles? >> > > Please :) I can check the compiles part. > > David > > On Tue, Mar 17, 2015 at 9:09 PM, David Holmes > > wrote: >> >> Sorry Jeremy, the patch failed on Windows as there is another usage >> in os_windows.cpp: >> >> void os::init_system_properties___values() { >> // sysclasspath, java_home, dll_dir >> { >> char *home_path; >> char *dll_path; >> char *pslash; >> char *bin = "\\bin"; >> char home_dir[MAX_PATH]; >> >> if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, MAX_PATH)) { >> >> David >> >> >> On 18/03/2015 12:01 PM, David Holmes wrote: >> >> Submitting via JPRT. >> >> Thanks, >> David >> >> On 18/03/2015 4:13 AM, Jeremy Manson wrote: >> >> >> >> On Sun, Mar 15, 2015 at 10:04 PM, David Holmes >> >> > >> wrote: >> >> Hi Jeremy, >> >> On 14/03/2015 3:00 AM, Jeremy Manson wrote: >> >> Thanks, David! New rev: >> >> http://cr.openjdk.java.net/~____jmanson/8074895/webrev.01/ >> >> >> > > >> >> >> Looks good. Please update copyright dates in >> memTracker.cpp and >> vmError.cpp. >> >> >> Done. Thanks for the review, and for feeding it through the >> other >> platforms! >> >> http://cr.openjdk.java.net/~__jmanson/8074895/webrev.02/ >> >> >> Jeremy >> >> >> From harold.seigel at oracle.com Wed Mar 18 18:18:20 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 18 Mar 2015 14:18:20 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> Message-ID: <5509C16C.2050401@oracle.com> Hi Karen, The fix does not affect normal verifier type-state (stack map) checking that is done when looping through the bytecodes. It only affects whether the incoming or outgoing type-state is used when comparing the type-state at a particular bytecode with the type-state at the start of its potential exception handlers. In addition, (to paraphrase Keith's comment in the bug), it only affects instructions that set the type of a local slot (astore and friends) ... . Instructions that affect the expression stack are not a problem since the type-state's stack is cleared when type checking an exception handler. So, other bytecodes such as aload and friends, getstatic and getfield, etc. are not an issue. Thanks, Harold On 3/16/2015 3:49 PM, Karen Kinnear wrote: > Harold, > > Thanks for helping me walk through this in more detail. > > The way I read this, the fix would apply to all bytecodes - except for > invokespecial - which is handled I believe correctly inside the > verify_invoke_init. > > So if you could possibly experiment with some additional instructions - I suspect > you can make a conditional check where you put the beginning check and remove > the check at the end. > > thanks, > Karen > > On Mar 15, 2015, at 8:58 PM, David Holmes wrote: > >> Hi Harold, >> On 14/03/2015 4:06 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for bug JDK-7127066. The fix applies to astore* >>> bytecodes because, when inside an exception handler, they can reference >>> the thrown object and modify the number of stack locals, enabling the >>> incorrect stack match. >>> >>> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>> >>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>> java/lang, java/io, and java/util tests, and testbase quick and split >>> verifier tests, and with the test case provided in the bug. >> The new check looks okay, though I can't verify the exact placement of it. >> >> Thanks, >> David >> >>> Thanks! Harold From coleen.phillimore at oracle.com Wed Mar 18 19:58:22 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Mar 2015 15:58:22 -0400 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <550222F6.7020503@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> Message-ID: <5509D8DE.9010707@oracle.com> Hi, When I build a zero interpreter, I get a crash in SafeFetch32 from the test. Is this patch missing support for Zero? thanks, coleen On 3/12/15, 7:36 PM, David Holmes wrote: > All looking good so pushing now. > > Thanks, > David > > On 12/03/2015 10:22 PM, David Holmes wrote: >> Hi Thomas, >> >> I'll try to re-test this internally in the morning. Sorry for the delay. >> >> David >> >> On 12/03/2015 3:10 AM, Thomas St?fe wrote: >>> Hi Goetz, >>> >>> thanks for reviewing! >>> >>> Here the updated changes: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.03/webrev/ >>> >>> - I changed os_linux_sparc.cpp to reflect your comments: removed >>> set_cont_address() and replaced it with ucontext_set_pc(). However, >>> I do >>> not have a linux sparc machine to build and test, so the change is made >>> blind. Hope it does not break. >>> >>> - I removed the "CanUseSafeFetch.." calls from the initial test >>> routine. >>> Originally I was afraid there were platforms where there are no >>> implementations for SafeFetch32 or SafeFetchN, but that does not >>> seem to >>> be the case. Hopefully, I cannot speak for arm or whatever other closed >>> platforms are there. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Wed, Mar 11, 2015 at 4:17 PM, Lindenmaier, Goetz >>> > wrote: >>> >>> Hi Thomas, >>> >>> I had a look at your change. I'm fine with it, except for two >>> minor >>> things: >>> >>> os_linux_sparc.cpp >>> Why didn't you just replace set_cont_address by ucontext_set_pc on >>> linux_sparc? >>> As it is now, ucontext_set_pc is just a rename of an existing >>> function. >>> >>> stubRoutines.cpp: >>> Why do you test for availability of the stubs when testing them? I >>> would consider >>> it a bug if the stub is not generated at that point, and that would >>> not be seen here >>> as is now. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -----Original Message----- >>> From: hotspot-runtime-dev >>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net >>> ] On Behalf Of >>> Thomas St?fe >>> Sent: Dienstag, 10. M?rz 2015 18:21 >>> To: David Holmes >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> >>> Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not >>> work >>> in error handling >>> >>> Hi David, >>> >>> see here my new patch: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ >>> >>> Turns out that SafeFetch32 does not work in 32bit windows during >>> initialization, because there is no SEH exception guard >>> installed at >>> that >>> time (during the call to CreateJavaVM). Neither is there one for >>> 64bit >>> Windows, but there, we register SEH handlers for dynamic code, that >>> hides >>> the error. >>> >>> This is an issue I'd like to address with a separate patch (see >>> https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I >>> deactivated >>> the SafeFetch test during stub routine initialization for Windows >>> 32bit. >>> >>> Other changes in the fix: >>> - as you wished I changed the ULL literals to UCONST64 >>> - I activated the Jtreg test for windows too (SafeFetch works on >>> windows >>> during error handling, only not during initialization). >>> >>> Thomas >>> >>> >>> >>> >>> >>> On Mon, Mar 9, 2015 at 11:06 PM, David Holmes >>> > >>> wrote: >>> >>> > On 10/03/2015 2:30 AM, Thomas St?fe wrote: >>> > >>> >> Hi David, >>> >> >>> >> I see now that only Windows 32bit is broken. I will investigate >>> this. >>> >> >>> > >>> > Yes, sorry, I hadn't noticed it was only 32-bit failing. >>> > >>> > Thanks, >>> > David >>> > >>> > Thomas >>> >> >>> >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe >>> >>> >> >> >> wrote: >>> >> >>> >> Hi David, >>> >> >>> >> I am sorry, but I am unable to reproduce the error. Both >>> slowdebug >>> >> and fastdebug builds on Windows come up and SafeFetch works >>> (also in >>> >> error handling). Are you sure the crash is caused by my >>> change? If >>> >> yes, could you send me an hs-err file or at least the >>> configure line >>> >> you used for building? >>> >> >>> >> Kind Regards, Thomas >>> >> >>> >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes >>> >> >>> >> >>> wrote: >>> >> >>> >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >>> >> >>> >> Hi David, >>> >> >>> >> Ouch. The only thing I can think about are the >>> added >>> >> initialization >>> >> tests in stubRoutines.cpp. I will check this. >>> >> >>> >> >>> >> Ah! It hadn't registered with me that this test code >>> was >>> going >>> >> to be executed. Seems the likely cause as a clean repo >>> has no >>> >> problems. >>> >> >>> >> David >>> >> >>> >> Kind Regards, Thomas >>> >> >>> >> >>> >> >>> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >>> >> >> >> > >>> >> >> __com >>> >> >> >>> wrote: >>> >> >>> >> Hi Thomas, >>> >> >>> >> FYI When I applied this to latest hs-rt forest >>> and ran >>> >> through JPRT >>> >> the Windows fastdebug builds were DOA (instant >>> segfault >>> >> just running >>> >> "java -version"). Can't see how your changes >>> could do >>> >> this so >>> >> running a test on unmodified forest. >>> >> >>> >> David >>> >> >>> >> >>> >> On 9/03/2015 9:40 AM, David Holmes wrote: >>> >> >>> >> Hi Thomas, >>> >> >>> >> Minor nit: in >>> >> >>> >> src/share/vm/runtime/____stubRoutines.cpp::test_____ >>> >> safefetchN >>> >> can >>> >> you use UCONST64 macro instead of explicit >>> ULL - >>> >> thanks. >>> >> >>> >> Otherwise this seems okay, but we will >>> also >>> need >>> >> the aarch64 >>> >> component >>> >> (and I'll look into our internal needs). >>> >> >>> >> Thanks, >>> >> David >>> >> >>> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >>> >> >>> >> Hi all, >>> >> >>> >> could someone please review the >>> following fix >>> >> (I also will >>> >> need a >>> >> sponsor): >>> >> >>> >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ >>> >> webrev.____01/ >>> >> >>> >> >> webrev.__01/> >>> >> >>> >> >>> >> >> webrev.__01/ >>> >> >>> >> >> 01/>> >>> >> >>> >> https://bugs.openjdk.java.net/____browse/JDK-8074552 >>> >> >>> >> >>> >> >>> >> >> >> >>> >> > >>> >> >>> >> The fix will make SafeFetch[32,N] work >>> in error >>> >> reporting. >>> >> >>> >> At SAP, we use SafeFetch a lot in >>> error >>> >> reporting to poke >>> >> around in >>> >> potentially invalid memory (e.g. >>> writing hex >>> >> dumps over >>> >> areas which >>> >> may be >>> >> partly unmapped), and we feel that >>> this >>> could >>> >> be useful for the >>> >> OpenJDK too. >>> >> >>> >> Without this fix, SafeFetch will cause >>> a crash, >>> >> the current >>> >> error >>> >> reporting >>> >> step will be interrupted and error >>> reporting >>> >> will continue >>> >> with the next >>> >> step; that is not optimal because the >>> >> interrupted step may >>> >> have shown >>> >> valuable information. >>> >> >>> >> This fix handles SafeFetch faults >>> during error >>> >> reporting the >>> >> same way as >>> >> they are handled normally. The >>> changes are: >>> >> >>> >> - handle safe fetch fault in the >>> various >>> >> (os_cpu dependend) >>> >> secondary >>> >> signal handlers >>> >> >>> >> - provide a function to check if it is >>> safe to >>> >> use SafeFetch: >>> >> CanUseSafeFetch32(). SafeFetch needs >>> stub >>> >> routines and will >>> >> crash when >>> >> used >>> >> before stub generation. >>> >> >>> >> - set_context_pc() is added which >>> complements >>> >> the existing >>> >> get_context_pc() >>> >> and all instances where the pc in >>> ucontext_t >>> >> was modified >>> >> directly are >>> >> changed to use set_context_pc() >>> >> >>> >> - in stubRoutines.cpp, a small test >>> was >>> added >>> >> to the already >>> >> existing >>> >> stub >>> >> routines tests which run at VM init >>> >> >>> >> - in vmError.cpp, a test was added to >>> test >>> >> SafeFetch during >>> >> error >>> >> reporting, similar to the tests >>> introduced for >>> >> 8065895 >>> >> >>> >> - A JTreg test was added >>> >> >>> >> Thanks and Kind Regards, >>> >> >>> >> Thomas Stuefe >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> From david.holmes at oracle.com Wed Mar 18 21:39:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2015 07:39:00 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> Message-ID: <5509F074.70501@oracle.com> On 19/03/2015 3:04 AM, Jeremy Manson wrote: > Okay. Here you go: > > http://cr.openjdk.java.net/~jmanson/8074895/webrev.03/index.html ! if (alt_home_dir != NULL) { ! strcpy(home_dir, alt_home_dir); ! } else { That needs to be strncpy limited by MAX_PATH. David > Jeremy > > On Wed, Mar 18, 2015 at 12:31 AM, David Holmes > wrote: > > On 18/03/2015 4:15 PM, Jeremy Manson wrote: > > Oops... Should I fix it, post a patch, and hope it compiles? > > > Please :) I can check the compiles part. > > David > > On Tue, Mar 17, 2015 at 9:09 PM, David Holmes > > >> wrote: > > Sorry Jeremy, the patch failed on Windows as there is > another usage > in os_windows.cpp: > > void os::init_system_properties_____values() { > // sysclasspath, java_home, dll_dir > { > char *home_path; > char *dll_path; > char *pslash; > char *bin = "\\bin"; > char home_dir[MAX_PATH]; > > if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, MAX_PATH)) { > > David > > > On 18/03/2015 12:01 PM, David Holmes wrote: > > Submitting via JPRT. > > Thanks, > David > > On 18/03/2015 4:13 AM, Jeremy Manson wrote: > > > > On Sun, Mar 15, 2015 at 10:04 PM, David Holmes > > > > ____com > >>> wrote: > > Hi Jeremy, > > On 14/03/2015 3:00 AM, Jeremy Manson wrote: > > Thanks, David! New rev: > > http://cr.openjdk.java.net/~______jmanson/8074895/webrev.01/ > > > > > > > > > >> > > > Looks good. Please update copyright dates in > memTracker.cpp and > vmError.cpp. > > > Done. Thanks for the review, and for feeding it > through the > other > platforms! > > http://cr.openjdk.java.net/~____jmanson/8074895/webrev.02/ > > > > > > Jeremy > > > From david.holmes at oracle.com Wed Mar 18 21:49:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2015 07:49:19 +1000 Subject: RFR(S) 8075216: Remove old flags, regarding to JDK9, from obsolete_jvm_flags In-Reply-To: <550981ED.2080606@oracle.com> References: <5508503A.8080101@oracle.com> <5508CBCE.9070600@oracle.com> <550981ED.2080606@oracle.com> Message-ID: <5509F2DF.6060600@oracle.com> Thanks Dmitry - pushing changes. David On 18/03/2015 11:47 PM, Dmitry Dmitriev wrote: > Hello David, > > Thank you for review and sponsorship! > > I add suggested comment: > http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.01/ > > > Regards, > Dmitry > > On 18.03.2015 3:50, David Holmes wrote: >> Hi Dmitry, >> >> On 18/03/2015 2:03 AM, Dmitry Dmitriev wrote: >>> Hello, >>> >>> Please review this small fix which remove old deprecated >>> options(regarding to JDK 9) from obsolete_jvm_flags table. >> >> We could completely re-do the obsolete option mechanism now that hsx >> is not an issue, but simply deleting all the already invalid options >> is fine. Though some additional commentary we be useful: >> >> 241 * limit, we flatly refuse to admit the existence of the flag. >> This allows >> 242 * a flag to die correctly over JDK releases using HSX. >> + * But now that HSX is no longer supported only options >> + * with a future accept_until value need to be listed, and >> + * the list can be pruned on each major release. >> >>> Also, I need a sponsor for this fix, who can push it, because I'm not >>> have a OpenJDK name. >> >> I can sponsor this. >> >> Thanks, >> David >> >>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075216/webrev.00/ >>> >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075216 >>> >>> Thank you, >>> Dmitry > From coleen.phillimore at oracle.com Thu Mar 19 00:36:59 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Mar 2015 20:36:59 -0400 Subject: RFR 8005521: StressMethodComparator is not thread-safe Message-ID: <550A1A2B.2090907@oracle.com> Summary: Remove the debug option. It isn't correct or tested. CCC approved. See bug for details. open webrev at http://cr.openjdk.java.net/~coleenp/8005521/ bug link https://bugs.openjdk.java.net/browse/JDK-8005521 Thanks, Coleen From dean.long at oracle.com Thu Mar 19 01:13:27 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 18 Mar 2015 18:13:27 -0700 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <55098C6B.5080409@oracle.com> References: <5508747B.7000602@oracle.com> <55087B31.2030203@oracle.com> <55098C6B.5080409@oracle.com> Message-ID: <550A22B7.1040801@oracle.com> Hi Harold, this looks good now. Thanks for adding the IsolatedHandlerInTry test. dl On 3/18/2015 7:32 AM, harold seigel wrote: > Hi, > > Please review this new fix for JDK-8075118. This fix keeps a list of > catch handlers that have been scanned to prevent the infinite loop > described below. This change removes the previous fix's check if the > catch handler is inside the TRY block, preventing the problem that > Dean brought up. > > The webrev includes 2 tests, HandlerInTry.jasm, that is based on the > test case provided in the bug, that caused the infinite loop. And, > IsolatedHandlerInTry.jasm, that tests a catch handler that is inside > its TRY block but only reachable as a handler. > > Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/ > > The new fix was tested with the test program provided by the bug, the > JCK Lang, VM, and API tests, the testbase quick and split verifier > tests, the JTREG hotspot tests, and with the two tests described above. > > Thanks, Harold > > On 3/17/2015 3:06 PM, Dean Long wrote: >> Hi Harold. How does this change guarantee that the catch handler is >> always scanned? If it was an island of code surrounded by gotos, so >> that it is only reachable through the handler, then it looks like it >> will now be skipped entirely. >> >> dl >> >> On 3/17/2015 11:37 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for bug JDK-8075118. The code being verified >>> contained a TRY block whose catch handler was inside the TRY block. >>> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY >>> block and then scans the bytecodes in the TRY block's handler and >>> then scans the bytecodes of its handler's handler, etc. Since, the >>> bytecodes in the handler and the bytecode's handler's handler were >>> the same, it just kept scanning the same bytecodes over and over. >>> >>> The fix prevents re-scanning a handler's bytecodes if they are >>> contained in the TRY block. >>> >>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 >>> >>> The fix was tested with the test program provided by the bug, the >>> JCK Lang, VM, and API tests, the testbase quick and split verifier >>> tests, and with the JTREG hotspot tests. >>> >>> Thanks! Harold >> > From george.triantafillou at oracle.com Thu Mar 19 01:15:38 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 18 Mar 2015 21:15:38 -0400 Subject: RFR 8005521: StressMethodComparator is not thread-safe In-Reply-To: <550A1A2B.2090907@oracle.com> References: <550A1A2B.2090907@oracle.com> Message-ID: <550A233A.2090405@oracle.com> Hi Coleen, This looks good! -George On 3/18/2015 8:36 PM, Coleen Phillimore wrote: > Summary: Remove the debug option. It isn't correct or tested. > > CCC approved. See bug for details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8005521/ > bug link https://bugs.openjdk.java.net/browse/JDK-8005521 > > Thanks, > Coleen From harold.seigel at oracle.com Thu Mar 19 01:26:20 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 18 Mar 2015 21:26:20 -0400 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <550A22B7.1040801@oracle.com> References: <5508747B.7000602@oracle.com> <55087B31.2030203@oracle.com> <55098C6B.5080409@oracle.com> <550A22B7.1040801@oracle.com> Message-ID: <550A25BC.7030506@oracle.com> Hi Dean, Thanks for your help. Harold On 3/18/2015 9:13 PM, Dean Long wrote: > Hi Harold, this looks good now. Thanks for adding the > IsolatedHandlerInTry test. > > dl > > On 3/18/2015 7:32 AM, harold seigel wrote: >> Hi, >> >> Please review this new fix for JDK-8075118. This fix keeps a list of >> catch handlers that have been scanned to prevent the infinite loop >> described below. This change removes the previous fix's check if >> the catch handler is inside the TRY block, preventing the problem >> that Dean brought up. >> >> The webrev includes 2 tests, HandlerInTry.jasm, that is based on the >> test case provided in the bug, that caused the infinite loop. And, >> IsolatedHandlerInTry.jasm, that tests a catch handler that is inside >> its TRY block but only reachable as a handler. >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/ >> >> The new fix was tested with the test program provided by the bug, the >> JCK Lang, VM, and API tests, the testbase quick and split verifier >> tests, the JTREG hotspot tests, and with the two tests described above. >> >> Thanks, Harold >> >> On 3/17/2015 3:06 PM, Dean Long wrote: >>> Hi Harold. How does this change guarantee that the catch handler is >>> always scanned? If it was an island of code surrounded by gotos, so >>> that it is only reachable through the handler, then it looks like it >>> will now be skipped entirely. >>> >>> dl >>> >>> On 3/17/2015 11:37 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for bug JDK-8075118. The code being >>>> verified contained a TRY block whose catch handler was inside the >>>> TRY block. Function ClassVerifier::ends_in_throw() scans the >>>> bytecodes in a TRY block and then scans the bytecodes in the TRY >>>> block's handler and then scans the bytecodes of its handler's >>>> handler, etc. Since, the bytecodes in the handler and the >>>> bytecode's handler's handler were the same, it just kept scanning >>>> the same bytecodes over and over. >>>> >>>> The fix prevents re-scanning a handler's bytecodes if they are >>>> contained in the TRY block. >>>> >>>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 >>>> >>>> The fix was tested with the test program provided by the bug, the >>>> JCK Lang, VM, and API tests, the testbase quick and split verifier >>>> tests, and with the JTREG hotspot tests. >>>> >>>> Thanks! Harold >>> >> > From david.holmes at oracle.com Thu Mar 19 01:53:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2015 11:53:26 +1000 Subject: RFR 8005521: StressMethodComparator is not thread-safe In-Reply-To: <550A1A2B.2090907@oracle.com> References: <550A1A2B.2090907@oracle.com> Message-ID: <550A2C16.10408@oracle.com> Looks good! Thanks, David On 19/03/2015 10:36 AM, Coleen Phillimore wrote: > Summary: Remove the debug option. It isn't correct or tested. > > CCC approved. See bug for details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8005521/ > bug link https://bugs.openjdk.java.net/browse/JDK-8005521 > > Thanks, > Coleen From david.holmes at oracle.com Thu Mar 19 02:05:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Mar 2015 12:05:47 +1000 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <55098C6B.5080409@oracle.com> References: <5508747B.7000602@oracle.com> <55087B31.2030203@oracle.com> <55098C6B.5080409@oracle.com> Message-ID: <550A2EFB.7060807@oracle.com> Hi Harold, On 19/03/2015 12:32 AM, harold seigel wrote: > Hi, > > Please review this new fix for JDK-8075118. This fix keeps a list of > catch handlers that have been scanned to prevent the infinite loop > described below. This change removes the previous fix's check if the > catch handler is inside the TRY block, preventing the problem that Dean > brought up. > > The webrev includes 2 tests, HandlerInTry.jasm, that is based on the > test case provided in the bug, that caused the infinite loop. And, > IsolatedHandlerInTry.jasm, that tests a catch handler that is inside its > TRY block but only reachable as a handler. > > Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/ The fix looks okay to me. The new test files need the OpenJDK copyright notice, not Oracle one. Thanks, David > The new fix was tested with the test program provided by the bug, the > JCK Lang, VM, and API tests, the testbase quick and split verifier > tests, the JTREG hotspot tests, and with the two tests described above. > > Thanks, Harold > > On 3/17/2015 3:06 PM, Dean Long wrote: >> Hi Harold. How does this change guarantee that the catch handler is >> always scanned? If it was an island of code surrounded by gotos, so >> that it is only reachable through the handler, then it looks like it >> will now be skipped entirely. >> >> dl >> >> On 3/17/2015 11:37 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for bug JDK-8075118. The code being verified >>> contained a TRY block whose catch handler was inside the TRY block. >>> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY >>> block and then scans the bytecodes in the TRY block's handler and >>> then scans the bytecodes of its handler's handler, etc. Since, the >>> bytecodes in the handler and the bytecode's handler's handler were >>> the same, it just kept scanning the same bytecodes over and over. >>> >>> The fix prevents re-scanning a handler's bytecodes if they are >>> contained in the TRY block. >>> >>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 >>> >>> The fix was tested with the test program provided by the bug, the JCK >>> Lang, VM, and API tests, the testbase quick and split verifier tests, >>> and with the JTREG hotspot tests. >>> >>> Thanks! Harold >> > From coleen.phillimore at oracle.com Thu Mar 19 02:44:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Mar 2015 22:44:35 -0400 Subject: RFR 8005521: StressMethodComparator is not thread-safe In-Reply-To: <550A2C16.10408@oracle.com> References: <550A1A2B.2090907@oracle.com> <550A2C16.10408@oracle.com> Message-ID: <550A3813.9020105@oracle.com> Thanks, David! coleen On 3/18/15, 9:53 PM, David Holmes wrote: > Looks good! > > Thanks, > David > > On 19/03/2015 10:36 AM, Coleen Phillimore wrote: >> Summary: Remove the debug option. It isn't correct or tested. >> >> CCC approved. See bug for details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8005521/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8005521 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Mar 19 02:44:51 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Mar 2015 22:44:51 -0400 Subject: RFR 8005521: StressMethodComparator is not thread-safe In-Reply-To: <550A233A.2090405@oracle.com> References: <550A1A2B.2090907@oracle.com> <550A233A.2090405@oracle.com> Message-ID: <550A3823.8080005@oracle.com> Thanks for the quick review. Coleen On 3/18/15, 9:15 PM, George Triantafillou wrote: > Hi Coleen, > > This looks good! > > -George > > On 3/18/2015 8:36 PM, Coleen Phillimore wrote: >> Summary: Remove the debug option. It isn't correct or tested. >> >> CCC approved. See bug for details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8005521/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8005521 >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Thu Mar 19 03:15:02 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 18 Mar 2015 20:15:02 -0700 Subject: RFR 8005521: StressMethodComparator is not thread-safe In-Reply-To: <550A1A2B.2090907@oracle.com> References: <550A1A2B.2090907@oracle.com> Message-ID: <550A3F36.5020508@oracle.com> Coleen, It looks good. Thanks, Serguei On 3/18/15 5:36 PM, Coleen Phillimore wrote: > Summary: Remove the debug option. It isn't correct or tested. > > CCC approved. See bug for details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8005521/ > bug link https://bugs.openjdk.java.net/browse/JDK-8005521 > > Thanks, > Coleen From thomas.stuefe at gmail.com Thu Mar 19 09:35:13 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Mar 2015 10:35:13 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <5509D8DE.9010707@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> Message-ID: Hi Coleen, this may be the case. I do not know the zero port very good. SefeFetch handling needs support from both signal handler and access routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is missing. In theory it could be added, because doing so requires no assembly of any sorts. But it looks like the zero port avoids any technique which requires fiddling around with the ucontext_t in the signal handler to jump to a continuation point. This looks intentional and I do not want to introduce any code which breaks the intention of zero port. Of course, the other way would be just to disable the test for zero. What would be the right way? Kind regards, Thomas On Wed, Mar 18, 2015 at 8:58 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > Hi, When I build a zero interpreter, I get a crash in SafeFetch32 from the > test. Is this patch missing support for Zero? > > thanks, > coleen > > > On 3/12/15, 7:36 PM, David Holmes wrote: > >> All looking good so pushing now. >> >> Thanks, >> David >> >> On 12/03/2015 10:22 PM, David Holmes wrote: >> >>> Hi Thomas, >>> >>> I'll try to re-test this internally in the morning. Sorry for the delay. >>> >>> David >>> >>> On 12/03/2015 3:10 AM, Thomas St?fe wrote: >>> >>>> Hi Goetz, >>>> >>>> thanks for reviewing! >>>> >>>> Here the updated changes: >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.03/webrev/ >>>> >>>> - I changed os_linux_sparc.cpp to reflect your comments: removed >>>> set_cont_address() and replaced it with ucontext_set_pc(). However, I do >>>> not have a linux sparc machine to build and test, so the change is made >>>> blind. Hope it does not break. >>>> >>>> - I removed the "CanUseSafeFetch.." calls from the initial test routine. >>>> Originally I was afraid there were platforms where there are no >>>> implementations for SafeFetch32 or SafeFetchN, but that does not seem to >>>> be the case. Hopefully, I cannot speak for arm or whatever other closed >>>> platforms are there. >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> On Wed, Mar 11, 2015 at 4:17 PM, Lindenmaier, Goetz >>>> > wrote: >>>> >>>> Hi Thomas, >>>> >>>> I had a look at your change. I'm fine with it, except for two minor >>>> things: >>>> >>>> os_linux_sparc.cpp >>>> Why didn't you just replace set_cont_address by ucontext_set_pc on >>>> linux_sparc? >>>> As it is now, ucontext_set_pc is just a rename of an existing >>>> function. >>>> >>>> stubRoutines.cpp: >>>> Why do you test for availability of the stubs when testing them? I >>>> would consider >>>> it a bug if the stub is not generated at that point, and that would >>>> not be seen here >>>> as is now. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: hotspot-runtime-dev >>>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net >>>> ] On Behalf Of >>>> Thomas St?fe >>>> Sent: Dienstag, 10. M?rz 2015 18:21 >>>> To: David Holmes >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> >>>> Subject: Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work >>>> in error handling >>>> >>>> Hi David, >>>> >>>> see here my new patch: >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.02/webrev/ >>>> >>>> Turns out that SafeFetch32 does not work in 32bit windows during >>>> initialization, because there is no SEH exception guard installed at >>>> that >>>> time (during the call to CreateJavaVM). Neither is there one for >>>> 64bit >>>> Windows, but there, we register SEH handlers for dynamic code, that >>>> hides >>>> the error. >>>> >>>> This is an issue I'd like to address with a separate patch (see >>>> https://bugs.openjdk.java.net/browse/JDK-8074860). For now, I >>>> deactivated >>>> the SafeFetch test during stub routine initialization for Windows >>>> 32bit. >>>> >>>> Other changes in the fix: >>>> - as you wished I changed the ULL literals to UCONST64 >>>> - I activated the Jtreg test for windows too (SafeFetch works on >>>> windows >>>> during error handling, only not during initialization). >>>> >>>> Thomas >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Mar 9, 2015 at 11:06 PM, David Holmes >>>> > >>>> wrote: >>>> >>>> > On 10/03/2015 2:30 AM, Thomas St?fe wrote: >>>> > >>>> >> Hi David, >>>> >> >>>> >> I see now that only Windows 32bit is broken. I will investigate >>>> this. >>>> >> >>>> > >>>> > Yes, sorry, I hadn't noticed it was only 32-bit failing. >>>> > >>>> > Thanks, >>>> > David >>>> > >>>> > Thomas >>>> >> >>>> >> On Mon, Mar 9, 2015 at 4:12 PM, Thomas St?fe >>>> >>>> >> >>> >> wrote: >>>> >> >>>> >> Hi David, >>>> >> >>>> >> I am sorry, but I am unable to reproduce the error. Both >>>> slowdebug >>>> >> and fastdebug builds on Windows come up and SafeFetch works >>>> (also in >>>> >> error handling). Are you sure the crash is caused by my >>>> change? If >>>> >> yes, could you send me an hs-err file or at least the >>>> configure line >>>> >> you used for building? >>>> >> >>>> >> Kind Regards, Thomas >>>> >> >>>> >> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes >>>> >> >>>> >> >>>> wrote: >>>> >> >>>> >> On 9/03/2015 4:21 PM, Thomas St?fe wrote: >>>> >> >>>> >> Hi David, >>>> >> >>>> >> Ouch. The only thing I can think about are the added >>>> >> initialization >>>> >> tests in stubRoutines.cpp. I will check this. >>>> >> >>>> >> >>>> >> Ah! It hadn't registered with me that this test code was >>>> going >>>> >> to be executed. Seems the likely cause as a clean repo >>>> has no >>>> >> problems. >>>> >> >>>> >> David >>>> >> >>>> >> Kind Regards, Thomas >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes >>>> >> >>> >>> > >>>> >> >>> __com >>>> >> >>> >>> wrote: >>>> >> >>>> >> Hi Thomas, >>>> >> >>>> >> FYI When I applied this to latest hs-rt forest >>>> and ran >>>> >> through JPRT >>>> >> the Windows fastdebug builds were DOA (instant >>>> segfault >>>> >> just running >>>> >> "java -version"). Can't see how your changes >>>> could do >>>> >> this so >>>> >> running a test on unmodified forest. >>>> >> >>>> >> David >>>> >> >>>> >> >>>> >> On 9/03/2015 9:40 AM, David Holmes wrote: >>>> >> >>>> >> Hi Thomas, >>>> >> >>>> >> Minor nit: in >>>> >> >>>> >> src/share/vm/runtime/____stubRoutines.cpp::test_____ >>>> >> safefetchN >>>> >> can >>>> >> you use UCONST64 macro instead of explicit >>>> ULL - >>>> >> thanks. >>>> >> >>>> >> Otherwise this seems okay, but we will also >>>> need >>>> >> the aarch64 >>>> >> component >>>> >> (and I'll look into our internal needs). >>>> >> >>>> >> Thanks, >>>> >> David >>>> >> >>>> >> On 7/03/2015 2:10 AM, Thomas St?fe wrote: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> could someone please review the >>>> following fix >>>> >> (I also will >>>> >> need a >>>> >> sponsor): >>>> >> >>>> >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074552/ >>>> >> webrev.____01/ >>>> >> >>>> >>> >> webrev.__01/> >>>> >> >>>> >> >>>> >>> >> webrev.__01/ >>>> >> >>>> >>> >> 01/>> >>>> >> >>>> >> https://bugs.openjdk.java.net/____browse/JDK-8074552 >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>>> >> > >>>> >> >>>> >> The fix will make SafeFetch[32,N] work >>>> in error >>>> >> reporting. >>>> >> >>>> >> At SAP, we use SafeFetch a lot in error >>>> >> reporting to poke >>>> >> around in >>>> >> potentially invalid memory (e.g. >>>> writing hex >>>> >> dumps over >>>> >> areas which >>>> >> may be >>>> >> partly unmapped), and we feel that this >>>> could >>>> >> be useful for the >>>> >> OpenJDK too. >>>> >> >>>> >> Without this fix, SafeFetch will cause >>>> a crash, >>>> >> the current >>>> >> error >>>> >> reporting >>>> >> step will be interrupted and error >>>> reporting >>>> >> will continue >>>> >> with the next >>>> >> step; that is not optimal because the >>>> >> interrupted step may >>>> >> have shown >>>> >> valuable information. >>>> >> >>>> >> This fix handles SafeFetch faults >>>> during error >>>> >> reporting the >>>> >> same way as >>>> >> they are handled normally. The >>>> changes are: >>>> >> >>>> >> - handle safe fetch fault in the >>>> various >>>> >> (os_cpu dependend) >>>> >> secondary >>>> >> signal handlers >>>> >> >>>> >> - provide a function to check if it is >>>> safe to >>>> >> use SafeFetch: >>>> >> CanUseSafeFetch32(). SafeFetch needs >>>> stub >>>> >> routines and will >>>> >> crash when >>>> >> used >>>> >> before stub generation. >>>> >> >>>> >> - set_context_pc() is added which >>>> complements >>>> >> the existing >>>> >> get_context_pc() >>>> >> and all instances where the pc in >>>> ucontext_t >>>> >> was modified >>>> >> directly are >>>> >> changed to use set_context_pc() >>>> >> >>>> >> - in stubRoutines.cpp, a small test was >>>> added >>>> >> to the already >>>> >> existing >>>> >> stub >>>> >> routines tests which run at VM init >>>> >> >>>> >> - in vmError.cpp, a test was added to >>>> test >>>> >> SafeFetch during >>>> >> error >>>> >> reporting, similar to the tests >>>> introduced for >>>> >> 8065895 >>>> >> >>>> >> - A JTreg test was added >>>> >> >>>> >> Thanks and Kind Regards, >>>> >> >>>> >> Thomas Stuefe >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >>>> >>>> > From adinn at redhat.com Thu Mar 19 11:28:30 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 19 Mar 2015 11:28:30 +0000 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> Message-ID: <550AB2DE.4000607@redhat.com> On 19/03/15 09:35, Thomas St?fe wrote: > this may be the case. I do not know the zero port very good. > > SefeFetch handling needs support from both signal handler and access > routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is > missing. > > In theory it could be added, because doing so requires no assembly of any > sorts. But it looks like the zero port avoids any technique which requires > fiddling around with the ucontext_t in the signal handler to jump to a > continuation point. This looks intentional and I do not want to introduce > any code which breaks the intention of zero port. > > Of course, the other way would be just to disable the test for zero. > > What would be the right way? Coleen, thanks very much for checking to see if this fix causes an issue for zero. Thomas, I have pointed the relevant Red Hat developers at this thread. One of them should respond soon. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From harold.seigel at oracle.com Thu Mar 19 12:42:31 2015 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 19 Mar 2015 08:42:31 -0400 Subject: RFR(XS) 8075118: JVM stuck in infinite loop during verification In-Reply-To: <550A2EFB.7060807@oracle.com> References: <5508747B.7000602@oracle.com> <55087B31.2030203@oracle.com> <55098C6B.5080409@oracle.com> <550A2EFB.7060807@oracle.com> Message-ID: <550AC437.4080201@oracle.com> Hi David, Thanks for the review. I'll fix the copyright before pushing the change. Harold On 3/18/2015 10:05 PM, David Holmes wrote: > Hi Harold, > > On 19/03/2015 12:32 AM, harold seigel wrote: >> Hi, >> >> Please review this new fix for JDK-8075118. This fix keeps a list of >> catch handlers that have been scanned to prevent the infinite loop >> described below. This change removes the previous fix's check if the >> catch handler is inside the TRY block, preventing the problem that Dean >> brought up. >> >> The webrev includes 2 tests, HandlerInTry.jasm, that is based on the >> test case provided in the bug, that caused the infinite loop. And, >> IsolatedHandlerInTry.jasm, that tests a catch handler that is inside its >> TRY block but only reachable as a handler. >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/ > > The fix looks okay to me. > > The new test files need the OpenJDK copyright notice, not Oracle one. > > Thanks, > David > >> The new fix was tested with the test program provided by the bug, the >> JCK Lang, VM, and API tests, the testbase quick and split verifier >> tests, the JTREG hotspot tests, and with the two tests described above. >> >> Thanks, Harold >> >> On 3/17/2015 3:06 PM, Dean Long wrote: >>> Hi Harold. How does this change guarantee that the catch handler is >>> always scanned? If it was an island of code surrounded by gotos, so >>> that it is only reachable through the handler, then it looks like it >>> will now be skipped entirely. >>> >>> dl >>> >>> On 3/17/2015 11:37 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for bug JDK-8075118. The code being verified >>>> contained a TRY block whose catch handler was inside the TRY block. >>>> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY >>>> block and then scans the bytecodes in the TRY block's handler and >>>> then scans the bytecodes of its handler's handler, etc. Since, the >>>> bytecodes in the handler and the bytecode's handler's handler were >>>> the same, it just kept scanning the same bytecodes over and over. >>>> >>>> The fix prevents re-scanning a handler's bytecodes if they are >>>> contained in the TRY block. >>>> >>>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/ >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8075118 >>>> >>>> The fix was tested with the test program provided by the bug, the JCK >>>> Lang, VM, and API tests, the testbase quick and split verifier tests, >>>> and with the JTREG hotspot tests. >>>> >>>> Thanks! Harold >>> >> From sgehwolf at redhat.com Thu Mar 19 14:31:32 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 19 Mar 2015 15:31:32 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <550AB2DE.4000607@redhat.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> <550AB2DE.4000607@redhat.com> Message-ID: <1426775492.27867.14.camel@redhat.com> On Thu, 2015-03-19 at 11:28 +0000, Andrew Dinn wrote: > On 19/03/15 09:35, Thomas St?fe wrote: > > this may be the case. I do not know the zero port very good. > > > > SefeFetch handling needs support from both signal handler and access > > routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is > > missing. > > > > In theory it could be added, because doing so requires no assembly of any > > sorts. But it looks like the zero port avoids any technique which requires > > fiddling around with the ucontext_t in the signal handler to jump to a > > continuation point. This looks intentional and I do not want to introduce > > any code which breaks the intention of zero port. > > > > Of course, the other way would be just to disable the test for zero. > > > > What would be the right way? Thomas, I think the way to go is to skip both, the test and the new error handler feature for Zero. Since it is C++ interpreter only, it's OK to not have this extra info in hs_err. Shark, on the other hand, is likely different but I don't know much about it. > Coleen, thanks very much for checking to see if this fix causes an issue > for zero. +1, very much appreciated! I see that this has already been pushed[1]. I'll follow up with a fix for Zero shortly (current w-i-p patch attached). Cheers, Severin [1] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > Thomas, I have pointed the relevant Red Hat developers at this thread. > One of them should respond soon. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8074552-follow-up-wip.patch Type: text/x-patch Size: 1700 bytes Desc: not available URL: From andreas.eriksson at oracle.com Thu Mar 19 16:45:06 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 19 Mar 2015 17:45:06 +0100 Subject: RFR (S): 8072588 - JVM crashes in JNI if toString is declared as an interface method In-Reply-To: <54FF1775.8020308@oracle.com> References: <54FF1775.8020308@oracle.com> Message-ID: <550AFD12.60106@oracle.com> Hi, Could someone please take a look at this? Regards, Andreas On 2015-03-10 17:10, Andreas Eriksson wrote: > Hi, > > Please review this fix for a JNI issue in jni_invoke_nonstatic. > > The problem is that when toString is declared as an interface method > it still has a vtable index, not an itable index as > jni_invoke_nonstatic expects. > > This fix checks for a valid itable index instead of checking if the > holder is an interface. > I also moved a duplicated check for JNI_VIRTUAL to be done in one > check instead. > The change has been verified to fix the problem with a small JNI test, > and has passed a jprt run with the hotspot testset. > > Webrev: > http://cr.openjdk.java.net/~aeriksso/8072588/webrev.00/ > > Regards, > Andreas From thomas.stuefe at gmail.com Thu Mar 19 18:47:54 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Mar 2015 19:47:54 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <1426775492.27867.14.camel@redhat.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> <550AB2DE.4000607@redhat.com> <1426775492.27867.14.camel@redhat.com> Message-ID: Hi Severin, thank you for fixing this! In the future I know now who to ask if a change affects zero. Thomas On Thu, Mar 19, 2015 at 3:31 PM, Severin Gehwolf wrote: > On Thu, 2015-03-19 at 11:28 +0000, Andrew Dinn wrote: > > On 19/03/15 09:35, Thomas St?fe wrote: > > > this may be the case. I do not know the zero port very good. > > > > > > SefeFetch handling needs support from both signal handler and access > > > routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is > > > missing. > > > > > > In theory it could be added, because doing so requires no assembly of > any > > > sorts. But it looks like the zero port avoids any technique which > requires > > > fiddling around with the ucontext_t in the signal handler to jump to a > > > continuation point. This looks intentional and I do not want to > introduce > > > any code which breaks the intention of zero port. > > > > > > Of course, the other way would be just to disable the test for zero. > > > > > > What would be the right way? > > Thomas, I think the way to go is to skip both, the test and the new > error handler feature for Zero. Since it is C++ interpreter only, it's > OK to not have this extra info in hs_err. > > Shark, on the other hand, is likely different but I don't know much > about it. > > > Coleen, thanks very much for checking to see if this fix causes an issue > > for zero. > > +1, very much appreciated! > > I see that this has already been pushed[1]. I'll follow up with a fix > for Zero shortly (current w-i-p patch attached). > > Cheers, > Severin > > [1] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > > Thomas, I have pointed the relevant Red Hat developers at this thread. > > One of them should respond soon. > > > > regards, > > > > > > Andrew Dinn > > ----------- > > Senior Principal Software Engineer > > Red Hat UK Ltd > > Registered in UK and Wales under Company Registration No. 3798903 > > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > > (USA), Michael O'Neill (Ireland) > > > > > > > > From coleen.phillimore at oracle.com Thu Mar 19 18:57:49 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 19 Mar 2015 14:57:49 -0400 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <1426775492.27867.14.camel@redhat.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> <550AB2DE.4000607@redhat.com> <1426775492.27867.14.camel@redhat.com> Message-ID: <550B1C2D.4090105@oracle.com> Yes, this patch looks like what I'm testing with. I also had to make this change to get it to compile on linux x64. --- a/src/cpu/zero/vm/frame_zero.cpp +++ b/src/cpu/zero/vm/frame_zero.cpp @@ -213,7 +213,7 @@ valuebuf[buflen - 1] = '\0'; // Print the result - st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf); + st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf, valuebuf); } } Thanks, Coleen On 3/19/15, 10:31 AM, Severin Gehwolf wrote: > On Thu, 2015-03-19 at 11:28 +0000, Andrew Dinn wrote: >> On 19/03/15 09:35, Thomas St?fe wrote: >>> this may be the case. I do not know the zero port very good. >>> >>> SefeFetch handling needs support from both signal handler and access >>> routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is >>> missing. >>> >>> In theory it could be added, because doing so requires no assembly of any >>> sorts. But it looks like the zero port avoids any technique which requires >>> fiddling around with the ucontext_t in the signal handler to jump to a >>> continuation point. This looks intentional and I do not want to introduce >>> any code which breaks the intention of zero port. >>> >>> Of course, the other way would be just to disable the test for zero. >>> >>> What would be the right way? > Thomas, I think the way to go is to skip both, the test and the new > error handler feature for Zero. Since it is C++ interpreter only, it's > OK to not have this extra info in hs_err. > > Shark, on the other hand, is likely different but I don't know much > about it. > >> Coleen, thanks very much for checking to see if this fix causes an issue >> for zero. > +1, very much appreciated! > > I see that this has already been pushed[1]. I'll follow up with a fix > for Zero shortly (current w-i-p patch attached). > > Cheers, > Severin > > [1] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > >> Thomas, I have pointed the relevant Red Hat developers at this thread. >> One of them should respond soon. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in UK and Wales under Company Registration No. 3798903 >> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters >> (USA), Michael O'Neill (Ireland) >> >> > > From karen.kinnear at oracle.com Thu Mar 19 19:33:13 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 19 Mar 2015 15:33:13 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <5509C16C.2050401@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> Message-ID: Harold, I get it - this only affects instructions that set the type of a local slot since the operand stack is cleared. So - what about istore? If we have a local slot that contains a long or double, Frederic reminded me that JVMS 2.6.1 does allow stores to those separate slots, e.g. an istore. My mental model of this is that it would change the type of the local slot. Would that mean we would want to check any of the *store bytecodes? (I know the spec would change for all bytecodes which might be cleaner - I suspect you are being extra cautious about making changes to reduce risk of breaking something in the field). thanks, Karen On Mar 18, 2015, at 2:18 PM, harold seigel wrote: > Hi Karen, > > The fix does not affect normal verifier type-state (stack map) checking that is done when looping through the bytecodes. It only affects whether the incoming or outgoing type-state is used when comparing the type-state at a particular bytecode with the type-state at the start of its potential exception handlers. > > In addition, (to paraphrase Keith's comment in the bug), it only affects instructions that set the type of a local slot (astore and friends) ... . Instructions that affect the expression stack are not a problem since the type-state's stack is cleared when type checking an exception handler. > > So, other bytecodes such as aload and friends, getstatic and getfield, etc. are not an issue. > > Thanks, Harold > > On 3/16/2015 3:49 PM, Karen Kinnear wrote: >> Harold, >> >> Thanks for helping me walk through this in more detail. >> >> The way I read this, the fix would apply to all bytecodes - except for >> invokespecial - which is handled I believe correctly inside the >> verify_invoke_init. >> >> So if you could possibly experiment with some additional instructions - I suspect >> you can make a conditional check where you put the beginning check and remove >> the check at the end. >> >> thanks, >> Karen >> >> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >> >>> Hi Harold, >>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for bug JDK-7127066. The fix applies to astore* >>>> bytecodes because, when inside an exception handler, they can reference >>>> the thrown object and modify the number of stack locals, enabling the >>>> incorrect stack match. >>>> >>>> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>> >>>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>>> java/lang, java/io, and java/util tests, and testbase quick and split >>>> verifier tests, and with the test case provided in the bug. >>> The new check looks okay, though I can't verify the exact placement of it. >>> >>> Thanks, >>> David >>> >>>> Thanks! Harold > From sgehwolf at redhat.com Fri Mar 20 08:27:01 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Mar 2015 09:27:01 +0100 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <550B1C2D.4090105@oracle.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> <550AB2DE.4000607@redhat.com> <1426775492.27867.14.camel@redhat.com> <550B1C2D.4090105@oracle.com> Message-ID: <1426840021.3382.12.camel@redhat.com> On Thu, 2015-03-19 at 14:57 -0400, Coleen Phillimore wrote: > Yes, this patch looks like what I'm testing with. I also had to make > this change to get it to compile on linux x64. > > --- a/src/cpu/zero/vm/frame_zero.cpp > +++ b/src/cpu/zero/vm/frame_zero.cpp > @@ -213,7 +213,7 @@ > valuebuf[buflen - 1] = '\0'; > > // Print the result > - st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf); > + st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf, > valuebuf); > } > } Interesting. I haven't seen this before. What's the exact environment you are compiling on? Which GCC? slowdebug, fastdebug or release type build? FWIW, Fedora 21 on x86_64 Zero slowdebug build didn't need this. It compiled fine here. There ought to be a way for those things to not slip through the cracks... I already have this [1] and [2]. Those are using hs-comp trees currently. I'll probably switch them over to use hs-rt instead. Thanks again, Coleen! Cheers, Severin [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/ [2] http://builder.classpath.org/jenkins/job/OpenJDK8_jdk8u_Zero/ > On 3/19/15, 10:31 AM, Severin Gehwolf wrote: > > On Thu, 2015-03-19 at 11:28 +0000, Andrew Dinn wrote: > >> On 19/03/15 09:35, Thomas St?fe wrote: > >>> this may be the case. I do not know the zero port very good. > >>> > >>> SefeFetch handling needs support from both signal handler and access > >>> routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is > >>> missing. > >>> > >>> In theory it could be added, because doing so requires no assembly of any > >>> sorts. But it looks like the zero port avoids any technique which requires > >>> fiddling around with the ucontext_t in the signal handler to jump to a > >>> continuation point. This looks intentional and I do not want to introduce > >>> any code which breaks the intention of zero port. > >>> > >>> Of course, the other way would be just to disable the test for zero. > >>> > >>> What would be the right way? > > Thomas, I think the way to go is to skip both, the test and the new > > error handler feature for Zero. Since it is C++ interpreter only, it's > > OK to not have this extra info in hs_err. > > > > Shark, on the other hand, is likely different but I don't know much > > about it. > > > >> Coleen, thanks very much for checking to see if this fix causes an issue > >> for zero. > > +1, very much appreciated! > > > > I see that this has already been pushed[1]. I'll follow up with a fix > > for Zero shortly (current w-i-p patch attached). > > > > Cheers, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 > > > >> Thomas, I have pointed the relevant Red Hat developers at this thread. > >> One of them should respond soon. > >> > >> regards, > >> > >> > >> Andrew Dinn > >> ----------- > >> Senior Principal Software Engineer > >> Red Hat UK Ltd > >> Registered in UK and Wales under Company Registration No. 3798903 > >> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > >> (USA), Michael O'Neill (Ireland) > >> > >> > > > > > From david.simms at oracle.com Fri Mar 20 09:14:25 2015 From: david.simms at oracle.com (David Simms) Date: Fri, 20 Mar 2015 10:14:25 +0100 Subject: RFR (S): 8072588 - JVM crashes in JNI if toString is declared as an interface method In-Reply-To: <550AFD12.60106@oracle.com> References: <54FF1775.8020308@oracle.com> <550AFD12.60106@oracle.com> Message-ID: <550BE4F1.70401@oracle.com> Looks good to me (not a 'R'-eviewer) I'd like to have your test checked in if possible. Native JNI testing has just recently been added, we can talk about the details off-list. /David Simms On 19/03/15 17:45, Andreas Eriksson wrote: > Hi, > > Could someone please take a look at this? > > Regards, > Andreas > > On 2015-03-10 17:10, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for a JNI issue in jni_invoke_nonstatic. >> >> The problem is that when toString is declared as an interface method >> it still has a vtable index, not an itable index as >> jni_invoke_nonstatic expects. >> >> This fix checks for a valid itable index instead of checking if the >> holder is an interface. >> I also moved a duplicated check for JNI_VIRTUAL to be done in one >> check instead. >> The change has been verified to fix the problem with a small JNI >> test, and has passed a jprt run with the hotspot testset. >> >> Webrev: >> http://cr.openjdk.java.net/~aeriksso/8072588/webrev.00/ >> >> Regards, >> Andreas > From sgehwolf at redhat.com Fri Mar 20 11:57:23 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Mar 2015 12:57:23 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 Message-ID: <1426852643.3382.50.camel@redhat.com> Hi, Could somebody please review and sponsor this patch? The commit of JDK-8074552 broke the Zero port since it performs tests on JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers (relying on a continuation scheme for safe fetch errors) work. Yet performing this test correctly requires support from the signal handler and access routines to ucontext_t which are missing for Zero. The intent of JDK-8074552 was to improve error reporting on SEGV's. Having this feature in Zero is less useful, since it's a C++ interpreter only environment. This patch disables the test and makes CanUseSafeFetch* functions return false unconditionally for Zero JVMs so as to not produce a recursive SEGV's during error reporting. I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped for Zero. bug: https://bugs.openjdk.java.net/browse/JDK-8075533 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ Testing done: make bootcycle-images fails before this patch and passes after for a Zero JVM on x86_64. Thanks, Severin From andreas.eriksson at oracle.com Fri Mar 20 14:24:18 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Fri, 20 Mar 2015 15:24:18 +0100 Subject: RFR (S): 8072588 - JVM crashes in JNI if toString is declared as an interface method In-Reply-To: <550BE4F1.70401@oracle.com> References: <54FF1775.8020308@oracle.com> <550AFD12.60106@oracle.com> <550BE4F1.70401@oracle.com> Message-ID: <550C2D92.7000806@oracle.com> Hi Karen I discussed this with David, and he thought it best if you took a look, if you can spare the time. Webrev is here: http://cr.openjdk.java.net/~aeriksso/8072588/webrev.00/ Also, we discussed another way that might solve this, which is to replace the vtable index with an itable index for interface classes. Basically, in assign_itable_indices_for_interface (klassVtable.cpp) remove the checks for if there already is a vtable index. if (!m->has_vtable_index()) { assert(m->vtable_index() == Method::pending_itable_index, "set by initialize_vtable"); m->set_itable_index(ime_num); ... Which way do you think is best? Regards, Andreas On 2015-03-20 10:14, David Simms wrote: > > Looks good to me (not a 'R'-eviewer) > > I'd like to have your test checked in if possible. Native JNI testing > has just recently been added, we can talk about the details off-list. > > /David Simms > > On 19/03/15 17:45, Andreas Eriksson wrote: >> Hi, >> >> Could someone please take a look at this? >> >> Regards, >> Andreas >> >> On 2015-03-10 17:10, Andreas Eriksson wrote: >>> Hi, >>> >>> Please review this fix for a JNI issue in jni_invoke_nonstatic. >>> >>> The problem is that when toString is declared as an interface method >>> it still has a vtable index, not an itable index as >>> jni_invoke_nonstatic expects. >>> >>> This fix checks for a valid itable index instead of checking if the >>> holder is an interface. >>> I also moved a duplicated check for JNI_VIRTUAL to be done in one >>> check instead. >>> The change has been verified to fix the problem with a small JNI >>> test, and has passed a jprt run with the hotspot testset. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~aeriksso/8072588/webrev.00/ >>> >>> Regards, >>> Andreas >> > From volker.simonis at gmail.com Fri Mar 20 15:17:29 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 20 Mar 2015 16:17:29 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <1426852643.3382.50.camel@redhat.com> References: <1426852643.3382.50.camel@redhat.com> Message-ID: Hi Severin, I can't understand how SafeFetch32 and SafeFetchN are supposed to work at all in Zero. The whole point of having the SafeFetch routines is to have a possibility of peeking at potentially illegal memory addresses. The current implementation of SafeFetch on Zero can not provide this functionality so in my eyes it is useless. I think we should do the following: - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero (this way the unmodified CanUseSafeFetchXX() routines would work for Zero as well) - remove the implementations of SafeFetchN and SafeFetch32 and set StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry to NULL in stubGenerator_zero.cpp (this will automatically make StubRoutines::SafeFetchN_stub() return null on Zero) - the calls to test_safefetch32XX() should be guarded by CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in stubRoutines.cpp) The test changes are good. Regards, Volker On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this patch? > > The commit of JDK-8074552 broke the Zero port since it performs tests on > JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers > (relying on a continuation scheme for safe fetch errors) work. Yet > performing this test correctly requires support from the signal handler > and access routines to ucontext_t which are missing for Zero. > > The intent of JDK-8074552 was to improve error reporting on SEGV's. > Having this feature in Zero is less useful, since it's a C++ interpreter > only environment. > > This patch disables the test and makes CanUseSafeFetch* functions return > false unconditionally for Zero JVMs so as to not produce a recursive > SEGV's during error reporting. > > I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped > for Zero. > > bug: https://bugs.openjdk.java.net/browse/JDK-8075533 > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ > > Testing done: make bootcycle-images fails before this patch and passes > after for a Zero JVM on x86_64. > > Thanks, > Severin > From thomas.stuefe at gmail.com Fri Mar 20 16:39:52 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 20 Mar 2015 17:39:52 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: References: <1426852643.3382.50.camel@redhat.com> Message-ID: Hi Volker, Serverin, On Fri, Mar 20, 2015 at 4:17 PM, Volker Simonis wrote: > Hi Severin, > > I can't understand how SafeFetch32 and SafeFetchN are supposed to work > at all in Zero. The whole point of having the SafeFetch routines is to > have a possibility of peeking at potentially illegal memory addresses. > The current implementation of SafeFetch on Zero can not provide this > functionality so in my eyes it is useless. > > I do not think there is a hard technical reason preventing us from doing this on zero. See the short discussion at the end of: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014231.html You need the stub routines and a bit of handling in the signal handlers. >From what I understood it was a decision of the zero people not to support it. I think we should do the following: > - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero > (this way the unmodified CanUseSafeFetchXX() routines would work for > Zero as well) > - remove the implementations of SafeFetchN and SafeFetch32 and set > StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry > to NULL in stubGenerator_zero.cpp (this will automatically make > StubRoutines::SafeFetchN_stub() return null on Zero) > I agree with all that. Unless we question the decision to not support SafeFetch and add support to it on zero, it is quite handy after all. > - the calls to test_safefetch32XX() should be guarded by > CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in > stubRoutines.cpp) > Talk to Goetz :) I did this originally (guarding test_safeFetch() with CanUseSafeFetch()), and his wish was to remove that condition; reason was that we thought that all platforms support SafeFetch and hence the test was unneccessary. We just did not think of zero. In the light of zero not having (or wanting to have) SafeFetch support, we should guard the test with CanUseSafeFetchxxx. Regards, Thomas > > The test changes are good. > > Regards, > Volker > > > On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf > wrote: > > Hi, > > > > Could somebody please review and sponsor this patch? > > > > The commit of JDK-8074552 broke the Zero port since it performs tests on > > JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers > > (relying on a continuation scheme for safe fetch errors) work. Yet > > performing this test correctly requires support from the signal handler > > and access routines to ucontext_t which are missing for Zero. > > > > The intent of JDK-8074552 was to improve error reporting on SEGV's. > > Having this feature in Zero is less useful, since it's a C++ interpreter > > only environment. > > > > This patch disables the test and makes CanUseSafeFetch* functions return > > false unconditionally for Zero JVMs so as to not produce a recursive > > SEGV's during error reporting. > > > > I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped > > for Zero. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8075533 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ > > > > Testing done: make bootcycle-images fails before this patch and passes > > after for a Zero JVM on x86_64. > > > > Thanks, > > Severin > > > From yumin.qi at oracle.com Fri Mar 20 17:22:39 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 20 Mar 2015 10:22:39 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5509B093.30904@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> Message-ID: <550C575F.4080102@oracle.com> Hi, All http://cr.openjdk.java.net/~minqi/8074354/webrev03/ This version is based on Thomas' suggestion. Tests passed vm.runtime.quick.testlist, JPRT and manual tests. Thanks Yumin On 3/18/2015 10:06 AM, Yumin Qi wrote: > > On 3/18/2015 4:26 AM, Thomas St?fe wrote: >> Hi Yumin, >> >> - just aesthetics, but on all implementations of os_abort(), at least >> on the UNIX variants, maybe we could consistently rename the >> parameters to be "siginfo" and "context" instead of using Windows terms? >> > Sure. >> - On check_create_dump_limit(), you do not need exceptionRecord, >> contextRecord parameters anymore. The only parameters now needed are >> buffer and buffer size, which is not even an output parameter, just a >> scratch buffer for this function to use for printf. For output, it >> calls VMError::report_coredump_status(...) at the end to provide >> information about the core file. >> >> - I would rename that function from check_create_dump_limit() to >> check_dump_limit() - nothing is created anymore. >> > Yes, no need to carry those two parameters. I tried to keep less > changes, but decided to change now. > >> - on Windows, in os::abort(), there is no point anymore in calling >> VMError::report_coredump_status(...) because that information is only >> used during error log writing which already happened. It only makes >> sense to call this function in check_create_dump_limit(), which >> happens before error log writing. >> Instead, maybe error messages like "Call to MiniDumpWriteDump() >> failed" should just be written to stderr? This would be consistent >> with Unix, where the OS writes a short message on stderr if core file >> writing fails. >> > Sure, will direct output to stderr. >> - there is now a new test, >> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java - could >> you please also add "-XX:-CreateCoredumpOnCrash" ? I just added the >> test and did not want to add the option before it was available. >> > OK > > Thanks > Yumin >> Thanks for your work! >> >> Thomas >> >> >> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi > > wrote: >> >> Hi, Dan and all >> >> I have updated webrev at: >> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >> >> >> 1) bug changed synopsis >> 8074354: Make CreateMinidumpOnCrash a new name and >> available on all platforms >> 2) tests: JPRT, vm.runtime.quick.testlist (on Windows), jtreg on >> Windows and Linux/Unix. >> >> Thanks >> Yumin >> >> >> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >> >> I believe there are both JavaTest/JTREG tests in the hotspot >> repo >> and there are VM/NSK tests from back when we did phone home... >> >> Check with Christian or Misha... >> >> Dan >> >> >> On 3/12/15 1:50 PM, Yumin Qi wrote: >> >> Thanks, Dan >> >> Will look at and run those tests. Are they under nsk? >> >> Yumin >> >> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >> >> Yumin, >> >> There are some error handler tests. You should find >> those and make >> sure that you run them on Windows since you're >> changing the order >> there... >> >> Dan >> >> >> On 3/12/15 12:42 PM, Yumin Qi wrote: >> >> Hi, Thomas and all >> >> The second version of the change: >> webrev: >> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >> >> >> In this version: >> 1) switch order on Windows to first print log >> file as other platform, then dump core file if >> needed. When VMError created after crash, siginfo >> and context which are ExceptionRecord and >> ContextRecord on Windows are recorded, mini (or >> full, due to 'or' used so type will be mini >> anyway) dump creates dump file based on those two >> as before. >> 2) to make os::abort to get above two pointers, >> added two more fields to the function parameters: >> 3) changes for >> test/runtime/ErrorHandling/SecondaryError.java --- >> added "-XX:-CreateCoredumpOnCrash" >> >> - static void abort(bool dump_core = true); >> + static void abort(bool dump_core = true, >> void *siginfo = NULL, void *context = NULL); >> >> Tests: JPRT and manually. >> >> Thanks >> Yumin >> >> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >> >> Hi Yumin, >> >> There is also >> test/runtime/ErrorHandling/SecondaryErrorTest.java >> - could you please add >> "-XX:-CreateCoredumpOnCrash" ? Thank you! >> >> Beyond that, as I wrote in the bug report >> comments: >> >> "This is also a problem on Windows - >> MiniDumpWriteDump() may hang infinitly. And on >> Windows this is worse than under UNIX because >> we create the Dump before writing the hs-err >> file, so if the Dump hangs, we get no error >> log. I would like to revert the order: create >> the minidump after writing the error log, the >> same way Unix does it. We did this in our JVM >> (SAP) because for us, error logs are more >> useful than minidumps. " >> >> So, I would like to see os::abort on Windows >> call MiniDumpWriteDump(), and thus the mini >> dump writing moved after the error log >> writing. This would also make the code way >> cleaner because the control flow would be the >> same on all platforms. >> >> I understand that this may be out of scope for >> your change, but I would like to know what >> others think about this. >> >> Kind regards, Thomas >> >> >> >> >> >> >> >> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >> > >> > >> wrote: >> >> Please review: >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8074354 >> webrev: >> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >> >> >> >> Summary: Tests timed out when VM crashes >> and dumping core file >> which in the test case is not needed. To >> make core not created, >> the fix changed CreateMinidumpOnCrash to >> CreateCoredumpOnCrash, >> the former is only used on Windows and the >> latter for all >> platforms. When VM crashes on non Windows, >> core file generated as >> default if OS sets core dump allowed. >> Default value of >> CreateCoredumpOnCrash set to 'true' to >> keep same behavior on non >> Windows platforms, but changed for Windows >> --- original is false, >> not create minidump on Windows. With >> CreateCoredumpOnCrash turned >> off, no core file will be generated. >> CreateMinidumpOnCrash still >> can be used on commandline but only as >> alias for the new flag. >> >> Tests: JPRT, manual tests setting >> CreateMinidumpOnCrash on >> commandline to verify flag change as alias. >> >> Thanks >> Yumin >> >> >> >> >> >> >> >> > From jeremymanson at google.com Fri Mar 20 17:32:18 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 20 Mar 2015 10:32:18 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5509F074.70501@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> Message-ID: Argh. Yes. Martin told me not to get involved with Windows, but would I listen? Of course not... http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ On Wed, Mar 18, 2015 at 2:39 PM, David Holmes wrote: > On 19/03/2015 3:04 AM, Jeremy Manson wrote: > >> Okay. Here you go: >> >> http://cr.openjdk.java.net/~jmanson/8074895/webrev.03/index.html >> > > ! if (alt_home_dir != NULL) { > ! strcpy(home_dir, alt_home_dir); > ! } else { > > That needs to be strncpy limited by MAX_PATH. > > David > > Jeremy >> >> On Wed, Mar 18, 2015 at 12:31 AM, David Holmes > > wrote: >> >> On 18/03/2015 4:15 PM, Jeremy Manson wrote: >> >> Oops... Should I fix it, post a patch, and hope it compiles? >> >> >> Please :) I can check the compiles part. >> >> David >> >> On Tue, Mar 17, 2015 at 9:09 PM, David Holmes >> >> > >> wrote: >> >> Sorry Jeremy, the patch failed on Windows as there is >> another usage >> in os_windows.cpp: >> >> void os::init_system_properties_____values() { >> // sysclasspath, java_home, dll_dir >> { >> char *home_path; >> char *dll_path; >> char *pslash; >> char *bin = "\\bin"; >> char home_dir[MAX_PATH]; >> >> if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, MAX_PATH)) { >> >> David >> >> >> On 18/03/2015 12:01 PM, David Holmes wrote: >> >> Submitting via JPRT. >> >> Thanks, >> David >> >> On 18/03/2015 4:13 AM, Jeremy Manson wrote: >> >> >> >> On Sun, Mar 15, 2015 at 10:04 PM, David Holmes >> > >> > >> >> > ____com >> > >>> wrote: >> >> Hi Jeremy, >> >> On 14/03/2015 3:00 AM, Jeremy Manson wrote: >> >> Thanks, David! New rev: >> >> http://cr.openjdk.java.net/~______jmanson/8074895/webrev.01/ >> >> >> > > >> >> >> > >> >> > >> >> >> >> Looks good. Please update copyright dates in >> memTracker.cpp and >> vmError.cpp. >> >> >> Done. Thanks for the review, and for feeding it >> through the >> other >> platforms! >> >> http://cr.openjdk.java.net/~____jmanson/8074895/webrev.02/ >> >> >> > > >> >> Jeremy >> >> >> >> From sgehwolf at redhat.com Fri Mar 20 17:45:15 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Mar 2015 18:45:15 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: References: <1426852643.3382.50.camel@redhat.com> Message-ID: <1426873515.3382.73.camel@redhat.com> Hi Volker, Thanks for the review! On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: > Hi Severin, > > I can't understand how SafeFetch32 and SafeFetchN are supposed to work > at all in Zero. The whole point of having the SafeFetch routines is to > have a possibility of peeking at potentially illegal memory addresses. You are right. I did some digging in the hg history and it seems this implementation for Zero has been added with JDK-8022188 after JDK-8016697 introduced it. > The current implementation of SafeFetch on Zero can not provide this > functionality so in my eyes it is useless. I agree. > I think we should do the following: > - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero > (this way the unmodified CanUseSafeFetchXX() routines would work for > Zero as well) > - remove the implementations of SafeFetchN and SafeFetch32 and set > StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry > to NULL in stubGenerator_zero.cpp (this will automatically make > StubRoutines::SafeFetchN_stub() return null on Zero) > - the calls to test_safefetch32XX() should be guarded by > CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in > stubRoutines.cpp) Sounds good, I'll follow up with an updated webrev shortly. > The test changes are good. Cheers, Severin > Regards, > Volker > > > On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this patch? > > > > The commit of JDK-8074552 broke the Zero port since it performs tests on > > JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers > > (relying on a continuation scheme for safe fetch errors) work. Yet > > performing this test correctly requires support from the signal handler > > and access routines to ucontext_t which are missing for Zero. > > > > The intent of JDK-8074552 was to improve error reporting on SEGV's. > > Having this feature in Zero is less useful, since it's a C++ interpreter > > only environment. > > > > This patch disables the test and makes CanUseSafeFetch* functions return > > false unconditionally for Zero JVMs so as to not produce a recursive > > SEGV's during error reporting. > > > > I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped > > for Zero. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8075533 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ > > > > Testing done: make bootcycle-images fails before this patch and passes > > after for a Zero JVM on x86_64. > > > > Thanks, > > Severin > > From harold.seigel at oracle.com Fri Mar 20 17:52:32 2015 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 20 Mar 2015 13:52:32 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> Message-ID: <550C5E60.2050305@oracle.com> Hi Karen, Thank you for your comments. Bytecode istore can change the type of a local slot. So, here's a new webrev that uses the incoming type state for all of the astore*, dstore*, fstore*, istore*, and lstore* bytecodes. The webrev also contains a new test for the istore bytecode case, called BadMapIstore.jasm. Could you please review this webrev, when you have a chance? New open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.2/ Thanks! Harold On 3/19/2015 3:33 PM, Karen Kinnear wrote: > Harold, > > I get it - this only affects instructions that set the type of a local slot since the operand stack is cleared. > > So - what about istore? > If we have a local slot that contains a long or double, Frederic reminded me that JVMS 2.6.1 does allow stores to those separate slots, > e.g. an istore. My mental model of this is that it would change the type of the local slot. > > Would that mean we would want to check any of the *store bytecodes? > > (I know the spec would change for all bytecodes which might be cleaner - I suspect you are being extra cautious about making changes > to reduce risk of breaking something in the field). > > thanks, > Karen > > On Mar 18, 2015, at 2:18 PM, harold seigel wrote: > >> Hi Karen, >> >> The fix does not affect normal verifier type-state (stack map) checking that is done when looping through the bytecodes. It only affects whether the incoming or outgoing type-state is used when comparing the type-state at a particular bytecode with the type-state at the start of its potential exception handlers. >> >> In addition, (to paraphrase Keith's comment in the bug), it only affects instructions that set the type of a local slot (astore and friends) ... . Instructions that affect the expression stack are not a problem since the type-state's stack is cleared when type checking an exception handler. >> >> So, other bytecodes such as aload and friends, getstatic and getfield, etc. are not an issue. >> >> Thanks, Harold >> >> On 3/16/2015 3:49 PM, Karen Kinnear wrote: >>> Harold, >>> >>> Thanks for helping me walk through this in more detail. >>> >>> The way I read this, the fix would apply to all bytecodes - except for >>> invokespecial - which is handled I believe correctly inside the >>> verify_invoke_init. >>> >>> So if you could possibly experiment with some additional instructions - I suspect >>> you can make a conditional check where you put the beginning check and remove >>> the check at the end. >>> >>> thanks, >>> Karen >>> >>> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >>> >>>> Hi Harold, >>>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for bug JDK-7127066. The fix applies to astore* >>>>> bytecodes because, when inside an exception handler, they can reference >>>>> the thrown object and modify the number of stack locals, enabling the >>>>> incorrect stack match. >>>>> >>>>> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>>> >>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>>> >>>>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>>>> java/lang, java/io, and java/util tests, and testbase quick and split >>>>> verifier tests, and with the test case provided in the bug. >>>> The new check looks okay, though I can't verify the exact placement of it. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks! Harold From thomas.stuefe at gmail.com Fri Mar 20 18:55:01 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 20 Mar 2015 19:55:01 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <550C575F.4080102@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> Message-ID: Hi Yumin, I think you meant to post webrev.04? I looked at 04, and it looks nice. Thank you! (still only reviewer with r) Thomas On Mar 20, 2015 6:20 PM, "Yumin Qi" wrote: > Hi, All > > http://cr.openjdk.java.net/~minqi/8074354/webrev03/ > > This version is based on Thomas' suggestion. > Tests passed vm.runtime.quick.testlist, JPRT and manual tests. > > Thanks > Yumin > > On 3/18/2015 10:06 AM, Yumin Qi wrote: > >> >> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >> >>> Hi Yumin, >>> >>> - just aesthetics, but on all implementations of os_abort(), at least on >>> the UNIX variants, maybe we could consistently rename the parameters to be >>> "siginfo" and "context" instead of using Windows terms? >>> >>> Sure. >> >>> - On check_create_dump_limit(), you do not need exceptionRecord, >>> contextRecord parameters anymore. The only parameters now needed are buffer >>> and buffer size, which is not even an output parameter, just a scratch >>> buffer for this function to use for printf. For output, it calls >>> VMError::report_coredump_status(...) at the end to provide information >>> about the core file. >>> >>> - I would rename that function from check_create_dump_limit() to >>> check_dump_limit() - nothing is created anymore. >>> >>> Yes, no need to carry those two parameters. I tried to keep less >> changes, but decided to change now. >> >> - on Windows, in os::abort(), there is no point anymore in calling >>> VMError::report_coredump_status(...) because that information is only >>> used during error log writing which already happened. It only makes sense >>> to call this function in check_create_dump_limit(), which happens before >>> error log writing. >>> Instead, maybe error messages like "Call to MiniDumpWriteDump() failed" >>> should just be written to stderr? This would be consistent with Unix, where >>> the OS writes a short message on stderr if core file writing fails. >>> >>> Sure, will direct output to stderr. >> >>> - there is now a new test, test/runtime/ErrorHandling/ >>> SafeFetchInErrorHandlingTest.java - could you please also add >>> "-XX:-CreateCoredumpOnCrash" ? I just added the test and did not want to >>> add the option before it was available. >>> >>> OK >> >> Thanks >> Yumin >> >>> Thanks for your work! >>> >>> Thomas >>> >>> >>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >> yumin.qi at oracle.com>> wrote: >>> >>> Hi, Dan and all >>> >>> I have updated webrev at: >>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>> >>> >>> 1) bug changed synopsis >>> 8074354: Make CreateMinidumpOnCrash a new name and >>> available on all platforms >>> 2) tests: JPRT, vm.runtime.quick.testlist (on Windows), jtreg on >>> Windows and Linux/Unix. >>> >>> Thanks >>> Yumin >>> >>> >>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>> >>> I believe there are both JavaTest/JTREG tests in the hotspot repo >>> and there are VM/NSK tests from back when we did phone home... >>> >>> Check with Christian or Misha... >>> >>> Dan >>> >>> >>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>> >>> Thanks, Dan >>> >>> Will look at and run those tests. Are they under nsk? >>> >>> Yumin >>> >>> On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: >>> >>> Yumin, >>> >>> There are some error handler tests. You should find >>> those and make >>> sure that you run them on Windows since you're >>> changing the order >>> there... >>> >>> Dan >>> >>> >>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>> >>> Hi, Thomas and all >>> >>> The second version of the change: >>> webrev: >>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ < >>> http://cr.openjdk.java.net/%7Eminqi/8074354/webrev02/> >>> >>> In this version: >>> 1) switch order on Windows to first print log >>> file as other platform, then dump core file if >>> needed. When VMError created after crash, siginfo >>> and context which are ExceptionRecord and >>> ContextRecord on Windows are recorded, mini (or >>> full, due to 'or' used so type will be mini >>> anyway) dump creates dump file based on those two >>> as before. >>> 2) to make os::abort to get above two pointers, >>> added two more fields to the function parameters: >>> 3) changes for >>> test/runtime/ErrorHandling/SecondaryError.java --- >>> added "-XX:-CreateCoredumpOnCrash" >>> >>> - static void abort(bool dump_core = true); >>> + static void abort(bool dump_core = true, >>> void *siginfo = NULL, void *context = NULL); >>> >>> Tests: JPRT and manually. >>> >>> Thanks >>> Yumin >>> >>> On 3/11/2015 3:47 AM, Thomas St?fe wrote: >>> >>> Hi Yumin, >>> >>> There is also >>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>> - could you please add >>> "-XX:-CreateCoredumpOnCrash" ? Thank you! >>> >>> Beyond that, as I wrote in the bug report >>> comments: >>> >>> "This is also a problem on Windows - >>> MiniDumpWriteDump() may hang infinitly. And on >>> Windows this is worse than under UNIX because >>> we create the Dump before writing the hs-err >>> file, so if the Dump hangs, we get no error >>> log. I would like to revert the order: create >>> the minidump after writing the error log, the >>> same way Unix does it. We did this in our JVM >>> (SAP) because for us, error logs are more >>> useful than minidumps. " >>> >>> So, I would like to see os::abort on Windows >>> call MiniDumpWriteDump(), and thus the mini >>> dump writing moved after the error log >>> writing. This would also make the code way >>> cleaner because the control flow would be the >>> same on all platforms. >>> >>> I understand that this may be out of scope for >>> your change, but I would like to know what >>> others think about this. >>> >>> Kind regards, Thomas >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Mar 11, 2015 at 8:02 AM, Yumin Qi >>> >> >>> >> >> wrote: >>> >>> Please review: >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>> webrev: >>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>> >>> >>> >>> Summary: Tests timed out when VM crashes >>> and dumping core file >>> which in the test case is not needed. To >>> make core not created, >>> the fix changed CreateMinidumpOnCrash to >>> CreateCoredumpOnCrash, >>> the former is only used on Windows and the >>> latter for all >>> platforms. When VM crashes on non Windows, >>> core file generated as >>> default if OS sets core dump allowed. >>> Default value of >>> CreateCoredumpOnCrash set to 'true' to >>> keep same behavior on non >>> Windows platforms, but changed for Windows >>> --- original is false, >>> not create minidump on Windows. With >>> CreateCoredumpOnCrash turned >>> off, no core file will be generated. >>> CreateMinidumpOnCrash still >>> can be used on commandline but only as >>> alias for the new flag. >>> >>> Tests: JPRT, manual tests setting >>> CreateMinidumpOnCrash on >>> commandline to verify flag change as alias. >>> >>> Thanks >>> Yumin >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > From coleen.phillimore at oracle.com Fri Mar 20 20:34:19 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Mar 2015 16:34:19 -0400 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <1426873515.3382.73.camel@redhat.com> References: <1426852643.3382.50.camel@redhat.com> <1426873515.3382.73.camel@redhat.com> Message-ID: <550C844B.1060108@oracle.com> Severin, Thank you for taking care of this. I have one question for the greater project. Is there platform support in jtreg so we don't need to change the Java code? http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html + if (!Platform.isDebugBuild() || Platform.isZero()) { Thanks, Coleen On 3/20/15, 1:45 PM, Severin Gehwolf wrote: > Hi Volker, > > Thanks for the review! > > On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: >> Hi Severin, >> >> I can't understand how SafeFetch32 and SafeFetchN are supposed to work >> at all in Zero. The whole point of having the SafeFetch routines is to >> have a possibility of peeking at potentially illegal memory addresses. > You are right. I did some digging in the hg history and it seems this > implementation for Zero has been added with JDK-8022188 after > JDK-8016697 introduced it. > >> The current implementation of SafeFetch on Zero can not provide this >> functionality so in my eyes it is useless. > I agree. > >> I think we should do the following: >> - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero >> (this way the unmodified CanUseSafeFetchXX() routines would work for >> Zero as well) >> - remove the implementations of SafeFetchN and SafeFetch32 and set >> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry >> to NULL in stubGenerator_zero.cpp (this will automatically make >> StubRoutines::SafeFetchN_stub() return null on Zero) >> - the calls to test_safefetch32XX() should be guarded by >> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in >> stubRoutines.cpp) > Sounds good, I'll follow up with an updated webrev shortly. > >> The test changes are good. > Cheers, > Severin > >> Regards, >> Volker >> >> >> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this patch? >>> >>> The commit of JDK-8074552 broke the Zero port since it performs tests on >>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers >>> (relying on a continuation scheme for safe fetch errors) work. Yet >>> performing this test correctly requires support from the signal handler >>> and access routines to ucontext_t which are missing for Zero. >>> >>> The intent of JDK-8074552 was to improve error reporting on SEGV's. >>> Having this feature in Zero is less useful, since it's a C++ interpreter >>> only environment. >>> >>> This patch disables the test and makes CanUseSafeFetch* functions return >>> false unconditionally for Zero JVMs so as to not produce a recursive >>> SEGV's during error reporting. >>> >>> I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped >>> for Zero. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533 >>> webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ >>> >>> Testing done: make bootcycle-images fails before this patch and passes >>> after for a Zero JVM on x86_64. >>> >>> Thanks, >>> Severin >>> > > From coleen.phillimore at oracle.com Fri Mar 20 20:39:11 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Mar 2015 16:39:11 -0400 Subject: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling In-Reply-To: <1426840021.3382.12.camel@redhat.com> References: <54FCDE07.8010604@oracle.com> <54FD3609.4020009@oracle.com> <54FD42E1.90504@oracle.com> <54FE194A.4080205@oracle.com> <4295855A5C1DE049A61835A1887419CC2CFACB1B@DEWDFEMB12A.global.corp.sap> <550184EB.8020905@oracle.com> <550222F6.7020503@oracle.com> <5509D8DE.9010707@oracle.com> <550AB2DE.4000607@redhat.com> <1426775492.27867.14.camel@redhat.com> <550B1C2D.4090105@oracle.com> <1426840021.3382.12.camel@redhat.com> Message-ID: <550C856F.9070208@oracle.com> On 3/20/15, 4:27 AM, Severin Gehwolf wrote: > On Thu, 2015-03-19 at 14:57 -0400, Coleen Phillimore wrote: >> Yes, this patch looks like what I'm testing with. I also had to make >> this change to get it to compile on linux x64. >> >> --- a/src/cpu/zero/vm/frame_zero.cpp >> +++ b/src/cpu/zero/vm/frame_zero.cpp >> @@ -213,7 +213,7 @@ >> valuebuf[buflen - 1] = '\0'; >> >> // Print the result >> - st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf); >> + st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf, >> valuebuf); >> } >> } > Interesting. I haven't seen this before. What's the exact environment > you are compiling on? Which GCC? slowdebug, fastdebug or release type > build? FWIW, Fedora 21 on x86_64 Zero slowdebug build didn't need this. > It compiled fine here. I'm compiling for linux 64 bit debug on ubuntu. philli% gcc --version gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 > > There ought to be a way for those things to not slip through the > cracks... I already have this [1] and [2]. Those are using hs-comp trees > currently. I'll probably switch them over to use hs-rt instead. I don't know how to consistently catch these gcc errors so they don't keep falling through the cracks! :( Yes, please use hs-rt for this. I think we are more interested at the moment. thanks! Coleen > > Thanks again, Coleen! > > Cheers, > Severin > > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/ > [2] http://builder.classpath.org/jenkins/job/OpenJDK8_jdk8u_Zero/ > >> On 3/19/15, 10:31 AM, Severin Gehwolf wrote: >>> On Thu, 2015-03-19 at 11:28 +0000, Andrew Dinn wrote: >>>> On 19/03/15 09:35, Thomas St?fe wrote: >>>>> this may be the case. I do not know the zero port very good. >>>>> >>>>> SefeFetch handling needs support from both signal handler and access >>>>> routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is >>>>> missing. >>>>> >>>>> In theory it could be added, because doing so requires no assembly of any >>>>> sorts. But it looks like the zero port avoids any technique which requires >>>>> fiddling around with the ucontext_t in the signal handler to jump to a >>>>> continuation point. This looks intentional and I do not want to introduce >>>>> any code which breaks the intention of zero port. >>>>> >>>>> Of course, the other way would be just to disable the test for zero. >>>>> >>>>> What would be the right way? >>> Thomas, I think the way to go is to skip both, the test and the new >>> error handler feature for Zero. Since it is C++ interpreter only, it's >>> OK to not have this extra info in hs_err. >>> >>> Shark, on the other hand, is likely different but I don't know much >>> about it. >>> >>>> Coleen, thanks very much for checking to see if this fix causes an issue >>>> for zero. >>> +1, very much appreciated! >>> >>> I see that this has already been pushed[1]. I'll follow up with a fix >>> for Zero shortly (current w-i-p patch attached). >>> >>> Cheers, >>> Severin >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421 >>> >>>> Thomas, I have pointed the relevant Red Hat developers at this thread. >>>> One of them should respond soon. >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> Senior Principal Software Engineer >>>> Red Hat UK Ltd >>>> Registered in UK and Wales under Company Registration No. 3798903 >>>> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters >>>> (USA), Michael O'Neill (Ireland) >>>> >>>> >>> > > From yumin.qi at oracle.com Fri Mar 20 20:53:23 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 20 Mar 2015 13:53:23 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <5500A424.5000401@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> Message-ID: <550C88C3.7030008@oracle.com> Hi, Coleen and all New version with suggested changes can be reviewed at: http://cr.openjdk.java.net/~minqi/8074345/webrev02/ Removed _fast_invokeinvirtual from last version, disable rewriting _invokevirtual if UseSharedSpaces turned on. Only on sparc _invokevirtual got rewritten. Other platforms as unimplemented. Thanks Yumin On 3/11/2015 1:23 PM, Yumin Qi wrote: > Thanks, I will have another webrev after build/test/perf test. > > Yumin > > On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >> >> Hi Yumin, One comment embedded. >> >> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>> Hi, Coleen >>> >>> Thanks for the review. See embedded. >>> >>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>> >>>> Yumin, >>>> >>>> The new bytecode approach came out pretty cleanly, or as cleanly as >>>> this could be. >>>> >>>> The file templateTable_x86_32 and 64 have just been merged, so >>>> you'll have to make your change in the new version. >>>> >>>> I also have some comments: >>>> >>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>>> >>>> >>>> Typo "rewirting" >>>> >>> Sure. >>>> In these files, can you break up the long lines into three lines? >>>> >>>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, >>>> Rbc, Rscratch); } >>>> + if (!is_static && rc == MAY_REWRITE) { >>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>> >>> Sure. >>>> >>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>>> >>>> >>>> How many bytecodes do we have now? We're limited to 255 (or 256) >>>> and there are other new bytecodes being added. >>>> >>> now total is 234 (after the fix). See below answer. >>>> What was the performance benefit to this? I think if we wanted to >>>> be conservative, we'd turn off RewriteFrequentPairs and only do >>>> nofast_getfield and nofast_putfield. I think they were the only >>>> bytecodes that actually affected performance. >>>> >>>> In this file above, can you remove the last block of comments about >>>> fast_linearswitch and fast_ldc? I think this confuses rewriting in >>>> the interpreter and rewriting in the rewriter, or rather makes the >>>> confusion worse. I don't think this comment is helpful. >>>> >>>> I'd prefer to see the first comment smaller also, like: >>>> >>>> + // These bytecodes are rewritten at CDS dump time, so that we >>>> can prevent them from being >>>> + // rewritten at run time. This way, the ConstMethods can be >>>> placed in the CDS ReadOnly >>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>> rewrite non-CDS bytecodes >>>> + // at run time. >>>> + _nofast_getfield , >>>> + _nofast_putfield , >>>> + _nofast_aload_0 , >>>> + _nofast_iload , >>>> + _nofast_invokevirtual , >>>> >>>> It's sort of obvious which bytecode they rewrite. I don't know how >>>> much performance fast_invokevfinal is worth. I thought I deleted >>>> it. Can we not rewrite this so we don't waste another bytecode on >>>> it? Maybe add a RewriteVFinal option and consider removing it for >>>> the future? x86 doesn't use it and I can't see how this would save >>>> any significant performance to be worth having! >>>> >>> _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, >>> no need to take care for it. For sparc, it does patch code. I am >>> thinking of a way if we need to add _nofast_code as you indicated, >>> we only have 255 codes to use. >> >> PPC isn't removed from the open repository. >>> >>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>> RewriteFrequentPair; >> >> I think the conditional would be >> >> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>> >>> Can this boolean decide if we not rewrite the bytecode to fast? >>> If so, I can remove all the _nofast_code and do not patch code when >>> it is on. >> >> Yes, this would be nice to not add the bytecode. >> >>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>>> >>>> >>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>> control for fast code under CDS >>>> >>>> >>>> I don't know what our coding standard is but in the >>>> templateTable_.cpp files these strings look like macros. I'd >>>> rather see them as MayRewrite or MayNotRewrite. >>>> >>> Agree. >>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>>> >>>> >>>> I think there's a java_code() function that returns the original >>>> bytecode that you could use instead of the case statement in >>>> resolve_cache_and_index(). The indentation is odd in the webrev. >>>> This probably applies to the other cpu directories. >>>> >>>> One last question below: >>>> >>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>> Please review: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>> >>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS are >>>>> mapped read only. So memory fault will be triggered when >>>>> RewriteBytecodes turned on. This also disable all method >>>>> rewritten, leads interpreter run slower. Observed about 2% >>>>> regression with C2 on some benchmarks, since interpreter speed is >>>>> important to C2. By enable RewriteBytecodes and >>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for >>>>> corresponding fast codes at dump time to avoid byte code rewritten >>>>> at run time, we prevent byte code rewritten and modify the read >>>>> only shared portion in CDS. Meanwhile other byte codes with fast >>>>> codes still get speed up. >>>>> >>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported >>>>> platforms. Interpreter only tests showed about 3% improvement. >>>> >>>> What performance did you measure? Is it -Xint -Xshare:on with and >>>> without your patch? It was only 3% better? >>>> >>>> What was the difference in performance with -Xint >>>> -XX:-RewriteBytecodes vs. -Xint >>>> -XX:+RewriteBytecodes/FrequentPairs? I thought this was around 15%. >>>> >>> I will send you a separate email of the links which run with >>> CDS/NoCDS/CDS+Int >> >> Thanks for the links. From your experiments, I think your >> performance improvement with your patch and CDS with -Xmixed is 4%. >> That's good enough for a couple of bytecodes. >> >> Coleen >> >>> >>> Thanks >>> Yumin >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>> >>> >> > From karen.kinnear at oracle.com Fri Mar 20 21:30:28 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 20 Mar 2015 17:30:28 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <550C5E60.2050305@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> <550C5E60.2050305@oracle.com> Message-ID: <0B640921-E5C0-44AC-9DDA-CCFF295C5A7D@oracle.com> Harold, Looks really good. Thank you very much for the revision. thanks, Karen On Mar 20, 2015, at 1:52 PM, harold seigel wrote: > Hi Karen, > > Thank you for your comments. > > Bytecode istore can change the type of a local slot. So, here's a new webrev that uses the incoming type state for all of the astore*, dstore*, fstore*, istore*, and lstore* bytecodes. The webrev also contains a new test for the istore bytecode case, called BadMapIstore.jasm. > > Could you please review this webrev, when you have a chance? > > New open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.2/ > > Thanks! Harold > > On 3/19/2015 3:33 PM, Karen Kinnear wrote: >> Harold, >> >> I get it - this only affects instructions that set the type of a local slot since the operand stack is cleared. >> >> So - what about istore? >> If we have a local slot that contains a long or double, Frederic reminded me that JVMS 2.6.1 does allow stores to those separate slots, >> e.g. an istore. My mental model of this is that it would change the type of the local slot. >> >> Would that mean we would want to check any of the *store bytecodes? >> >> (I know the spec would change for all bytecodes which might be cleaner - I suspect you are being extra cautious about making changes >> to reduce risk of breaking something in the field). >> >> thanks, >> Karen >> >> On Mar 18, 2015, at 2:18 PM, harold seigel wrote: >> >>> Hi Karen, >>> >>> The fix does not affect normal verifier type-state (stack map) checking that is done when looping through the bytecodes. It only affects whether the incoming or outgoing type-state is used when comparing the type-state at a particular bytecode with the type-state at the start of its potential exception handlers. >>> >>> In addition, (to paraphrase Keith's comment in the bug), it only affects instructions that set the type of a local slot (astore and friends) ... . Instructions that affect the expression stack are not a problem since the type-state's stack is cleared when type checking an exception handler. >>> >>> So, other bytecodes such as aload and friends, getstatic and getfield, etc. are not an issue. >>> >>> Thanks, Harold >>> >>> On 3/16/2015 3:49 PM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Thanks for helping me walk through this in more detail. >>>> >>>> The way I read this, the fix would apply to all bytecodes - except for >>>> invokespecial - which is handled I believe correctly inside the >>>> verify_invoke_init. >>>> >>>> So if you could possibly experiment with some additional instructions - I suspect >>>> you can make a conditional check where you put the beginning check and remove >>>> the check at the end. >>>> >>>> thanks, >>>> Karen >>>> >>>> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >>>> >>>>> Hi Harold, >>>>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this fix for bug JDK-7127066. The fix applies to astore* >>>>>> bytecodes because, when inside an exception handler, they can reference >>>>>> the thrown object and modify the number of stack locals, enabling the >>>>>> incorrect stack match. >>>>>> >>>>>> Open webrev: http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>>>> >>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>>>> >>>>>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>>>>> java/lang, java/io, and java/util tests, and testbase quick and split >>>>>> verifier tests, and with the test case provided in the bug. >>>>> The new check looks okay, though I can't verify the exact placement of it. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks! Harold > From yumin.qi at oracle.com Fri Mar 20 22:20:15 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 20 Mar 2015 15:20:15 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> Message-ID: <550C9D1F.2010007@oracle.com> Thomas, Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add another test case change: test/runtime/memory/ReadFromNoaccessArea.java (Thanks Dan's update) Thanks Yumin On 3/20/2015 11:55 AM, Thomas St?fe wrote: > > Hi Yumin, > > I think you meant to post webrev.04? > > I looked at 04, and it looks nice. Thank you! > > (still only reviewer with r) > > Thomas > > On Mar 20, 2015 6:20 PM, "Yumin Qi" > wrote: > > Hi, All > > http://cr.openjdk.java.net/~minqi/8074354/webrev03/ > > > This version is based on Thomas' suggestion. > Tests passed vm.runtime.quick.testlist, JPRT and manual tests. > > Thanks > Yumin > > On 3/18/2015 10:06 AM, Yumin Qi wrote: > > > On 3/18/2015 4:26 AM, Thomas St?fe wrote: > > Hi Yumin, > > - just aesthetics, but on all implementations of > os_abort(), at least on the UNIX variants, maybe we could > consistently rename the parameters to be "siginfo" and > "context" instead of using Windows terms? > > Sure. > > - On check_create_dump_limit(), you do not need > exceptionRecord, contextRecord parameters anymore. The > only parameters now needed are buffer and buffer size, > which is not even an output parameter, just a scratch > buffer for this function to use for printf. For output, it > calls VMError::report_coredump_status(...) at the end to > provide information about the core file. > > - I would rename that function from > check_create_dump_limit() to check_dump_limit() - nothing > is created anymore. > > Yes, no need to carry those two parameters. I tried to keep > less changes, but decided to change now. > > - on Windows, in os::abort(), there is no point anymore in > calling VMError::report_coredump_status(...) because that > information is only used during error log writing which > already happened. It only makes sense to call this > function in check_create_dump_limit(), which happens > before error log writing. > Instead, maybe error messages like "Call to > MiniDumpWriteDump() failed" should just be written to > stderr? This would be consistent with Unix, where the OS > writes a short message on stderr if core file writing fails. > > Sure, will direct output to stderr. > > - there is now a new test, > test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java > - could you please also add "-XX:-CreateCoredumpOnCrash" ? > I just added the test and did not want to add the option > before it was available. > > OK > > Thanks > Yumin > > Thanks for your work! > > Thomas > > > On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi > > >> > wrote: > > Hi, Dan and all > > I have updated webrev at: > http://cr.openjdk.java.net/~minqi/8074354/webrev03/ > > > > 1) bug changed synopsis > 8074354: Make CreateMinidumpOnCrash a new name and > available on all platforms > 2) tests: JPRT, vm.runtime.quick.testlist (on > Windows), jtreg on > Windows and Linux/Unix. > > Thanks > Yumin > > > On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: > > I believe there are both JavaTest/JTREG tests in > the hotspot repo > and there are VM/NSK tests from back when we did > phone home... > > Check with Christian or Misha... > > Dan > > > On 3/12/15 1:50 PM, Yumin Qi wrote: > > Thanks, Dan > > Will look at and run those tests. Are they > under nsk? > > Yumin > > On 3/12/2015 12:29 PM, Daniel D. Daugherty wrote: > > Yumin, > > There are some error handler tests. You > should find > those and make > sure that you run them on Windows since you're > changing the order > there... > > Dan > > > On 3/12/15 12:42 PM, Yumin Qi wrote: > > Hi, Thomas and all > > The second version of the change: > webrev: > http://cr.openjdk.java.net/~minqi/8074354/webrev02/ > > > > In this version: > 1) switch order on Windows to first > print log > file as other platform, then dump core > file if > needed. When VMError created after > crash, siginfo > and context which are ExceptionRecord and > ContextRecord on Windows are recorded, > mini (or > full, due to 'or' used so type will be > mini > anyway) dump creates dump file based > on those two > as before. > 2) to make os::abort to get above > two pointers, > added two more fields to the function > parameters: > 3) changes for > test/runtime/ErrorHandling/SecondaryError.java --- > added "-XX:-CreateCoredumpOnCrash" > > - static void abort(bool > dump_core = true); > + static void abort(bool dump_core > = true, > void *siginfo = NULL, void *context = > NULL); > > Tests: JPRT and manually. > > Thanks > Yumin > > On 3/11/2015 3:47 AM, Thomas St?fe wrote: > > Hi Yumin, > > There is also > test/runtime/ErrorHandling/SecondaryErrorTest.java > - could you please add > "-XX:-CreateCoredumpOnCrash" ? > Thank you! > > Beyond that, as I wrote in the bug > report > comments: > > "This is also a problem on Windows - > MiniDumpWriteDump() may hang > infinitly. And on > Windows this is worse than under > UNIX because > we create the Dump before writing > the hs-err > file, so if the Dump hangs, we get > no error > log. I would like to revert the > order: create > the minidump after writing the > error log, the > same way Unix does it. We did this > in our JVM > (SAP) because for us, error logs > are more > useful than minidumps. " > > So, I would like to see os::abort > on Windows > call MiniDumpWriteDump(), and thus > the mini > dump writing moved after the error log > writing. This would also make the > code way > cleaner because the control flow > would be the > same on all platforms. > > I understand that this may be out > of scope for > your change, but I would like to > know what > others think about this. > > Kind regards, Thomas > > > > > > > > On Wed, Mar 11, 2015 at 8:02 AM, > Yumin Qi > > > > > >>> wrote: > > Please review: > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074354 > webrev: > http://cr.openjdk.java.net/~minqi/8074354/webrev01/ > > > > > Summary: Tests timed out when > VM crashes > and dumping core file > which in the test case is not > needed. To > make core not created, > the fix changed > CreateMinidumpOnCrash to > CreateCoredumpOnCrash, > the former is only used on > Windows and the > latter for all > platforms. When VM crashes on > non Windows, > core file generated as > default if OS sets core dump > allowed. > Default value of > CreateCoredumpOnCrash set to > 'true' to > keep same behavior on non > Windows platforms, but changed > for Windows > --- original is false, > not create minidump on > Windows. With > CreateCoredumpOnCrash turned > off, no core file will be > generated. > CreateMinidumpOnCrash still > can be used on commandline but > only as > alias for the new flag. > > Tests: JPRT, manual tests setting > CreateMinidumpOnCrash on > commandline to verify flag > change as alias. > > Thanks > Yumin > > > > > > > > > > From david.holmes at oracle.com Mon Mar 23 06:12:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Mar 2015 16:12:18 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> Message-ID: <550FAEC2.5040908@oracle.com> On 21/03/2015 3:32 AM, Jeremy Manson wrote: > Argh. Yes. Martin told me not to get involved with Windows, but would > I listen? Of course not... > > http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ Looks okay to me - running a test job now. Coleen: can you re-review the os_windows.cpp changes please. Thanks, David > On Wed, Mar 18, 2015 at 2:39 PM, David Holmes > wrote: > > On 19/03/2015 3:04 AM, Jeremy Manson wrote: > > Okay. Here you go: > > http://cr.openjdk.java.net/~__jmanson/8074895/webrev.03/__index.html > > > > ! if (alt_home_dir != NULL) { > ! strcpy(home_dir, alt_home_dir); > ! } else { > > That needs to be strncpy limited by MAX_PATH. > > David > > Jeremy > > On Wed, Mar 18, 2015 at 12:31 AM, David Holmes > > >> wrote: > > On 18/03/2015 4:15 PM, Jeremy Manson wrote: > > Oops... Should I fix it, post a patch, and hope it > compiles? > > > Please :) I can check the compiles part. > > David > > On Tue, Mar 17, 2015 at 9:09 PM, David Holmes > > > > ____com > >>> wrote: > > Sorry Jeremy, the patch failed on Windows as there is > another usage > in os_windows.cpp: > > void os::init_system_properties_______values() { > // sysclasspath, java_home, dll_dir > { > char *home_path; > char *dll_path; > char *pslash; > char *bin = "\\bin"; > char home_dir[MAX_PATH]; > > if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, > MAX_PATH)) { > > David > > > On 18/03/2015 12:01 PM, David Holmes wrote: > > Submitting via JPRT. > > Thanks, > David > > On 18/03/2015 4:13 AM, Jeremy Manson wrote: > > > > On Sun, Mar 15, 2015 at 10:04 PM, David Holmes > > > > ____com > >> > . > .>______com > ____com > >>>> wrote: > > Hi Jeremy, > > On 14/03/2015 3:00 AM, Jeremy Manson > wrote: > > Thanks, David! New rev: > > http://cr.openjdk.java.net/~________jmanson/8074895/webrev.01/ > > > > > > > > > >> > > > > > > > > > > > > >>> > > > Looks good. Please update copyright > dates in > memTracker.cpp and > vmError.cpp. > > > Done. Thanks for the review, and for > feeding it > through the > other > platforms! > > http://cr.openjdk.java.net/~______jmanson/8074895/webrev.02/ > > > > > > > > > >> > > Jeremy > > > > From david.holmes at oracle.com Mon Mar 23 07:45:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Mar 2015 17:45:54 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <550FAEC2.5040908@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> Message-ID: <550FC4B2.1000606@oracle.com> On 23/03/2015 4:12 PM, David Holmes wrote: > On 21/03/2015 3:32 AM, Jeremy Manson wrote: >> Argh. Yes. Martin told me not to get involved with Windows, but would >> I listen? Of course not... >> >> http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ > > Looks okay to me - running a test job now. This just isn't meant to be :( It seems that: GrowableArray options(2, true); in arguments.cpp is giving the windows compiler some grief: C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) : error C2220: warning treated as error - no 'object' file generated C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(168) : while compiling class template member function 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' with [ E=JavaVMOption ] C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\arguments.cpp(3516) : see reference to class template instantiation 'GrowableArray' being compiled with [ E=JavaVMOption ] C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) : warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(388) : warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(379) : while compiling class template member function 'void GrowableArray::grow(int)' with [ E=JavaVMOption ] I'm guessing it doesn't like the enum as the generic arg, but don't know why given that it accepts plain int elsewhere. ??? David ----- > Coleen: can you re-review the os_windows.cpp changes please. > > Thanks, > David > >> On Wed, Mar 18, 2015 at 2:39 PM, David Holmes > > wrote: >> >> On 19/03/2015 3:04 AM, Jeremy Manson wrote: >> >> Okay. Here you go: >> >> >> http://cr.openjdk.java.net/~__jmanson/8074895/webrev.03/__index.html >> >> >> >> >> ! if (alt_home_dir != NULL) { >> ! strcpy(home_dir, alt_home_dir); >> ! } else { >> >> That needs to be strncpy limited by MAX_PATH. >> >> David >> >> Jeremy >> >> On Wed, Mar 18, 2015 at 12:31 AM, David Holmes >> >> > >> wrote: >> >> On 18/03/2015 4:15 PM, Jeremy Manson wrote: >> >> Oops... Should I fix it, post a patch, and hope it >> compiles? >> >> >> Please :) I can check the compiles part. >> >> David >> >> On Tue, Mar 17, 2015 at 9:09 PM, David Holmes >> > >> > > >> > ____com >> > >>> wrote: >> >> Sorry Jeremy, the patch failed on Windows as >> there is >> another usage >> in os_windows.cpp: >> >> void os::init_system_properties_______values() { >> // sysclasspath, java_home, dll_dir >> { >> char *home_path; >> char *dll_path; >> char *pslash; >> char *bin = "\\bin"; >> char home_dir[MAX_PATH]; >> >> if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, >> MAX_PATH)) { >> >> David >> >> >> On 18/03/2015 12:01 PM, David Holmes wrote: >> >> Submitting via JPRT. >> >> Thanks, >> David >> >> On 18/03/2015 4:13 AM, Jeremy Manson wrote: >> >> >> >> On Sun, Mar 15, 2015 at 10:04 PM, David >> Holmes >> > >> > > >> > ____com >> > >> >> > . >> > .>______com >> > ____com >> > >>>> wrote: >> >> Hi Jeremy, >> >> On 14/03/2015 3:00 AM, Jeremy Manson >> wrote: >> >> Thanks, David! New rev: >> >> http://cr.openjdk.java.net/~________jmanson/8074895/webrev.01/ >> >> >> > > >> >> >> > >> >> > >> >> >> >> >> > >> >> > > >> >> >> > >> >> > >>> >> >> >> Looks good. Please update copyright >> dates in >> memTracker.cpp and >> vmError.cpp. >> >> >> Done. Thanks for the review, and for >> feeding it >> through the >> other >> platforms! >> >> http://cr.openjdk.java.net/~______jmanson/8074895/webrev.02/ >> >> >> > > >> >> >> > >> >> > >> >> >> Jeremy >> >> >> >> From roland.westrelin at oracle.com Mon Mar 23 08:45:48 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 23 Mar 2015 09:45:48 +0100 Subject: RFR(S): 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: <76A01490-93E7-412A-9A91-E2A809A4B108@oracle.com> References: <55022AB8.6020705@oracle.com> <76A01490-93E7-412A-9A91-E2A809A4B108@oracle.com> Message-ID: <2B47FF63-FDB7-4219-A653-96DC3F0DDFC5@oracle.com> Given I didn?t get any new comments on this, I?m pushing it. Roland. > On Mar 13, 2015, at 10:43 AM, Roland Westrelin wrote: > >> Fix looks correct. I CC to runtime group. They may know answers for your questions. > > Thanks for the review. We?ve been the ones making changes to dependencies.cpp for default methods, not sure the runtime team can help. > > I tried removing: > > // Disable CHA for default methods for now > if (root_m->get_Method()->is_default_method()) { > return NULL; > } > > and the test case that comes with that change crashes. So it looks like it?s still needed. > > Roland. > >> >> Thanks, >> Vladimir >> >> On 3/12/15 6:31 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8069263/webrev.00/ >>> >>> In the test case, I1.m1() is a default method that is added by default methods processing to the list of default methods of class C2. The call at line 54 triggers CHA. It finds m1 in class C2 but with holder I1 as unique target. The assert fires because m1?s holder is not C2 but m1 is in the list of C2?s methods. >>> >>> I fixed this by returning no unique method in that case because: >>> >>> 1) we seem to still not expect that we can handle default methods properly in CHA even though we?ve added code in dependencies.cpp to support them. ciMethod::find_monomorphic_target) has this code: >>> >>> // Disable CHA for default methods for now >>> if (root_m->get_Method()->is_default_method()) { >>> return NULL; >>> } >>> >>> Or maybe that code should be removed? >>> >>> 2) a proper fix would require that we record the method, its actual holder (C2) in the dependency which would require more extensive changes. I wonder if the extra complexity would make sense. >>> >>> Roland. >>> >>> > From sgehwolf at redhat.com Mon Mar 23 09:27:03 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Mar 2015 10:27:03 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <550C844B.1060108@oracle.com> References: <1426852643.3382.50.camel@redhat.com> <1426873515.3382.73.camel@redhat.com> <550C844B.1060108@oracle.com> Message-ID: <1427102823.3346.7.camel@redhat.com> On Fri, 2015-03-20 at 16:34 -0400, Coleen Phillimore wrote: > Severin, Thank you for taking care of this. I have one question for > the greater project. > > Is there platform support in jtreg so we don't need to change the Java code? > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html > > + if (!Platform.isDebugBuild() || Platform.isZero()) { I'm not sure I understand the question. Could you elaborate? What's "platform support in jtreg" exactly? FWIW, I'm not aware of any specific Zero support in jtreg itself. Cheers, Severin > Thanks, > Coleen > > On 3/20/15, 1:45 PM, Severin Gehwolf wrote: > > Hi Volker, > > > > Thanks for the review! > > > > On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: > >> Hi Severin, > >> > >> I can't understand how SafeFetch32 and SafeFetchN are supposed to work > >> at all in Zero. The whole point of having the SafeFetch routines is to > >> have a possibility of peeking at potentially illegal memory addresses. > > You are right. I did some digging in the hg history and it seems this > > implementation for Zero has been added with JDK-8022188 after > > JDK-8016697 introduced it. > > > >> The current implementation of SafeFetch on Zero can not provide this > >> functionality so in my eyes it is useless. > > I agree. > > > >> I think we should do the following: > >> - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero > >> (this way the unmodified CanUseSafeFetchXX() routines would work for > >> Zero as well) > >> - remove the implementations of SafeFetchN and SafeFetch32 and set > >> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry > >> to NULL in stubGenerator_zero.cpp (this will automatically make > >> StubRoutines::SafeFetchN_stub() return null on Zero) > >> - the calls to test_safefetch32XX() should be guarded by > >> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in > >> stubRoutines.cpp) > > Sounds good, I'll follow up with an updated webrev shortly. > > > >> The test changes are good. > > Cheers, > > Severin > > > >> Regards, > >> Volker > >> > >> > >> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Could somebody please review and sponsor this patch? > >>> > >>> The commit of JDK-8074552 broke the Zero port since it performs tests on > >>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers > >>> (relying on a continuation scheme for safe fetch errors) work. Yet > >>> performing this test correctly requires support from the signal handler > >>> and access routines to ucontext_t which are missing for Zero. > >>> > >>> The intent of JDK-8074552 was to improve error reporting on SEGV's. > >>> Having this feature in Zero is less useful, since it's a C++ interpreter > >>> only environment. > >>> > >>> This patch disables the test and makes CanUseSafeFetch* functions return > >>> false unconditionally for Zero JVMs so as to not produce a recursive > >>> SEGV's during error reporting. > >>> > >>> I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped > >>> for Zero. > >>> > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533 > >>> webrev: > >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ > >>> > >>> Testing done: make bootcycle-images fails before this patch and passes > >>> after for a Zero JVM on x86_64. > >>> > >>> Thanks, > >>> Severin > >>> > > > > > From sgehwolf at redhat.com Mon Mar 23 13:02:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Mar 2015 14:02:05 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: References: <1426852643.3382.50.camel@redhat.com> Message-ID: <1427115725.3346.18.camel@redhat.com> Hi Volker, Updated webrev which does what you suggested: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.02/ Thanks, Severin On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: > Hi Severin, > > I can't understand how SafeFetch32 and SafeFetchN are supposed to work > at all in Zero. The whole point of having the SafeFetch routines is to > have a possibility of peeking at potentially illegal memory addresses. > The current implementation of SafeFetch on Zero can not provide this > functionality so in my eyes it is useless. > > I think we should do the following: > - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero > (this way the unmodified CanUseSafeFetchXX() routines would work for > Zero as well) > - remove the implementations of SafeFetchN and SafeFetch32 and set > StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry > to NULL in stubGenerator_zero.cpp (this will automatically make > StubRoutines::SafeFetchN_stub() return null on Zero) > - the calls to test_safefetch32XX() should be guarded by > CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in > stubRoutines.cpp) > > The test changes are good. > > Regards, > Volker > > > On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this patch? > > > > The commit of JDK-8074552 broke the Zero port since it performs tests on > > JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers > > (relying on a continuation scheme for safe fetch errors) work. Yet > > performing this test correctly requires support from the signal handler > > and access routines to ucontext_t which are missing for Zero. > > > > The intent of JDK-8074552 was to improve error reporting on SEGV's. > > Having this feature in Zero is less useful, since it's a C++ interpreter > > only environment. > > > > This patch disables the test and makes CanUseSafeFetch* functions return > > false unconditionally for Zero JVMs so as to not produce a recursive > > SEGV's during error reporting. > > > > I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped > > for Zero. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8075533 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ > > > > Testing done: make bootcycle-images fails before this patch and passes > > after for a Zero JVM on x86_64. > > > > Thanks, > > Severin > > From coleen.phillimore at oracle.com Mon Mar 23 14:48:09 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 23 Mar 2015 10:48:09 -0400 Subject: RFR(S): 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: <2B47FF63-FDB7-4219-A653-96DC3F0DDFC5@oracle.com> References: <55022AB8.6020705@oracle.com> <76A01490-93E7-412A-9A91-E2A809A4B108@oracle.com> <2B47FF63-FDB7-4219-A653-96DC3F0DDFC5@oracle.com> Message-ID: <551027A9.1050302@oracle.com> On 3/23/15, 4:45 AM, Roland Westrelin wrote: > Given I didn?t get any new comments on this, I?m pushing it. Sorry, I started to answer with "I don't know..." Vladimir Ivanov may have fixed that code also. Coleen > > Roland. > > >> On Mar 13, 2015, at 10:43 AM, Roland Westrelin wrote: >> >>> Fix looks correct. I CC to runtime group. They may know answers for your questions. >> Thanks for the review. We?ve been the ones making changes to dependencies.cpp for default methods, not sure the runtime team can help. >> >> I tried removing: >> >> // Disable CHA for default methods for now >> if (root_m->get_Method()->is_default_method()) { >> return NULL; >> } >> >> and the test case that comes with that change crashes. So it looks like it?s still needed. >> >> Roland. >> >>> Thanks, >>> Vladimir >>> >>> On 3/12/15 6:31 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8069263/webrev.00/ >>>> >>>> In the test case, I1.m1() is a default method that is added by default methods processing to the list of default methods of class C2. The call at line 54 triggers CHA. It finds m1 in class C2 but with holder I1 as unique target. The assert fires because m1?s holder is not C2 but m1 is in the list of C2?s methods. >>>> >>>> I fixed this by returning no unique method in that case because: >>>> >>>> 1) we seem to still not expect that we can handle default methods properly in CHA even though we?ve added code in dependencies.cpp to support them. ciMethod::find_monomorphic_target) has this code: >>>> >>>> // Disable CHA for default methods for now >>>> if (root_m->get_Method()->is_default_method()) { >>>> return NULL; >>>> } >>>> >>>> Or maybe that code should be removed? >>>> >>>> 2) a proper fix would require that we record the method, its actual holder (C2) in the dependency which would require more extensive changes. I wonder if the extra complexity would make sense. >>>> >>>> Roland. >>>> >>>> From coleen.phillimore at oracle.com Mon Mar 23 14:51:53 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 23 Mar 2015 10:51:53 -0400 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <1427102823.3346.7.camel@redhat.com> References: <1426852643.3382.50.camel@redhat.com> <1426873515.3382.73.camel@redhat.com> <550C844B.1060108@oracle.com> <1427102823.3346.7.camel@redhat.com> Message-ID: <55102889.10109@oracle.com> On 3/23/15, 5:27 AM, Severin Gehwolf wrote: > On Fri, 2015-03-20 at 16:34 -0400, Coleen Phillimore wrote: >> Severin, Thank you for taking care of this. I have one question for >> the greater project. >> >> Is there platform support in jtreg so we don't need to change the Java code? >> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html >> >> + if (!Platform.isDebugBuild() || Platform.isZero()) { > I'm not sure I understand the question. Could you elaborate? What's > "platform support in jtreg" exactly? Sorry, that question was meant for the jtreg experts. There may be better way to exclude certain tests. How do you run hotspot/test/runtime/CompressedOops tests since CompressedOops isn't supported with Zero? thanks, Coleen > > FWIW, I'm not aware of any specific Zero support in jtreg itself. > > Cheers, > Severin > >> Thanks, >> Coleen >> >> On 3/20/15, 1:45 PM, Severin Gehwolf wrote: >>> Hi Volker, >>> >>> Thanks for the review! >>> >>> On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: >>>> Hi Severin, >>>> >>>> I can't understand how SafeFetch32 and SafeFetchN are supposed to work >>>> at all in Zero. The whole point of having the SafeFetch routines is to >>>> have a possibility of peeking at potentially illegal memory addresses. >>> You are right. I did some digging in the hg history and it seems this >>> implementation for Zero has been added with JDK-8022188 after >>> JDK-8016697 introduced it. >>> >>>> The current implementation of SafeFetch on Zero can not provide this >>>> functionality so in my eyes it is useless. >>> I agree. >>> >>>> I think we should do the following: >>>> - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero >>>> (this way the unmodified CanUseSafeFetchXX() routines would work for >>>> Zero as well) >>>> - remove the implementations of SafeFetchN and SafeFetch32 and set >>>> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry >>>> to NULL in stubGenerator_zero.cpp (this will automatically make >>>> StubRoutines::SafeFetchN_stub() return null on Zero) >>>> - the calls to test_safefetch32XX() should be guarded by >>>> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in >>>> stubRoutines.cpp) >>> Sounds good, I'll follow up with an updated webrev shortly. >>> >>>> The test changes are good. >>> Cheers, >>> Severin >>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could somebody please review and sponsor this patch? >>>>> >>>>> The commit of JDK-8074552 broke the Zero port since it performs tests on >>>>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers >>>>> (relying on a continuation scheme for safe fetch errors) work. Yet >>>>> performing this test correctly requires support from the signal handler >>>>> and access routines to ucontext_t which are missing for Zero. >>>>> >>>>> The intent of JDK-8074552 was to improve error reporting on SEGV's. >>>>> Having this feature in Zero is less useful, since it's a C++ interpreter >>>>> only environment. >>>>> >>>>> This patch disables the test and makes CanUseSafeFetch* functions return >>>>> false unconditionally for Zero JVMs so as to not produce a recursive >>>>> SEGV's during error reporting. >>>>> >>>>> I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped >>>>> for Zero. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ >>>>> >>>>> Testing done: make bootcycle-images fails before this patch and passes >>>>> after for a Zero JVM on x86_64. >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>> > > From volker.simonis at gmail.com Mon Mar 23 14:56:05 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 23 Mar 2015 15:56:05 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <1427115725.3346.18.camel@redhat.com> References: <1426852643.3382.50.camel@redhat.com> <1427115725.3346.18.camel@redhat.com> Message-ID: Hi Severin, your change looks good now except one minor thing I forgot to mention in my last mail. Can you please always update the copyright year in all the files you edit to the current year. And I also noticed that the test "test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java" has somehow slipped trough without any copyright header at all. Could you please also add a complete copyright header to that file. Unfortunately you still need a sponsor from within Oracle because you touch shared files :( Thank you and best regards, Volker On Mon, Mar 23, 2015 at 2:02 PM, Severin Gehwolf wrote: > Hi Volker, > > Updated webrev which does what you suggested: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.02/ > > Thanks, > Severin > > On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: >> Hi Severin, >> >> I can't understand how SafeFetch32 and SafeFetchN are supposed to work >> at all in Zero. The whole point of having the SafeFetch routines is to >> have a possibility of peeking at potentially illegal memory addresses. >> The current implementation of SafeFetch on Zero can not provide this >> functionality so in my eyes it is useless. >> >> I think we should do the following: >> - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero >> (this way the unmodified CanUseSafeFetchXX() routines would work for >> Zero as well) >> - remove the implementations of SafeFetchN and SafeFetch32 and set >> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry >> to NULL in stubGenerator_zero.cpp (this will automatically make >> StubRoutines::SafeFetchN_stub() return null on Zero) >> - the calls to test_safefetch32XX() should be guarded by >> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in >> stubRoutines.cpp) >> >> The test changes are good. >> >> Regards, >> Volker >> >> >> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: >> > Hi, >> > >> > Could somebody please review and sponsor this patch? >> > >> > The commit of JDK-8074552 broke the Zero port since it performs tests on >> > JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers >> > (relying on a continuation scheme for safe fetch errors) work. Yet >> > performing this test correctly requires support from the signal handler >> > and access routines to ucontext_t which are missing for Zero. >> > >> > The intent of JDK-8074552 was to improve error reporting on SEGV's. >> > Having this feature in Zero is less useful, since it's a C++ interpreter >> > only environment. >> > >> > This patch disables the test and makes CanUseSafeFetch* functions return >> > false unconditionally for Zero JVMs so as to not produce a recursive >> > SEGV's during error reporting. >> > >> > I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped >> > for Zero. >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8075533 >> > webrev: >> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ >> > >> > Testing done: make bootcycle-images fails before this patch and passes >> > after for a Zero JVM on x86_64. >> > >> > Thanks, >> > Severin >> > > > > From roland.westrelin at oracle.com Mon Mar 23 15:04:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 23 Mar 2015 16:04:51 +0100 Subject: RFR(S): 8069263: assert(fm == NULL || fm->method_holder() == _participants[n]) failed: sanity In-Reply-To: <551027A9.1050302@oracle.com> References: <55022AB8.6020705@oracle.com> <76A01490-93E7-412A-9A91-E2A809A4B108@oracle.com> <2B47FF63-FDB7-4219-A653-96DC3F0DDFC5@oracle.com> <551027A9.1050302@oracle.com> Message-ID: >> Given I didn?t get any new comments on this, I?m pushing it. > > Sorry, I started to answer with "I don't know..." Vladimir Ivanov may have fixed that code also. Thanks for getting back to me. Anyway I pushed it. Roland. > > Coleen >> >> Roland. >> >> >>> On Mar 13, 2015, at 10:43 AM, Roland Westrelin wrote: >>> >>>> Fix looks correct. I CC to runtime group. They may know answers for your questions. >>> Thanks for the review. We?ve been the ones making changes to dependencies.cpp for default methods, not sure the runtime team can help. >>> >>> I tried removing: >>> >>> // Disable CHA for default methods for now >>> if (root_m->get_Method()->is_default_method()) { >>> return NULL; >>> } >>> >>> and the test case that comes with that change crashes. So it looks like it?s still needed. >>> >>> Roland. >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 3/12/15 6:31 AM, Roland Westrelin wrote: >>>>> http://cr.openjdk.java.net/~roland/8069263/webrev.00/ >>>>> >>>>> In the test case, I1.m1() is a default method that is added by default methods processing to the list of default methods of class C2. The call at line 54 triggers CHA. It finds m1 in class C2 but with holder I1 as unique target. The assert fires because m1?s holder is not C2 but m1 is in the list of C2?s methods. >>>>> >>>>> I fixed this by returning no unique method in that case because: >>>>> >>>>> 1) we seem to still not expect that we can handle default methods properly in CHA even though we?ve added code in dependencies.cpp to support them. ciMethod::find_monomorphic_target) has this code: >>>>> >>>>> // Disable CHA for default methods for now >>>>> if (root_m->get_Method()->is_default_method()) { >>>>> return NULL; >>>>> } >>>>> >>>>> Or maybe that code should be removed? >>>>> >>>>> 2) a proper fix would require that we record the method, its actual holder (C2) in the dependency which would require more extensive changes. I wonder if the extra complexity would make sense. >>>>> >>>>> Roland. >>>>> >>>>> > From sgehwolf at redhat.com Mon Mar 23 15:08:59 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Mar 2015 16:08:59 +0100 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <55102889.10109@oracle.com> References: <1426852643.3382.50.camel@redhat.com> <1426873515.3382.73.camel@redhat.com> <550C844B.1060108@oracle.com> <1427102823.3346.7.camel@redhat.com> <55102889.10109@oracle.com> Message-ID: <1427123339.3346.27.camel@redhat.com> On Mon, 2015-03-23 at 10:51 -0400, Coleen Phillimore wrote: > On 3/23/15, 5:27 AM, Severin Gehwolf wrote: > > On Fri, 2015-03-20 at 16:34 -0400, Coleen Phillimore wrote: > >> Severin, Thank you for taking care of this. I have one question for > >> the greater project. > >> > >> Is there platform support in jtreg so we don't need to change the Java code? > >> > >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html > >> > >> + if (!Platform.isDebugBuild() || Platform.isZero()) { > > I'm not sure I understand the question. Could you elaborate? What's > > "platform support in jtreg" exactly? > > Sorry, that question was meant for the jtreg experts. There may be > better way to exclude certain tests. I see. > How do you run hotspot/test/runtime/CompressedOops tests since > CompressedOops isn't supported with Zero? We don't do anything special for them. I'd suspect they just fail. Nobody has yet taken on the task of going through all jtreg tests and check if they make sense for Zero :-/ Cheers, Severin > thanks, > Coleen > > > > > FWIW, I'm not aware of any specific Zero support in jtreg itself. > > > > Cheers, > > Severin > > > >> Thanks, > >> Coleen > >> > >> On 3/20/15, 1:45 PM, Severin Gehwolf wrote: > >>> Hi Volker, > >>> > >>> Thanks for the review! > >>> > >>> On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: > >>>> Hi Severin, > >>>> > >>>> I can't understand how SafeFetch32 and SafeFetchN are supposed to work > >>>> at all in Zero. The whole point of having the SafeFetch routines is to > >>>> have a possibility of peeking at potentially illegal memory addresses. > >>> You are right. I did some digging in the hg history and it seems this > >>> implementation for Zero has been added with JDK-8022188 after > >>> JDK-8016697 introduced it. > >>> > >>>> The current implementation of SafeFetch on Zero can not provide this > >>>> functionality so in my eyes it is useless. > >>> I agree. > >>> > >>>> I think we should do the following: > >>>> - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero > >>>> (this way the unmodified CanUseSafeFetchXX() routines would work for > >>>> Zero as well) > >>>> - remove the implementations of SafeFetchN and SafeFetch32 and set > >>>> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry > >>>> to NULL in stubGenerator_zero.cpp (this will automatically make > >>>> StubRoutines::SafeFetchN_stub() return null on Zero) > >>>> - the calls to test_safefetch32XX() should be guarded by > >>>> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in > >>>> stubRoutines.cpp) > >>> Sounds good, I'll follow up with an updated webrev shortly. > >>> > >>>> The test changes are good. > >>> Cheers, > >>> Severin > >>> > >>>> Regards, > >>>> Volker > >>>> > >>>> > >>>> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: > >>>>> Hi, > >>>>> > >>>>> Could somebody please review and sponsor this patch? > >>>>> > >>>>> The commit of JDK-8074552 broke the Zero port since it performs tests on > >>>>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers > >>>>> (relying on a continuation scheme for safe fetch errors) work. Yet > >>>>> performing this test correctly requires support from the signal handler > >>>>> and access routines to ucontext_t which are missing for Zero. > >>>>> > >>>>> The intent of JDK-8074552 was to improve error reporting on SEGV's. > >>>>> Having this feature in Zero is less useful, since it's a C++ interpreter > >>>>> only environment. > >>>>> > >>>>> This patch disables the test and makes CanUseSafeFetch* functions return > >>>>> false unconditionally for Zero JVMs so as to not produce a recursive > >>>>> SEGV's during error reporting. > >>>>> > >>>>> I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped > >>>>> for Zero. > >>>>> > >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533 > >>>>> webrev: > >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ > >>>>> > >>>>> Testing done: make bootcycle-images fails before this patch and passes > >>>>> after for a Zero JVM on x86_64. > >>>>> > >>>>> Thanks, > >>>>> Severin > >>>>> > >>> > > > > > From coleen.phillimore at oracle.com Mon Mar 23 15:14:21 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 23 Mar 2015 11:14:21 -0400 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: References: <1426852643.3382.50.camel@redhat.com> <1427115725.3346.18.camel@redhat.com> Message-ID: <55102DCD.1080101@oracle.com> This looks good to me and I'll sponsor it. Thanks for answering my other question. Thanks, Coleen On 3/23/15, 10:56 AM, Volker Simonis wrote: > Hi Severin, > > your change looks good now except one minor thing I forgot to mention > in my last mail. Can you please always update the copyright year in > all the files you edit to the current year. And I also noticed that > the test "test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java" > has somehow slipped trough without any copyright header at all. Could > you please also add a complete copyright header to that file. > > Unfortunately you still need a sponsor from within Oracle because you > touch shared files :( > > Thank you and best regards, > Volker > > > On Mon, Mar 23, 2015 at 2:02 PM, Severin Gehwolf wrote: >> Hi Volker, >> >> Updated webrev which does what you suggested: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.02/ >> >> Thanks, >> Severin >> >> On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: >>> Hi Severin, >>> >>> I can't understand how SafeFetch32 and SafeFetchN are supposed to work >>> at all in Zero. The whole point of having the SafeFetch routines is to >>> have a possibility of peeking at potentially illegal memory addresses. >>> The current implementation of SafeFetch on Zero can not provide this >>> functionality so in my eyes it is useless. >>> >>> I think we should do the following: >>> - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero >>> (this way the unmodified CanUseSafeFetchXX() routines would work for >>> Zero as well) >>> - remove the implementations of SafeFetchN and SafeFetch32 and set >>> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry >>> to NULL in stubGenerator_zero.cpp (this will automatically make >>> StubRoutines::SafeFetchN_stub() return null on Zero) >>> - the calls to test_safefetch32XX() should be guarded by >>> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in >>> stubRoutines.cpp) >>> >>> The test changes are good. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could somebody please review and sponsor this patch? >>>> >>>> The commit of JDK-8074552 broke the Zero port since it performs tests on >>>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers >>>> (relying on a continuation scheme for safe fetch errors) work. Yet >>>> performing this test correctly requires support from the signal handler >>>> and access routines to ucontext_t which are missing for Zero. >>>> >>>> The intent of JDK-8074552 was to improve error reporting on SEGV's. >>>> Having this feature in Zero is less useful, since it's a C++ interpreter >>>> only environment. >>>> >>>> This patch disables the test and makes CanUseSafeFetch* functions return >>>> false unconditionally for Zero JVMs so as to not produce a recursive >>>> SEGV's during error reporting. >>>> >>>> I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped >>>> for Zero. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533 >>>> webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ >>>> >>>> Testing done: make bootcycle-images fails before this patch and passes >>>> after for a Zero JVM on x86_64. >>>> >>>> Thanks, >>>> Severin >>>> >> >> From kim.barrett at oracle.com Mon Mar 23 15:48:54 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 23 Mar 2015 11:48:54 -0400 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <550FC4B2.1000606@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> Message-ID: <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> On Mar 23, 2015, at 3:45 AM, David Holmes wrote: > > On 23/03/2015 4:12 PM, David Holmes wrote: >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>> Argh. Yes. Martin told me not to get involved with Windows, but would >>> I listen? Of course not... >>> >>> http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ >> >> Looks okay to me - running a test job now. > > This just isn't meant to be :( It seems that: > > GrowableArray options(2, true); > > in arguments.cpp is giving the windows compiler some grief: > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) : error C2220: warning treated as error - no 'object' file generated > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(168) : while compiling class template member function 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' > with > [ > E=JavaVMOption > ] > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\arguments.cpp(3516) : see reference to class template instantiation 'GrowableArray' being compiled > with > [ > E=JavaVMOption > ] > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) : warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(388) : warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(379) : while compiling class template member function 'void GrowableArray::grow(int)' > with > [ > E=JavaVMOption > ] > > I'm guessing it doesn't like the enum as the generic arg, but don't know why given that it accepts plain int elsewhere. ??? Just suppressing this warning (unconditionally everywhere) would probably make sense. Microsoft describes it as an obsolete warning: https://msdn.microsoft.com/en-us/library/wewb47ee.aspx "This warning is obsolete. It is only generated in Visual Studio 2005 through Visual Studio 2012. It reports a behavior change from the Visual C++ compiler that shipped in Visual Studio .NET when initializing a POD (plain old data) object with (); the compiler default-initializes the object.? It?s too bad the JDK9 supported build platform for Windows is still lagging. From jeremymanson at google.com Mon Mar 23 16:56:51 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 23 Mar 2015 09:56:51 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> Message-ID: Thanks, Kim. This is a pretty silly warning to have break the build. Does anyone have a problem with PODs being default initialized? That's required by the standard, so if you do, then you are Doing It Wrong. I assume it is pretty easy to turn the warning off. I'd do it, but I don't have the Windows build-fu necessary. Also, do we think it would require another bug? I'd hate to have to change my (or any) code for this. Jeremy On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett wrote: > On Mar 23, 2015, at 3:45 AM, David Holmes wrote: > > > > On 23/03/2015 4:12 PM, David Holmes wrote: > >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: > >>> Argh. Yes. Martin told me not to get involved with Windows, but would > >>> I listen? Of course not... > >>> > >>> http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ > >> > >> Looks okay to me - running a test job now. > > > > This just isn't meant to be :( It seems that: > > > > GrowableArray options(2, true); > > > > in arguments.cpp is giving the windows compiler some grief: > > > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) > : error C2220: warning treated as error - no 'object' file generated > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(168) > : while compiling class template member function > 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' > > with > > [ > > E=JavaVMOption > > ] > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\arguments.cpp(3516) > : see reference to class template instantiation 'GrowableArray' being > compiled > > with > > [ > > E=JavaVMOption > > ] > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) > : warning C4345: behavior change: an object of POD type constructed with an > initializer of the form () will be default-initialized > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(388) > : warning C4345: behavior change: an object of POD type constructed with an > initializer of the form () will be default-initialized > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(379) > : while compiling class template member function 'void > GrowableArray::grow(int)' > > with > > [ > > E=JavaVMOption > > ] > > > > I'm guessing it doesn't like the enum as the generic arg, but don't know > why given that it accepts plain int elsewhere. ??? > > Just suppressing this warning (unconditionally everywhere) would probably > make sense. > > Microsoft describes it as an obsolete warning: > > https://msdn.microsoft.com/en-us/library/wewb47ee.aspx > > "This warning is obsolete. It is only generated in Visual Studio 2005 > through Visual Studio 2012. It reports a behavior change from the Visual > C++ compiler that shipped in Visual Studio .NET when initializing a POD > (plain old data) object with (); the compiler default-initializes the > object.? > > It?s too bad the JDK9 supported build platform for Windows is still > lagging. > > From yumin.qi at oracle.com Mon Mar 23 18:48:56 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 23 Mar 2015 11:48:56 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <550C9D1F.2010007@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> Message-ID: <55106018.3020005@oracle.com> Since Thomas is not a reviewer in open jdk, I need two volunteers (at least one "R"eviewer). Dan, since you already reviewed previous version, could you have a look? Thanks Yumin On 3/20/2015 3:20 PM, Yumin Qi wrote: > Thomas, > > Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add > another test case change: test/runtime/memory/ReadFromNoaccessArea.java > (Thanks Dan's update) > > Thanks > Yumin > > On 3/20/2015 11:55 AM, Thomas St?fe wrote: >> >> Hi Yumin, >> >> I think you meant to post webrev.04? >> >> I looked at 04, and it looks nice. Thank you! >> >> (still only reviewer with r) >> >> Thomas >> >> On Mar 20, 2015 6:20 PM, "Yumin Qi" > > wrote: >> >> Hi, All >> >> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >> >> >> This version is based on Thomas' suggestion. >> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >> >> Thanks >> Yumin >> >> On 3/18/2015 10:06 AM, Yumin Qi wrote: >> >> >> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >> >> Hi Yumin, >> >> - just aesthetics, but on all implementations of >> os_abort(), at least on the UNIX variants, maybe we could >> consistently rename the parameters to be "siginfo" and >> "context" instead of using Windows terms? >> >> Sure. >> >> - On check_create_dump_limit(), you do not need >> exceptionRecord, contextRecord parameters anymore. The >> only parameters now needed are buffer and buffer size, >> which is not even an output parameter, just a scratch >> buffer for this function to use for printf. For output, it >> calls VMError::report_coredump_status(...) at the end to >> provide information about the core file. >> >> - I would rename that function from >> check_create_dump_limit() to check_dump_limit() - nothing >> is created anymore. >> >> Yes, no need to carry those two parameters. I tried to keep >> less changes, but decided to change now. >> >> - on Windows, in os::abort(), there is no point anymore in >> calling VMError::report_coredump_status(...) because that >> information is only used during error log writing which >> already happened. It only makes sense to call this >> function in check_create_dump_limit(), which happens >> before error log writing. >> Instead, maybe error messages like "Call to >> MiniDumpWriteDump() failed" should just be written to >> stderr? This would be consistent with Unix, where the OS >> writes a short message on stderr if core file writing fails. >> >> Sure, will direct output to stderr. >> >> - there is now a new test, >> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >> - could you please also add "-XX:-CreateCoredumpOnCrash" ? >> I just added the test and did not want to add the option >> before it was available. >> >> OK >> >> Thanks >> Yumin >> >> Thanks for your work! >> >> Thomas >> >> >> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >> >> >> >> wrote: >> >> Hi, Dan and all >> >> I have updated webrev at: >> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >> >> >> >> 1) bug changed synopsis >> 8074354: Make CreateMinidumpOnCrash a new name >> and >> available on all platforms >> 2) tests: JPRT, vm.runtime.quick.testlist (on >> Windows), jtreg on >> Windows and Linux/Unix. >> >> Thanks >> Yumin >> >> >> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >> >> I believe there are both JavaTest/JTREG tests in >> the hotspot repo >> and there are VM/NSK tests from back when we did >> phone home... >> >> Check with Christian or Misha... >> >> Dan >> >> >> On 3/12/15 1:50 PM, Yumin Qi wrote: >> >> Thanks, Dan >> >> Will look at and run those tests. Are they >> under nsk? >> >> Yumin >> >> On 3/12/2015 12:29 PM, Daniel D. Daugherty >> wrote: >> >> Yumin, >> >> There are some error handler tests. You >> should find >> those and make >> sure that you run them on Windows since >> you're >> changing the order >> there... >> >> Dan >> >> >> On 3/12/15 12:42 PM, Yumin Qi wrote: >> >> Hi, Thomas and all >> >> The second version of the change: >> webrev: >> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >> >> >> >> In this version: >> 1) switch order on Windows to first >> print log >> file as other platform, then dump core >> file if >> needed. When VMError created after >> crash, siginfo >> and context which are ExceptionRecord >> and >> ContextRecord on Windows are recorded, >> mini (or >> full, due to 'or' used so type will be >> mini >> anyway) dump creates dump file based >> on those two >> as before. >> 2) to make os::abort to get above >> two pointers, >> added two more fields to the function >> parameters: >> 3) changes for >> test/runtime/ErrorHandling/SecondaryError.java --- >> added "-XX:-CreateCoredumpOnCrash" >> >> - static void abort(bool >> dump_core = true); >> + static void abort(bool dump_core >> = true, >> void *siginfo = NULL, void *context = >> NULL); >> >> Tests: JPRT and manually. >> >> Thanks >> Yumin >> >> On 3/11/2015 3:47 AM, Thomas St?fe >> wrote: >> >> Hi Yumin, >> >> There is also >> test/runtime/ErrorHandling/SecondaryErrorTest.java >> - could you please add >> "-XX:-CreateCoredumpOnCrash" ? >> Thank you! >> >> Beyond that, as I wrote in the bug >> report >> comments: >> >> "This is also a problem on Windows - >> MiniDumpWriteDump() may hang >> infinitly. And on >> Windows this is worse than under >> UNIX because >> we create the Dump before writing >> the hs-err >> file, so if the Dump hangs, we get >> no error >> log. I would like to revert the >> order: create >> the minidump after writing the >> error log, the >> same way Unix does it. We did this >> in our JVM >> (SAP) because for us, error logs >> are more >> useful than minidumps. " >> >> So, I would like to see os::abort >> on Windows >> call MiniDumpWriteDump(), and thus >> the mini >> dump writing moved after the >> error log >> writing. This would also make the >> code way >> cleaner because the control flow >> would be the >> same on all platforms. >> >> I understand that this may be out >> of scope for >> your change, but I would like to >> know what >> others think about this. >> >> Kind regards, Thomas >> >> >> >> >> >> >> >> On Wed, Mar 11, 2015 at 8:02 AM, >> Yumin Qi >> > >> > > >> > >> > >>> wrote: >> >> Please review: >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8074354 >> webrev: >> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >> >> >> >> >> Summary: Tests timed out when >> VM crashes >> and dumping core file >> which in the test case is not >> needed. To >> make core not created, >> the fix changed >> CreateMinidumpOnCrash to >> CreateCoredumpOnCrash, >> the former is only used on >> Windows and the >> latter for all >> platforms. When VM crashes on >> non Windows, >> core file generated as >> default if OS sets core dump >> allowed. >> Default value of >> CreateCoredumpOnCrash set to >> 'true' to >> keep same behavior on non >> Windows platforms, but changed >> for Windows >> --- original is false, >> not create minidump on >> Windows. With >> CreateCoredumpOnCrash turned >> off, no core file will be >> generated. >> CreateMinidumpOnCrash still >> can be used on commandline but >> only as >> alias for the new flag. >> >> Tests: JPRT, manual tests >> setting >> CreateMinidumpOnCrash on >> commandline to verify flag >> change as alias. >> >> Thanks >> Yumin >> >> >> >> >> >> >> >> >> >> > From david.holmes at oracle.com Tue Mar 24 07:22:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Mar 2015 17:22:52 +1000 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <550C5E60.2050305@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> <550C5E60.2050305@oracle.com> Message-ID: <551110CC.5090607@oracle.com> Hi Harold, On 21/03/2015 3:52 AM, harold seigel wrote: > Hi Karen, > > Thank you for your comments. > > Bytecode istore can change the type of a local slot. So, here's a new > webrev that uses the incoming type state for all of the astore*, > dstore*, fstore*, istore*, and lstore* bytecodes. The webrev also > contains a new test for the istore bytecode case, called BadMapIstore.jasm. > > Could you please review this webrev, when you have a chance? > > New open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.2/ This seems more inline with the "astore and friends" comment in the bug report. Do we need to add test cases for all the *store variants? Thanks, David > Thanks! Harold > > On 3/19/2015 3:33 PM, Karen Kinnear wrote: >> Harold, >> >> I get it - this only affects instructions that set the type of a local >> slot since the operand stack is cleared. >> >> So - what about istore? >> If we have a local slot that contains a long or double, Frederic >> reminded me that JVMS 2.6.1 does allow stores to those separate slots, >> e.g. an istore. My mental model of this is that it would change the >> type of the local slot. >> >> Would that mean we would want to check any of the *store bytecodes? >> >> (I know the spec would change for all bytecodes which might be cleaner >> - I suspect you are being extra cautious about making changes >> to reduce risk of breaking something in the field). >> >> thanks, >> Karen >> >> On Mar 18, 2015, at 2:18 PM, harold seigel wrote: >> >>> Hi Karen, >>> >>> The fix does not affect normal verifier type-state (stack map) >>> checking that is done when looping through the bytecodes. It only >>> affects whether the incoming or outgoing type-state is used when >>> comparing the type-state at a particular bytecode with the type-state >>> at the start of its potential exception handlers. >>> >>> In addition, (to paraphrase Keith's comment in the bug), it only >>> affects instructions that set the type of a local slot (astore and >>> friends) ... . Instructions that affect the expression stack are not >>> a problem since the type-state's stack is cleared when type checking >>> an exception handler. >>> >>> So, other bytecodes such as aload and friends, getstatic and >>> getfield, etc. are not an issue. >>> >>> Thanks, Harold >>> >>> On 3/16/2015 3:49 PM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> Thanks for helping me walk through this in more detail. >>>> >>>> The way I read this, the fix would apply to all bytecodes - except for >>>> invokespecial - which is handled I believe correctly inside the >>>> verify_invoke_init. >>>> >>>> So if you could possibly experiment with some additional >>>> instructions - I suspect >>>> you can make a conditional check where you put the beginning check >>>> and remove >>>> the check at the end. >>>> >>>> thanks, >>>> Karen >>>> >>>> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >>>> >>>>> Hi Harold, >>>>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this fix for bug JDK-7127066. The fix applies to >>>>>> astore* >>>>>> bytecodes because, when inside an exception handler, they can >>>>>> reference >>>>>> the thrown object and modify the number of stack locals, enabling the >>>>>> incorrect stack match. >>>>>> >>>>>> Open webrev: >>>>>> http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>>>> >>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>>>> >>>>>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>>>>> java/lang, java/io, and java/util tests, and testbase quick and split >>>>>> verifier tests, and with the test case provided in the bug. >>>>> The new check looks okay, though I can't verify the exact placement >>>>> of it. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks! Harold > From jonathan.gibbons at oracle.com Tue Mar 24 00:59:50 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 Mar 2015 17:59:50 -0700 Subject: RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552 In-Reply-To: <55102889.10109@oracle.com> References: <1426852643.3382.50.camel@redhat.com> <1426873515.3382.73.camel@redhat.com> <550C844B.1060108@oracle.com> <1427102823.3346.7.camel@redhat.com> <55102889.10109@oracle.com> Message-ID: <5510B706.9010202@oracle.com> Coleen, There's new stuff coming up in jtreg that will allow jtreg to query VM properties, as provided by the VM and VM SQE teams. But that has not started yet. -- Jon On 03/23/2015 07:51 AM, Coleen Phillimore wrote: > > On 3/23/15, 5:27 AM, Severin Gehwolf wrote: >> On Fri, 2015-03-20 at 16:34 -0400, Coleen Phillimore wrote: >>> Severin, Thank you for taking care of this. I have one question for >>> the greater project. >>> >>> Is there platform support in jtreg so we don't need to change the >>> Java code? >>> >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html >>> >>> >>> + if (!Platform.isDebugBuild() || Platform.isZero()) { >> I'm not sure I understand the question. Could you elaborate? What's >> "platform support in jtreg" exactly? > > Sorry, that question was meant for the jtreg experts. There may be > better way to exclude certain tests. > > How do you run hotspot/test/runtime/CompressedOops tests since > CompressedOops isn't supported with Zero? > > thanks, > Coleen > >> >> FWIW, I'm not aware of any specific Zero support in jtreg itself. >> >> Cheers, >> Severin >> >>> Thanks, >>> Coleen >>> >>> On 3/20/15, 1:45 PM, Severin Gehwolf wrote: >>>> Hi Volker, >>>> >>>> Thanks for the review! >>>> >>>> On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote: >>>>> Hi Severin, >>>>> >>>>> I can't understand how SafeFetch32 and SafeFetchN are supposed to >>>>> work >>>>> at all in Zero. The whole point of having the SafeFetch routines >>>>> is to >>>>> have a possibility of peeking at potentially illegal memory >>>>> addresses. >>>> You are right. I did some digging in the hg history and it seems this >>>> implementation for Zero has been added with JDK-8022188 after >>>> JDK-8016697 introduced it. >>>> >>>>> The current implementation of SafeFetch on Zero can not provide this >>>>> functionality so in my eyes it is useless. >>>> I agree. >>>> >>>>> I think we should do the following: >>>>> - StubRoutines::SafeFetchN_stub() should just return 'null' on >>>>> Zero >>>>> (this way the unmodified CanUseSafeFetchXX() routines would work for >>>>> Zero as well) >>>>> - remove the implementations of SafeFetchN and SafeFetch32 and >>>>> set >>>>> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry >>>>> to NULL in stubGenerator_zero.cpp (this will automatically make >>>>> StubRoutines::SafeFetchN_stub() return null on Zero) >>>>> - the calls to test_safefetch32XX() should be guarded by >>>>> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in >>>>> stubRoutines.cpp) >>>> Sounds good, I'll follow up with an updated webrev shortly. >>>> >>>>> The test changes are good. >>>> Cheers, >>>> Severin >>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Could somebody please review and sponsor this patch? >>>>>> >>>>>> The commit of JDK-8074552 broke the Zero port since it performs >>>>>> tests on >>>>>> JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers >>>>>> (relying on a continuation scheme for safe fetch errors) work. Yet >>>>>> performing this test correctly requires support from the signal >>>>>> handler >>>>>> and access routines to ucontext_t which are missing for Zero. >>>>>> >>>>>> The intent of JDK-8074552 was to improve error reporting on SEGV's. >>>>>> Having this feature in Zero is less useful, since it's a C++ >>>>>> interpreter >>>>>> only environment. >>>>>> >>>>>> This patch disables the test and makes CanUseSafeFetch* functions >>>>>> return >>>>>> false unconditionally for Zero JVMs so as to not produce a recursive >>>>>> SEGV's during error reporting. >>>>>> >>>>>> I've also updated test SafeFetchInErrorHandlingTest.java so it's >>>>>> skipped >>>>>> for Zero. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075533 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/ >>>>>> >>>>>> Testing done: make bootcycle-images fails before this patch and >>>>>> passes >>>>>> after for a Zero JVM on x86_64. >>>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> >>>> >> >> > From harold.seigel at oracle.com Tue Mar 24 14:04:38 2015 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 24 Mar 2015 10:04:38 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <551110CC.5090607@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> <550C5E60.2050305@oracle.com> <551110CC.5090607@oracle.com> Message-ID: <55116EF6.1080006@oracle.com> Hi David, Thanks for the review. I don't think we need to add test cases for all *store variants because they use the same code path, but I did add a test for a dstore opcode, because, like lstore, it affects two local slots. See BadMapDstore.jasm in new webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.3/ Does that seem okay? Thanks, Harold On 3/24/2015 3:22 AM, David Holmes wrote: > Hi Harold, > > On 21/03/2015 3:52 AM, harold seigel wrote: >> Hi Karen, >> >> Thank you for your comments. >> >> Bytecode istore can change the type of a local slot. So, here's a new >> webrev that uses the incoming type state for all of the astore*, >> dstore*, fstore*, istore*, and lstore* bytecodes. The webrev also >> contains a new test for the istore bytecode case, called >> BadMapIstore.jasm. >> >> Could you please review this webrev, when you have a chance? >> >> New open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.2/ > > This seems more inline with the "astore and friends" comment in the > bug report. Do we need to add test cases for all the *store variants? > > Thanks, > David > >> Thanks! Harold >> >> On 3/19/2015 3:33 PM, Karen Kinnear wrote: >>> Harold, >>> >>> I get it - this only affects instructions that set the type of a local >>> slot since the operand stack is cleared. >>> >>> So - what about istore? >>> If we have a local slot that contains a long or double, Frederic >>> reminded me that JVMS 2.6.1 does allow stores to those separate slots, >>> e.g. an istore. My mental model of this is that it would change the >>> type of the local slot. >>> >>> Would that mean we would want to check any of the *store bytecodes? >>> >>> (I know the spec would change for all bytecodes which might be cleaner >>> - I suspect you are being extra cautious about making changes >>> to reduce risk of breaking something in the field). >>> >>> thanks, >>> Karen >>> >>> On Mar 18, 2015, at 2:18 PM, harold seigel wrote: >>> >>>> Hi Karen, >>>> >>>> The fix does not affect normal verifier type-state (stack map) >>>> checking that is done when looping through the bytecodes. It only >>>> affects whether the incoming or outgoing type-state is used when >>>> comparing the type-state at a particular bytecode with the type-state >>>> at the start of its potential exception handlers. >>>> >>>> In addition, (to paraphrase Keith's comment in the bug), it only >>>> affects instructions that set the type of a local slot (astore and >>>> friends) ... . Instructions that affect the expression stack are not >>>> a problem since the type-state's stack is cleared when type checking >>>> an exception handler. >>>> >>>> So, other bytecodes such as aload and friends, getstatic and >>>> getfield, etc. are not an issue. >>>> >>>> Thanks, Harold >>>> >>>> On 3/16/2015 3:49 PM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> Thanks for helping me walk through this in more detail. >>>>> >>>>> The way I read this, the fix would apply to all bytecodes - except >>>>> for >>>>> invokespecial - which is handled I believe correctly inside >>>>> the >>>>> verify_invoke_init. >>>>> >>>>> So if you could possibly experiment with some additional >>>>> instructions - I suspect >>>>> you can make a conditional check where you put the beginning check >>>>> and remove >>>>> the check at the end. >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >>>>> >>>>>> Hi Harold, >>>>>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this fix for bug JDK-7127066. The fix applies to >>>>>>> astore* >>>>>>> bytecodes because, when inside an exception handler, they can >>>>>>> reference >>>>>>> the thrown object and modify the number of stack locals, >>>>>>> enabling the >>>>>>> incorrect stack match. >>>>>>> >>>>>>> Open webrev: >>>>>>> http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>>>>> >>>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>>>>> >>>>>>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>>>>>> java/lang, java/io, and java/util tests, and testbase quick and >>>>>>> split >>>>>>> verifier tests, and with the test case provided in the bug. >>>>>> The new check looks okay, though I can't verify the exact placement >>>>>> of it. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks! Harold >> From david.holmes at oracle.com Wed Mar 25 04:03:07 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 14:03:07 +1000 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <55116EF6.1080006@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> <550C5E60.2050305@oracle.com> <551110CC.5090607@oracle.com> <55116EF6.1080006@oracle.com> Message-ID: <5512337B.5000600@oracle.com> Hi Harold, On 25/03/2015 12:04 AM, harold seigel wrote: > Hi David, > > Thanks for the review. I don't think we need to add test cases for all > *store variants because they use the same code path, but I did add a > test for a dstore opcode, because, like lstore, it affects two local slots. > > See BadMapDstore.jasm in new webrev: > http://cr.openjdk.java.net/~hseigel/bug_7127066.3/ > > Does that seem okay? That seems fine. Thanks, David > Thanks, Harold > > On 3/24/2015 3:22 AM, David Holmes wrote: >> Hi Harold, >> >> On 21/03/2015 3:52 AM, harold seigel wrote: >>> Hi Karen, >>> >>> Thank you for your comments. >>> >>> Bytecode istore can change the type of a local slot. So, here's a new >>> webrev that uses the incoming type state for all of the astore*, >>> dstore*, fstore*, istore*, and lstore* bytecodes. The webrev also >>> contains a new test for the istore bytecode case, called >>> BadMapIstore.jasm. >>> >>> Could you please review this webrev, when you have a chance? >>> >>> New open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.2/ >> >> This seems more inline with the "astore and friends" comment in the >> bug report. Do we need to add test cases for all the *store variants? >> >> Thanks, >> David >> >>> Thanks! Harold >>> >>> On 3/19/2015 3:33 PM, Karen Kinnear wrote: >>>> Harold, >>>> >>>> I get it - this only affects instructions that set the type of a local >>>> slot since the operand stack is cleared. >>>> >>>> So - what about istore? >>>> If we have a local slot that contains a long or double, Frederic >>>> reminded me that JVMS 2.6.1 does allow stores to those separate slots, >>>> e.g. an istore. My mental model of this is that it would change the >>>> type of the local slot. >>>> >>>> Would that mean we would want to check any of the *store bytecodes? >>>> >>>> (I know the spec would change for all bytecodes which might be cleaner >>>> - I suspect you are being extra cautious about making changes >>>> to reduce risk of breaking something in the field). >>>> >>>> thanks, >>>> Karen >>>> >>>> On Mar 18, 2015, at 2:18 PM, harold seigel wrote: >>>> >>>>> Hi Karen, >>>>> >>>>> The fix does not affect normal verifier type-state (stack map) >>>>> checking that is done when looping through the bytecodes. It only >>>>> affects whether the incoming or outgoing type-state is used when >>>>> comparing the type-state at a particular bytecode with the type-state >>>>> at the start of its potential exception handlers. >>>>> >>>>> In addition, (to paraphrase Keith's comment in the bug), it only >>>>> affects instructions that set the type of a local slot (astore and >>>>> friends) ... . Instructions that affect the expression stack are not >>>>> a problem since the type-state's stack is cleared when type checking >>>>> an exception handler. >>>>> >>>>> So, other bytecodes such as aload and friends, getstatic and >>>>> getfield, etc. are not an issue. >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 3/16/2015 3:49 PM, Karen Kinnear wrote: >>>>>> Harold, >>>>>> >>>>>> Thanks for helping me walk through this in more detail. >>>>>> >>>>>> The way I read this, the fix would apply to all bytecodes - except >>>>>> for >>>>>> invokespecial - which is handled I believe correctly inside >>>>>> the >>>>>> verify_invoke_init. >>>>>> >>>>>> So if you could possibly experiment with some additional >>>>>> instructions - I suspect >>>>>> you can make a conditional check where you put the beginning check >>>>>> and remove >>>>>> the check at the end. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >>>>>> >>>>>>> Hi Harold, >>>>>>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this fix for bug JDK-7127066. The fix applies to >>>>>>>> astore* >>>>>>>> bytecodes because, when inside an exception handler, they can >>>>>>>> reference >>>>>>>> the thrown object and modify the number of stack locals, >>>>>>>> enabling the >>>>>>>> incorrect stack match. >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>>>>>> >>>>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>>>>>> >>>>>>>> The fix was tested with JCK api, lang, and vm tests, jtreg hotspot, >>>>>>>> java/lang, java/io, and java/util tests, and testbase quick and >>>>>>>> split >>>>>>>> verifier tests, and with the test case provided in the bug. >>>>>>> The new check looks okay, though I can't verify the exact placement >>>>>>> of it. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks! Harold >>> > From david.holmes at oracle.com Wed Mar 25 04:24:41 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Mar 2015 14:24:41 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> Message-ID: <55123889.7080504@oracle.com> On 24/03/2015 2:56 AM, Jeremy Manson wrote: > Thanks, Kim. This is a pretty silly warning to have break the build. > Does anyone have a problem with PODs being default initialized? That's > required by the standard, so if you do, then you are Doing It Wrong. > > I assume it is pretty easy to turn the warning off. I'd do it, but I > don't have the Windows build-fu necessary. Also, do we think it would > require another bug? Unless someone else can already tell me how I will try to find the cycles to either disable the warning in that file (if that works) else disable it in the build - which will need a new CR I think. David > I'd hate to have to change my (or any) code for this. > > Jeremy > > On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett > wrote: > > On Mar 23, 2015, at 3:45 AM, David Holmes > wrote: > > > > On 23/03/2015 4:12 PM, David Holmes wrote: > >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: > >>> Argh. Yes. Martin told me not to get involved with Windows, but would > >>> I listen? Of course not... > >>> > >>>http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ > >> > >> Looks okay to me - running a test job now. > > > > This just isn't meant to be :( It seems that: > > > > GrowableArray options(2, true); > > > > in arguments.cpp is giving the windows compiler some grief: > > > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) : error C2220: warning treated as error - no 'object' file generated > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(168) : while compiling class template member function 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' > > with > > [ > > E=JavaVMOption > > ] > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\arguments.cpp(3516) : see reference to class template instantiation 'GrowableArray' being compiled > > with > > [ > > E=JavaVMOption > > ] > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) : warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(388) : warning C4345: behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized > > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(379) : while compiling class template member function 'void GrowableArray::grow(int)' > > with > > [ > > E=JavaVMOption > > ] > > > > I'm guessing it doesn't like the enum as the generic arg, but don't know why given that it accepts plain int elsewhere. ??? > > Just suppressing this warning (unconditionally everywhere) would > probably make sense. > > Microsoft describes it as an obsolete warning: > > https://msdn.microsoft.com/en-us/library/wewb47ee.aspx > > "This warning is obsolete. It is only generated in Visual Studio > 2005 through Visual Studio 2012. It reports a behavior change from > the Visual C++ compiler that shipped in Visual Studio .NET when > initializing a POD (plain old data) object with (); the compiler > default-initializes the object.? > > It?s too bad the JDK9 supported build platform for Windows is still > lagging. > > From jeremymanson at google.com Wed Mar 25 05:16:17 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 24 Mar 2015 22:16:17 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <55123889.7080504@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> Message-ID: Thanks, David. Much appreciated. Jeremy On Tue, Mar 24, 2015 at 9:24 PM, David Holmes wrote: > On 24/03/2015 2:56 AM, Jeremy Manson wrote: > >> Thanks, Kim. This is a pretty silly warning to have break the build. >> Does anyone have a problem with PODs being default initialized? That's >> required by the standard, so if you do, then you are Doing It Wrong. >> >> I assume it is pretty easy to turn the warning off. I'd do it, but I >> don't have the Windows build-fu necessary. Also, do we think it would >> require another bug? >> > > Unless someone else can already tell me how I will try to find the cycles > to either disable the warning in that file (if that works) else disable it > in the build - which will need a new CR I think. > > David > > I'd hate to have to change my (or any) code for this. >> >> Jeremy >> >> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett > > wrote: >> >> On Mar 23, 2015, at 3:45 AM, David Holmes > > wrote: >> > >> > On 23/03/2015 4:12 PM, David Holmes wrote: >> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >> >>> Argh. Yes. Martin told me not to get involved with Windows, but >> would >> >>> I listen? Of course not... >> >>> >> >>>http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ >> >> >> >> Looks okay to me - running a test job now. >> > >> > This just isn't meant to be :( It seems that: >> > >> > GrowableArray options(2, true); >> > >> > in arguments.cpp is giving the windows compiler some grief: >> > >> > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >> utilities/growableArray.hpp(171) : error C2220: warning treated as error >> - no 'object' file generated >> > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >> utilities/growableArray.hpp(168) : while compiling class template member >> function 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\arguments.cpp(3516) >> : see reference to class template instantiation 'GrowableArray' being >> compiled >> > with >> > [ >> > E=JavaVMOption >> > ] >> > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >> utilities/growableArray.hpp(171) : warning C4345: behavior change: an >> object of POD type constructed with an initializer of the form () will be >> default-initialized >> > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >> utilities/growableArray.hpp(388) : warning C4345: behavior change: an >> object of POD type constructed with an initializer of the form () will be >> default-initialized >> > C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >> utilities/growableArray.hpp(379) : while compiling class template member >> function 'void GrowableArray::grow(int)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> > I'm guessing it doesn't like the enum as the generic arg, but don't >> know why given that it accepts plain int elsewhere. ??? >> >> Just suppressing this warning (unconditionally everywhere) would >> probably make sense. >> >> Microsoft describes it as an obsolete warning: >> >> https://msdn.microsoft.com/en-us/library/wewb47ee.aspx >> >> "This warning is obsolete. It is only generated in Visual Studio >> 2005 through Visual Studio 2012. It reports a behavior change from >> the Visual C++ compiler that shipped in Visual Studio .NET when >> initializing a POD (plain old data) object with (); the compiler >> default-initializes the object.? >> >> It?s too bad the JDK9 supported build platform for Windows is still >> lagging. >> >> >> From harold.seigel at oracle.com Wed Mar 25 11:37:17 2015 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 25 Mar 2015 07:37:17 -0400 Subject: RFR(S) 7127066: Class verifier accepts an invalid class file In-Reply-To: <5512337B.5000600@oracle.com> References: <55032736.90402@oracle.com> <55062AD3.4030506@oracle.com> <5509C16C.2050401@oracle.com> <550C5E60.2050305@oracle.com> <551110CC.5090607@oracle.com> <55116EF6.1080006@oracle.com> <5512337B.5000600@oracle.com> Message-ID: <55129DED.3010602@oracle.com> Thanks David! Harold On 3/25/2015 12:03 AM, David Holmes wrote: > Hi Harold, > > On 25/03/2015 12:04 AM, harold seigel wrote: >> Hi David, >> >> Thanks for the review. I don't think we need to add test cases for all >> *store variants because they use the same code path, but I did add a >> test for a dstore opcode, because, like lstore, it affects two local >> slots. >> >> See BadMapDstore.jasm in new webrev: >> http://cr.openjdk.java.net/~hseigel/bug_7127066.3/ >> >> Does that seem okay? > > That seems fine. > > Thanks, > David > >> Thanks, Harold >> >> On 3/24/2015 3:22 AM, David Holmes wrote: >>> Hi Harold, >>> >>> On 21/03/2015 3:52 AM, harold seigel wrote: >>>> Hi Karen, >>>> >>>> Thank you for your comments. >>>> >>>> Bytecode istore can change the type of a local slot. So, here's a new >>>> webrev that uses the incoming type state for all of the astore*, >>>> dstore*, fstore*, istore*, and lstore* bytecodes. The webrev also >>>> contains a new test for the istore bytecode case, called >>>> BadMapIstore.jasm. >>>> >>>> Could you please review this webrev, when you have a chance? >>>> >>>> New open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066.2/ >>> >>> This seems more inline with the "astore and friends" comment in the >>> bug report. Do we need to add test cases for all the *store variants? >>> >>> Thanks, >>> David >>> >>>> Thanks! Harold >>>> >>>> On 3/19/2015 3:33 PM, Karen Kinnear wrote: >>>>> Harold, >>>>> >>>>> I get it - this only affects instructions that set the type of a >>>>> local >>>>> slot since the operand stack is cleared. >>>>> >>>>> So - what about istore? >>>>> If we have a local slot that contains a long or double, Frederic >>>>> reminded me that JVMS 2.6.1 does allow stores to those separate >>>>> slots, >>>>> e.g. an istore. My mental model of this is that it would change the >>>>> type of the local slot. >>>>> >>>>> Would that mean we would want to check any of the *store bytecodes? >>>>> >>>>> (I know the spec would change for all bytecodes which might be >>>>> cleaner >>>>> - I suspect you are being extra cautious about making changes >>>>> to reduce risk of breaking something in the field). >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Mar 18, 2015, at 2:18 PM, harold seigel wrote: >>>>> >>>>>> Hi Karen, >>>>>> >>>>>> The fix does not affect normal verifier type-state (stack map) >>>>>> checking that is done when looping through the bytecodes. It only >>>>>> affects whether the incoming or outgoing type-state is used when >>>>>> comparing the type-state at a particular bytecode with the >>>>>> type-state >>>>>> at the start of its potential exception handlers. >>>>>> >>>>>> In addition, (to paraphrase Keith's comment in the bug), it only >>>>>> affects instructions that set the type of a local slot (astore and >>>>>> friends) ... . Instructions that affect the expression stack are >>>>>> not >>>>>> a problem since the type-state's stack is cleared when type checking >>>>>> an exception handler. >>>>>> >>>>>> So, other bytecodes such as aload and friends, getstatic and >>>>>> getfield, etc. are not an issue. >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 3/16/2015 3:49 PM, Karen Kinnear wrote: >>>>>>> Harold, >>>>>>> >>>>>>> Thanks for helping me walk through this in more detail. >>>>>>> >>>>>>> The way I read this, the fix would apply to all bytecodes - except >>>>>>> for >>>>>>> invokespecial - which is handled I believe correctly inside >>>>>>> the >>>>>>> verify_invoke_init. >>>>>>> >>>>>>> So if you could possibly experiment with some additional >>>>>>> instructions - I suspect >>>>>>> you can make a conditional check where you put the beginning check >>>>>>> and remove >>>>>>> the check at the end. >>>>>>> >>>>>>> thanks, >>>>>>> Karen >>>>>>> >>>>>>> On Mar 15, 2015, at 8:58 PM, David Holmes wrote: >>>>>>> >>>>>>>> Hi Harold, >>>>>>>> On 14/03/2015 4:06 AM, harold seigel wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this fix for bug JDK-7127066. The fix applies to >>>>>>>>> astore* >>>>>>>>> bytecodes because, when inside an exception handler, they can >>>>>>>>> reference >>>>>>>>> the thrown object and modify the number of stack locals, >>>>>>>>> enabling the >>>>>>>>> incorrect stack match. >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://oklahoma.us.oracle.com/~hseigel/webrev/bug_7127066/ >>>>>>>>> >>>>>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-7127066 >>>>>>>>> >>>>>>>>> The fix was tested with JCK api, lang, and vm tests, jtreg >>>>>>>>> hotspot, >>>>>>>>> java/lang, java/io, and java/util tests, and testbase quick and >>>>>>>>> split >>>>>>>>> verifier tests, and with the test case provided in the bug. >>>>>>>> The new check looks okay, though I can't verify the exact >>>>>>>> placement >>>>>>>> of it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks! Harold >>>> >> From thomas.stuefe at gmail.com Wed Mar 25 16:20:03 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 25 Mar 2015 17:20:03 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> <5c66c663-9106-427e-830a-2585f45ab906@default> Message-ID: ping... I still need a sponsor and another reviewer for this issue. Thank you! Thomas On Wed, Mar 18, 2015 at 11:13 AM, Thomas St?fe wrote: > Hi Markus, > > the way to do this cleanly would be to use Vectored Exceptions, which > would give us the same control flow as on Unix signal. However, Vectored > Exception handling was explicitly removed from the hotspot ages ago. > I guess because too many third party libraries install their own VE > handlers. > > To all: I still need one more reviewer and a sponsor. Thanks! > > Thomas > > > On Tue, Mar 17, 2015 at 9:40 AM, Markus Gronlund < > markus.gronlund at oracle.com> wrote: > > > > I don?t think it is worth it. But thanks for thinking about it. > > > > > > > > I was thinking if we could maybe do some callback trickery to set up the > SEH in Windows specific code only inside Threads::create_vm() ? but again, > probably not worth it. > > > > > > > > I am ok with the suggestion as it stands. > > > > > > > > /Markus > > > > > > > > > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > > Sent: den 17 mars 2015 09:34 > > To: Markus Gronlund > > Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes > > > > > > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing > around CreateJavaVM on Windows > > > > > > > > Hi Markus, David, > > > > > > > > thanks for reviewing this! > > > > > > > > yes, I also do not like the #ifdefs _WIN32. > > > > > > > > We could pretty it up a bit with macros: > > > > > > > > #define GUARD_SEH_START __try { > > > > #define GUARD_SEH_END } __except... > > > > > > > > and defining those empty on non-windows platforms? > > > > > > > > What do you think? > > > > > > > > Kind Regards, Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund < > markus.gronlund at oracle.com> wrote: > > > > Hi Thomas, > > > > This looks good, thank you for fixing this! > > > > I didn't know that the entire Threads::create_vm() routine is currently > unguarded - interesting. > > > > Small point: I agree with David about the annoyance of having platform > specific #ifdefs in the shared code, but I can't find any other position > where we could solve this better (we still need to reach through to the > ExceptionFilter). > > > > Let me know when you start to dig into the SEH (or lack of) for > attaching threads :-) > > > > Thanks again > > Markus > > > > > > -----Original Message----- > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > > Sent: den 16 mars 2015 12:32 > > To: David Holmes > > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing > around CreateJavaVM on Windows > > > > Hi, > > > > I still need one or two reviewers and a sponsor. > > > > Thank you! > > > > Thomas > > > > On Thu, Mar 12, 2015 at 10:41 AM, David Holmes > > wrote: > > > > > Hi Thomas, > > > > > > Thanks for the added info. I have no further comments. Hopefully > > > someone with SEH knowledge will also respond. > > > > > > David > > > > > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: > > > > > >> Hi David, > > >> > > >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes > > >> > wrote: > > >> > > >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: > > >> > > >> Hi David, > > >> > > >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes > > >> > > >> > >> > > >> >> wrote: > > >> > > >> Hi Thomas, > > >> > > >> I'm not really familiar with Windows SEH. Won't this > break > > >> custom > > >> launchers that already provide their own try/catch around > > >> Crate_JavaVM ? > > >> > > >> > > >> No. Windows SEH works stack based: any exception - e.g. a > crash - > > >> between __try and __except will be handled by the handler > given > > >> in the > > >> __except clause. Because they are stack based, they can be > > >> nested. If an > > >> exception is raised inside the inner __try/__except, first > > >> the inner > > >> handler is used, if that one feels not responsible, the next > > >> outer one > > >> and so on. > > >> > > >> With my fix, any exception raised inside CreateJavaVM will be > > >> handler by > > >> our handler topLevelExceptionFilter; only if our handler > feels not > > >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user > > >> handler will > > >> be called. > > >> > > >> > > >> My lack of knowledge about when our handler "feels responsible" > > >> still leaves me a little nervous here. :) > > >> > > >> > > >> I think the patch is quite safe. I added this patch to our code base > > >> in > > >> 2011 and since then this is active in productive code for SAP > customers. > > >> The SAP jvm gets heavily used with custom launchers which do their > > >> own error handling, so this is a well tested scenario. > > >> > > >> I would like to get a similar signal handling coverage as on UNIX: > > >> > > >> On Unix, we have global signal handling. The moment signal handling > > >> is established early in os::init(), every signal from everywhere is > > >> covered, even user code. We even have to take care that user handlers > > >> get also in the loop via signal chaining, libjsig.so etc. > > >> > > >> On Windows, it is the other way around: we have stack based signal > > >> handling , so we need __try/__except on every thread, and this means > > >> there are parts of jvm code which run without signal handling: > > >> - the whole initialization > > >> - attached threads (I think?) > > >> which means that on those cases, user handler gets signals which the > > >> libjvm should handle. > > >> > > >> This was "fixed" partly by surrounding small code which we know > > >> beforehand causes signals - how convenient - with __try/__except. For > > >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a > > >> crash. But you want error handling to always work. I also do not know > > >> if stuff like polling pages, implicit nulltests etc could be used in > > >> unprotected code. > > >> > > >> As a side note, there is a UNIX-like signal handling mode on Windows > > >> too, "vectored exception handling", which was used in the jvm but > > >> removed some time ago for reasons I do not really know. > > >> > > >> Any exception raised in the launcher itself outside of > > >> CreateJavaVM will > > >> still be handled by the user handler. > > >> > > >> (And I hate seeing the win32 ifdefs in the shared code > :( ). > > >> > > >> > > >> Yes I know, I kind of expected that feedback :( - I did not > find a > > >> better way of doing this. One could try to hide the > __try/__except > > >> behind macros, but that would be kind of unwieldy and I don't > like > > >> abstractiing something which only has meaning on one platform. > > >> > > >> > > >> Does it help if we make the caller responsible for SEH and then > put > > >> the try/catch in the launcher code (hopefully in a windows > specific > > >> part thereof) ? > > >> > > >> > > >> No, because the caller would need access to "topLevelExceptionFilter" > > >> - you would need to export that function from the libjvm and then > > >> tell the caller "always call topLevelExceptionFilter() if a signal > > >> happens on Windows", which is quite awkward and different than on > UNIX. > > >> > > >> Thomas > > >> > > >> Thanks, > > >> David > > >> > > >> > > >> Thanks, > > >> David > > >> > > >> > > >> > > >> Kind regards, Thomas > > >> > > >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: > > >> > > >> Hi all, > > >> > > >> please review this smallish change: > > >> > > >> webrev: > > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ > > >> webrev.____01/webrev/ > > >> > >> webrev.__01/webrev/> > > >> > > >> > >> webrev.__01/webrev/ > > >> > >> 01/webrev/>> > > >> bug: > > >> https://bugs.openjdk.java.net/____browse/JDK-8074860 > > >> > > >> > > >> > >> > > >> > > > >> > > >> This change adds SEH guards around > JNI_CreateJavaVM(). > > >> Without > > >> the change, > > >> on Windows, the VM initialization runs without crash > > >> protection: > > >> crashes > > >> will terminate VM immediately without writing an > > >> error log; > > >> also, any > > >> techniques relying on signals will not work, e.g. > > >> SafeFetch(). > > >> > > >> This was partly solved before on a case-by-case base > by > > >> wrapping > > >> code > > >> sections which may crash in their own __try/__except > > >> wrappers - > > >> e.g. CPU > > >> feature probing. > > >> > > >> The change guards the whole of JNI_CreateJavaVM > > >> invocation in > > >> __try/__except. Unfortunately, for that to compile, I > > >> needed to > > >> introduce a > > >> wrapper around JNI_CreateJavaVM and move the whole of > > >> JNI_CreateJavaVM to a > > >> new function "JNI_CreateJavaVM_inner". > > >> > > >> This fix also gets rid of various workarounds which > > >> were used > > >> before to > > >> guard code sections. > > >> > > >> Thanks for reviewing! > > >> > > >> Oh, on a side note: I tried to figure out if threads > > >> which are > > >> attached > > >> from the outside via JNI AttachCurrentThread() are in > > >> any way > > >> guarded with > > >> SEH protection. Newly created threads are guarded > > >> because they > > >> run thru > > >> java_start() in os_windows.cpp, which adds SEH guards > > >> to all > > >> frames below. > > >> But for attached threads, I did not find any SEH > guards > > >> - or > > >> maybe I am > > >> blind? What does that mean for java code running > inside > > >> attached > > >> threads? > > >> > > >> Regards, > > >> > > >> Thomas Stuefe > > >> > > >> > > >> > > >> > > > > > From ioi.lam at oracle.com Wed Mar 25 16:38:48 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 25 Mar 2015 09:38:48 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <550C88C3.7030008@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> Message-ID: <5512E498.3060204@oracle.com> Hi Yumin, The changes look good. Just a few nits: *src/share/vm/interpreter/bytecodes.hpp:** * 293 // Rewritten at CDS dump time to | Original bytecode 294 // _invoke_virtual rewritten on sparc, will be disabled if UseSharedSpaces turned on. 295 // ------------------------------+------------------ 296 _nofast_getfield , // <- _getfield 297 _nofast_putfield , // <- _putfield 298 _nofast_aload_0 , // <- _aload_0 299 _nofast_iload , // <- _iload I think it should be reformatted to line up the columns: 293 // Rewritten at CDS dump time to | Original bytecode 295 // ------------------------------+------------------ 296 _nofast_getfield , // <- _getfield 297 _nofast_putfield , // <- _putfield 298 _nofast_aload_0 , // <- _aload_0 299 _nofast_iload , // <- _iload 230 // NOTE: _invoke_virtual is rewritten only on sparc. This will be disabled if // UseSharedSpaces turned on. *src/share/vm/interpreter/rewriter.cpp:* There are many places that modify the Method object. Instead of putting asserts at all the places where an actual modification happens, I think it's better to use only one assert at the Rewriter entry point, and remove the other assets that you added: 516 void Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { + if (!DumpSharedSpaces) { + assert(!MetaspaceShared::is_in_shared_space(klass()), "archive methods must not be rewritten at run time"); + } 517 ResourceMark rm(THREAD); 518 Rewriter rw(klass, klass->constants(), klass->methods(), CHECK); 519 // (That's all, folks.) 520 } Also, I am not sure if the PPC directories in the repo have been 'locked' or not, but I guess you will find out when you do the push. I am not a Reviewer, so probably Coleen needs to look at this as well. Thanks - Ioi On 3/20/15, 1:53 PM, Yumin Qi wrote: > Hi, Coleen and all > > New version with suggested changes can be reviewed at: > http://cr.openjdk.java.net/~minqi/8074345/webrev02/ > > Removed _fast_invokeinvirtual from last version, disable rewriting > _invokevirtual if UseSharedSpaces turned on. Only on sparc > _invokevirtual got rewritten. Other platforms as unimplemented. > > Thanks > Yumin > > On 3/11/2015 1:23 PM, Yumin Qi wrote: >> Thanks, I will have another webrev after build/test/perf test. >> >> Yumin >> >> On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >>> >>> Hi Yumin, One comment embedded. >>> >>> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>>> Hi, Coleen >>>> >>>> Thanks for the review. See embedded. >>>> >>>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>>> >>>>> Yumin, >>>>> >>>>> The new bytecode approach came out pretty cleanly, or as cleanly >>>>> as this could be. >>>>> >>>>> The file templateTable_x86_32 and 64 have just been merged, so >>>>> you'll have to make your change in the new version. >>>>> >>>>> I also have some comments: >>>>> >>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>>>> >>>>> >>>>> Typo "rewirting" >>>>> >>>> Sure. >>>>> In these files, can you break up the long lines into three lines? >>>>> >>>>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, >>>>> Rbc, Rscratch); } >>>>> + if (!is_static && rc == MAY_REWRITE) { >>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>> >>>> Sure. >>>>> >>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>>>> >>>>> >>>>> How many bytecodes do we have now? We're limited to 255 (or 256) >>>>> and there are other new bytecodes being added. >>>>> >>>> now total is 234 (after the fix). See below answer. >>>>> What was the performance benefit to this? I think if we wanted >>>>> to be conservative, we'd turn off RewriteFrequentPairs and only do >>>>> nofast_getfield and nofast_putfield. I think they were the only >>>>> bytecodes that actually affected performance. >>>>> >>>>> In this file above, can you remove the last block of comments >>>>> about fast_linearswitch and fast_ldc? I think this confuses >>>>> rewriting in the interpreter and rewriting in the rewriter, or >>>>> rather makes the confusion worse. I don't think this comment is >>>>> helpful. >>>>> >>>>> I'd prefer to see the first comment smaller also, like: >>>>> >>>>> + // These bytecodes are rewritten at CDS dump time, so that we >>>>> can prevent them from being >>>>> + // rewritten at run time. This way, the ConstMethods can be >>>>> placed in the CDS ReadOnly >>>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>>> rewrite non-CDS bytecodes >>>>> + // at run time. >>>>> + _nofast_getfield , >>>>> + _nofast_putfield , >>>>> + _nofast_aload_0 , >>>>> + _nofast_iload , >>>>> + _nofast_invokevirtual , >>>>> >>>>> It's sort of obvious which bytecode they rewrite. I don't know >>>>> how much performance fast_invokevfinal is worth. I thought I >>>>> deleted it. Can we not rewrite this so we don't waste another >>>>> bytecode on it? Maybe add a RewriteVFinal option and consider >>>>> removing it for the future? x86 doesn't use it and I can't see >>>>> how this would save any significant performance to be worth having! >>>>> >>>> _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, >>>> no need to take care for it. For sparc, it does patch code. I am >>>> thinking of a way if we need to add _nofast_code as you indicated, >>>> we only have 255 codes to use. >>> >>> PPC isn't removed from the open repository. >>>> >>>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>>> RewriteFrequentPair; >>> >>> I think the conditional would be >>> >>> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>>> >>>> Can this boolean decide if we not rewrite the bytecode to fast? >>>> If so, I can remove all the _nofast_code and do not patch code when >>>> it is on. >>> >>> Yes, this would be nice to not add the bytecode. >>> >>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>>>> >>>>> >>>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>>> control for fast code under CDS >>>>> >>>>> >>>>> I don't know what our coding standard is but in the >>>>> templateTable_.cpp files these strings look like macros. I'd >>>>> rather see them as MayRewrite or MayNotRewrite. >>>>> >>>> Agree. >>>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>>>> >>>>> >>>>> I think there's a java_code() function that returns the original >>>>> bytecode that you could use instead of the case statement in >>>>> resolve_cache_and_index(). The indentation is odd in the webrev. >>>>> This probably applies to the other cpu directories. >>>>> >>>>> One last question below: >>>>> >>>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>>> Please review: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>>> >>>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS >>>>>> are mapped read only. So memory fault will be triggered when >>>>>> RewriteBytecodes turned on. This also disable all method >>>>>> rewritten, leads interpreter run slower. Observed about 2% >>>>>> regression with C2 on some benchmarks, since interpreter speed is >>>>>> important to C2. By enable RewriteBytecodes and >>>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for >>>>>> corresponding fast codes at dump time to avoid byte code >>>>>> rewritten at run time, we prevent byte code rewritten and modify >>>>>> the read only shared portion in CDS. Meanwhile other byte codes >>>>>> with fast codes still get speed up. >>>>>> >>>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported >>>>>> platforms. Interpreter only tests showed about 3% improvement. >>>>> >>>>> What performance did you measure? Is it -Xint -Xshare:on with and >>>>> without your patch? It was only 3% better? >>>>> >>>>> What was the difference in performance with -Xint >>>>> -XX:-RewriteBytecodes vs. -Xint >>>>> -XX:+RewriteBytecodes/FrequentPairs? I thought this was around 15%. >>>>> >>>> I will send you a separate email of the links which run with >>>> CDS/NoCDS/CDS+Int >>> >>> Thanks for the links. From your experiments, I think your >>> performance improvement with your patch and CDS with -Xmixed is 4%. >>> That's good enough for a couple of bytecodes. >>> >>> Coleen >>> >>>> >>>> Thanks >>>> Yumin >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>> >>>> >>> >> > From yumin.qi at oracle.com Wed Mar 25 16:55:09 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 25 Mar 2015 09:55:09 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <5512E498.3060204@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> Message-ID: <5512E86D.1000408@oracle.com> Thanks On 3/25/2015 9:38 AM, Ioi Lam wrote: > Hi Yumin, > > The changes look good. Just a few nits: > > *src/share/vm/interpreter/bytecodes.hpp:** > * > 293 // Rewritten at CDS dump time to | Original bytecode > 294 // _invoke_virtual rewritten on sparc, will be disabled if > UseSharedSpaces turned on. > 295 // ------------------------------+------------------ > 296 _nofast_getfield , // <- _getfield > 297 _nofast_putfield , // <- _putfield > 298 _nofast_aload_0 , // <- _aload_0 > 299 _nofast_iload , // <- _iload > > I think it should be reformatted to line up the columns: > > 293 // Rewritten at CDS dump time to | Original bytecode > 295 // ------------------------------+------------------ > 296 _nofast_getfield , // <- _getfield > 297 _nofast_putfield , // <- _putfield > 298 _nofast_aload_0 , // <- _aload_0 > 299 _nofast_iload , // <- _iload > 230 // NOTE: _invoke_virtual is rewritten only on sparc. This will > be disabled if > // UseSharedSpaces turned on. > Sure. > *src/share/vm/interpreter/rewriter.cpp:* > > There are many places that modify the Method object. Instead of > putting asserts at all the places where an actual modification > happens, I think it's better to use only one assert at the Rewriter > entry point, and remove the other assets that you added: > > 516 void Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { > + if (!DumpSharedSpaces) { > + assert(!MetaspaceShared::is_in_shared_space(klass()), "archive > methods must not be rewritten at run time"); > + } > 517 ResourceMark rm(THREAD); > 518 Rewriter rw(klass, klass->constants(), klass->methods(), > CHECK); > 519 // (That's all, folks.) > 520 } > Sure. > Also, I am not sure if the PPC directories in the repo have been > 'locked' or not, but I guess you will find out when you do the push. > I will get rid of the ppc change in next webrev. Yumin > I am not a Reviewer, so probably Coleen needs to look at this as well. > > Thanks > - Ioi > > On 3/20/15, 1:53 PM, Yumin Qi wrote: >> Hi, Coleen and all >> >> New version with suggested changes can be reviewed at: >> http://cr.openjdk.java.net/~minqi/8074345/webrev02/ >> >> Removed _fast_invokeinvirtual from last version, disable rewriting >> _invokevirtual if UseSharedSpaces turned on. Only on sparc >> _invokevirtual got rewritten. Other platforms as unimplemented. >> >> Thanks >> Yumin >> >> On 3/11/2015 1:23 PM, Yumin Qi wrote: >>> Thanks, I will have another webrev after build/test/perf test. >>> >>> Yumin >>> >>> On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >>>> >>>> Hi Yumin, One comment embedded. >>>> >>>> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>>>> Hi, Coleen >>>>> >>>>> Thanks for the review. See embedded. >>>>> >>>>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Yumin, >>>>>> >>>>>> The new bytecode approach came out pretty cleanly, or as cleanly >>>>>> as this could be. >>>>>> >>>>>> The file templateTable_x86_32 and 64 have just been merged, so >>>>>> you'll have to make your change in the new version. >>>>>> >>>>>> I also have some comments: >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>>>>> >>>>>> >>>>>> Typo "rewirting" >>>>>> >>>>> Sure. >>>>>> In these files, can you break up the long lines into three lines? >>>>>> >>>>>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, >>>>>> Rbc, Rscratch); } >>>>>> + if (!is_static && rc == MAY_REWRITE) { >>>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>>> >>>>> Sure. >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>>>>> >>>>>> >>>>>> How many bytecodes do we have now? We're limited to 255 (or 256) >>>>>> and there are other new bytecodes being added. >>>>>> >>>>> now total is 234 (after the fix). See below answer. >>>>>> What was the performance benefit to this? I think if we wanted >>>>>> to be conservative, we'd turn off RewriteFrequentPairs and only >>>>>> do nofast_getfield and nofast_putfield. I think they were the >>>>>> only bytecodes that actually affected performance. >>>>>> >>>>>> In this file above, can you remove the last block of comments >>>>>> about fast_linearswitch and fast_ldc? I think this confuses >>>>>> rewriting in the interpreter and rewriting in the rewriter, or >>>>>> rather makes the confusion worse. I don't think this comment is >>>>>> helpful. >>>>>> >>>>>> I'd prefer to see the first comment smaller also, like: >>>>>> >>>>>> + // These bytecodes are rewritten at CDS dump time, so that >>>>>> we can prevent them from being >>>>>> + // rewritten at run time. This way, the ConstMethods can be >>>>>> placed in the CDS ReadOnly >>>>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>>>> rewrite non-CDS bytecodes >>>>>> + // at run time. >>>>>> + _nofast_getfield , >>>>>> + _nofast_putfield , >>>>>> + _nofast_aload_0 , >>>>>> + _nofast_iload , >>>>>> + _nofast_invokevirtual , >>>>>> >>>>>> It's sort of obvious which bytecode they rewrite. I don't know >>>>>> how much performance fast_invokevfinal is worth. I thought I >>>>>> deleted it. Can we not rewrite this so we don't waste another >>>>>> bytecode on it? Maybe add a RewriteVFinal option and consider >>>>>> removing it for the future? x86 doesn't use it and I can't see >>>>>> how this would save any significant performance to be worth having! >>>>>> >>>>> _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, >>>>> no need to take care for it. For sparc, it does patch code. I am >>>>> thinking of a way if we need to add _nofast_code as you indicated, >>>>> we only have 255 codes to use. >>>> >>>> PPC isn't removed from the open repository. >>>>> >>>>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>>>> RewriteFrequentPair; >>>> >>>> I think the conditional would be >>>> >>>> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>>>> >>>>> Can this boolean decide if we not rewrite the bytecode to fast? >>>>> If so, I can remove all the _nofast_code and do not patch code >>>>> when it is on. >>>> >>>> Yes, this would be nice to not add the bytecode. >>>> >>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>>>>> >>>>>> >>>>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>>>> control for fast code under CDS >>>>>> >>>>>> >>>>>> I don't know what our coding standard is but in the >>>>>> templateTable_.cpp files these strings look like macros. I'd >>>>>> rather see them as MayRewrite or MayNotRewrite. >>>>>> >>>>> Agree. >>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>>>>> >>>>>> >>>>>> I think there's a java_code() function that returns the original >>>>>> bytecode that you could use instead of the case statement in >>>>>> resolve_cache_and_index(). The indentation is odd in the >>>>>> webrev. This probably applies to the other cpu directories. >>>>>> >>>>>> One last question below: >>>>>> >>>>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>>>> Please review: >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>>>> >>>>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS >>>>>>> are mapped read only. So memory fault will be triggered when >>>>>>> RewriteBytecodes turned on. This also disable all method >>>>>>> rewritten, leads interpreter run slower. Observed about 2% >>>>>>> regression with C2 on some benchmarks, since interpreter speed >>>>>>> is important to C2. By enable RewriteBytecodes and >>>>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for >>>>>>> corresponding fast codes at dump time to avoid byte code >>>>>>> rewritten at run time, we prevent byte code rewritten and modify >>>>>>> the read only shared portion in CDS. Meanwhile other byte codes >>>>>>> with fast codes still get speed up. >>>>>>> >>>>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all >>>>>>> supported platforms. Interpreter only tests showed about 3% >>>>>>> improvement. >>>>>> >>>>>> What performance did you measure? Is it -Xint -Xshare:on with >>>>>> and without your patch? It was only 3% better? >>>>>> >>>>>> What was the difference in performance with -Xint >>>>>> -XX:-RewriteBytecodes vs. -Xint >>>>>> -XX:+RewriteBytecodes/FrequentPairs? I thought this was around 15%. >>>>>> >>>>> I will send you a separate email of the links which run with >>>>> CDS/NoCDS/CDS+Int >>>> >>>> Thanks for the links. From your experiments, I think your >>>> performance improvement with your patch and CDS with -Xmixed is 4%. >>>> That's good enough for a couple of bytecodes. >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks >>>>> Yumin >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>> >>>>> >>>> >>> >> > From yumin.qi at oracle.com Wed Mar 25 18:11:13 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 25 Mar 2015 11:11:13 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <55106018.3020005@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> <55106018.3020005@oracle.com> Message-ID: <5512FA41.3020008@oracle.com> Hi, all I updated the webrev with a new change to test case: test/runtime/Unsafe/RangeCheck.java Add -XX:-CreateCoredumpOnCrash to test, no dump needed on this case. new webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev05/ Thanks Yumin On 3/23/2015 11:48 AM, Yumin Qi wrote: > Since Thomas is not a reviewer in open jdk, I need two volunteers (at > least one "R"eviewer). > > Dan, since you already reviewed previous version, could you have a look? > > Thanks > Yumin > > On 3/20/2015 3:20 PM, Yumin Qi wrote: >> Thomas, >> >> Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add >> another test case change: test/runtime/memory/ReadFromNoaccessArea.java >> (Thanks Dan's update) >> >> Thanks >> Yumin >> >> On 3/20/2015 11:55 AM, Thomas St?fe wrote: >>> >>> Hi Yumin, >>> >>> I think you meant to post webrev.04? >>> >>> I looked at 04, and it looks nice. Thank you! >>> >>> (still only reviewer with r) >>> >>> Thomas >>> >>> On Mar 20, 2015 6:20 PM, "Yumin Qi" >> > wrote: >>> >>> Hi, All >>> >>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>> >>> >>> This version is based on Thomas' suggestion. >>> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >>> >>> Thanks >>> Yumin >>> >>> On 3/18/2015 10:06 AM, Yumin Qi wrote: >>> >>> >>> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >>> >>> Hi Yumin, >>> >>> - just aesthetics, but on all implementations of >>> os_abort(), at least on the UNIX variants, maybe we could >>> consistently rename the parameters to be "siginfo" and >>> "context" instead of using Windows terms? >>> >>> Sure. >>> >>> - On check_create_dump_limit(), you do not need >>> exceptionRecord, contextRecord parameters anymore. The >>> only parameters now needed are buffer and buffer size, >>> which is not even an output parameter, just a scratch >>> buffer for this function to use for printf. For output, it >>> calls VMError::report_coredump_status(...) at the end to >>> provide information about the core file. >>> >>> - I would rename that function from >>> check_create_dump_limit() to check_dump_limit() - nothing >>> is created anymore. >>> >>> Yes, no need to carry those two parameters. I tried to keep >>> less changes, but decided to change now. >>> >>> - on Windows, in os::abort(), there is no point anymore in >>> calling VMError::report_coredump_status(...) because that >>> information is only used during error log writing which >>> already happened. It only makes sense to call this >>> function in check_create_dump_limit(), which happens >>> before error log writing. >>> Instead, maybe error messages like "Call to >>> MiniDumpWriteDump() failed" should just be written to >>> stderr? This would be consistent with Unix, where the OS >>> writes a short message on stderr if core file writing >>> fails. >>> >>> Sure, will direct output to stderr. >>> >>> - there is now a new test, >>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>> - could you please also add "-XX:-CreateCoredumpOnCrash" ? >>> I just added the test and did not want to add the option >>> before it was available. >>> >>> OK >>> >>> Thanks >>> Yumin >>> >>> Thanks for your work! >>> >>> Thomas >>> >>> >>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >>> >>> >> >>> wrote: >>> >>> Hi, Dan and all >>> >>> I have updated webrev at: >>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>> >>> >>> >>> 1) bug changed synopsis >>> 8074354: Make CreateMinidumpOnCrash a new >>> name and >>> available on all platforms >>> 2) tests: JPRT, vm.runtime.quick.testlist (on >>> Windows), jtreg on >>> Windows and Linux/Unix. >>> >>> Thanks >>> Yumin >>> >>> >>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>> >>> I believe there are both JavaTest/JTREG tests in >>> the hotspot repo >>> and there are VM/NSK tests from back when we did >>> phone home... >>> >>> Check with Christian or Misha... >>> >>> Dan >>> >>> >>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>> >>> Thanks, Dan >>> >>> Will look at and run those tests. Are they >>> under nsk? >>> >>> Yumin >>> >>> On 3/12/2015 12:29 PM, Daniel D. Daugherty >>> wrote: >>> >>> Yumin, >>> >>> There are some error handler tests. You >>> should find >>> those and make >>> sure that you run them on Windows since >>> you're >>> changing the order >>> there... >>> >>> Dan >>> >>> >>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>> >>> Hi, Thomas and all >>> >>> The second version of the change: >>> webrev: >>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>> >>> >>> >>> In this version: >>> 1) switch order on Windows to first >>> print log >>> file as other platform, then dump core >>> file if >>> needed. When VMError created after >>> crash, siginfo >>> and context which are >>> ExceptionRecord and >>> ContextRecord on Windows are recorded, >>> mini (or >>> full, due to 'or' used so type will be >>> mini >>> anyway) dump creates dump file based >>> on those two >>> as before. >>> 2) to make os::abort to get above >>> two pointers, >>> added two more fields to the function >>> parameters: >>> 3) changes for >>> test/runtime/ErrorHandling/SecondaryError.java --- >>> added "-XX:-CreateCoredumpOnCrash" >>> >>> - static void abort(bool >>> dump_core = true); >>> + static void abort(bool dump_core >>> = true, >>> void *siginfo = NULL, void *context = >>> NULL); >>> >>> Tests: JPRT and manually. >>> >>> Thanks >>> Yumin >>> >>> On 3/11/2015 3:47 AM, Thomas St?fe >>> wrote: >>> >>> Hi Yumin, >>> >>> There is also >>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>> - could you please add >>> "-XX:-CreateCoredumpOnCrash" ? >>> Thank you! >>> >>> Beyond that, as I wrote in the bug >>> report >>> comments: >>> >>> "This is also a problem on >>> Windows - >>> MiniDumpWriteDump() may hang >>> infinitly. And on >>> Windows this is worse than under >>> UNIX because >>> we create the Dump before writing >>> the hs-err >>> file, so if the Dump hangs, we get >>> no error >>> log. I would like to revert the >>> order: create >>> the minidump after writing the >>> error log, the >>> same way Unix does it. We did this >>> in our JVM >>> (SAP) because for us, error logs >>> are more >>> useful than minidumps. " >>> >>> So, I would like to see os::abort >>> on Windows >>> call MiniDumpWriteDump(), and thus >>> the mini >>> dump writing moved after the >>> error log >>> writing. This would also make the >>> code way >>> cleaner because the control flow >>> would be the >>> same on all platforms. >>> >>> I understand that this may be out >>> of scope for >>> your change, but I would like to >>> know what >>> others think about this. >>> >>> Kind regards, Thomas >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Mar 11, 2015 at 8:02 AM, >>> Yumin Qi >>> >> >>> >> > >>> >> >>> >> >>> wrote: >>> >>> Please review: >>> >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>> webrev: >>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>> >>> >>> >>> >>> Summary: Tests timed out when >>> VM crashes >>> and dumping core file >>> which in the test case is not >>> needed. To >>> make core not created, >>> the fix changed >>> CreateMinidumpOnCrash to >>> CreateCoredumpOnCrash, >>> the former is only used on >>> Windows and the >>> latter for all >>> platforms. When VM crashes on >>> non Windows, >>> core file generated as >>> default if OS sets core dump >>> allowed. >>> Default value of >>> CreateCoredumpOnCrash set to >>> 'true' to >>> keep same behavior on non >>> Windows platforms, but changed >>> for Windows >>> --- original is false, >>> not create minidump on >>> Windows. With >>> CreateCoredumpOnCrash turned >>> off, no core file will be >>> generated. >>> CreateMinidumpOnCrash still >>> can be used on commandline but >>> only as >>> alias for the new flag. >>> >>> Tests: JPRT, manual tests >>> setting >>> CreateMinidumpOnCrash on >>> commandline to verify flag >>> change as alias. >>> >>> Thanks >>> Yumin >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > From yumin.qi at oracle.com Wed Mar 25 21:24:51 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 25 Mar 2015 14:24:51 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <5512E91E.9010008@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> Message-ID: <551327A3.7050007@oracle.com> Hi, Coleen New version based on Ioi's suggestion is located at: http://cr.openjdk.java.net/~minqi/8074345/webrev03/ Test: JPRT. Manual test on -Xshare:[dump | on ] Thanks Yumin On 3/25/2015 9:58 AM, Coleen Phillimore wrote: > > Yes, this was on my to-do list, sorry I haven't gotten to it yet. > Coleen > > On 3/25/15, 12:38 PM, Ioi Lam wrote: >> Hi Yumin, >> >> The changes look good. Just a few nits: >> >> *src/share/vm/interpreter/bytecodes.hpp:** >> * >> 293 // Rewritten at CDS dump time to | Original bytecode >> 294 // _invoke_virtual rewritten on sparc, will be disabled if >> UseSharedSpaces turned on. >> 295 // ------------------------------+------------------ >> 296 _nofast_getfield , // <- _getfield >> 297 _nofast_putfield , // <- _putfield >> 298 _nofast_aload_0 , // <- _aload_0 >> 299 _nofast_iload , // <- _iload >> >> I think it should be reformatted to line up the columns: >> >> 293 // Rewritten at CDS dump time to | Original bytecode >> 295 // ------------------------------+------------------ >> 296 _nofast_getfield , // <- _getfield >> 297 _nofast_putfield , // <- _putfield >> 298 _nofast_aload_0 , // <- _aload_0 >> 299 _nofast_iload , // <- _iload >> 230 // NOTE: _invoke_virtual is rewritten only on sparc. This >> will be disabled if >> // UseSharedSpaces turned on. >> >> *src/share/vm/interpreter/rewriter.cpp:* >> >> There are many places that modify the Method object. Instead of >> putting asserts at all the places where an actual modification >> happens, I think it's better to use only one assert at the Rewriter >> entry point, and remove the other assets that you added: >> >> 516 void Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { >> + if (!DumpSharedSpaces) { >> + assert(!MetaspaceShared::is_in_shared_space(klass()), "archive >> methods must not be rewritten at run time"); >> + } >> 517 ResourceMark rm(THREAD); >> 518 Rewriter rw(klass, klass->constants(), klass->methods(), >> CHECK); >> 519 // (That's all, folks.) >> 520 } >> >> Also, I am not sure if the PPC directories in the repo have been >> 'locked' or not, but I guess you will find out when you do the push. >> >> I am not a Reviewer, so probably Coleen needs to look at this as well. >> >> Thanks >> - Ioi >> >> On 3/20/15, 1:53 PM, Yumin Qi wrote: >>> Hi, Coleen and all >>> >>> New version with suggested changes can be reviewed at: >>> http://cr.openjdk.java.net/~minqi/8074345/webrev02/ >>> >>> Removed _fast_invokeinvirtual from last version, disable rewriting >>> _invokevirtual if UseSharedSpaces turned on. Only on sparc >>> _invokevirtual got rewritten. Other platforms as unimplemented. >>> >>> Thanks >>> Yumin >>> >>> On 3/11/2015 1:23 PM, Yumin Qi wrote: >>>> Thanks, I will have another webrev after build/test/perf test. >>>> >>>> Yumin >>>> >>>> On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Yumin, One comment embedded. >>>>> >>>>> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>>>>> Hi, Coleen >>>>>> >>>>>> Thanks for the review. See embedded. >>>>>> >>>>>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Yumin, >>>>>>> >>>>>>> The new bytecode approach came out pretty cleanly, or as cleanly >>>>>>> as this could be. >>>>>>> >>>>>>> The file templateTable_x86_32 and 64 have just been merged, so >>>>>>> you'll have to make your change in the new version. >>>>>>> >>>>>>> I also have some comments: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> Typo "rewirting" >>>>>>> >>>>>> Sure. >>>>>>> In these files, can you break up the long lines into three lines? >>>>>>> >>>>>>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, >>>>>>> Rbc, Rscratch); } >>>>>>> + if (!is_static && rc == MAY_REWRITE) { >>>>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>>>> >>>>>> Sure. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> How many bytecodes do we have now? We're limited to 255 (or >>>>>>> 256) and there are other new bytecodes being added. >>>>>>> >>>>>> now total is 234 (after the fix). See below answer. >>>>>>> What was the performance benefit to this? I think if we wanted >>>>>>> to be conservative, we'd turn off RewriteFrequentPairs and only >>>>>>> do nofast_getfield and nofast_putfield. I think they were the >>>>>>> only bytecodes that actually affected performance. >>>>>>> >>>>>>> In this file above, can you remove the last block of comments >>>>>>> about fast_linearswitch and fast_ldc? I think this confuses >>>>>>> rewriting in the interpreter and rewriting in the rewriter, or >>>>>>> rather makes the confusion worse. I don't think this comment is >>>>>>> helpful. >>>>>>> >>>>>>> I'd prefer to see the first comment smaller also, like: >>>>>>> >>>>>>> + // These bytecodes are rewritten at CDS dump time, so that >>>>>>> we can prevent them from being >>>>>>> + // rewritten at run time. This way, the ConstMethods can be >>>>>>> placed in the CDS ReadOnly >>>>>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>>>>> rewrite non-CDS bytecodes >>>>>>> + // at run time. >>>>>>> + _nofast_getfield , >>>>>>> + _nofast_putfield , >>>>>>> + _nofast_aload_0 , >>>>>>> + _nofast_iload , >>>>>>> + _nofast_invokevirtual , >>>>>>> >>>>>>> It's sort of obvious which bytecode they rewrite. I don't know >>>>>>> how much performance fast_invokevfinal is worth. I thought I >>>>>>> deleted it. Can we not rewrite this so we don't waste another >>>>>>> bytecode on it? Maybe add a RewriteVFinal option and consider >>>>>>> removing it for the future? x86 doesn't use it and I can't see >>>>>>> how this would save any significant performance to be worth having! >>>>>>> >>>>>> _invokevirtual got rewritten on sparc and ppc. Now ppc is >>>>>> removed, no need to take care for it. For sparc, it does patch >>>>>> code. I am thinking of a way if we need to add _nofast_code as >>>>>> you indicated, we only have 255 codes to use. >>>>> >>>>> PPC isn't removed from the open repository. >>>>>> >>>>>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>>>>> RewriteFrequentPair; >>>>> >>>>> I think the conditional would be >>>>> >>>>> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>>>>> >>>>>> Can this boolean decide if we not rewrite the bytecode to >>>>>> fast? If so, I can remove all the _nofast_code and do not patch >>>>>> code when it is on. >>>>> >>>>> Yes, this would be nice to not add the bytecode. >>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>>>>>> >>>>>>> >>>>>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>>>>> control for fast code under CDS >>>>>>> >>>>>>> >>>>>>> I don't know what our coding standard is but in the >>>>>>> templateTable_.cpp files these strings look like macros. >>>>>>> I'd rather see them as MayRewrite or MayNotRewrite. >>>>>>> >>>>>> Agree. >>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> I think there's a java_code() function that returns the original >>>>>>> bytecode that you could use instead of the case statement in >>>>>>> resolve_cache_and_index(). The indentation is odd in the >>>>>>> webrev. This probably applies to the other cpu directories. >>>>>>> >>>>>>> One last question below: >>>>>>> >>>>>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>>>>> Please review: >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>>>>> >>>>>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>>>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS >>>>>>>> are mapped read only. So memory fault will be triggered when >>>>>>>> RewriteBytecodes turned on. This also disable all method >>>>>>>> rewritten, leads interpreter run slower. Observed about 2% >>>>>>>> regression with C2 on some benchmarks, since interpreter speed >>>>>>>> is important to C2. By enable RewriteBytecodes and >>>>>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for >>>>>>>> corresponding fast codes at dump time to avoid byte code >>>>>>>> rewritten at run time, we prevent byte code rewritten and >>>>>>>> modify the read only shared portion in CDS. Meanwhile other >>>>>>>> byte codes with fast codes still get speed up. >>>>>>>> >>>>>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all >>>>>>>> supported platforms. Interpreter only tests showed about 3% >>>>>>>> improvement. >>>>>>> >>>>>>> What performance did you measure? Is it -Xint -Xshare:on with >>>>>>> and without your patch? It was only 3% better? >>>>>>> >>>>>>> What was the difference in performance with -Xint >>>>>>> -XX:-RewriteBytecodes vs. -Xint >>>>>>> -XX:+RewriteBytecodes/FrequentPairs? I thought this was around 15%. >>>>>>> >>>>>> I will send you a separate email of the links which run with >>>>>> CDS/NoCDS/CDS+Int >>>>> >>>>> Thanks for the links. From your experiments, I think your >>>>> performance improvement with your patch and CDS with -Xmixed is >>>>> 4%. That's good enough for a couple of bytecodes. >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Mar 25 21:45:11 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 17:45:11 -0400 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <551327A3.7050007@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> <551327A3.7050007@oracle.com> Message-ID: <55132C67.3040808@oracle.com> Yumin, This looks great. You addressed my earlier pre-review comments. There are two other architectures now, that I don't believe we build and test. I think it's only cpu code that would be changed so the fixes for these architectures won't need a sponsor. Zero doesn't support CDS so I think the minimal changes you've put in bytecodeInterpreter.cpp are good. Thanks! Coleen On 3/25/15, 5:24 PM, Yumin Qi wrote: > Hi, Coleen > > New version based on Ioi's suggestion is located at: > http://cr.openjdk.java.net/~minqi/8074345/webrev03/ > > Test: JPRT. Manual test on -Xshare:[dump | on ] > > Thanks > Yumin > > On 3/25/2015 9:58 AM, Coleen Phillimore wrote: >> >> Yes, this was on my to-do list, sorry I haven't gotten to it yet. >> Coleen >> >> On 3/25/15, 12:38 PM, Ioi Lam wrote: >>> Hi Yumin, >>> >>> The changes look good. Just a few nits: >>> >>> *src/share/vm/interpreter/bytecodes.hpp:** >>> * >>> 293 // Rewritten at CDS dump time to | Original bytecode >>> 294 // _invoke_virtual rewritten on sparc, will be disabled if >>> UseSharedSpaces turned on. >>> 295 // ------------------------------+------------------ >>> 296 _nofast_getfield , // <- _getfield >>> 297 _nofast_putfield , // <- _putfield >>> 298 _nofast_aload_0 , // <- _aload_0 >>> 299 _nofast_iload , // <- _iload >>> >>> I think it should be reformatted to line up the columns: >>> >>> 293 // Rewritten at CDS dump time to | Original bytecode >>> 295 // ------------------------------+------------------ >>> 296 _nofast_getfield , // <- _getfield >>> 297 _nofast_putfield , // <- _putfield >>> 298 _nofast_aload_0 , // <- _aload_0 >>> 299 _nofast_iload , // <- _iload >>> 230 // NOTE: _invoke_virtual is rewritten only on sparc. This >>> will be disabled if >>> // UseSharedSpaces turned on. >>> >>> *src/share/vm/interpreter/rewriter.cpp:* >>> >>> There are many places that modify the Method object. Instead of >>> putting asserts at all the places where an actual modification >>> happens, I think it's better to use only one assert at the Rewriter >>> entry point, and remove the other assets that you added: >>> >>> 516 void Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { >>> + if (!DumpSharedSpaces) { >>> + assert(!MetaspaceShared::is_in_shared_space(klass()), "archive >>> methods must not be rewritten at run time"); >>> + } >>> 517 ResourceMark rm(THREAD); >>> 518 Rewriter rw(klass, klass->constants(), klass->methods(), >>> CHECK); >>> 519 // (That's all, folks.) >>> 520 } >>> >>> Also, I am not sure if the PPC directories in the repo have been >>> 'locked' or not, but I guess you will find out when you do the push. >>> >>> I am not a Reviewer, so probably Coleen needs to look at this as well. >>> >>> Thanks >>> - Ioi >>> >>> On 3/20/15, 1:53 PM, Yumin Qi wrote: >>>> Hi, Coleen and all >>>> >>>> New version with suggested changes can be reviewed at: >>>> http://cr.openjdk.java.net/~minqi/8074345/webrev02/ >>>> >>>> Removed _fast_invokeinvirtual from last version, disable >>>> rewriting _invokevirtual if UseSharedSpaces turned on. Only on >>>> sparc _invokevirtual got rewritten. Other platforms as unimplemented. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/11/2015 1:23 PM, Yumin Qi wrote: >>>>> Thanks, I will have another webrev after build/test/perf test. >>>>> >>>>> Yumin >>>>> >>>>> On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Yumin, One comment embedded. >>>>>> >>>>>> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>>>>>> Hi, Coleen >>>>>>> >>>>>>> Thanks for the review. See embedded. >>>>>>> >>>>>>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Yumin, >>>>>>>> >>>>>>>> The new bytecode approach came out pretty cleanly, or as >>>>>>>> cleanly as this could be. >>>>>>>> >>>>>>>> The file templateTable_x86_32 and 64 have just been merged, so >>>>>>>> you'll have to make your change in the new version. >>>>>>>> >>>>>>>> I also have some comments: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> Typo "rewirting" >>>>>>>> >>>>>>> Sure. >>>>>>>> In these files, can you break up the long lines into three lines? >>>>>>>> >>>>>>>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, >>>>>>>> Rbc, Rscratch); } >>>>>>>> + if (!is_static && rc == MAY_REWRITE) { >>>>>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>>>>> >>>>>>> Sure. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> How many bytecodes do we have now? We're limited to 255 (or >>>>>>>> 256) and there are other new bytecodes being added. >>>>>>>> >>>>>>> now total is 234 (after the fix). See below answer. >>>>>>>> What was the performance benefit to this? I think if we >>>>>>>> wanted to be conservative, we'd turn off RewriteFrequentPairs >>>>>>>> and only do nofast_getfield and nofast_putfield. I think they >>>>>>>> were the only bytecodes that actually affected performance. >>>>>>>> >>>>>>>> In this file above, can you remove the last block of comments >>>>>>>> about fast_linearswitch and fast_ldc? I think this confuses >>>>>>>> rewriting in the interpreter and rewriting in the rewriter, or >>>>>>>> rather makes the confusion worse. I don't think this comment >>>>>>>> is helpful. >>>>>>>> >>>>>>>> I'd prefer to see the first comment smaller also, like: >>>>>>>> >>>>>>>> + // These bytecodes are rewritten at CDS dump time, so that >>>>>>>> we can prevent them from being >>>>>>>> + // rewritten at run time. This way, the ConstMethods can >>>>>>>> be placed in the CDS ReadOnly >>>>>>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>>>>>> rewrite non-CDS bytecodes >>>>>>>> + // at run time. >>>>>>>> + _nofast_getfield , >>>>>>>> + _nofast_putfield , >>>>>>>> + _nofast_aload_0 , >>>>>>>> + _nofast_iload , >>>>>>>> + _nofast_invokevirtual , >>>>>>>> >>>>>>>> It's sort of obvious which bytecode they rewrite. I don't know >>>>>>>> how much performance fast_invokevfinal is worth. I thought I >>>>>>>> deleted it. Can we not rewrite this so we don't waste another >>>>>>>> bytecode on it? Maybe add a RewriteVFinal option and consider >>>>>>>> removing it for the future? x86 doesn't use it and I can't see >>>>>>>> how this would save any significant performance to be worth >>>>>>>> having! >>>>>>>> >>>>>>> _invokevirtual got rewritten on sparc and ppc. Now ppc is >>>>>>> removed, no need to take care for it. For sparc, it does patch >>>>>>> code. I am thinking of a way if we need to add _nofast_code as >>>>>>> you indicated, we only have 255 codes to use. >>>>>> >>>>>> PPC isn't removed from the open repository. >>>>>>> >>>>>>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>>>>>> RewriteFrequentPair; >>>>>> >>>>>> I think the conditional would be >>>>>> >>>>>> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>>>>>> >>>>>>> Can this boolean decide if we not rewrite the bytecode to >>>>>>> fast? If so, I can remove all the _nofast_code and do not patch >>>>>>> code when it is on. >>>>>> >>>>>> Yes, this would be nice to not add the bytecode. >>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>>>>>> control for fast code under CDS >>>>>>>> >>>>>>>> >>>>>>>> I don't know what our coding standard is but in the >>>>>>>> templateTable_.cpp files these strings look like macros. >>>>>>>> I'd rather see them as MayRewrite or MayNotRewrite. >>>>>>>> >>>>>>> Agree. >>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>>>>>>> >>>>>>>> >>>>>>>> I think there's a java_code() function that returns the >>>>>>>> original bytecode that you could use instead of the case >>>>>>>> statement in resolve_cache_and_index(). The indentation is odd >>>>>>>> in the webrev. This probably applies to the other cpu directories. >>>>>>>> >>>>>>>> One last question below: >>>>>>>> >>>>>>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>>>>>> Please review: >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>>>>>> >>>>>>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>>>>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS >>>>>>>>> are mapped read only. So memory fault will be triggered when >>>>>>>>> RewriteBytecodes turned on. This also disable all method >>>>>>>>> rewritten, leads interpreter run slower. Observed about 2% >>>>>>>>> regression with C2 on some benchmarks, since interpreter speed >>>>>>>>> is important to C2. By enable RewriteBytecodes and >>>>>>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx >>>>>>>>> for corresponding fast codes at dump time to avoid byte code >>>>>>>>> rewritten at run time, we prevent byte code rewritten and >>>>>>>>> modify the read only shared portion in CDS. Meanwhile other >>>>>>>>> byte codes with fast codes still get speed up. >>>>>>>>> >>>>>>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all >>>>>>>>> supported platforms. Interpreter only tests showed about 3% >>>>>>>>> improvement. >>>>>>>> >>>>>>>> What performance did you measure? Is it -Xint -Xshare:on with >>>>>>>> and without your patch? It was only 3% better? >>>>>>>> >>>>>>>> What was the difference in performance with -Xint >>>>>>>> -XX:-RewriteBytecodes vs. -Xint >>>>>>>> -XX:+RewriteBytecodes/FrequentPairs? I thought this was around >>>>>>>> 15%. >>>>>>>> >>>>>>> I will send you a separate email of the links which run with >>>>>>> CDS/NoCDS/CDS+Int >>>>>> >>>>>> Thanks for the links. From your experiments, I think your >>>>>> performance improvement with your patch and CDS with -Xmixed is >>>>>> 4%. That's good enough for a couple of bytecodes. >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From yumin.qi at oracle.com Wed Mar 25 21:48:27 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 25 Mar 2015 14:48:27 -0700 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <55132C67.3040808@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> <551327A3.7050007@oracle.com> <55132C67.3040808@oracle.com> Message-ID: <55132D2B.3060502@oracle.com> Thanks for your review! Yumin On 3/25/2015 2:45 PM, Coleen Phillimore wrote: > > Yumin, > > This looks great. You addressed my earlier pre-review comments. > > There are two other architectures now, that I don't believe we build > and test. I think it's only cpu code that would be changed so the > fixes for these architectures won't need a sponsor. > > Zero doesn't support CDS so I think the minimal changes you've put in > bytecodeInterpreter.cpp are good. > > Thanks! > Coleen > > > On 3/25/15, 5:24 PM, Yumin Qi wrote: >> Hi, Coleen >> >> New version based on Ioi's suggestion is located at: >> http://cr.openjdk.java.net/~minqi/8074345/webrev03/ >> >> Test: JPRT. Manual test on -Xshare:[dump | on ] >> >> Thanks >> Yumin >> >> On 3/25/2015 9:58 AM, Coleen Phillimore wrote: >>> >>> Yes, this was on my to-do list, sorry I haven't gotten to it yet. >>> Coleen >>> >>> On 3/25/15, 12:38 PM, Ioi Lam wrote: >>>> Hi Yumin, >>>> >>>> The changes look good. Just a few nits: >>>> >>>> *src/share/vm/interpreter/bytecodes.hpp:** >>>> * >>>> 293 // Rewritten at CDS dump time to | Original bytecode >>>> 294 // _invoke_virtual rewritten on sparc, will be disabled if >>>> UseSharedSpaces turned on. >>>> 295 // ------------------------------+------------------ >>>> 296 _nofast_getfield , // <- _getfield >>>> 297 _nofast_putfield , // <- _putfield >>>> 298 _nofast_aload_0 , // <- _aload_0 >>>> 299 _nofast_iload , // <- _iload >>>> >>>> I think it should be reformatted to line up the columns: >>>> >>>> 293 // Rewritten at CDS dump time to | Original bytecode >>>> 295 // ------------------------------+------------------ >>>> 296 _nofast_getfield , // <- _getfield >>>> 297 _nofast_putfield , // <- _putfield >>>> 298 _nofast_aload_0 , // <- _aload_0 >>>> 299 _nofast_iload , // <- _iload >>>> 230 // NOTE: _invoke_virtual is rewritten only on sparc. This >>>> will be disabled if >>>> // UseSharedSpaces turned on. >>>> >>>> *src/share/vm/interpreter/rewriter.cpp:* >>>> >>>> There are many places that modify the Method object. Instead of >>>> putting asserts at all the places where an actual modification >>>> happens, I think it's better to use only one assert at the Rewriter >>>> entry point, and remove the other assets that you added: >>>> >>>> 516 void Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { >>>> + if (!DumpSharedSpaces) { >>>> + assert(!MetaspaceShared::is_in_shared_space(klass()), "archive >>>> methods must not be rewritten at run time"); >>>> + } >>>> 517 ResourceMark rm(THREAD); >>>> 518 Rewriter rw(klass, klass->constants(), klass->methods(), >>>> CHECK); >>>> 519 // (That's all, folks.) >>>> 520 } >>>> >>>> Also, I am not sure if the PPC directories in the repo have been >>>> 'locked' or not, but I guess you will find out when you do the push. >>>> >>>> I am not a Reviewer, so probably Coleen needs to look at this as well. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 3/20/15, 1:53 PM, Yumin Qi wrote: >>>>> Hi, Coleen and all >>>>> >>>>> New version with suggested changes can be reviewed at: >>>>> http://cr.openjdk.java.net/~minqi/8074345/webrev02/ >>>>> >>>>> Removed _fast_invokeinvirtual from last version, disable >>>>> rewriting _invokevirtual if UseSharedSpaces turned on. Only on >>>>> sparc _invokevirtual got rewritten. Other platforms as >>>>> unimplemented. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/11/2015 1:23 PM, Yumin Qi wrote: >>>>>> Thanks, I will have another webrev after build/test/perf test. >>>>>> >>>>>> Yumin >>>>>> >>>>>> On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Yumin, One comment embedded. >>>>>>> >>>>>>> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>>>>>>> Hi, Coleen >>>>>>>> >>>>>>>> Thanks for the review. See embedded. >>>>>>>> >>>>>>>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> Yumin, >>>>>>>>> >>>>>>>>> The new bytecode approach came out pretty cleanly, or as >>>>>>>>> cleanly as this could be. >>>>>>>>> >>>>>>>>> The file templateTable_x86_32 and 64 have just been merged, so >>>>>>>>> you'll have to make your change in the new version. >>>>>>>>> >>>>>>>>> I also have some comments: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Typo "rewirting" >>>>>>>>> >>>>>>>> Sure. >>>>>>>>> In these files, can you break up the long lines into three lines? >>>>>>>>> >>>>>>>>> - if (!is_static) { >>>>>>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>>>>>> + if (!is_static && rc == MAY_REWRITE) { >>>>>>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>>>>>> >>>>>>>> Sure. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> How many bytecodes do we have now? We're limited to 255 (or >>>>>>>>> 256) and there are other new bytecodes being added. >>>>>>>>> >>>>>>>> now total is 234 (after the fix). See below answer. >>>>>>>>> What was the performance benefit to this? I think if we >>>>>>>>> wanted to be conservative, we'd turn off RewriteFrequentPairs >>>>>>>>> and only do nofast_getfield and nofast_putfield. I think they >>>>>>>>> were the only bytecodes that actually affected performance. >>>>>>>>> >>>>>>>>> In this file above, can you remove the last block of comments >>>>>>>>> about fast_linearswitch and fast_ldc? I think this confuses >>>>>>>>> rewriting in the interpreter and rewriting in the rewriter, or >>>>>>>>> rather makes the confusion worse. I don't think this comment >>>>>>>>> is helpful. >>>>>>>>> >>>>>>>>> I'd prefer to see the first comment smaller also, like: >>>>>>>>> >>>>>>>>> + // These bytecodes are rewritten at CDS dump time, so >>>>>>>>> that we can prevent them from being >>>>>>>>> + // rewritten at run time. This way, the ConstMethods can >>>>>>>>> be placed in the CDS ReadOnly >>>>>>>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>>>>>>> rewrite non-CDS bytecodes >>>>>>>>> + // at run time. >>>>>>>>> + _nofast_getfield , >>>>>>>>> + _nofast_putfield , >>>>>>>>> + _nofast_aload_0 , >>>>>>>>> + _nofast_iload , >>>>>>>>> + _nofast_invokevirtual , >>>>>>>>> >>>>>>>>> It's sort of obvious which bytecode they rewrite. I don't know >>>>>>>>> how much performance fast_invokevfinal is worth. I thought I >>>>>>>>> deleted it. Can we not rewrite this so we don't waste another >>>>>>>>> bytecode on it? Maybe add a RewriteVFinal option and consider >>>>>>>>> removing it for the future? x86 doesn't use it and I can't see >>>>>>>>> how this would save any significant performance to be worth >>>>>>>>> having! >>>>>>>>> >>>>>>>> _invokevirtual got rewritten on sparc and ppc. Now ppc is >>>>>>>> removed, no need to take care for it. For sparc, it does patch >>>>>>>> code. I am thinking of a way if we need to add _nofast_code as >>>>>>>> you indicated, we only have 255 codes to use. >>>>>>> >>>>>>> PPC isn't removed from the open repository. >>>>>>>> >>>>>>>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>>>>>>> RewriteFrequentPair; >>>>>>> >>>>>>> I think the conditional would be >>>>>>> >>>>>>> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>>>>>>> >>>>>>>> Can this boolean decide if we not rewrite the bytecode to >>>>>>>> fast? If so, I can remove all the _nofast_code and do not patch >>>>>>>> code when it is on. >>>>>>> >>>>>>> Yes, this would be nice to not add the bytecode. >>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>>>>>>> control for fast code under CDS >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't know what our coding standard is but in the >>>>>>>>> templateTable_.cpp files these strings look like macros. >>>>>>>>> I'd rather see them as MayRewrite or MayNotRewrite. >>>>>>>>> >>>>>>>> Agree. >>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> I think there's a java_code() function that returns the >>>>>>>>> original bytecode that you could use instead of the case >>>>>>>>> statement in resolve_cache_and_index(). The indentation is >>>>>>>>> odd in the webrev. This probably applies to the other cpu >>>>>>>>> directories. >>>>>>>>> >>>>>>>>> One last question below: >>>>>>>>> >>>>>>>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>>>>>>> Please review: >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>>>>>>> >>>>>>>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>>>>>>> RewriteFrequentPairs are disabled due to ConstantMethod in >>>>>>>>>> CDS are mapped read only. So memory fault will be triggered >>>>>>>>>> when RewriteBytecodes turned on. This also disable all method >>>>>>>>>> rewritten, leads interpreter run slower. Observed about 2% >>>>>>>>>> regression with C2 on some benchmarks, since interpreter >>>>>>>>>> speed is important to C2. By enable RewriteBytecodes and >>>>>>>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx >>>>>>>>>> for corresponding fast codes at dump time to avoid byte code >>>>>>>>>> rewritten at run time, we prevent byte code rewritten and >>>>>>>>>> modify the read only shared portion in CDS. Meanwhile other >>>>>>>>>> byte codes with fast codes still get speed up. >>>>>>>>>> >>>>>>>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all >>>>>>>>>> supported platforms. Interpreter only tests showed about 3% >>>>>>>>>> improvement. >>>>>>>>> >>>>>>>>> What performance did you measure? Is it -Xint -Xshare:on with >>>>>>>>> and without your patch? It was only 3% better? >>>>>>>>> >>>>>>>>> What was the difference in performance with -Xint >>>>>>>>> -XX:-RewriteBytecodes vs. -Xint >>>>>>>>> -XX:+RewriteBytecodes/FrequentPairs? I thought this was around >>>>>>>>> 15%. >>>>>>>>> >>>>>>>> I will send you a separate email of the links which run with >>>>>>>> CDS/NoCDS/CDS+Int >>>>>>> >>>>>>> Thanks for the links. From your experiments, I think your >>>>>>> performance improvement with your patch and CDS with -Xmixed is >>>>>>> 4%. That's good enough for a couple of bytecodes. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Mar 26 00:00:07 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 20:00:07 -0400 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <550FAEC2.5040908@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> Message-ID: <55134C07.1050308@oracle.com> This looks fine to me. Sorry for the delay reviewing this. Coleen On 3/23/15, 2:12 AM, David Holmes wrote: > On 21/03/2015 3:32 AM, Jeremy Manson wrote: >> Argh. Yes. Martin told me not to get involved with Windows, but would >> I listen? Of course not... >> >> http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ > > Looks okay to me - running a test job now. > > Coleen: can you re-review the os_windows.cpp changes please. > > Thanks, > David > >> On Wed, Mar 18, 2015 at 2:39 PM, David Holmes > > wrote: >> >> On 19/03/2015 3:04 AM, Jeremy Manson wrote: >> >> Okay. Here you go: >> >> http://cr.openjdk.java.net/~__jmanson/8074895/webrev.03/__index.html >> >> >> >> ! if (alt_home_dir != NULL) { >> ! strcpy(home_dir, alt_home_dir); >> ! } else { >> >> That needs to be strncpy limited by MAX_PATH. >> >> David >> >> Jeremy >> >> On Wed, Mar 18, 2015 at 12:31 AM, David Holmes >> >> > >> wrote: >> >> On 18/03/2015 4:15 PM, Jeremy Manson wrote: >> >> Oops... Should I fix it, post a patch, and hope it >> compiles? >> >> >> Please :) I can check the compiles part. >> >> David >> >> On Tue, Mar 17, 2015 at 9:09 PM, David Holmes >> > >> > > >> > ____com >> > >>> wrote: >> >> Sorry Jeremy, the patch failed on Windows as >> there is >> another usage >> in os_windows.cpp: >> >> void os::init_system_properties_______values() { >> // sysclasspath, java_home, dll_dir >> { >> char *home_path; >> char *dll_path; >> char *pslash; >> char *bin = "\\bin"; >> char home_dir[MAX_PATH]; >> >> if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, >> MAX_PATH)) { >> >> David >> >> >> On 18/03/2015 12:01 PM, David Holmes wrote: >> >> Submitting via JPRT. >> >> Thanks, >> David >> >> On 18/03/2015 4:13 AM, Jeremy Manson wrote: >> >> >> >> On Sun, Mar 15, 2015 at 10:04 PM, David >> Holmes >> > >> > > >> > ____com >> > >> >> > . >> > .>______com >> > ____com >> > >>>> wrote: >> >> Hi Jeremy, >> >> On 14/03/2015 3:00 AM, Jeremy Manson >> wrote: >> >> Thanks, David! New rev: >> >> http://cr.openjdk.java.net/~________jmanson/8074895/webrev.01/ >> >> >> > > >> >> >> > >> >> > >> >> >> >> >> > >> >> > > >> >> >> > >> >> > >>> >> >> >> Looks good. Please update copyright >> dates in >> memTracker.cpp and >> vmError.cpp. >> >> >> Done. Thanks for the review, and for >> feeding it >> through the >> other >> platforms! >> >> http://cr.openjdk.java.net/~______jmanson/8074895/webrev.02/ >> >> >> > > >> >> >> > >> >> > >> >> >> Jeremy >> >> >> >> From coleen.phillimore at oracle.com Thu Mar 26 00:56:27 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Mar 2015 20:56:27 -0400 Subject: RFR(S) Contended Locking fast exit bucket (8073165) In-Reply-To: <55026C81.4030207@oracle.com> References: <54FDD431.7010704@oracle.com> <55026C81.4030207@oracle.com> Message-ID: <5513593B.8010807@oracle.com> Dan, I've finally gotten around to seeing this. What is this? + if (EmitSync & 1024) { and + if (EmitSync & 512) { I thought this sort of unintelligible code was going to get cleaned up? Do these constants mean anything? Other than being powers of two? + if (EmitSync & 16384) { This one isn't a power of two. In http://cr.openjdk.java.net/~dcubed/8073165-webrev/0-jdk9-hs-rt/src/share/vm/runtime/synchronizer.cpp.udiff.html + assert(inusetally == Self->omInUseCount, "in use count off"); is this in_use_tally ? is curmidinuse cur_mid_in_use? I wonder what gOmInUseList is. global object monitor in use list? http://cr.openjdk.java.net/~dcubed/8073165-webrev/0-jdk9-hs-rt/src/share/vm/runtime/synchronizer.hpp.udiff.html deflate_monitor_list appears to be more descriptive. Sorry I can only comment on surface things. It's a shame this code has to be in macro assembler. It appears to be called from generate_native_wrapper so affects performance of synchronized native methods? Thanks, Coleen On 3/13/15, 12:50 AM, David Holmes wrote: > Hi Dan, > > Well that was fun ... :) > > On 10/03/2015 3:11 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have the Contended Locking fast exit bucket ready for review. >> >> The code changes in this bucket are primarily assembly language >> tweaks that come into play when an inflated ObjectMonitor is in >> use. There are tweaks that apply to the default code path and >> there are tweaks that only apply when an experimental flag is >> set. This code code review is focused on the default code path >> or the "out of the box" configuration. >> >> This work is being tracked by the following bug ID: >> >> JDK-8073165 Contended Locking fast exit bucket >> https://bugs.openjdk.java.net/browse/JDK-8073165 >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8073165-webrev/0-jdk9-hs-rt/ >> >> Here is the JEP link: >> >> https://bugs.openjdk.java.net/browse/JDK-8046133 >> >> Testing: >> >> - Aurora Adhoc RT/SVC baseline batch >> - JPRT test jobs >> - MonitorExitStresser micro-benchmark (in process) >> - MonitorEnterExitStresser micro-benchmark (in process) >> - CallTimerGrid stress testing (in process) >> - Aurora performance testing: >> - out of the box for the "promotion" and 32-bit server configs >> - heavy weight monitors for the "promotion" and 32-bit server configs >> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors) >> (in process) >> >> >> 8073165 summary of changes: >> >> macroAssembler_sparc.cpp: MacroAssembler::compiler_unlock_object() >> >> - default (OOTB) EmitSync value == 0 >> - an _owner field optimization is in the non-default path under >> a (EmitSync & 1024) check >> >> - classic lock release without 1-0 support is in the non-default >> path under a (EmitSync & 512) check >> >> - an EntryList, cxq and _succ field optimization is in the >> non-default path under a (EmitSync & 16384) check >> >> - the default path is now the 1-0 form that avoids CAS and membar >> in the common case; see the "1-0 exit" section in objectMonitor.cpp > > I don't pretend that I could follow all these changes (I don't read > sparc very well) - the main thing of interest is the EmitSync==0 path > - everything else is just experimental (did you actually test to any > great extent with all these different possible EmitSync values?). > > So looking at the default path ... I could not figure out what logic > this (pre-existing) code is effecting: > > 3071 ld_ptr(Address(Rmark, > OM_OFFSET_NO_MONITOR_VALUE_TAG(recursions)), Rbox); > 3072 orcc(Rbox, G0, G0); > 3073 brx(Assembler::notZero, false, Assembler::pn, done); > > It seems to be a check for: > > if (recursions != 0) return; > > which would be fine except where is recursions decremented ?? > > But that aside the description seems reasonable. > >> sharedRuntime_sparc.cpp: >> >> - add JavaThread* param for >> SharedRuntime::complete_monitor_unlocking_C call > > Ok. > >> macroAssembler_x86.cpp: MacroAssembler::fast_unlock() >> >> - with all the new/modified comments and all the optional >> code path updates, it is hard to see that the only real >> changes to the default code path are 1) the _owner==Self >> check has been made optional and 2) the optional succ >> field check for the slow path is now on the default path >> >> - default (OOTB) EmitSync value == 0 >> - remove optional (EmitSync & 8) code >> - refactor code in MacroAssembler::fast_unlock >> - remove old mfence() support > > So I had expected to see this change conditional on the runtime > processor type. But then I checked Dave's blog and saw this was > determined 5+ years ago (!!!) so those older processors are no longer > a consideration. I do hope the performance tests have been re-run > since then though ;-) > >> - an _owner field optimization is in the non-default path under >> a (EmitSync & 1024) check > > Doesn't the comment: > > 2163 if (EmitSync & 1024) { > 2164 // Don't bother to ratify that m_Owner==Self > > apply to else part? > >> - an _owner field optimization is in the non-default path under >> a (EmitSync & 16) check >> - a barrier optimization is in the non-default path under a >> (EmitSync & 32) check >> - remove old AMD optional work around > > 2229 // box is really RAX -- the following CMPXCHG depends on > that binding > 2230 // cmpxchg R,[M] is equivalent to rax = CAS(M,rax,R) > 2231 > 2232 movptr(boxReg, (int32_t)NULL_WORD); // box is really RAX > > You've repeated the comment about box. > >> sharedRuntime_x86_32.cpp: >> sharedRuntime_x86_64.cpp: >> >> - add thread param for SharedRuntime::complete_monitor_unlocking_C >> call > > Ok. > >> macro.[ch]pp: PhaseMacroExpand::make_slow_call() >> >> - add param2 and update callers > > Ok. > >> runtime.[ch]pp: OptoRuntime::complete_monitor_exit_Type() >> >> - add JavaThread* parameter > > Ok > >> sharedRuntime.[ch]pp: SharedRuntime::complete_monitor_unlocking_C() >> >> - add JavaThread* parameter > > Ok. So all that passing through of the Thread was just to avoid a call > to JavaThread::current()? I thought that was already optimized to just > be a register load (at least on some platforms) ? > >> synchronizer.cpp: ObjectSynchronizer::omRelease() >> >> - cleanup in use list traversal >> - add assert that ObjectMonitor being released was >> actually found and extracted >> >> synchronizer.[ch]pp: >> >> - add some comments in various places >> - rename walk_monitor_list() -> deflate_monitor_list() >> and update callers >> - minor logic refactoring > > Generally okay. > > Minor nit: you changed inuse to "in use" but for the "inuse list" it > should really be "in-use list" (and not in-use-list as appears in a > couple of existing places) > > 1507 // if deflate_monitor succeeded,/moribund > > Not sure what that comment is supposed to mean :) > >> thread.hpp: >> >> - add _TSelf field for mfence() replacement > > Hmmmm, so we add a new pointer field to the Thread structure purely > for use on x86 if running with a particular experimental option set ? > That doesn't seem like it fits with our normal considerations for > space/time trade-offs. Maybe the xchg T,T->TSelf stuff should be under > a compile-flag instead? > >> >> Thanks, in advance, for any comments, questions or suggestions. > > Cheers, > David > >> Dan From david.holmes at oracle.com Thu Mar 26 06:41:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Mar 2015 16:41:54 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <55123889.7080504@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> Message-ID: <5513AA32.4020901@oracle.com> Okay I managed to fix this with: --- old/src/share/vm/utilities/growableArray.hpp 2015-03-26 02:34:35.715892476 -0400 +++ new/src/share/vm/utilities/growableArray.hpp 2015-03-26 02:34:34.663833288 -0400 @@ -168,6 +168,8 @@ GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F = mtInternal) : GenericGrowableArray(initial_size, 0, C_heap, F) { _data = (E*)raw_allocate(sizeof(E)); +// Needed for Visual Studio 2012 and older +#pragma warning(suppress: 4345) for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); } @@ -385,6 +387,8 @@ E* newData = (E*)raw_allocate(sizeof(E)); int i = 0; for ( ; i < _len; i++) ::new ((void*)&newData[i]) E(_data[i]); +// Needed for Visual Studio 2012 and older +#pragma warning(suppress: 4345) for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); for (i = 0; i < old_max; i++) _data[i].~E(); if (on_C_heap() && _data != NULL) { So unless someone finds this totally objectionable it is what I propose to go with. Full webrev at: http://cr.openjdk.java.net/~dholmes/8074895/webrev/ Thanks, David On 25/03/2015 2:24 PM, David Holmes wrote: > On 24/03/2015 2:56 AM, Jeremy Manson wrote: >> Thanks, Kim. This is a pretty silly warning to have break the build. >> Does anyone have a problem with PODs being default initialized? That's >> required by the standard, so if you do, then you are Doing It Wrong. >> >> I assume it is pretty easy to turn the warning off. I'd do it, but I >> don't have the Windows build-fu necessary. Also, do we think it would >> require another bug? > > Unless someone else can already tell me how I will try to find the > cycles to either disable the warning in that file (if that works) else > disable it in the build - which will need a new CR I think. > > David > >> I'd hate to have to change my (or any) code for this. >> >> Jeremy >> >> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett > > wrote: >> >> On Mar 23, 2015, at 3:45 AM, David Holmes > > wrote: >> > >> > On 23/03/2015 4:12 PM, David Holmes wrote: >> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >> >>> Argh. Yes. Martin told me not to get involved with Windows, >> but would >> >>> I listen? Of course not... >> >>> >> >>>http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ >> >> >> >> Looks okay to me - running a test job now. >> > >> > This just isn't meant to be :( It seems that: >> > >> > GrowableArray options(2, true); >> > >> > in arguments.cpp is giving the windows compiler some grief: >> > >> > >> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) >> : error C2220: warning treated as error - no 'object' file generated >> > >> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(168) >> : while compiling class template member function >> 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\arguments.cpp(3516) >> : see reference to class template instantiation 'GrowableArray' >> being compiled >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(171) >> : warning C4345: behavior change: an object of POD type constructed >> with an initializer of the form () will be default-initialized >> > >> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(388) >> : warning C4345: behavior change: an object of POD type constructed >> with an initializer of the form () will be default-initialized >> > >> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\utilities/growableArray.hpp(379) >> : while compiling class template member function 'void >> GrowableArray::grow(int)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> > I'm guessing it doesn't like the enum as the generic arg, but >> don't know why given that it accepts plain int elsewhere. ??? >> >> Just suppressing this warning (unconditionally everywhere) would >> probably make sense. >> >> Microsoft describes it as an obsolete warning: >> >> https://msdn.microsoft.com/en-us/library/wewb47ee.aspx >> >> "This warning is obsolete. It is only generated in Visual Studio >> 2005 through Visual Studio 2012. It reports a behavior change from >> the Visual C++ compiler that shipped in Visual Studio .NET when >> initializing a POD (plain old data) object with (); the compiler >> default-initializes the object.? >> >> It?s too bad the JDK9 supported build platform for Windows is still >> lagging. >> >> From ejones at twitter.com Thu Mar 26 15:14:20 2015 From: ejones at twitter.com (Evan Jones) Date: Thu, 26 Mar 2015 11:14:20 -0400 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? Message-ID: At Twitter, I recently discovered that the hsperfdata file that is created by default by the JVM causes long safepoint and GC pauses. It turns out that writes to mmap-ed files can block until disk I/O completes, even if the I/O is to another disk. For details see: http://www.evanjones.ca/jvm-mmap-pause.html We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM flag on a number of our latency sensitive services, and have seen a significant improvement. Our JVM team (which I am *not* part of), is investigating potential changes to the JVM to prevent this. Any suggestions for an approach to solving this problem that could be accepted into Hotspot itself? Some options: * Make the location of this file configurable (this was set with java.io.tmpdir for a time, but then was reverted; see http://bugs.java.com/view_bug.do?bug_id=6447182) * Use shared memory that is not backed by a file? * Something else I'm not considering? Thanks! Evan Jones From mikael.gerdin at oracle.com Thu Mar 26 15:33:49 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 16:33:49 +0100 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: References: Message-ID: <551426DD.6050506@oracle.com> Hi Evan, On 2015-03-26 16:14, Evan Jones wrote: > At Twitter, I recently discovered that the hsperfdata file that is created > by default by the JVM causes long safepoint and GC pauses. It turns out > that writes to mmap-ed files can block until disk I/O completes, even if > the I/O is to another disk. For details see: > http://www.evanjones.ca/jvm-mmap-pause.html Truly interesting stuff! I know we've seen similar discrepancies in user/sys/real time before, this could indeed be a cause for at least some of them. > > We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM > flag on a number of our latency sensitive services, and have seen a > significant improvement. Our JVM team (which I am *not* part of), is > investigating potential changes to the JVM to prevent this. > > Any suggestions for an approach to solving this problem that could be > accepted into Hotspot itself? Some options: > > * Make the location of this file configurable (this was set with > java.io.tmpdir for a time, but then was reverted; see > http://bugs.java.com/view_bug.do?bug_id=6447182) > > * Use shared memory that is not backed by a file? Yeah, something like shm_open("/hsperfdata__", O_RDWR|O_CREAT|O_EXCL, 0600) > > * Something else I'm not considering? Have the VM asynchronously update the values in the hsperfdata file by caching the new values somewhere in memory and using the ServiceThread to commit the updated values to the mmaped perf data? I'll file and issue for this and copy the relevant information into it. /Mikael > > > Thanks! > > Evan Jones > From mikael.gerdin at oracle.com Thu Mar 26 15:42:14 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Mar 2015 16:42:14 +0100 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <551426DD.6050506@oracle.com> References: <551426DD.6050506@oracle.com> Message-ID: <551428D6.7030306@oracle.com> On 2015-03-26 16:33, Mikael Gerdin wrote: > Hi Evan, > > On 2015-03-26 16:14, Evan Jones wrote: >> At Twitter, I recently discovered that the hsperfdata file that is >> created >> by default by the JVM causes long safepoint and GC pauses. It turns out >> that writes to mmap-ed files can block until disk I/O completes, even if >> the I/O is to another disk. For details see: >> http://www.evanjones.ca/jvm-mmap-pause.html > > Truly interesting stuff! > > I know we've seen similar discrepancies in user/sys/real time before, > this could indeed be a cause for at least some of them. > >> >> We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM >> flag on a number of our latency sensitive services, and have seen a >> significant improvement. Our JVM team (which I am *not* part of), is >> investigating potential changes to the JVM to prevent this. >> >> Any suggestions for an approach to solving this problem that could be >> accepted into Hotspot itself? Some options: >> >> * Make the location of this file configurable (this was set with >> java.io.tmpdir for a time, but then was reverted; see >> http://bugs.java.com/view_bug.do?bug_id=6447182) >> >> * Use shared memory that is not backed by a file? > > Yeah, something like shm_open("/hsperfdata__", > O_RDWR|O_CREAT|O_EXCL, 0600) > >> >> * Something else I'm not considering? > > Have the VM asynchronously update the values in the hsperfdata file by > caching the new values somewhere in memory and using the ServiceThread > to commit the updated values to the mmaped perf data? > > I'll file and issue for this and copy the relevant information into it. https://bugs.openjdk.java.net/browse/JDK-8076103 /m > > /Mikael > >> >> >> Thanks! >> >> Evan Jones >> > From dmitry.samersoff at oracle.com Thu Mar 26 17:54:03 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 26 Mar 2015 20:54:03 +0300 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: References: Message-ID: <551447BB.5070508@oracle.com> Evan, What filesystem do you use for /tmp ? Did you try to reproduce the problem with tmpfs? -Dmitry On 2015-03-26 18:14, Evan Jones wrote: > At Twitter, I recently discovered that the hsperfdata file that is created > by default by the JVM causes long safepoint and GC pauses. It turns out > that writes to mmap-ed files can block until disk I/O completes, even if > the I/O is to another disk. For details see: > http://www.evanjones.ca/jvm-mmap-pause.html > > We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM > flag on a number of our latency sensitive services, and have seen a > significant improvement. Our JVM team (which I am *not* part of), is > investigating potential changes to the JVM to prevent this. > > Any suggestions for an approach to solving this problem that could be > accepted into Hotspot itself? Some options: > > * Make the location of this file configurable (this was set with > java.io.tmpdir for a time, but then was reverted; see > http://bugs.java.com/view_bug.do?bug_id=6447182) > > * Use shared memory that is not backed by a file? > > * Something else I'm not considering? > > > Thanks! > > Evan Jones > -- 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 christian.tornqvist at oracle.com Thu Mar 26 19:08:06 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 26 Mar 2015 15:08:06 -0400 Subject: RFR(S): 8075438 - [TESTBUG] Hotspot JTREG tests should use unique CDS archive names Message-ID: <007501d067f8$31a128a0$94e379e0$@oracle.com> Hi everyone, Please review this small change that changes the CDS archive names to be unique. The theory is that sometimes on Windows, something (Anti-virus software?) is keeping the archive file open after the JVM has been shut down. JTreg will use the same folder for tests in the same folder and the next test may fail to create the archive (seen in 8067333, 8075212, 8056944 and 8075212) Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8075438/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8075438 Thanks, Christian From george.triantafillou at oracle.com Thu Mar 26 20:13:27 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 26 Mar 2015 16:13:27 -0400 Subject: RFR(S): 8075438 - [TESTBUG] Hotspot JTREG tests should use unique CDS archive names In-Reply-To: <007501d067f8$31a128a0$94e379e0$@oracle.com> References: <007501d067f8$31a128a0$94e379e0$@oracle.com> Message-ID: <55146867.4070304@oracle.com> Christian, Looks good! -George On 3/26/2015 3:08 PM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that changes the CDS archive names to be > unique. The theory is that sometimes on Windows, something (Anti-virus > software?) is keeping the archive file open after the JVM has been shut > down. JTreg will use the same folder for tests in the same folder and the > next test may fail to create the archive (seen in 8067333, 8075212, 8056944 > and 8075212) > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8075438/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8075438 > > > > Thanks, > > Christian > From dean.long at oracle.com Thu Mar 26 20:15:09 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 26 Mar 2015 13:15:09 -0700 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: References: Message-ID: <551468CD.505@oracle.com> I'm curious, does the problem go away if the mmap doesn't use MAP_SHARED? dl On 3/26/2015 8:14 AM, Evan Jones wrote: > At Twitter, I recently discovered that the hsperfdata file that is created > by default by the JVM causes long safepoint and GC pauses. It turns out > that writes to mmap-ed files can block until disk I/O completes, even if > the I/O is to another disk. For details see: > http://www.evanjones.ca/jvm-mmap-pause.html > > We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM > flag on a number of our latency sensitive services, and have seen a > significant improvement. Our JVM team (which I am *not* part of), is > investigating potential changes to the JVM to prevent this. > > Any suggestions for an approach to solving this problem that could be > accepted into Hotspot itself? Some options: > > * Make the location of this file configurable (this was set with > java.io.tmpdir for a time, but then was reverted; see > http://bugs.java.com/view_bug.do?bug_id=6447182) > > * Use shared memory that is not backed by a file? > > * Something else I'm not considering? > > > Thanks! > > Evan Jones From harold.seigel at oracle.com Thu Mar 26 20:41:19 2015 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 26 Mar 2015 16:41:19 -0400 Subject: RFR(S): 8075438 - [TESTBUG] Hotspot JTREG tests should use unique CDS archive names In-Reply-To: <007501d067f8$31a128a0$94e379e0$@oracle.com> References: <007501d067f8$31a128a0$94e379e0$@oracle.com> Message-ID: <55146EEF.1070607@oracle.com> Hi Christian, The changes look good. Thanks, Harold On 3/26/2015 3:08 PM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that changes the CDS archive names to be > unique. The theory is that sometimes on Windows, something (Anti-virus > software?) is keeping the archive file open after the JVM has been shut > down. JTreg will use the same folder for tests in the same folder and the > next test may fail to create the archive (seen in 8067333, 8075212, 8056944 > and 8075212) > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8075438/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8075438 > > > > Thanks, > > Christian > From david.holmes at oracle.com Thu Mar 26 20:53:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Mar 2015 06:53:13 +1000 Subject: RFR(S): 8075438 - [TESTBUG] Hotspot JTREG tests should use unique CDS archive names In-Reply-To: <007501d067f8$31a128a0$94e379e0$@oracle.com> References: <007501d067f8$31a128a0$94e379e0$@oracle.com> Message-ID: <551471B9.6030107@oracle.com> Hi Christian, On 27/03/2015 5:08 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that changes the CDS archive names to be > unique. The theory is that sometimes on Windows, something (Anti-virus > software?) is keeping the archive file open after the JVM has been shut > down. JTreg will use the same folder for tests in the same folder and the > next test may fail to create the archive (seen in 8067333, 8075212, 8056944 > and 8075212) Is this because jtreg is deleting the directory contents and windows is preventing the file from being deleted, and so it interferes with the next test? When a test uses '.' for files what actual directory gets used for that? JTwork/scratch or JTwork/path/to/test ? Thanks, David > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8075438/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8075438 > > > > Thanks, > > Christian > From ejones at twitter.com Thu Mar 26 21:08:18 2015 From: ejones at twitter.com (Evan Jones) Date: Thu, 26 Mar 2015 17:08:18 -0400 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <551447BB.5070508@oracle.com> References: <551447BB.5070508@oracle.com> Message-ID: This problem does *not* happen if /tmp is on tmpfs (or if /tmp/hsperfdata_user is symlinked to tmpfs). It *does* happen on ext2, ext3, ext4, btrfs, and xfs. It is *extremely* common on btrfs, and rare on xfs (but still seems to occur). On Thu, Mar 26, 2015 at 1:54 PM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > Evan, > > What filesystem do you use for /tmp ? > > Did you try to reproduce the problem with tmpfs? > > -Dmitry > > On 2015-03-26 18:14, Evan Jones wrote: > > At Twitter, I recently discovered that the hsperfdata file that is > created > > by default by the JVM causes long safepoint and GC pauses. It turns out > > that writes to mmap-ed files can block until disk I/O completes, even if > > the I/O is to another disk. For details see: > > http://www.evanjones.ca/jvm-mmap-pause.html > > > > We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM > > flag on a number of our latency sensitive services, and have seen a > > significant improvement. Our JVM team (which I am *not* part of), is > > investigating potential changes to the JVM to prevent this. > > > > Any suggestions for an approach to solving this problem that could be > > accepted into Hotspot itself? Some options: > > > > * Make the location of this file configurable (this was set with > > java.io.tmpdir for a time, but then was reverted; see > > http://bugs.java.com/view_bug.do?bug_id=6447182) > > > > * Use shared memory that is not backed by a file? > > > > * Something else I'm not considering? > > > > > > Thanks! > > > > Evan Jones > > > > > -- > 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 ejones at twitter.com Thu Mar 26 21:09:38 2015 From: ejones at twitter.com (Evan Jones) Date: Thu, 26 Mar 2015 17:09:38 -0400 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <551426DD.6050506@oracle.com> References: <551426DD.6050506@oracle.com> Message-ID: On Thu, Mar 26, 2015 at 11:33 AM, Mikael Gerdin wrote: > > Have the VM asynchronously update the values in the hsperfdata file by > caching the new values somewhere in memory and using the ServiceThread to > commit the updated values to the mmaped perf data? > This approach could work, but wouldn't it have to be a native thread? I thought the ServiceThread is actually a Java thread, so it needs to reach safepoints with all the others? It seems reasonable to have the statistics in private memory, periodically written out to /tmp by some other JVM thread. Thanks for filing the bug! From ejones at twitter.com Thu Mar 26 21:25:10 2015 From: ejones at twitter.com (Evan Jones) Date: Thu, 26 Mar 2015 17:25:10 -0400 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <551468CD.505@oracle.com> References: <551468CD.505@oracle.com> Message-ID: On Thu, Mar 26, 2015 at 4:15 PM, Dean Long wrote: > I'm curious, does the problem go away if the mmap doesn't use MAP_SHARED? That is a variant I did not try, however for the JVM stats I don't think that would work. Doesn't MAP_PRIVATE mean that the modifications to the mmap-ed file are not written back to disk? The point of this shared file is that other tools can read the statistics. From dean.long at oracle.com Thu Mar 26 21:33:35 2015 From: dean.long at oracle.com (Dean Long) Date: Thu, 26 Mar 2015 14:33:35 -0700 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: References: <551468CD.505@oracle.com> Message-ID: <55147B2F.1090900@oracle.com> On 3/26/2015 2:25 PM, Evan Jones wrote: > On Thu, Mar 26, 2015 at 4:15 PM, Dean Long > wrote: > > I'm curious, does the problem go away if the mmap doesn't use > MAP_SHARED? > > > That is a variant I did not try, however for the JVM stats I don't > think that would work. Doesn't MAP_PRIVATE mean that the modifications > to the mmap-ed file are not written back to disk? The point of this > shared file is that other tools can read the statistics. Looks like you're right. For some reason I was thinking that there was something in between MAP_SHARED and MAP_PRIVATE, where other processes would only be guaranteed to see the changes after the fd was closed. dl From ysr1729 at gmail.com Thu Mar 26 22:39:19 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 26 Mar 2015 15:39:19 -0700 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <551447BB.5070508@oracle.com> References: <551447BB.5070508@oracle.com> Message-ID: It's a non-issue with a pure ram-based file system. Or tmpfs with no swap. The issue arises only when the backing file is disk based or the ram-based backing file is subject to swapping. The workaround is to ensure that the backing file is not (ever) backed by disk, when pressure on the page cache can cause the file pages to be evicted. -- Ramki ysr1729 > On Mar 26, 2015, at 10:54, Dmitry Samersoff wrote: > > Evan, > > What filesystem do you use for /tmp ? > > Did you try to reproduce the problem with tmpfs? > > -Dmitry > >> On 2015-03-26 18:14, Evan Jones wrote: >> At Twitter, I recently discovered that the hsperfdata file that is created >> by default by the JVM causes long safepoint and GC pauses. It turns out >> that writes to mmap-ed files can block until disk I/O completes, even if >> the I/O is to another disk. For details see: >> http://www.evanjones.ca/jvm-mmap-pause.html >> >> We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM >> flag on a number of our latency sensitive services, and have seen a >> significant improvement. Our JVM team (which I am *not* part of), is >> investigating potential changes to the JVM to prevent this. >> >> Any suggestions for an approach to solving this problem that could be >> accepted into Hotspot itself? Some options: >> >> * Make the location of this file configurable (this was set with >> java.io.tmpdir for a time, but then was reverted; see >> http://bugs.java.com/view_bug.do?bug_id=6447182) >> >> * Use shared memory that is not backed by a file? >> >> * Something else I'm not considering? >> >> >> Thanks! >> >> Evan Jones > > > -- > 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 yumin.qi at oracle.com Fri Mar 27 02:34:51 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 26 Mar 2015 19:34:51 -0700 Subject: RFR: 8025692: Add trace to find out what methods are used at runtime. Message-ID: <5514C1CB.7020009@oracle.com> Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8025692 webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/ Summary: Add two flags to help list all java methods called in runtime, this is also in product and can help CDS to rearrange methods in shared archive to avoid loading infrequent methods into memory. Tests: vm.runtime.quick.testlist, JPRT Thanks Yumin From jeremymanson at google.com Fri Mar 27 07:24:24 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 27 Mar 2015 00:24:24 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5513AA32.4020901@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> Message-ID: I hate to see legacy cruft deliberately introduced into the codebase. I guess it is too painful to turn it off in a makefile? Stuff ignored by compilers in rarely touched code like this tends to turn crufty and become confusing, e.g., something I saw a month or two ago: http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 Referring you to a page in what you have to think about for a second before you realize is JVMS v1, which has been obsolete since 2000, and is unavailable from the publisher. Doing it this way seems fine to me, but I don't know anything about suppressing warnings on Windows, so that's not a firm endorsement. Not that my non-reviewer endorsement would do you any good. Jeremy On Wed, Mar 25, 2015 at 11:41 PM, David Holmes wrote: > Okay I managed to fix this with: > > --- old/src/share/vm/utilities/growableArray.hpp 2015-03-26 > 02:34:35.715892476 -0400 > +++ new/src/share/vm/utilities/growableArray.hpp 2015-03-26 > 02:34:34.663833288 -0400 > @@ -168,6 +168,8 @@ > GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F = > mtInternal) > : GenericGrowableArray(initial_size, 0, C_heap, F) { > _data = (E*)raw_allocate(sizeof(E)); > +// Needed for Visual Studio 2012 and older > +#pragma warning(suppress: 4345) > for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); > } > > @@ -385,6 +387,8 @@ > E* newData = (E*)raw_allocate(sizeof(E)); > int i = 0; > for ( ; i < _len; i++) ::new ((void*)&newData[i]) E(_data[i]); > +// Needed for Visual Studio 2012 and older > +#pragma warning(suppress: 4345) > for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); > for (i = 0; i < old_max; i++) _data[i].~E(); > if (on_C_heap() && _data != NULL) { > > So unless someone finds this totally objectionable it is what I propose to > go with. Full webrev at: > > http://cr.openjdk.java.net/~dholmes/8074895/webrev/ > > Thanks, > David > > > On 25/03/2015 2:24 PM, David Holmes wrote: > >> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >> >>> Thanks, Kim. This is a pretty silly warning to have break the build. >>> Does anyone have a problem with PODs being default initialized? That's >>> required by the standard, so if you do, then you are Doing It Wrong. >>> >>> I assume it is pretty easy to turn the warning off. I'd do it, but I >>> don't have the Windows build-fu necessary. Also, do we think it would >>> require another bug? >>> >> >> Unless someone else can already tell me how I will try to find the >> cycles to either disable the warning in that file (if that works) else >> disable it in the build - which will need a new CR I think. >> >> David >> >> I'd hate to have to change my (or any) code for this. >>> >>> Jeremy >>> >>> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >> > wrote: >>> >>> On Mar 23, 2015, at 3:45 AM, David Holmes >> > wrote: >>> > >>> > On 23/03/2015 4:12 PM, David Holmes wrote: >>> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>> >>> Argh. Yes. Martin told me not to get involved with Windows, >>> but would >>> >>> I listen? Of course not... >>> >>> >>> >>>http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ >>> >> >>> >> Looks okay to me - running a test job now. >>> > >>> > This just isn't meant to be :( It seems that: >>> > >>> > GrowableArray options(2, true); >>> > >>> > in arguments.cpp is giving the windows compiler some grief: >>> > >>> > >>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>> utilities/growableArray.hpp(171) >>> : error C2220: warning treated as error - no 'object' file generated >>> > >>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>> utilities/growableArray.hpp(168) >>> : while compiling class template member function >>> 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' >>> > with >>> > [ >>> > E=JavaVMOption >>> > ] >>> > >>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\ >>> arguments.cpp(3516) >>> : see reference to class template instantiation 'GrowableArray' >>> being compiled >>> > with >>> > [ >>> > E=JavaVMOption >>> > ] >>> > >>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>> utilities/growableArray.hpp(171) >>> : warning C4345: behavior change: an object of POD type constructed >>> with an initializer of the form () will be default-initialized >>> > >>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>> utilities/growableArray.hpp(388) >>> : warning C4345: behavior change: an object of POD type constructed >>> with an initializer of the form () will be default-initialized >>> > >>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>> utilities/growableArray.hpp(379) >>> : while compiling class template member function 'void >>> GrowableArray::grow(int)' >>> > with >>> > [ >>> > E=JavaVMOption >>> > ] >>> > >>> > I'm guessing it doesn't like the enum as the generic arg, but >>> don't know why given that it accepts plain int elsewhere. ??? >>> >>> Just suppressing this warning (unconditionally everywhere) would >>> probably make sense. >>> >>> Microsoft describes it as an obsolete warning: >>> >>> https://msdn.microsoft.com/en-us/library/wewb47ee.aspx >>> >>> "This warning is obsolete. It is only generated in Visual Studio >>> 2005 through Visual Studio 2012. It reports a behavior change from >>> the Visual C++ compiler that shipped in Visual Studio .NET when >>> initializing a POD (plain old data) object with (); the compiler >>> default-initializes the object.? >>> >>> It?s too bad the JDK9 supported build platform for Windows is still >>> lagging. >>> >>> >>> From jeremymanson at google.com Fri Mar 27 07:25:37 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 27 Mar 2015 00:25:37 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> Message-ID: Oh, and thank you for doing it! I didn't think my piddling little P4 change was going to cause so much trouble! Jeremy On Fri, Mar 27, 2015 at 12:24 AM, Jeremy Manson wrote: > I hate to see legacy cruft deliberately introduced into the codebase. I > guess it is too painful to turn it off in a makefile? Stuff ignored by > compilers in rarely touched code like this tends to turn crufty and become > confusing, e.g., something I saw a month or two ago: > > > http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 > > Referring you to a page in what you have to think about for a second > before you realize is JVMS v1, which has been obsolete since 2000, and is > unavailable from the publisher. > > Doing it this way seems fine to me, but I don't know anything about > suppressing warnings on Windows, so that's not a firm endorsement. Not > that my non-reviewer endorsement would do you any good. > > Jeremy > > On Wed, Mar 25, 2015 at 11:41 PM, David Holmes > wrote: > >> Okay I managed to fix this with: >> >> --- old/src/share/vm/utilities/growableArray.hpp 2015-03-26 >> 02:34:35.715892476 -0400 >> +++ new/src/share/vm/utilities/growableArray.hpp 2015-03-26 >> 02:34:34.663833288 -0400 >> @@ -168,6 +168,8 @@ >> GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F = >> mtInternal) >> : GenericGrowableArray(initial_size, 0, C_heap, F) { >> _data = (E*)raw_allocate(sizeof(E)); >> +// Needed for Visual Studio 2012 and older >> +#pragma warning(suppress: 4345) >> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >> } >> >> @@ -385,6 +387,8 @@ >> E* newData = (E*)raw_allocate(sizeof(E)); >> int i = 0; >> for ( ; i < _len; i++) ::new ((void*)&newData[i]) E(_data[i]); >> +// Needed for Visual Studio 2012 and older >> +#pragma warning(suppress: 4345) >> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >> for (i = 0; i < old_max; i++) _data[i].~E(); >> if (on_C_heap() && _data != NULL) { >> >> So unless someone finds this totally objectionable it is what I propose >> to go with. Full webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8074895/webrev/ >> >> Thanks, >> David >> >> >> On 25/03/2015 2:24 PM, David Holmes wrote: >> >>> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >>> >>>> Thanks, Kim. This is a pretty silly warning to have break the build. >>>> Does anyone have a problem with PODs being default initialized? That's >>>> required by the standard, so if you do, then you are Doing It Wrong. >>>> >>>> I assume it is pretty easy to turn the warning off. I'd do it, but I >>>> don't have the Windows build-fu necessary. Also, do we think it would >>>> require another bug? >>>> >>> >>> Unless someone else can already tell me how I will try to find the >>> cycles to either disable the warning in that file (if that works) else >>> disable it in the build - which will need a new CR I think. >>> >>> David >>> >>> I'd hate to have to change my (or any) code for this. >>>> >>>> Jeremy >>>> >>>> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >>> > wrote: >>>> >>>> On Mar 23, 2015, at 3:45 AM, David Holmes >>> > wrote: >>>> > >>>> > On 23/03/2015 4:12 PM, David Holmes wrote: >>>> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>>> >>> Argh. Yes. Martin told me not to get involved with Windows, >>>> but would >>>> >>> I listen? Of course not... >>>> >>> >>>> >>>http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ >>>> >> >>>> >> Looks okay to me - running a test job now. >>>> > >>>> > This just isn't meant to be :( It seems that: >>>> > >>>> > GrowableArray options(2, true); >>>> > >>>> > in arguments.cpp is giving the windows compiler some grief: >>>> > >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>>> utilities/growableArray.hpp(171) >>>> : error C2220: warning treated as error - no 'object' file generated >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>>> utilities/growableArray.hpp(168) >>>> : while compiling class template member function >>>> 'GrowableArray::GrowableArray(int,bool,MEMFLAGS)' >>>> > with >>>> > [ >>>> > E=JavaVMOption >>>> > ] >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\runtime\ >>>> arguments.cpp(3516) >>>> : see reference to class template instantiation 'GrowableArray' >>>> being compiled >>>> > with >>>> > [ >>>> > E=JavaVMOption >>>> > ] >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>>> utilities/growableArray.hpp(171) >>>> : warning C4345: behavior change: an object of POD type constructed >>>> with an initializer of the form () will be default-initialized >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>>> utilities/growableArray.hpp(388) >>>> : warning C4345: behavior change: an object of POD type constructed >>>> with an initializer of the form () will be default-initialized >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\hotspot\src\share\vm\ >>>> utilities/growableArray.hpp(379) >>>> : while compiling class template member function 'void >>>> GrowableArray::grow(int)' >>>> > with >>>> > [ >>>> > E=JavaVMOption >>>> > ] >>>> > >>>> > I'm guessing it doesn't like the enum as the generic arg, but >>>> don't know why given that it accepts plain int elsewhere. ??? >>>> >>>> Just suppressing this warning (unconditionally everywhere) would >>>> probably make sense. >>>> >>>> Microsoft describes it as an obsolete warning: >>>> >>>> https://msdn.microsoft.com/en-us/library/wewb47ee.aspx >>>> >>>> "This warning is obsolete. It is only generated in Visual Studio >>>> 2005 through Visual Studio 2012. It reports a behavior change from >>>> the Visual C++ compiler that shipped in Visual Studio .NET when >>>> initializing a POD (plain old data) object with (); the compiler >>>> default-initializes the object.? >>>> >>>> It?s too bad the JDK9 supported build platform for Windows is still >>>> lagging. >>>> >>>> >>>> > From thomas.stuefe at gmail.com Fri Mar 27 08:58:45 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 09:58:45 +0100 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <55132D2B.3060502@oracle.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> <551327A3.7050007@oracle.com> <55132C67.3040808@oracle.com> <55132D2B.3060502@oracle.com> Message-ID: Hi, could this break zero? I try to build zero and get the following build error: /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?: /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:33: error: label ?opc_nofast_getfield? used but not defined /* 0xE8 */ &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, &&opc_nofast_aload_0, ^ /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:55: error: label ?opc_nofast_putfield? used but not defined /* 0xE8 */ &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, &&opc_nofast_aload_0, ^ /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:78: error: label ?opc_nofast_aload_0? used but not defined /* 0xE8 */ &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, &&opc_nofast_aload_0, ^ /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:582:14: error: label ?opc_nofast_iload? used but not defined /* 0xEC */ &&opc_nofast_iload,&&opc_default, &&opc_default, &&opc_default, ^ make[8]: *** [bytecodeInterpreter.o] Error 1 I build with a very unexciting configure line: bash ../sources/configure --with-boot-jdk=/shared/projects/sapjvm_8 --with-jvm-variants=zero on Ubuntu 14.4. Reverting back before this change makes the build go through (save for the printf() format issue in frame_zero.cpp which Colleen fixed in a later patch). Am I building wrong? Kind Regards, Thomas On Wed, Mar 25, 2015 at 10:48 PM, Yumin Qi wrote: > Thanks for your review! > > Yumin > > > On 3/25/2015 2:45 PM, Coleen Phillimore wrote: > >> >> Yumin, >> >> This looks great. You addressed my earlier pre-review comments. >> >> There are two other architectures now, that I don't believe we build and >> test. I think it's only cpu code that would be changed so the fixes for >> these architectures won't need a sponsor. >> >> Zero doesn't support CDS so I think the minimal changes you've put in >> bytecodeInterpreter.cpp are good. >> >> Thanks! >> Coleen >> >> >> On 3/25/15, 5:24 PM, Yumin Qi wrote: >> >>> Hi, Coleen >>> >>> New version based on Ioi's suggestion is located at: >>> http://cr.openjdk.java.net/~minqi/8074345/webrev03/ >>> >>> Test: JPRT. Manual test on -Xshare:[dump | on ] >>> >>> Thanks >>> Yumin >>> >>> On 3/25/2015 9:58 AM, Coleen Phillimore wrote: >>> >>>> >>>> Yes, this was on my to-do list, sorry I haven't gotten to it yet. >>>> Coleen >>>> >>>> On 3/25/15, 12:38 PM, Ioi Lam wrote: >>>> >>>>> Hi Yumin, >>>>> >>>>> The changes look good. Just a few nits: >>>>> >>>>> *src/share/vm/interpreter/bytecodes.hpp:** >>>>> * >>>>> 293 // Rewritten at CDS dump time to | Original bytecode >>>>> 294 // _invoke_virtual rewritten on sparc, will be disabled if >>>>> UseSharedSpaces turned on. >>>>> 295 // ------------------------------+------------------ >>>>> 296 _nofast_getfield , // <- _getfield >>>>> 297 _nofast_putfield , // <- _putfield >>>>> 298 _nofast_aload_0 , // <- _aload_0 >>>>> 299 _nofast_iload , // <- _iload >>>>> >>>>> I think it should be reformatted to line up the columns: >>>>> >>>>> 293 // Rewritten at CDS dump time to | Original bytecode >>>>> 295 // ------------------------------+------------------ >>>>> 296 _nofast_getfield , // <- _getfield >>>>> 297 _nofast_putfield , // <- _putfield >>>>> 298 _nofast_aload_0 , // <- _aload_0 >>>>> 299 _nofast_iload , // <- _iload >>>>> 230 // NOTE: _invoke_virtual is rewritten only on sparc. This will >>>>> be disabled if >>>>> // UseSharedSpaces turned on. >>>>> >>>>> *src/share/vm/interpreter/rewriter.cpp:* >>>>> >>>>> There are many places that modify the Method object. Instead of >>>>> putting asserts at all the places where an actual modification happens, I >>>>> think it's better to use only one assert at the Rewriter entry point, and >>>>> remove the other assets that you added: >>>>> >>>>> 516 void Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { >>>>> + if (!DumpSharedSpaces) { >>>>> + assert(!MetaspaceShared::is_in_shared_space(klass()), "archive >>>>> methods must not be rewritten at run time"); >>>>> + } >>>>> 517 ResourceMark rm(THREAD); >>>>> 518 Rewriter rw(klass, klass->constants(), klass->methods(), >>>>> CHECK); >>>>> 519 // (That's all, folks.) >>>>> 520 } >>>>> >>>>> Also, I am not sure if the PPC directories in the repo have been >>>>> 'locked' or not, but I guess you will find out when you do the push. >>>>> >>>>> I am not a Reviewer, so probably Coleen needs to look at this as well. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> On 3/20/15, 1:53 PM, Yumin Qi wrote: >>>>> >>>>>> Hi, Coleen and all >>>>>> >>>>>> New version with suggested changes can be reviewed at: >>>>>> http://cr.openjdk.java.net/~minqi/8074345/webrev02/ >>>>>> >>>>>> Removed _fast_invokeinvirtual from last version, disable rewriting >>>>>> _invokevirtual if UseSharedSpaces turned on. Only on sparc _invokevirtual >>>>>> got rewritten. Other platforms as unimplemented. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/11/2015 1:23 PM, Yumin Qi wrote: >>>>>> >>>>>>> Thanks, I will have another webrev after build/test/perf test. >>>>>>> >>>>>>> Yumin >>>>>>> >>>>>>> On 3/11/2015 1:11 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi Yumin, One comment embedded. >>>>>>>> >>>>>>>> On 3/11/15, 2:04 PM, Yumin Qi wrote: >>>>>>>> >>>>>>>>> Hi, Coleen >>>>>>>>> >>>>>>>>> Thanks for the review. See embedded. >>>>>>>>> >>>>>>>>> On 3/10/2015 2:54 PM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yumin, >>>>>>>>>> >>>>>>>>>> The new bytecode approach came out pretty cleanly, or as cleanly >>>>>>>>>> as this could be. >>>>>>>>>> >>>>>>>>>> The file templateTable_x86_32 and 64 have just been merged, so >>>>>>>>>> you'll have to make your change in the new version. >>>>>>>>>> >>>>>>>>>> I also have some comments: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/ >>>>>>>>>> interpreter/rewriter.cpp.udiff.html >>>>>>>>>> >>>>>>>>>> Typo "rewirting" >>>>>>>>>> >>>>>>>>>> Sure. >>>>>>>>> >>>>>>>>>> In these files, can you break up the long lines into three lines? >>>>>>>>>> >>>>>>>>>> - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, >>>>>>>>>> Rbc, Rscratch); } >>>>>>>>>> + if (!is_static && rc == MAY_REWRITE) { >>>>>>>>>> patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } >>>>>>>>>> >>>>>>>>>> Sure. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/ >>>>>>>>>> interpreter/bytecodes.hpp.udiff.html >>>>>>>>>> >>>>>>>>>> How many bytecodes do we have now? We're limited to 255 (or 256) >>>>>>>>>> and there are other new bytecodes being added. >>>>>>>>>> >>>>>>>>>> now total is 234 (after the fix). See below answer. >>>>>>>>> >>>>>>>>>> What was the performance benefit to this? I think if we wanted >>>>>>>>>> to be conservative, we'd turn off RewriteFrequentPairs and only do >>>>>>>>>> nofast_getfield and nofast_putfield. I think they were the only bytecodes >>>>>>>>>> that actually affected performance. >>>>>>>>>> >>>>>>>>>> In this file above, can you remove the last block of comments >>>>>>>>>> about fast_linearswitch and fast_ldc? I think this confuses rewriting in >>>>>>>>>> the interpreter and rewriting in the rewriter, or rather makes the >>>>>>>>>> confusion worse. I don't think this comment is helpful. >>>>>>>>>> >>>>>>>>>> I'd prefer to see the first comment smaller also, like: >>>>>>>>>> >>>>>>>>>> + // These bytecodes are rewritten at CDS dump time, so that >>>>>>>>>> we can prevent them from being >>>>>>>>>> + // rewritten at run time. This way, the ConstMethods can be >>>>>>>>>> placed in the CDS ReadOnly >>>>>>>>>> + // section, and RewriteByteCodes/RewriteFrequentPairs can >>>>>>>>>> rewrite non-CDS bytecodes >>>>>>>>>> + // at run time. >>>>>>>>>> + _nofast_getfield , >>>>>>>>>> + _nofast_putfield , >>>>>>>>>> + _nofast_aload_0 , >>>>>>>>>> + _nofast_iload , >>>>>>>>>> + _nofast_invokevirtual , >>>>>>>>>> >>>>>>>>>> It's sort of obvious which bytecode they rewrite. I don't know >>>>>>>>>> how much performance fast_invokevfinal is worth. I thought I deleted it. >>>>>>>>>> Can we not rewrite this so we don't waste another bytecode on it? Maybe >>>>>>>>>> add a RewriteVFinal option and consider removing it for the future? x86 >>>>>>>>>> doesn't use it and I can't see how this would save any significant >>>>>>>>>> performance to be worth having! >>>>>>>>>> >>>>>>>>>> _invokevirtual got rewritten on sparc and ppc. Now ppc is >>>>>>>>> removed, no need to take care for it. For sparc, it does patch code. I am >>>>>>>>> thinking of a way if we need to add _nofast_code as you indicated, we only >>>>>>>>> have 255 codes to use. >>>>>>>>> >>>>>>>> >>>>>>>> PPC isn't removed from the open repository. >>>>>>>> >>>>>>>>> >>>>>>>>> bool not_rewrite = UseSharedSpaces && RewriteBytecodes && >>>>>>>>> RewriteFrequentPair; >>>>>>>>> >>>>>>>> >>>>>>>> I think the conditional would be >>>>>>>> >>>>>>>> bool not_rewrite = UseSharedSpaces || !RewriteBytecodes; >>>>>>>> >>>>>>>>> >>>>>>>>> Can this boolean decide if we not rewrite the bytecode to fast? >>>>>>>>> If so, I can remove all the _nofast_code and do not patch code when it is >>>>>>>>> on. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, this would be nice to not add the bytecode. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/ >>>>>>>>>> interpreter/templateTable.hpp.udiff.html >>>>>>>>>> >>>>>>>>>> + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // >>>>>>>>>> control for fast code under CDS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't know what our coding standard is but in the >>>>>>>>>> templateTable_.cpp files these strings look like macros. I'd rather >>>>>>>>>> see them as MayRewrite or MayNotRewrite. >>>>>>>>>> >>>>>>>>>> Agree. >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/ >>>>>>>>>> vm/templateTable_sparc.cpp.udiff.html >>>>>>>>>> >>>>>>>>>> I think there's a java_code() function that returns the original >>>>>>>>>> bytecode that you could use instead of the case statement in >>>>>>>>>> resolve_cache_and_index(). The indentation is odd in the webrev. This >>>>>>>>>> probably applies to the other cpu directories. >>>>>>>>>> >>>>>>>>>> One last question below: >>>>>>>>>> >>>>>>>>>> On 3/5/15, 4:21 PM, Yumin Qi wrote: >>>>>>>>>> >>>>>>>>>>> Please review: >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074345 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~minqi/8074345/ >>>>>>>>>>> >>>>>>>>>>> Summary: Currently CDS when is disabled, RewriteBytecodes and >>>>>>>>>>> RewriteFrequentPairs are disabled due to ConstantMethod in CDS are mapped >>>>>>>>>>> read only. So memory fault will be triggered when RewriteBytecodes turned >>>>>>>>>>> on. This also disable all method rewritten, leads interpreter run slower. >>>>>>>>>>> Observed about 2% regression with C2 on some benchmarks, since interpreter >>>>>>>>>>> speed is important to C2. By enable RewriteBytecodes and >>>>>>>>>>> RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for >>>>>>>>>>> corresponding fast codes at dump time to avoid byte code rewritten at run >>>>>>>>>>> time, we prevent byte code rewritten and modify the read only shared >>>>>>>>>>> portion in CDS. Meanwhile other byte codes with fast codes still get speed >>>>>>>>>>> up. >>>>>>>>>>> >>>>>>>>>>> Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all >>>>>>>>>>> supported platforms. Interpreter only tests showed about 3% improvement. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What performance did you measure? Is it -Xint -Xshare:on with >>>>>>>>>> and without your patch? It was only 3% better? >>>>>>>>>> >>>>>>>>>> What was the difference in performance with -Xint >>>>>>>>>> -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? >>>>>>>>>> I thought this was around 15%. >>>>>>>>>> >>>>>>>>>> I will send you a separate email of the links which run with >>>>>>>>> CDS/NoCDS/CDS+Int >>>>>>>>> >>>>>>>> >>>>>>>> Thanks for the links. From your experiments, I think your >>>>>>>> performance improvement with your patch and CDS with -Xmixed is 4%. That's >>>>>>>> good enough for a couple of bytecodes. >>>>>>>> >>>>>>>> Coleen >>>>>>>> >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From thomas.stuefe at gmail.com Fri Mar 27 09:13:10 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 10:13:10 +0100 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5512FA41.3020008@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> <55106018.3020005@oracle.com> <5512FA41.3020008@oracle.com> Message-ID: Hi Yumin, still looks fine. Kind Regards, Thomas On Wed, Mar 25, 2015 at 7:11 PM, Yumin Qi wrote: > Hi, all > > I updated the webrev with a new change to test case: > test/runtime/Unsafe/RangeCheck.java > > Add -XX:-CreateCoredumpOnCrash to test, no dump needed on this case. > > new webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev05/ > > Thanks > Yumin > > > > On 3/23/2015 11:48 AM, Yumin Qi wrote: > >> Since Thomas is not a reviewer in open jdk, I need two volunteers (at >> least one "R"eviewer). >> >> Dan, since you already reviewed previous version, could you have a look? >> >> Thanks >> Yumin >> >> On 3/20/2015 3:20 PM, Yumin Qi wrote: >> >>> Thomas, >>> >>> Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add >>> another test case change: test/runtime/memory/ReadFromNoaccessArea.java >>> (Thanks Dan's update) >>> >>> Thanks >>> Yumin >>> >>> On 3/20/2015 11:55 AM, Thomas St?fe wrote: >>> >>>> >>>> Hi Yumin, >>>> >>>> I think you meant to post webrev.04? >>>> >>>> I looked at 04, and it looks nice. Thank you! >>>> >>>> (still only reviewer with r) >>>> >>>> Thomas >>>> >>>> On Mar 20, 2015 6:20 PM, "Yumin Qi" >>> yumin.qi at oracle.com>> wrote: >>>> >>>> Hi, All >>>> >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>> >>>> >>>> This version is based on Thomas' suggestion. >>>> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/18/2015 10:06 AM, Yumin Qi wrote: >>>> >>>> >>>> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >>>> >>>> Hi Yumin, >>>> >>>> - just aesthetics, but on all implementations of >>>> os_abort(), at least on the UNIX variants, maybe we could >>>> consistently rename the parameters to be "siginfo" and >>>> "context" instead of using Windows terms? >>>> >>>> Sure. >>>> >>>> - On check_create_dump_limit(), you do not need >>>> exceptionRecord, contextRecord parameters anymore. The >>>> only parameters now needed are buffer and buffer size, >>>> which is not even an output parameter, just a scratch >>>> buffer for this function to use for printf. For output, it >>>> calls VMError::report_coredump_status(...) at the end to >>>> provide information about the core file. >>>> >>>> - I would rename that function from >>>> check_create_dump_limit() to check_dump_limit() - nothing >>>> is created anymore. >>>> >>>> Yes, no need to carry those two parameters. I tried to keep >>>> less changes, but decided to change now. >>>> >>>> - on Windows, in os::abort(), there is no point anymore in >>>> calling VMError::report_coredump_status(...) because that >>>> information is only used during error log writing which >>>> already happened. It only makes sense to call this >>>> function in check_create_dump_limit(), which happens >>>> before error log writing. >>>> Instead, maybe error messages like "Call to >>>> MiniDumpWriteDump() failed" should just be written to >>>> stderr? This would be consistent with Unix, where the OS >>>> writes a short message on stderr if core file writing fails. >>>> >>>> Sure, will direct output to stderr. >>>> >>>> - there is now a new test, >>>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>>> - could you please also add "-XX:-CreateCoredumpOnCrash" ? >>>> I just added the test and did not want to add the option >>>> before it was available. >>>> >>>> OK >>>> >>>> Thanks >>>> Yumin >>>> >>>> Thanks for your work! >>>> >>>> Thomas >>>> >>>> >>>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >>>> >>>> >> >>>> wrote: >>>> >>>> Hi, Dan and all >>>> >>>> I have updated webrev at: >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>> >>>> >>>> >>>> 1) bug changed synopsis >>>> 8074354: Make CreateMinidumpOnCrash a new name >>>> and >>>> available on all platforms >>>> 2) tests: JPRT, vm.runtime.quick.testlist (on >>>> Windows), jtreg on >>>> Windows and Linux/Unix. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>>> >>>> I believe there are both JavaTest/JTREG tests in >>>> the hotspot repo >>>> and there are VM/NSK tests from back when we did >>>> phone home... >>>> >>>> Check with Christian or Misha... >>>> >>>> Dan >>>> >>>> >>>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>>> >>>> Thanks, Dan >>>> >>>> Will look at and run those tests. Are they >>>> under nsk? >>>> >>>> Yumin >>>> >>>> On 3/12/2015 12:29 PM, Daniel D. Daugherty >>>> wrote: >>>> >>>> Yumin, >>>> >>>> There are some error handler tests. You >>>> should find >>>> those and make >>>> sure that you run them on Windows since >>>> you're >>>> changing the order >>>> there... >>>> >>>> Dan >>>> >>>> >>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>> >>>> Hi, Thomas and all >>>> >>>> The second version of the change: >>>> webrev: >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>> >>>> >>>> >>>> In this version: >>>> 1) switch order on Windows to first >>>> print log >>>> file as other platform, then dump core >>>> file if >>>> needed. When VMError created after >>>> crash, siginfo >>>> and context which are ExceptionRecord >>>> and >>>> ContextRecord on Windows are recorded, >>>> mini (or >>>> full, due to 'or' used so type will be >>>> mini >>>> anyway) dump creates dump file based >>>> on those two >>>> as before. >>>> 2) to make os::abort to get above >>>> two pointers, >>>> added two more fields to the function >>>> parameters: >>>> 3) changes for >>>> test/runtime/ErrorHandling/SecondaryError.java --- >>>> added "-XX:-CreateCoredumpOnCrash" >>>> >>>> - static void abort(bool >>>> dump_core = true); >>>> + static void abort(bool dump_core >>>> = true, >>>> void *siginfo = NULL, void *context = >>>> NULL); >>>> >>>> Tests: JPRT and manually. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/11/2015 3:47 AM, Thomas St?fe >>>> wrote: >>>> >>>> Hi Yumin, >>>> >>>> There is also >>>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>>> - could you please add >>>> "-XX:-CreateCoredumpOnCrash" ? >>>> Thank you! >>>> >>>> Beyond that, as I wrote in the bug >>>> report >>>> comments: >>>> >>>> "This is also a problem on Windows - >>>> MiniDumpWriteDump() may hang >>>> infinitly. And on >>>> Windows this is worse than under >>>> UNIX because >>>> we create the Dump before writing >>>> the hs-err >>>> file, so if the Dump hangs, we get >>>> no error >>>> log. I would like to revert the >>>> order: create >>>> the minidump after writing the >>>> error log, the >>>> same way Unix does it. We did this >>>> in our JVM >>>> (SAP) because for us, error logs >>>> are more >>>> useful than minidumps. " >>>> >>>> So, I would like to see os::abort >>>> on Windows >>>> call MiniDumpWriteDump(), and thus >>>> the mini >>>> dump writing moved after the error >>>> log >>>> writing. This would also make the >>>> code way >>>> cleaner because the control flow >>>> would be the >>>> same on all platforms. >>>> >>>> I understand that this may be out >>>> of scope for >>>> your change, but I would like to >>>> know what >>>> others think about this. >>>> >>>> Kind regards, Thomas >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Mar 11, 2015 at 8:02 AM, >>>> Yumin Qi >>>> >>> >>>> >>> > >>>> >>> >>>> >>> >>> wrote: >>>> >>>> Please review: >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>>> webrev: >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>> >>>> >>>> >>>> >>>> Summary: Tests timed out when >>>> VM crashes >>>> and dumping core file >>>> which in the test case is not >>>> needed. To >>>> make core not created, >>>> the fix changed >>>> CreateMinidumpOnCrash to >>>> CreateCoredumpOnCrash, >>>> the former is only used on >>>> Windows and the >>>> latter for all >>>> platforms. When VM crashes on >>>> non Windows, >>>> core file generated as >>>> default if OS sets core dump >>>> allowed. >>>> Default value of >>>> CreateCoredumpOnCrash set to >>>> 'true' to >>>> keep same behavior on non >>>> Windows platforms, but changed >>>> for Windows >>>> --- original is false, >>>> not create minidump on >>>> Windows. With >>>> CreateCoredumpOnCrash turned >>>> off, no core file will be >>>> generated. >>>> CreateMinidumpOnCrash still >>>> can be used on commandline but >>>> only as >>>> alias for the new flag. >>>> >>>> Tests: JPRT, manual tests >>>> setting >>>> CreateMinidumpOnCrash on >>>> commandline to verify flag >>>> change as alias. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > From thomas.stuefe at gmail.com Fri Mar 27 09:16:53 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 10:16:53 +0100 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> <5c66c663-9106-427e-830a-2585f45ab906@default> Message-ID: Posting this to hotspot-dev in the hope of attracting one more reviewer and a sponsor. Th,ank you, Thomas On Wed, Mar 25, 2015 at 5:20 PM, Thomas St?fe wrote: > ping... > > I still need a sponsor and another reviewer for this issue. Thank you! > > Thomas > > On Wed, Mar 18, 2015 at 11:13 AM, Thomas St?fe > wrote: > >> Hi Markus, >> >> the way to do this cleanly would be to use Vectored Exceptions, which >> would give us the same control flow as on Unix signal. However, Vectored >> Exception handling was explicitly removed from the hotspot ages ago. >> I guess because too many third party libraries install their own VE >> handlers. >> >> To all: I still need one more reviewer and a sponsor. Thanks! >> >> Thomas >> >> >> On Tue, Mar 17, 2015 at 9:40 AM, Markus Gronlund < >> markus.gronlund at oracle.com> wrote: >> > >> > I don?t think it is worth it. But thanks for thinking about it. >> > >> > >> > >> > I was thinking if we could maybe do some callback trickery to set up >> the SEH in Windows specific code only inside Threads::create_vm() ? but >> again, probably not worth it. >> > >> > >> > >> > I am ok with the suggestion as it stands. >> > >> > >> > >> > /Markus >> > >> > >> > >> > >> > >> > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> > Sent: den 17 mars 2015 09:34 >> > To: Markus Gronlund >> > Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes >> > >> > >> > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >> around CreateJavaVM on Windows >> > >> > >> > >> > Hi Markus, David, >> > >> > >> > >> > thanks for reviewing this! >> > >> > >> > >> > yes, I also do not like the #ifdefs _WIN32. >> > >> > >> > >> > We could pretty it up a bit with macros: >> > >> > >> > >> > #define GUARD_SEH_START __try { >> > >> > #define GUARD_SEH_END } __except... >> > >> > >> > >> > and defining those empty on non-windows platforms? >> > >> > >> > >> > What do you think? >> > >> > >> > >> > Kind Regards, Thomas >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund < >> markus.gronlund at oracle.com> wrote: >> > >> > Hi Thomas, >> > >> > This looks good, thank you for fixing this! >> > >> > I didn't know that the entire Threads::create_vm() routine is currently >> unguarded - interesting. >> > >> > Small point: I agree with David about the annoyance of having platform >> specific #ifdefs in the shared code, but I can't find any other position >> where we could solve this better (we still need to reach through to the >> ExceptionFilter). >> > >> > Let me know when you start to dig into the SEH (or lack of) for >> attaching threads :-) >> > >> > Thanks again >> > Markus >> > >> > >> > -----Original Message----- >> > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >> > Sent: den 16 mars 2015 12:32 >> > To: David Holmes >> > Cc: hotspot-runtime-dev at openjdk.java.net >> > Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >> around CreateJavaVM on Windows >> > >> > Hi, >> > >> > I still need one or two reviewers and a sponsor. >> > >> > Thank you! >> > >> > Thomas >> > >> > On Thu, Mar 12, 2015 at 10:41 AM, David Holmes > > >> > wrote: >> > >> > > Hi Thomas, >> > > >> > > Thanks for the added info. I have no further comments. Hopefully >> > > someone with SEH knowledge will also respond. >> > > >> > > David >> > > >> > > On 12/03/2015 7:18 PM, Thomas St?fe wrote: >> > > >> > >> Hi David, >> > >> >> > >> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes >> > >> > wrote: >> > >> >> > >> On 12/03/2015 8:03 AM, Thomas St?fe wrote: >> > >> >> > >> Hi David, >> > >> >> > >> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >> > >> >> > >> > > >> >> > >> >> wrote: >> > >> >> > >> Hi Thomas, >> > >> >> > >> I'm not really familiar with Windows SEH. Won't this >> break >> > >> custom >> > >> launchers that already provide their own try/catch >> around >> > >> Crate_JavaVM ? >> > >> >> > >> >> > >> No. Windows SEH works stack based: any exception - e.g. a >> crash - >> > >> between __try and __except will be handled by the handler >> given >> > >> in the >> > >> __except clause. Because they are stack based, they can be >> > >> nested. If an >> > >> exception is raised inside the inner __try/__except, first >> > >> the inner >> > >> handler is used, if that one feels not responsible, the next >> > >> outer one >> > >> and so on. >> > >> >> > >> With my fix, any exception raised inside CreateJavaVM will be >> > >> handler by >> > >> our handler topLevelExceptionFilter; only if our handler >> feels not >> > >> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >> > >> handler will >> > >> be called. >> > >> >> > >> >> > >> My lack of knowledge about when our handler "feels responsible" >> > >> still leaves me a little nervous here. :) >> > >> >> > >> >> > >> I think the patch is quite safe. I added this patch to our code base >> > >> in >> > >> 2011 and since then this is active in productive code for SAP >> customers. >> > >> The SAP jvm gets heavily used with custom launchers which do their >> > >> own error handling, so this is a well tested scenario. >> > >> >> > >> I would like to get a similar signal handling coverage as on UNIX: >> > >> >> > >> On Unix, we have global signal handling. The moment signal handling >> > >> is established early in os::init(), every signal from everywhere is >> > >> covered, even user code. We even have to take care that user handlers >> > >> get also in the loop via signal chaining, libjsig.so etc. >> > >> >> > >> On Windows, it is the other way around: we have stack based signal >> > >> handling , so we need __try/__except on every thread, and this means >> > >> there are parts of jvm code which run without signal handling: >> > >> - the whole initialization >> > >> - attached threads (I think?) >> > >> which means that on those cases, user handler gets signals which the >> > >> libjvm should handle. >> > >> >> > >> This was "fixed" partly by surrounding small code which we know >> > >> beforehand causes signals - how convenient - with __try/__except. For >> > >> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >> > >> crash. But you want error handling to always work. I also do not know >> > >> if stuff like polling pages, implicit nulltests etc could be used in >> > >> unprotected code. >> > >> >> > >> As a side note, there is a UNIX-like signal handling mode on Windows >> > >> too, "vectored exception handling", which was used in the jvm but >> > >> removed some time ago for reasons I do not really know. >> > >> >> > >> Any exception raised in the launcher itself outside of >> > >> CreateJavaVM will >> > >> still be handled by the user handler. >> > >> >> > >> (And I hate seeing the win32 ifdefs in the shared code >> :( ). >> > >> >> > >> >> > >> Yes I know, I kind of expected that feedback :( - I did not >> find a >> > >> better way of doing this. One could try to hide the >> __try/__except >> > >> behind macros, but that would be kind of unwieldy and I >> don't like >> > >> abstractiing something which only has meaning on one >> platform. >> > >> >> > >> >> > >> Does it help if we make the caller responsible for SEH and then >> put >> > >> the try/catch in the launcher code (hopefully in a windows >> specific >> > >> part thereof) ? >> > >> >> > >> >> > >> No, because the caller would need access to "topLevelExceptionFilter" >> > >> - you would need to export that function from the libjvm and then >> > >> tell the caller "always call topLevelExceptionFilter() if a signal >> > >> happens on Windows", which is quite awkward and different than on >> UNIX. >> > >> >> > >> Thomas >> > >> >> > >> Thanks, >> > >> David >> > >> >> > >> >> > >> Thanks, >> > >> David >> > >> >> > >> >> > >> >> > >> Kind regards, Thomas >> > >> >> > >> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >> > >> >> > >> Hi all, >> > >> >> > >> please review this smallish change: >> > >> >> > >> webrev: >> > >> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >> > >> webrev.____01/webrev/ >> > >> > > >> webrev.__01/webrev/> >> > >> >> > >> > > >> webrev.__01/webrev/ >> > >> > > >> 01/webrev/>> >> > >> bug: >> > >> https://bugs.openjdk.java.net/____browse/JDK-8074860 >> > >> >> > >> >> > >> > > >> >> > >> > >> > >> >> > >> This change adds SEH guards around >> JNI_CreateJavaVM(). >> > >> Without >> > >> the change, >> > >> on Windows, the VM initialization runs without crash >> > >> protection: >> > >> crashes >> > >> will terminate VM immediately without writing an >> > >> error log; >> > >> also, any >> > >> techniques relying on signals will not work, e.g. >> > >> SafeFetch(). >> > >> >> > >> This was partly solved before on a case-by-case >> base by >> > >> wrapping >> > >> code >> > >> sections which may crash in their own __try/__except >> > >> wrappers - >> > >> e.g. CPU >> > >> feature probing. >> > >> >> > >> The change guards the whole of JNI_CreateJavaVM >> > >> invocation in >> > >> __try/__except. Unfortunately, for that to compile, >> I >> > >> needed to >> > >> introduce a >> > >> wrapper around JNI_CreateJavaVM and move the whole >> of >> > >> JNI_CreateJavaVM to a >> > >> new function "JNI_CreateJavaVM_inner". >> > >> >> > >> This fix also gets rid of various workarounds which >> > >> were used >> > >> before to >> > >> guard code sections. >> > >> >> > >> Thanks for reviewing! >> > >> >> > >> Oh, on a side note: I tried to figure out if threads >> > >> which are >> > >> attached >> > >> from the outside via JNI AttachCurrentThread() are >> in >> > >> any way >> > >> guarded with >> > >> SEH protection. Newly created threads are guarded >> > >> because they >> > >> run thru >> > >> java_start() in os_windows.cpp, which adds SEH >> guards >> > >> to all >> > >> frames below. >> > >> But for attached threads, I did not find any SEH >> guards >> > >> - or >> > >> maybe I am >> > >> blind? What does that mean for java code running >> inside >> > >> attached >> > >> threads? >> > >> >> > >> Regards, >> > >> >> > >> Thomas Stuefe >> > >> >> > >> >> > >> >> > >> >> > >> > >> > > From sgehwolf at redhat.com Fri Mar 27 09:48:07 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Mar 2015 10:48:07 +0100 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> <551327A3.7050007@oracle.com> <55132C67.3040808@oracle.com> <55132D2B.3060502@oracle.com> Message-ID: <1427449687.3497.16.camel@redhat.com> Hi, On Fri, 2015-03-27 at 09:58 +0100, Thomas St?fe wrote: > Hi, > > > could this break zero? I try to build zero and get the following build > error: > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?: > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:33: error: label ?opc_nofast_getfield? used but not defined > /* 0xE8 */ > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > &&opc_nofast_aload_0, > ^ > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:55: error: label ?opc_nofast_putfield? used but not defined > /* 0xE8 */ > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > &&opc_nofast_aload_0, > ^ > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:78: error: label ?opc_nofast_aload_0? used but not defined > /* 0xE8 */ > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > &&opc_nofast_aload_0, > > ^ > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:582:14: error: label ?opc_nofast_iload? used but not defined > /* 0xEC */ &&opc_nofast_iload,&&opc_default, &&opc_default, > &&opc_default, > ^ > make[8]: *** [bytecodeInterpreter.o] Error 1 > > > > > I build with a very unexciting configure line: > > > bash ../sources/configure --with-boot-jdk=/shared/projects/sapjvm_8 > --with-jvm-variants=zero > > > > on Ubuntu 14.4. > > > Reverting back before this change makes the build go through (save for > the printf() format issue in frame_zero.cpp which Colleen fixed in a > later patch). > > > Am I building wrong? I have Zero (slowdebug) building fine on F21 with java-1.8.0-openjdk as boot JDK. This is revision 2206bbeb3185, so includes Coleen's fix and 8074345. $ ../build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -version openjdk version "1.9.0-internal-debug" OpenJDK Runtime Environment (build 1.9.0-internal-debug-sgehwolf_2015_03_26_10_51-b00) OpenJDK 64-Bit Zero VM (build 1.9.0-internal-debug-sgehwolf_2015_03_26_10_51-b00, interpreted mode) Did you do make dist-clean? Could this be product build only problem? Cheers, Severin > On Wed, Mar 25, 2015 at 10:48 PM, Yumin Qi > wrote: > Thanks for your review! > > Yumin > > > On 3/25/2015 2:45 PM, Coleen Phillimore wrote: > > Yumin, > > This looks great. You addressed my earlier pre-review > comments. > > There are two other architectures now, that I don't > believe we build and test. I think it's only cpu > code that would be changed so the fixes for these > architectures won't need a sponsor. > > Zero doesn't support CDS so I think the minimal > changes you've put in bytecodeInterpreter.cpp are > good. > > Thanks! > Coleen > > > On 3/25/15, 5:24 PM, Yumin Qi wrote: > Hi, Coleen > > New version based on Ioi's suggestion is > located at: > http://cr.openjdk.java.net/~minqi/8074345/webrev03/ > > Test: JPRT. Manual test on -Xshare:[dump | > on ] > > Thanks > Yumin > > On 3/25/2015 9:58 AM, Coleen Phillimore wrote: > > Yes, this was on my to-do list, sorry > I haven't gotten to it yet. > Coleen > > On 3/25/15, 12:38 PM, Ioi Lam wrote: > Hi Yumin, > > The changes look good. Just a > few nits: > > *src/share/vm/interpreter/bytecodes.hpp:** > * > 293 // Rewritten at CDS > dump time to | Original > bytecode > 294 // _invoke_virtual > rewritten on sparc, will be > disabled if UseSharedSpaces > turned on. > 295 // > ------------------------------+------------------ > 296 _nofast_getfield > , // <- _getfield > 297 _nofast_putfield > , // <- _putfield > 298 _nofast_aload_0 > , // <- _aload_0 > 299 _nofast_iload > , // <- _iload > > I think it should be > reformatted to line up the > columns: > > 293 // Rewritten at CDS > dump time to | Original > bytecode > 295 // > ------------------------------+------------------ > 296 _nofast_getfield > , // <- _getfield > 297 _nofast_putfield > , // <- _putfield > 298 _nofast_aload_0 > , // <- _aload_0 > 299 _nofast_iload > , // <- _iload > 230 // NOTE: > _invoke_virtual is rewritten > only on sparc. This will be > disabled if > // UseSharedSpaces > turned on. > > *src/share/vm/interpreter/rewriter.cpp:* > > There are many places that > modify the Method object. > Instead of putting asserts at > all the places where an actual > modification happens, I think > it's better to use only one > assert at the Rewriter entry > point, and remove the other > assets that you added: > > 516 void > Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { > + if (!DumpSharedSpaces) > { > + assert(! > MetaspaceShared::is_in_shared_space(klass()), "archive methods must not be rewritten at run time"); > + } > 517 ResourceMark rm(THREAD); > 518 Rewriter rw(klass, > klass->constants(), > klass->methods(), CHECK); > 519 // (That's all, folks.) > 520 } > > Also, I am not sure if the PPC > directories in the repo have > been 'locked' or not, but I > guess you will find out when > you do the push. > > I am not a Reviewer, so > probably Coleen needs to look > at this as well. > > Thanks > - Ioi > > On 3/20/15, 1:53 PM, Yumin Qi > wrote: > Hi, Coleen and all > > New version with > suggested changes can > be reviewed at: > http://cr.openjdk.java.net/~minqi/8074345/webrev02/ > > Removed > _fast_invokeinvirtual > from last version, > disable rewriting > _invokevirtual if > UseSharedSpaces turned > on. Only on sparc > _invokevirtual got > rewritten. Other > platforms as > unimplemented. > > Thanks > Yumin > > On 3/11/2015 1:23 PM, > Yumin Qi wrote: > Thanks, I will > have another > webrev after > build/test/perf test. > > Yumin > > On 3/11/2015 > 1:11 PM, > Coleen > Phillimore > wrote: > > Hi > Yumin, > One > comment embedded. > > On > 3/11/15, 2:04 PM, Yumin Qi wrote: > Hi, Coleen > > > Thanks for the review. See embedded. > > On 3/10/2015 2:54 PM, Coleen Phillimore wrote: > > Yumin, > > The new bytecode approach came out pretty cleanly, or as cleanly as this could be. > > The file templateTable_x86_32 and 64 have just been merged, so you'll have to make your change in the new version. > > I also have some comments: > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html > > Typo "rewirting" > > Sure. > In these files, can you break up the long lines into three lines? > > - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } > + if (!is_static && rc == MAY_REWRITE) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } > > Sure. > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html > > How many bytecodes do we have now? We're limited to 255 (or 256) and there are other new bytecodes being added. > > now total is 234 (after the fix). See below answer. > What was the performance benefit to this? I think if we wanted to be conservative, we'd turn off RewriteFrequentPairs and only do nofast_getfield and nofast_putfield. I think they were the only bytecodes that actually affected performance. > > In this file above, can you remove the last block of comments about fast_linearswitch and fast_ldc? I think this confuses rewriting in the interpreter and rewriting in the rewriter, or rather makes the confusion worse. I don't think this comment is helpful. > > I'd prefer to see the first comment smaller also, like: > > + // These bytecodes are rewritten at CDS dump time, so that we can prevent them from being > + // rewritten at run time. This way, the ConstMethods can be placed in the CDS ReadOnly > + // section, and RewriteByteCodes/RewriteFrequentPairs can rewrite non-CDS bytecodes > + // at run time. > + _nofast_getfield , > + _nofast_putfield , > + _nofast_aload_0 , > + _nofast_iload , > + _nofast_invokevirtual , > > It's sort of obvious which bytecode they rewrite. I don't know how much performance fast_invokevfinal is worth. I thought I deleted it. Can we not rewrite this so we don't waste another bytecode on it? Maybe add a RewriteVFinal option and consider removing it for the future? x86 doesn't use it and I can't see how this would save any significant performance to be worth having! > > _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, no need to take care for it. For sparc, it does patch code. I am thinking of a way if we need to add _nofast_code as you indicated, we only have 255 codes to use. > > PPC > isn't > removed from the open repository. > > bool not_rewrite = UseSharedSpaces && RewriteBytecodes && RewriteFrequentPair; > > I > think > the > conditional would be > > > bool > not_rewrite = UseSharedSpaces || !RewriteBytecodes; > > Can this boolean decide if we not rewrite the bytecode to fast? If so, I can remove all the _nofast_code and do not patch code when it is on. > > Yes, > this > would > be > nice > to not > add > the > bytecode. > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html > > + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // control for fast code under CDS > > > I don't know what our coding standard is but in the templateTable_.cpp files these strings look like macros. I'd rather see them as MayRewrite or MayNotRewrite. > > Agree. > http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html > > I think there's a java_code() function that returns the original bytecode that you could use instead of the case statement in resolve_cache_and_index(). The indentation is odd in the webrev. This probably applies to the other cpu directories. > > One last question below: > > On 3/5/15, 4:21 PM, Yumin Qi wrote: > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8074345 > webrev: http://cr.openjdk.java.net/~minqi/8074345/ > > Summary: Currently CDS when is disabled, RewriteBytecodes and RewriteFrequentPairs are disabled due to ConstantMethod in CDS are mapped read only. So memory fault will be triggered when RewriteBytecodes turned on. This also disable all method rewritten, leads interpreter run slower. Observed about 2% regression with C2 on some benchmarks, since interpreter speed is important to C2. By enable RewriteBytecodes and RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for corresponding fast codes at dump time to avoid byte code rewritten at run time, we prevent byte code rewritten and modify the read only shared portion in CDS. Meanwhile other byte codes with fast codes still get speed up. > > Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all supported platforms. Interpreter only tests showed about 3% improvement. > > What performance did you measure? Is it -Xint -Xshare:on with and without your patch? It was only 3% better? > > What was the difference in performance with -Xint -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? I thought this was around 15%. > > I will send you a separate email of the links which run with CDS/NoCDS/CDS+Int > > Thanks > for > the > links. > From > your > experiments, I think your performance improvement with your patch and CDS with -Xmixed is 4%. That's good enough for a couple of bytecodes. > > Coleen > > > Thanks > Yumin > Thanks, > Coleen > > > Thanks > Yumin > > > > > > > > > > > > > > From thomas.stuefe at gmail.com Fri Mar 27 10:14:41 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 27 Mar 2015 11:14:41 +0100 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: <1427449687.3497.16.camel@redhat.com> References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> <551327A3.7050007@oracle.com> <55132C67.3040808@oracle.com> <55132D2B.3060502@oracle.com> <1427449687.3497.16.camel@redhat.com> Message-ID: Hi Severin, Could be a product issue. Tried a slowdebug build and my laptop battery just died on me but I believe the Hotspot was built completely before that. .. Thomas On Mar 27, 2015 10:48 AM, "Severin Gehwolf" wrote: > Hi, > > On Fri, 2015-03-27 at 09:58 +0100, Thomas St?fe wrote: > > Hi, > > > > > > could this break zero? I try to build zero and get the following build > > error: > > > > > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: > In static member function ?static void > BytecodeInterpreter::run(interpreterState)?: > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:33: > error: label ?opc_nofast_getfield? used but not defined > > /* 0xE8 */ > > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > > &&opc_nofast_aload_0, > > ^ > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:55: > error: label ?opc_nofast_putfield? used but not defined > > /* 0xE8 */ > > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > > &&opc_nofast_aload_0, > > ^ > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:78: > error: label ?opc_nofast_aload_0? used but not defined > > /* 0xE8 */ > > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > > &&opc_nofast_aload_0, > > > > ^ > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:582:14: > error: label ?opc_nofast_iload? used but not defined > > /* 0xEC */ &&opc_nofast_iload,&&opc_default, &&opc_default, > > &&opc_default, > > ^ > > make[8]: *** [bytecodeInterpreter.o] Error 1 > > > > > > > > > > I build with a very unexciting configure line: > > > > > > bash ../sources/configure --with-boot-jdk=/shared/projects/sapjvm_8 > > --with-jvm-variants=zero > > > > > > > > on Ubuntu 14.4. > > > > > > Reverting back before this change makes the build go through (save for > > the printf() format issue in frame_zero.cpp which Colleen fixed in a > > later patch). > > > > > > Am I building wrong? > > I have Zero (slowdebug) building fine on F21 with java-1.8.0-openjdk as > boot JDK. This is revision 2206bbeb3185, so includes Coleen's fix and > 8074345. > > $ ../build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -version > openjdk version "1.9.0-internal-debug" > OpenJDK Runtime Environment (build > 1.9.0-internal-debug-sgehwolf_2015_03_26_10_51-b00) > OpenJDK 64-Bit Zero VM (build > 1.9.0-internal-debug-sgehwolf_2015_03_26_10_51-b00, interpreted mode) > > Did you do make dist-clean? Could this be product build only problem? > > Cheers, > Severin > > > On Wed, Mar 25, 2015 at 10:48 PM, Yumin Qi > > wrote: > > Thanks for your review! > > > > Yumin > > > > > > On 3/25/2015 2:45 PM, Coleen Phillimore wrote: > > > > Yumin, > > > > This looks great. You addressed my earlier pre-review > > comments. > > > > There are two other architectures now, that I don't > > believe we build and test. I think it's only cpu > > code that would be changed so the fixes for these > > architectures won't need a sponsor. > > > > Zero doesn't support CDS so I think the minimal > > changes you've put in bytecodeInterpreter.cpp are > > good. > > > > Thanks! > > Coleen > > > > > > On 3/25/15, 5:24 PM, Yumin Qi wrote: > > Hi, Coleen > > > > New version based on Ioi's suggestion is > > located at: > > > http://cr.openjdk.java.net/~minqi/8074345/webrev03/ > > > > Test: JPRT. Manual test on -Xshare:[dump | > > on ] > > > > Thanks > > Yumin > > > > On 3/25/2015 9:58 AM, Coleen Phillimore wrote: > > > > Yes, this was on my to-do list, sorry > > I haven't gotten to it yet. > > Coleen > > > > On 3/25/15, 12:38 PM, Ioi Lam wrote: > > Hi Yumin, > > > > The changes look good. Just a > > few nits: > > > > > *src/share/vm/interpreter/bytecodes.hpp:** > > * > > 293 // Rewritten at CDS > > dump time to | Original > > bytecode > > 294 // _invoke_virtual > > rewritten on sparc, will be > > disabled if UseSharedSpaces > > turned on. > > 295 // > > > ------------------------------+------------------ > > 296 _nofast_getfield > > , // <- _getfield > > 297 _nofast_putfield > > , // <- _putfield > > 298 _nofast_aload_0 > > , // <- _aload_0 > > 299 _nofast_iload > > , // <- _iload > > > > I think it should be > > reformatted to line up the > > columns: > > > > 293 // Rewritten at CDS > > dump time to | Original > > bytecode > > 295 // > > > ------------------------------+------------------ > > 296 _nofast_getfield > > , // <- _getfield > > 297 _nofast_putfield > > , // <- _putfield > > 298 _nofast_aload_0 > > , // <- _aload_0 > > 299 _nofast_iload > > , // <- _iload > > 230 // NOTE: > > _invoke_virtual is rewritten > > only on sparc. This will be > > disabled if > > // UseSharedSpaces > > turned on. > > > > > *src/share/vm/interpreter/rewriter.cpp:* > > > > There are many places that > > modify the Method object. > > Instead of putting asserts at > > all the places where an actual > > modification happens, I think > > it's better to use only one > > assert at the Rewriter entry > > point, and remove the other > > assets that you added: > > > > 516 void > > > Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { > > + if (!DumpSharedSpaces) > > { > > + assert(! > > > MetaspaceShared::is_in_shared_space(klass()), "archive methods must not be > rewritten at run time"); > > + } > > 517 ResourceMark rm(THREAD); > > 518 Rewriter rw(klass, > > klass->constants(), > > klass->methods(), CHECK); > > 519 // (That's all, folks.) > > 520 } > > > > Also, I am not sure if the PPC > > directories in the repo have > > been 'locked' or not, but I > > guess you will find out when > > you do the push. > > > > I am not a Reviewer, so > > probably Coleen needs to look > > at this as well. > > > > Thanks > > - Ioi > > > > On 3/20/15, 1:53 PM, Yumin Qi > > wrote: > > Hi, Coleen and all > > > > New version with > > suggested changes can > > be reviewed at: > > > http://cr.openjdk.java.net/~minqi/8074345/webrev02/ > > > > Removed > > _fast_invokeinvirtual > > from last version, > > disable rewriting > > _invokevirtual if > > UseSharedSpaces turned > > on. Only on sparc > > _invokevirtual got > > rewritten. Other > > platforms as > > unimplemented. > > > > Thanks > > Yumin > > > > On 3/11/2015 1:23 PM, > > Yumin Qi wrote: > > Thanks, I will > > have another > > webrev after > > build/test/perf > test. > > > > Yumin > > > > On 3/11/2015 > > 1:11 PM, > > Coleen > > Phillimore > > wrote: > > > > Hi > > Yumin, > > One > > comment > embedded. > > > > On > > 3/11/15, > 2:04 PM, Yumin Qi wrote: > > > Hi, Coleen > > > > > > > Thanks for the review. See embedded. > > > > > On 3/10/2015 2:54 PM, Coleen Phillimore wrote: > > > > > Yumin, > > > > > The new bytecode approach came out pretty cleanly, or as cleanly as > this could be. > > > > > The file templateTable_x86_32 and 64 have just been merged, so > you'll have to make your change in the new version. > > > > > I also have some comments: > > > > > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html > > > > > Typo "rewirting" > > > > > Sure. > > > In these files, can you break up the long lines into three lines? > > > > > - if (!is_static) { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, > Rscratch); } > > > + if (!is_static && rc == MAY_REWRITE) { > patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } > > > > > Sure. > > > > > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html > > > > > How many bytecodes do we have now? We're limited to 255 (or 256) > and there are other new bytecodes being added. > > > > > now total is 234 (after the fix). See below answer. > > > What was the performance benefit to this? I think if we wanted to > be conservative, we'd turn off RewriteFrequentPairs and only do > nofast_getfield and nofast_putfield. I think they were the only bytecodes > that actually affected performance. > > > > > In this file above, can you remove the last block of comments about > fast_linearswitch and fast_ldc? I think this confuses rewriting in the > interpreter and rewriting in the rewriter, or rather makes the confusion > worse. I don't think this comment is helpful. > > > > > I'd prefer to see the first comment smaller also, like: > > > > > + // These bytecodes are rewritten at CDS dump time, so that we > can prevent them from being > > > + // rewritten at run time. This way, the ConstMethods can be > placed in the CDS ReadOnly > > > + // section, and RewriteByteCodes/RewriteFrequentPairs can > rewrite non-CDS bytecodes > > > + // at run time. > > > + _nofast_getfield , > > > + _nofast_putfield , > > > + _nofast_aload_0 , > > > + _nofast_iload , > > > + _nofast_invokevirtual , > > > > > It's sort of obvious which bytecode they rewrite. I don't know how > much performance fast_invokevfinal is worth. I thought I deleted it. Can > we not rewrite this so we don't waste another bytecode on it? Maybe add a > RewriteVFinal option and consider removing it for the future? x86 doesn't > use it and I can't see how this would save any significant performance to > be worth having! > > > > > _invokevirtual got rewritten on sparc and ppc. Now ppc is removed, no need > to take care for it. For sparc, it does patch code. I am thinking of a way > if we need to add _nofast_code as you indicated, we only have 255 codes to > use. > > > > PPC > > isn't > > removed > from the open repository. > > > > > bool not_rewrite = UseSharedSpaces && RewriteBytecodes && > RewriteFrequentPair; > > > > I > > think > > the > > > conditional would be > > > > > > bool > > > not_rewrite = UseSharedSpaces || !RewriteBytecodes; > > > > > Can this boolean decide if we not rewrite the bytecode to fast? If so, I > can remove all the _nofast_code and do not patch code when it is on. > > > > Yes, > > this > > would > > be > > nice > > to not > > add > > the > > bytecode. > > > > > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html > > > > > + enum RewriteControl { MAY_REWRITE, MAY_NOT_REWRITE }; // control > for fast code under CDS > > > > > > > I don't know what our coding standard is but in the > templateTable_.cpp files these strings look like macros. I'd rather > see them as MayRewrite or MayNotRewrite. > > > > > Agree. > > > > http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html > > > > > I think there's a java_code() function that returns the original > bytecode that you could use instead of the case statement in > resolve_cache_and_index(). The indentation is odd in the webrev. This > probably applies to the other cpu directories. > > > > > One last question below: > > > > > On 3/5/15, 4:21 PM, Yumin Qi wrote: > > > Please review: > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8074345 > > > webrev: http://cr.openjdk.java.net/~minqi/8074345/ > > > > > Summary: Currently CDS when is disabled, RewriteBytecodes > and RewriteFrequentPairs are disabled due to ConstantMethod in CDS are > mapped read only. So memory fault will be triggered when RewriteBytecodes > turned on. This also disable all method rewritten, leads interpreter run > slower. Observed about 2% regression with C2 on some benchmarks, since > interpreter speed is important to C2. By enable RewriteBytecodes and > RewriteFrequentPairs under CDS enabled, adding _nofast_xxxx for > corresponding fast codes at dump time to avoid byte code rewritten at run > time, we prevent byte code rewritten and modify the read only shared > portion in CDS. Meanwhile other byte codes with fast codes still get speed > up. > > > > > Tests: JPRT, jtreg, refworkload (20+ benchmarks) on all > supported platforms. Interpreter only tests showed about 3% improvement. > > > > > What performance did you measure? Is it -Xint -Xshare:on with and > without your patch? It was only 3% better? > > > > > What was the difference in performance with -Xint > -XX:-RewriteBytecodes vs. -Xint -XX:+RewriteBytecodes/FrequentPairs? I > thought this was around 15%. > > > > > I will send you a separate email of the links which run with > CDS/NoCDS/CDS+Int > > > > Thanks > > for > > the > > links. > > From > > your > > > experiments, I think your performance improvement with your patch and CDS > with -Xmixed is 4%. That's good enough for a couple of bytecodes. > > > > Coleen > > > > > > > Thanks > > > Yumin > > > Thanks, > > > Coleen > > > > > > > Thanks > > > Yumin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From sgehwolf at redhat.com Fri Mar 27 11:16:22 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Mar 2015 12:16:22 +0100 Subject: RFR: 8074345: Enable RewriteBytecodes when VM runs with CDS In-Reply-To: References: <54F8C8DC.2030502@oracle.com> <54FF6822.5070702@oracle.com> <5500839B.5030608@oracle.com> <5500A17D.1080809@oracle.com> <5500A424.5000401@oracle.com> <550C88C3.7030008@oracle.com> <5512E498.3060204@oracle.com> <5512E91E.9010008@oracle.com> <551327A3.7050007@oracle.com> <55132C67.3040808@oracle.com> <55132D2B.3060502@oracle.com> <1427449687.3497.16.camel@redhat.com> Message-ID: <1427454982.3497.18.camel@redhat.com> Hi, On Fri, 2015-03-27 at 11:14 +0100, Thomas St?fe wrote: > Hi Severin, > > Could be a product issue. Tried a slowdebug build and my laptop > battery just died on me but I believe the Hotspot was built completely > before that. Yes, reproduced. It's a release type zero build issue. Cheers, Severin > .. Thomas > > On Mar 27, 2015 10:48 AM, "Severin Gehwolf" > wrote: > Hi, > > On Fri, 2015-03-27 at 09:58 +0100, Thomas St?fe wrote: > > Hi, > > > > > > could this break zero? I try to build zero and get the > following build > > error: > > > > > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?: > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:33: error: label ?opc_nofast_getfield? used but not defined > > /* 0xE8 */ > > > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > > &&opc_nofast_aload_0, > > ^ > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:55: error: label ?opc_nofast_putfield? used but not defined > > /* 0xE8 */ > > > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > > &&opc_nofast_aload_0, > > ^ > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:581:78: error: label ?opc_nofast_aload_0? used but not defined > > /* 0xE8 */ > > > &&opc_invokehandle,&&opc_nofast_getfield,&&opc_nofast_putfield, > > &&opc_nofast_aload_0, > > > > ^ > > /shared/projects/openjdk/jdk9-hs-rt/sources/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:582:14: error: label ?opc_nofast_iload? used but not defined > > /* 0xEC */ &&opc_nofast_iload,&&opc_default, > &&opc_default, > > &&opc_default, > > ^ > > make[8]: *** [bytecodeInterpreter.o] Error 1 > > > > > > > > > > I build with a very unexciting configure line: > > > > > > bash ../sources/configure > --with-boot-jdk=/shared/projects/sapjvm_8 > > --with-jvm-variants=zero > > > > > > > > on Ubuntu 14.4. > > > > > > Reverting back before this change makes the build go through > (save for > > the printf() format issue in frame_zero.cpp which Colleen > fixed in a > > later patch). > > > > > > Am I building wrong? > > I have Zero (slowdebug) building fine on F21 with > java-1.8.0-openjdk as > boot JDK. This is revision 2206bbeb3185, so includes Coleen's > fix and > 8074345. > > $ ../build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -version > openjdk version "1.9.0-internal-debug" > OpenJDK Runtime Environment (build > 1.9.0-internal-debug-sgehwolf_2015_03_26_10_51-b00) > OpenJDK 64-Bit Zero VM (build > 1.9.0-internal-debug-sgehwolf_2015_03_26_10_51-b00, > interpreted mode) > > Did you do make dist-clean? Could this be product build only > problem? > > Cheers, > Severin > > > On Wed, Mar 25, 2015 at 10:48 PM, Yumin Qi > > > wrote: > > Thanks for your review! > > > > Yumin > > > > > > On 3/25/2015 2:45 PM, Coleen Phillimore wrote: > > > > Yumin, > > > > This looks great. You addressed my earlier > pre-review > > comments. > > > > There are two other architectures now, that > I don't > > believe we build and test. I think it's > only cpu > > code that would be changed so the fixes for > these > > architectures won't need a sponsor. > > > > Zero doesn't support CDS so I think the > minimal > > changes you've put in > bytecodeInterpreter.cpp are > > good. > > > > Thanks! > > Coleen > > > > > > On 3/25/15, 5:24 PM, Yumin Qi wrote: > > Hi, Coleen > > > > New version based on Ioi's > suggestion is > > located at: > > > http://cr.openjdk.java.net/~minqi/8074345/webrev03/ > > > > Test: JPRT. Manual test on > -Xshare:[dump | > > on ] > > > > Thanks > > Yumin > > > > On 3/25/2015 9:58 AM, Coleen > Phillimore wrote: > > > > Yes, this was on my to-do > list, sorry > > I haven't gotten to it yet. > > Coleen > > > > On 3/25/15, 12:38 PM, Ioi > Lam wrote: > > Hi Yumin, > > > > The changes look > good. Just a > > few nits: > > > > > *src/share/vm/interpreter/bytecodes.hpp:** > > * > > 293 // > Rewritten at CDS > > dump time to | > Original > > bytecode > > 294 // > _invoke_virtual > > rewritten on sparc, > will be > > disabled if > UseSharedSpaces > > turned on. > > 295 // > > > ------------------------------+------------------ > > 296 > _nofast_getfield > > , // <- _getfield > > 297 > _nofast_putfield > > , // <- _putfield > > 298 > _nofast_aload_0 > > , // <- _aload_0 > > 299 > _nofast_iload > > , // <- _iload > > > > I think it should be > > reformatted to line > up the > > columns: > > > > 293 // > Rewritten at CDS > > dump time to | > Original > > bytecode > > 295 // > > > ------------------------------+------------------ > > 296 > _nofast_getfield > > , // <- > _getfield > > 297 > _nofast_putfield > > , // <- > _putfield > > 298 > _nofast_aload_0 > > , // <- > _aload_0 > > 299 > _nofast_iload > > , // <- > _iload > > 230 // NOTE: > > _invoke_virtual is > rewritten > > only on sparc. This > will be > > disabled if > > // > UseSharedSpaces > > turned on. > > > > > *src/share/vm/interpreter/rewriter.cpp:* > > > > There are many > places that > > modify the Method > object. > > Instead of putting > asserts at > > all the places where > an actual > > modification > happens, I think > > it's better to use > only one > > assert at the > Rewriter entry > > point, and remove > the other > > assets that you > added: > > > > 516 void > > > Rewriter::rewrite(instanceKlassHandle klass, TRAPS) { > > + if (! > DumpSharedSpaces) > > { > > + assert(! > > > MetaspaceShared::is_in_shared_space(klass()), "archive > methods must not be rewritten at run time"); > > + } > > 517 ResourceMark > rm(THREAD); > > 518 Rewriter > rw(klass, > > klass->constants(), > > klass->methods(), > CHECK); > > 519 // (That's > all, folks.) > > 520 } > > > > Also, I am not sure > if the PPC > > directories in the > repo have > > been 'locked' or > not, but I > > guess you will find > out when > > you do the push. > > > > I am not a Reviewer, > so > > probably Coleen > needs to look > > at this as well. > > > > Thanks > > - Ioi > > > > On 3/20/15, 1:53 PM, > Yumin Qi > > wrote: > > Hi, Coleen > and all > > > > New > version with > > suggested > changes can > > be reviewed > at: > > > http://cr.openjdk.java.net/~minqi/8074345/webrev02/ > > > > Removed > > > _fast_invokeinvirtual > > from last > version, > > disable > rewriting > > > _invokevirtual if > > > UseSharedSpaces turned > > on. Only on > sparc > > > _invokevirtual got > > rewritten. > Other > > platforms as > > > unimplemented. > > > > Thanks > > Yumin > > > > On 3/11/2015 > 1:23 PM, > > Yumin Qi > wrote: > > > Thanks, I will > > have > another > > > webrev after > > > build/test/perf test. > > > > > Yumin > > > > On > 3/11/2015 > > 1:11 > PM, > > > Coleen > > > Phillimore > > > wrote: > > > > > Hi > > > Yumin, > > > One > > > comment embedded. > > > > > On > > > 3/11/15, 2:04 PM, Yumin Qi wrote: > > > Hi, Coleen > > > > > > > Thanks for the review. See embedded. > > > > > On 3/10/2015 2:54 PM, Coleen Phillimore wrote: > > > > > Yumin, > > > > > The new bytecode approach came out pretty > cleanly, or as cleanly as this could be. > > > > > The file templateTable_x86_32 and 64 have > just been merged, so you'll have to make your change in the > new version. > > > > > I also have some comments: > > > > > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/rewriter.cpp.udiff.html > > > > > Typo "rewirting" > > > > > Sure. > > > In these files, can you break up the long > lines into three lines? > > > > > - if (!is_static) > { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } > > > + if (!is_static && rc == MAY_REWRITE) > { patch_bytecode(Bytecodes::_fast_fgetfield, Rbc, Rscratch); } > > > > > Sure. > > > > > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/bytecodes.hpp.udiff.html > > > > > How many bytecodes do we have now? We're > limited to 255 (or 256) and there are other new bytecodes > being added. > > > > > now total is 234 (after the fix). See below > answer. > > > What was the performance benefit to > this? I think if we wanted to be conservative, we'd turn off > RewriteFrequentPairs and only do nofast_getfield and > nofast_putfield. I think they were the only bytecodes that > actually affected performance. > > > > > In this file above, can you remove the > last block of comments about fast_linearswitch and fast_ldc? I > think this confuses rewriting in the interpreter and rewriting > in the rewriter, or rather makes the confusion worse. I don't > think this comment is helpful. > > > > > I'd prefer to see the first comment > smaller also, like: > > > > > + // These bytecodes are rewritten at > CDS dump time, so that we can prevent them from being > > > + // rewritten at run time. This way, > the ConstMethods can be placed in the CDS ReadOnly > > > + // section, and > RewriteByteCodes/RewriteFrequentPairs can rewrite non-CDS > bytecodes > > > + // at run time. > > > + _nofast_getfield , > > > + _nofast_putfield , > > > + _nofast_aload_0 , > > > + _nofast_iload , > > > + _nofast_invokevirtual , > > > > > It's sort of obvious which bytecode they > rewrite. I don't know how much performance fast_invokevfinal > is worth. I thought I deleted it. Can we not rewrite this so > we don't waste another bytecode on it? Maybe add a > RewriteVFinal option and consider removing it for the future? > x86 doesn't use it and I can't see how this would save any > significant performance to be worth having! > > > > > _invokevirtual got rewritten on sparc and ppc. > Now ppc is removed, no need to take care for it. For sparc, it > does patch code. I am thinking of a way if we need to add > _nofast_code as you indicated, we only have 255 codes to use. > > > > > PPC > > > isn't > > > removed from the open repository. > > > > > bool not_rewrite = UseSharedSpaces && RewriteBytecodes && > RewriteFrequentPair; > > > > > I > > > think > > > the > > > conditional would be > > > > > > > bool > > > not_rewrite = UseSharedSpaces || !RewriteBytecodes; > > > > > Can this boolean decide if we not rewrite the bytecode to > fast? If so, I can remove all the _nofast_code and do not > patch code when it is on. > > > > > Yes, > > > this > > > would > > > be > > > nice > > > to not > > > add > > > the > > > bytecode. > > > > > > http://cr.openjdk.java.net/~minqi/8074345/src/share/vm/interpreter/templateTable.hpp.udiff.html > > > > > + enum RewriteControl { MAY_REWRITE, > MAY_NOT_REWRITE }; // control for fast code under CDS > > > > > > > I don't know what our coding standard is > but in the templateTable_.cpp files these strings look > like macros. I'd rather see them as MayRewrite or > MayNotRewrite. > > > > > Agree. > > > > http://cr.openjdk.java.net/~minqi/8074345/src/cpu/sparc/vm/templateTable_sparc.cpp.udiff.html > > > > > I think there's a java_code() function > that returns the original bytecode that you could use instead > of the case statement in resolve_cache_and_index(). The > indentation is odd in the webrev. This probably applies to the > other cpu directories. > > > > > One last question below: > > > > > On 3/5/15, 4:21 PM, Yumin Qi wrote: > > > Please review: > > > > > bug: > https://bugs.openjdk.java.net/browse/JDK-8074345 > > > webrev: > http://cr.openjdk.java.net/~minqi/8074345/ > > > > > Summary: Currently CDS when is > disabled, RewriteBytecodes and RewriteFrequentPairs are > disabled due to ConstantMethod in CDS are mapped read only. So > memory fault will be triggered when RewriteBytecodes turned > on. This also disable all method rewritten, leads interpreter > run slower. Observed about 2% regression with C2 on some > benchmarks, since interpreter speed is important to C2. By > enable RewriteBytecodes and RewriteFrequentPairs under CDS > enabled, adding _nofast_xxxx for corresponding fast codes at > dump time to avoid byte code rewritten at run time, we prevent > byte code rewritten and modify the read only shared portion in > CDS. Meanwhile other byte codes with fast codes still get > speed up. > > > > > Tests: JPRT, jtreg, refworkload > (20+ benchmarks) on all supported platforms. Interpreter only > tests showed about 3% improvement. > > > > > What performance did you measure? Is it > -Xint -Xshare:on with and without your patch? It was only 3% > better? > > > > > What was the difference in performance > with -Xint -XX:-RewriteBytecodes vs. -Xint -XX: > +RewriteBytecodes/FrequentPairs? I thought this was around > 15%. > > > > > I will send you a separate email of the links > which run with CDS/NoCDS/CDS+Int > > > > > Thanks > > > for > > > the > > > links. > > > From > > > your > > > experiments, I think your performance improvement with > your patch and CDS with -Xmixed is 4%. That's good enough for > a couple of bytecodes. > > > > > Coleen > > > > > > > Thanks > > > Yumin > > > Thanks, > > > Coleen > > > > > > > Thanks > > > Yumin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From david.holmes at oracle.com Fri Mar 27 12:04:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Mar 2015 22:04:24 +1000 Subject: RFR(s): 8074860: Structured Exception Catcher missing around CreateJavaVM on Windows In-Reply-To: References: <5500A8DC.90600@oracle.com> <5500FDD9.3060801@oracle.com> <55015F5A.60507@oracle.com> <1ddc090f-0196-4d53-a755-c81bf12c662e@default> <5c66c663-9106-427e-830a-2585f45ab906@default> Message-ID: <55154748.6030309@oracle.com> Hi Thomas, On 27/03/2015 7:16 PM, Thomas St?fe wrote: > Posting this to hotspot-dev in the hope of attracting one more reviewer and > a sponsor. I can sponsor if required, but am still hoping for someone more knowledgeable in Windows SEH to do the review. David > Th,ank you, > > Thomas > > > On Wed, Mar 25, 2015 at 5:20 PM, Thomas St?fe > wrote: > >> ping... >> >> I still need a sponsor and another reviewer for this issue. Thank you! >> >> Thomas >> >> On Wed, Mar 18, 2015 at 11:13 AM, Thomas St?fe >> wrote: >> >>> Hi Markus, >>> >>> the way to do this cleanly would be to use Vectored Exceptions, which >>> would give us the same control flow as on Unix signal. However, Vectored >>> Exception handling was explicitly removed from the hotspot ages ago. >>> I guess because too many third party libraries install their own VE >>> handlers. >>> >>> To all: I still need one more reviewer and a sponsor. Thanks! >>> >>> Thomas >>> >>> >>> On Tue, Mar 17, 2015 at 9:40 AM, Markus Gronlund < >>> markus.gronlund at oracle.com> wrote: >>>> >>>> I don?t think it is worth it. But thanks for thinking about it. >>>> >>>> >>>> >>>> I was thinking if we could maybe do some callback trickery to set up >>> the SEH in Windows specific code only inside Threads::create_vm() ? but >>> again, probably not worth it. >>>> >>>> >>>> >>>> I am ok with the suggestion as it stands. >>>> >>>> >>>> >>>> /Markus >>>> >>>> >>>> >>>> >>>> >>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>> Sent: den 17 mars 2015 09:34 >>>> To: Markus Gronlund >>>> Cc: hotspot-runtime-dev at openjdk.java.net; David Holmes >>>> >>>> >>>> Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >>> around CreateJavaVM on Windows >>>> >>>> >>>> >>>> Hi Markus, David, >>>> >>>> >>>> >>>> thanks for reviewing this! >>>> >>>> >>>> >>>> yes, I also do not like the #ifdefs _WIN32. >>>> >>>> >>>> >>>> We could pretty it up a bit with macros: >>>> >>>> >>>> >>>> #define GUARD_SEH_START __try { >>>> >>>> #define GUARD_SEH_END } __except... >>>> >>>> >>>> >>>> and defining those empty on non-windows platforms? >>>> >>>> >>>> >>>> What do you think? >>>> >>>> >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 17, 2015 at 9:24 AM, Markus Gronlund < >>> markus.gronlund at oracle.com> wrote: >>>> >>>> Hi Thomas, >>>> >>>> This looks good, thank you for fixing this! >>>> >>>> I didn't know that the entire Threads::create_vm() routine is currently >>> unguarded - interesting. >>>> >>>> Small point: I agree with David about the annoyance of having platform >>> specific #ifdefs in the shared code, but I can't find any other position >>> where we could solve this better (we still need to reach through to the >>> ExceptionFilter). >>>> >>>> Let me know when you start to dig into the SEH (or lack of) for >>> attaching threads :-) >>>> >>>> Thanks again >>>> Markus >>>> >>>> >>>> -----Original Message----- >>>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>>> Sent: den 16 mars 2015 12:32 >>>> To: David Holmes >>>> Cc: hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(s): 8074860: Structured Exception Catcher missing >>> around CreateJavaVM on Windows >>>> >>>> Hi, >>>> >>>> I still need one or two reviewers and a sponsor. >>>> >>>> Thank you! >>>> >>>> Thomas >>>> >>>> On Thu, Mar 12, 2015 at 10:41 AM, David Holmes >>> >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> Thanks for the added info. I have no further comments. Hopefully >>>>> someone with SEH knowledge will also respond. >>>>> >>>>> David >>>>> >>>>> On 12/03/2015 7:18 PM, Thomas St?fe wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> On Thu, Mar 12, 2015 at 3:45 AM, David Holmes >>>>>> > wrote: >>>>>> >>>>>> On 12/03/2015 8:03 AM, Thomas St?fe wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> On Wed, Mar 11, 2015 at 9:43 PM, David Holmes >>>>>> >>>>>> >>>>> >>>>>> >> wrote: >>>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> I'm not really familiar with Windows SEH. Won't this >>> break >>>>>> custom >>>>>> launchers that already provide their own try/catch >>> around >>>>>> Crate_JavaVM ? >>>>>> >>>>>> >>>>>> No. Windows SEH works stack based: any exception - e.g. a >>> crash - >>>>>> between __try and __except will be handled by the handler >>> given >>>>>> in the >>>>>> __except clause. Because they are stack based, they can be >>>>>> nested. If an >>>>>> exception is raised inside the inner __try/__except, first >>>>>> the inner >>>>>> handler is used, if that one feels not responsible, the next >>>>>> outer one >>>>>> and so on. >>>>>> >>>>>> With my fix, any exception raised inside CreateJavaVM will be >>>>>> handler by >>>>>> our handler topLevelExceptionFilter; only if our handler >>> feels not >>>>>> responsible (returns EXCEPTION_CONTINUE_SEARCH), the user >>>>>> handler will >>>>>> be called. >>>>>> >>>>>> >>>>>> My lack of knowledge about when our handler "feels responsible" >>>>>> still leaves me a little nervous here. :) >>>>>> >>>>>> >>>>>> I think the patch is quite safe. I added this patch to our code base >>>>>> in >>>>>> 2011 and since then this is active in productive code for SAP >>> customers. >>>>>> The SAP jvm gets heavily used with custom launchers which do their >>>>>> own error handling, so this is a well tested scenario. >>>>>> >>>>>> I would like to get a similar signal handling coverage as on UNIX: >>>>>> >>>>>> On Unix, we have global signal handling. The moment signal handling >>>>>> is established early in os::init(), every signal from everywhere is >>>>>> covered, even user code. We even have to take care that user handlers >>>>>> get also in the loop via signal chaining, libjsig.so etc. >>>>>> >>>>>> On Windows, it is the other way around: we have stack based signal >>>>>> handling , so we need __try/__except on every thread, and this means >>>>>> there are parts of jvm code which run without signal handling: >>>>>> - the whole initialization >>>>>> - attached threads (I think?) >>>>>> which means that on those cases, user handler gets signals which the >>>>>> libjvm should handle. >>>>>> >>>>>> This was "fixed" partly by surrounding small code which we know >>>>>> beforehand causes signals - how convenient - with __try/__except. For >>>>>> example, the code which handles "-XX:ErrorHandlerTest" to trigger a >>>>>> crash. But you want error handling to always work. I also do not know >>>>>> if stuff like polling pages, implicit nulltests etc could be used in >>>>>> unprotected code. >>>>>> >>>>>> As a side note, there is a UNIX-like signal handling mode on Windows >>>>>> too, "vectored exception handling", which was used in the jvm but >>>>>> removed some time ago for reasons I do not really know. >>>>>> >>>>>> Any exception raised in the launcher itself outside of >>>>>> CreateJavaVM will >>>>>> still be handled by the user handler. >>>>>> >>>>>> (And I hate seeing the win32 ifdefs in the shared code >>> :( ). >>>>>> >>>>>> >>>>>> Yes I know, I kind of expected that feedback :( - I did not >>> find a >>>>>> better way of doing this. One could try to hide the >>> __try/__except >>>>>> behind macros, but that would be kind of unwieldy and I >>> don't like >>>>>> abstractiing something which only has meaning on one >>> platform. >>>>>> >>>>>> >>>>>> Does it help if we make the caller responsible for SEH and then >>> put >>>>>> the try/catch in the launcher code (hopefully in a windows >>> specific >>>>>> part thereof) ? >>>>>> >>>>>> >>>>>> No, because the caller would need access to "topLevelExceptionFilter" >>>>>> - you would need to export that function from the libjvm and then >>>>>> tell the caller "always call topLevelExceptionFilter() if a signal >>>>>> happens on Windows", which is quite awkward and different than on >>> UNIX. >>>>>> >>>>>> Thomas >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> Kind regards, Thomas >>>>>> >>>>>> On 12/03/2015 1:40 AM, Thomas St?fe wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> please review this smallish change: >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~____stuefe/webrevs/8074860/ >>>>>> webrev.____01/webrev/ >>>>>> >>>>> webrev.__01/webrev/> >>>>>> >>>>>> >>>>> webrev.__01/webrev/ >>>>>> >>>>> 01/webrev/>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/____browse/JDK-8074860 >>>>>> >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> This change adds SEH guards around >>> JNI_CreateJavaVM(). >>>>>> Without >>>>>> the change, >>>>>> on Windows, the VM initialization runs without crash >>>>>> protection: >>>>>> crashes >>>>>> will terminate VM immediately without writing an >>>>>> error log; >>>>>> also, any >>>>>> techniques relying on signals will not work, e.g. >>>>>> SafeFetch(). >>>>>> >>>>>> This was partly solved before on a case-by-case >>> base by >>>>>> wrapping >>>>>> code >>>>>> sections which may crash in their own __try/__except >>>>>> wrappers - >>>>>> e.g. CPU >>>>>> feature probing. >>>>>> >>>>>> The change guards the whole of JNI_CreateJavaVM >>>>>> invocation in >>>>>> __try/__except. Unfortunately, for that to compile, >>> I >>>>>> needed to >>>>>> introduce a >>>>>> wrapper around JNI_CreateJavaVM and move the whole >>> of >>>>>> JNI_CreateJavaVM to a >>>>>> new function "JNI_CreateJavaVM_inner". >>>>>> >>>>>> This fix also gets rid of various workarounds which >>>>>> were used >>>>>> before to >>>>>> guard code sections. >>>>>> >>>>>> Thanks for reviewing! >>>>>> >>>>>> Oh, on a side note: I tried to figure out if threads >>>>>> which are >>>>>> attached >>>>>> from the outside via JNI AttachCurrentThread() are >>> in >>>>>> any way >>>>>> guarded with >>>>>> SEH protection. Newly created threads are guarded >>>>>> because they >>>>>> run thru >>>>>> java_start() in os_windows.cpp, which adds SEH >>> guards >>>>>> to all >>>>>> frames below. >>>>>> But for attached threads, I did not find any SEH >>> guards >>>>>> - or >>>>>> maybe I am >>>>>> blind? What does that mean for java code running >>> inside >>>>>> attached >>>>>> threads? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Thomas Stuefe >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> >> From staffan.larsen at oracle.com Fri Mar 27 12:21:30 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 27 Mar 2015 13:21:30 +0100 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <551426DD.6050506@oracle.com> References: <551426DD.6050506@oracle.com> Message-ID: <141463FA-4986-49C1-A6D7-6EFAD271A8A1@oracle.com> > On 26 mar 2015, at 16:33, Mikael Gerdin wrote: > > Hi Evan, > > On 2015-03-26 16:14, Evan Jones wrote: >> At Twitter, I recently discovered that the hsperfdata file that is created >> by default by the JVM causes long safepoint and GC pauses. It turns out >> that writes to mmap-ed files can block until disk I/O completes, even if >> the I/O is to another disk. For details see: >> http://www.evanjones.ca/jvm-mmap-pause.html > > Truly interesting stuff! > > I know we've seen similar discrepancies in user/sys/real time before, this could indeed be a cause for at least some of them. > >> >> We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM >> flag on a number of our latency sensitive services, and have seen a >> significant improvement. Our JVM team (which I am *not* part of), is >> investigating potential changes to the JVM to prevent this. >> >> Any suggestions for an approach to solving this problem that could be >> accepted into Hotspot itself? Some options: >> >> * Make the location of this file configurable (this was set with >> java.io.tmpdir for a time, but then was reverted; see >> http://bugs.java.com/view_bug.do?bug_id=6447182) >> >> * Use shared memory that is not backed by a file? > > Yeah, something like shm_open("/hsperfdata__", O_RDWR|O_CREAT|O_EXCL, 0600) The problem with that is that tools such as jcmd and jps uses these files to find currently running JVMs on the system. We would need a separate method to do that discovery in that case. > >> >> * Something else I'm not considering? > > Have the VM asynchronously update the values in the hsperfdata file by caching the new values somewhere in memory and using the ServiceThread to commit the updated values to the mmaped perf data? That will add a latency to when the values are available for watchers. Maybe not a problem since the data can?t be read synchronously anyway. /Staffan > > I'll file and issue for this and copy the relevant information into it. > > /Mikael > >> >> >> Thanks! >> >> Evan Jones >> > From mikael.gerdin at oracle.com Fri Mar 27 12:26:11 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 27 Mar 2015 13:26:11 +0100 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <141463FA-4986-49C1-A6D7-6EFAD271A8A1@oracle.com> References: <551426DD.6050506@oracle.com> <141463FA-4986-49C1-A6D7-6EFAD271A8A1@oracle.com> Message-ID: <55154C63.2020109@oracle.com> On 2015-03-27 13:21, Staffan Larsen wrote: > >> On 26 mar 2015, at 16:33, Mikael Gerdin wrote: >> >> Hi Evan, >> >> On 2015-03-26 16:14, Evan Jones wrote: >>> At Twitter, I recently discovered that the hsperfdata file that is created >>> by default by the JVM causes long safepoint and GC pauses. It turns out >>> that writes to mmap-ed files can block until disk I/O completes, even if >>> the I/O is to another disk. For details see: >>> http://www.evanjones.ca/jvm-mmap-pause.html >> >> Truly interesting stuff! >> >> I know we've seen similar discrepancies in user/sys/real time before, this could indeed be a cause for at least some of them. >> >>> >>> We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM >>> flag on a number of our latency sensitive services, and have seen a >>> significant improvement. Our JVM team (which I am *not* part of), is >>> investigating potential changes to the JVM to prevent this. >>> >>> Any suggestions for an approach to solving this problem that could be >>> accepted into Hotspot itself? Some options: >>> >>> * Make the location of this file configurable (this was set with >>> java.io.tmpdir for a time, but then was reverted; see >>> http://bugs.java.com/view_bug.do?bug_id=6447182) >>> >>> * Use shared memory that is not backed by a file? >> >> Yeah, something like shm_open("/hsperfdata__", O_RDWR|O_CREAT|O_EXCL, 0600) > > The problem with that is that tools such as jcmd and jps uses these files to find currently running JVMs on the system. We would need a separate method to do that discovery in that case. I see. I didn't realize that the attach mechanism relied on the hsperfdata file as well, I thought it used its own temp files. I guess the hsperfdata could be separated into a mostly-static version which lives in /tmp and a continuously updated one in shared memory, the location of the shared memory one could be encoded in the mostly-static file to avoid exposing yet another fixed file name API. /Mikael > >> >>> >>> * Something else I'm not considering? >> >> Have the VM asynchronously update the values in the hsperfdata file by caching the new values somewhere in memory and using the ServiceThread to commit the updated values to the mmaped perf data? > > That will add a latency to when the values are available for watchers. Maybe not a problem since the data can?t be read synchronously anyway. > > /Staffan > >> >> I'll file and issue for this and copy the relevant information into it. >> >> /Mikael >> >>> >>> >>> Thanks! >>> >>> Evan Jones >>> >> > From staffan.larsen at oracle.com Fri Mar 27 12:31:55 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 27 Mar 2015 13:31:55 +0100 Subject: hsperfdata causing long GC/safepoint times: Don't use mmap? In-Reply-To: <55154C63.2020109@oracle.com> References: <551426DD.6050506@oracle.com> <141463FA-4986-49C1-A6D7-6EFAD271A8A1@oracle.com> <55154C63.2020109@oracle.com> Message-ID: <50B38163-E0E2-4CC7-AC48-CFCFCB261EDD@oracle.com> > On 27 mar 2015, at 13:26, Mikael Gerdin wrote: > > On 2015-03-27 13:21, Staffan Larsen wrote: >> >>> On 26 mar 2015, at 16:33, Mikael Gerdin wrote: >>> >>> Hi Evan, >>> >>> On 2015-03-26 16:14, Evan Jones wrote: >>>> At Twitter, I recently discovered that the hsperfdata file that is created >>>> by default by the JVM causes long safepoint and GC pauses. It turns out >>>> that writes to mmap-ed files can block until disk I/O completes, even if >>>> the I/O is to another disk. For details see: >>>> http://www.evanjones.ca/jvm-mmap-pause.html >>> >>> Truly interesting stuff! >>> >>> I know we've seen similar discrepancies in user/sys/real time before, this could indeed be a cause for at least some of them. >>> >>>> >>>> We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM >>>> flag on a number of our latency sensitive services, and have seen a >>>> significant improvement. Our JVM team (which I am *not* part of), is >>>> investigating potential changes to the JVM to prevent this. >>>> >>>> Any suggestions for an approach to solving this problem that could be >>>> accepted into Hotspot itself? Some options: >>>> >>>> * Make the location of this file configurable (this was set with >>>> java.io.tmpdir for a time, but then was reverted; see >>>> http://bugs.java.com/view_bug.do?bug_id=6447182) >>>> >>>> * Use shared memory that is not backed by a file? >>> >>> Yeah, something like shm_open("/hsperfdata__", O_RDWR|O_CREAT|O_EXCL, 0600) >> >> The problem with that is that tools such as jcmd and jps uses these files to find currently running JVMs on the system. We would need a separate method to do that discovery in that case. > > I see. I didn't realize that the attach mechanism relied on the hsperfdata file as well, I thought it used its own temp files. It?s not the attach mechanism, but the discovery mechanism that is part of jvmstat. But the attaching tools uses that? Confusing. > I guess the hsperfdata could be separated into a mostly-static version which lives in /tmp and a continuously updated one in shared memory, the location of the shared memory one could be encoded in the mostly-static file to avoid exposing yet another fixed file name API. Yes, something like that could work. /Staffan > > /Mikael > >> >>> >>>> >>>> * Something else I'm not considering? >>> >>> Have the VM asynchronously update the values in the hsperfdata file by caching the new values somewhere in memory and using the ServiceThread to commit the updated values to the mmaped perf data? >> >> That will add a latency to when the values are available for watchers. Maybe not a problem since the data can?t be read synchronously anyway. >> >> /Staffan >> >>> >>> I'll file and issue for this and copy the relevant information into it. >>> >>> /Mikael >>> >>>> >>>> >>>> Thanks! >>>> >>>> Evan Jones From goetz.lindenmaier at sap.com Fri Mar 27 13:22:52 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Mar 2015 13:22:52 +0000 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" Message-ID: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Hi, This change ports the platform changes required after "8074345: Enable RewriteBytecodes when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required anyways, as new methods need to be implemented. Please review this change. It would be great if I can push this soon, if possible before 8074345 is transported to jdk9/hs. http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ Best regards, Goetz. From karen.kinnear at oracle.com Fri Mar 27 13:56:46 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 27 Mar 2015 09:56:46 -0400 Subject: RFR: 8025692: Add trace to find out what methods are used at runtime. In-Reply-To: <5514C1CB.7020009@oracle.com> References: <5514C1CB.7020009@oracle.com> Message-ID: Yumin, Couple of questions 1) The bug says "so that infrequently used methods" ... So I was expecting a use count, rather than what appears to be a table of any entries that are used. It looks fairly straightforward to add a use count. 2) You put the hook in ciMethod.cpp -- does this catch interpreter calls to a method? 3) Does the compiler already track profile information of how often a method is called? If so, is there a way to print that information? 4) is this something we would want to be able to turn on remotely, i.e. a writeable flag? So people could track calls from a given point? thanks, Karen On Mar 26, 2015, at 10:34 PM, Yumin Qi wrote: > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8025692 > webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/ > > Summary: Add two flags to help list all java methods called in runtime, this is also in product and can help CDS to rearrange methods in shared archive to avoid loading infrequent methods into memory. > > Tests: vm.runtime.quick.testlist, JPRT > > > Thanks > Yumin > > From coleen.phillimore at oracle.com Fri Mar 27 14:09:46 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Mar 2015 10:09:46 -0400 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Message-ID: <551564AA.20007@oracle.com> This change looks good. Coleen On 3/27/15, 9:22 AM, Lindenmaier, Goetz wrote: > Hi, > > This change ports the platform changes required after "8074345: Enable RewriteBytecodes > when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required > anyways, as new methods need to be implemented. > > Please review this change. It would be great if I can push this soon, if possible before > 8074345 is transported to jdk9/hs. > http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ > > Best regards, > Goetz. From cheleswer.sahu at oracle.com Fri Mar 27 07:36:11 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Fri, 27 Mar 2015 13:06:11 +0530 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <55141556.1070005@oracle.com> References: <55141556.1070005@oracle.com> Message-ID: <5515086B.7050907@oracle.com> Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 with fix successfully. As I do not have account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/. Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ Regards, Cheleswer From coleen.phillimore at oracle.com Fri Mar 27 14:24:13 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Mar 2015 10:24:13 -0400 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <5515086B.7050907@oracle.com> References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com> Message-ID: <5515680D.8000900@oracle.com> Thank you for fixing this!! This looks great. This should keep users from filing bug reports thinking that the VM has crashed. Coleen On 3/27/15, 3:36 AM, cheleswer sahu wrote: > Hi, > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the > JDK9 with fix successfully. As I do not have account for OpenJDK, > David Buck will push > the fix into jdk9/hs-rt/. > > Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ > > Regards, > Cheleswer > > > > From martin.doerr at sap.com Fri Mar 27 15:17:53 2015 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Mar 2015 15:17:53 +0000 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566AD1D8DA@DEWDFEMB19C.global.corp.sap> This change looks good. Best regards, Martin -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Freitag, 27. M?rz 2015 14:23 To: HotSpot Open Source Developers; hotspot-runtime-dev at openjdk.java.net Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" Hi, This change ports the platform changes required after "8074345: Enable RewriteBytecodes when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required anyways, as new methods need to be implemented. Please review this change. It would be great if I can push this soon, if possible before 8074345 is transported to jdk9/hs. http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ Best regards, Goetz. From volker.simonis at gmail.com Fri Mar 27 15:30:40 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Mar 2015 16:30:40 +0100 Subject: RFR(M): 8076163: ppc: port "8074345: Enable RewriteBytecodes when VM runs with CDS" In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CFB8F6F@DEWDFEMB12A.global.corp.sap> Message-ID: The change looks good! Thanks, Volker On Fri, Mar 27, 2015 at 2:22 PM, Lindenmaier, Goetz wrote: > Hi, > > This change ports the platform changes required after "8074345: Enable RewriteBytecodes > when VM runs with CDS" to ppc. Ppc does not support CDS, but the changes are required > anyways, as new methods need to be implemented. > > Please review this change. It would be great if I can push this soon, if possible before > 8074345 is transported to jdk9/hs. > http://cr.openjdk.java.net/~goetz/webrevs/8076163-tmpTbl/webrev.00/ > > Best regards, > Goetz. From sgehwolf at redhat.com Fri Mar 27 15:49:50 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 27 Mar 2015 16:49:50 +0100 Subject: RFR(s): 8076181: bytecodeInterpreter.cpp refers to unknown labels. Message-ID: <1427471390.3497.27.camel@redhat.com> Hi, Could somebody please review and sponsor this change? JDK-8074345 introduced new jumps to labels which were undefined in bytecodeInterpreter.cpp. This makes release builds of Zero fail[1], since it uses the computed goto approach rather than a switch statement which debug builds use. AFAIK, Zero is the only remaining user of the C ++ interpreter. The fix is to not introduce those unknown labels since they aren't implemented anyway. Note: CDS is not implemented in Zero. I'm not entirely sure why 8076181 touched bytecodeInterpreter.cpp in the first place. Bug: https://bugs.openjdk.java.net/browse/JDK-8076181 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076181/webrev.01/ Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014315.html From coleen.phillimore at oracle.com Fri Mar 27 15:58:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Mar 2015 11:58:23 -0400 Subject: RFR(s): 8076181: bytecodeInterpreter.cpp refers to unknown labels. In-Reply-To: <1427471390.3497.27.camel@redhat.com> References: <1427471390.3497.27.camel@redhat.com> Message-ID: <55157E1F.6070009@oracle.com> Yes, this is good. Sorry, I reviewed this and didn't think it would break anything (obviously wrong). I think this can be checked in directly by a committer. Thanks! Coleen On 3/27/15, 11:49 AM, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this change? > > JDK-8074345 introduced new jumps to labels which were undefined in > bytecodeInterpreter.cpp. This makes release builds of Zero fail[1], > since it uses the computed goto approach rather than a switch statement > which debug builds use. AFAIK, Zero is the only remaining user of the C > ++ interpreter. > > The fix is to not introduce those unknown labels since they aren't > implemented anyway. Note: CDS is not implemented in Zero. I'm not > entirely sure why 8076181 touched bytecodeInterpreter.cpp in the first > place. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076181 > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076181/webrev.01/ > > Thanks, > Severin > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014315.html > From yumin.qi at oracle.com Fri Mar 27 16:11:10 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 27 Mar 2015 09:11:10 -0700 Subject: RFR: 8025692: Add trace to find out what methods are used at runtime. In-Reply-To: References: <5514C1CB.7020009@oracle.com> Message-ID: <5515811E.5010004@oracle.com> Karen, Thanks. Seen your update on the bug. I will study further and update bug. Thanks Yumin On 3/27/2015 6:56 AM, Karen Kinnear wrote: > Yumin, > > Couple of questions > > 1) The bug says "so that infrequently used methods" ... > So I was expecting a use count, rather than what appears to be a table of any entries that are used. > It looks fairly straightforward to add a use count. > > 2) You put the hook in ciMethod.cpp -- does this catch interpreter calls to a method? > > 3) Does the compiler already track profile information of how often a method is called? If so, > is there a way to print that information? > > 4) is this something we would want to be able to turn on remotely, i.e. a writeable flag? So people could > track calls from a given point? > > thanks, > Karen > > On Mar 26, 2015, at 10:34 PM, Yumin Qi wrote: > >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8025692 >> webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/ >> >> Summary: Add two flags to help list all java methods called in runtime, this is also in product and can help CDS to rearrange methods in shared archive to avoid loading infrequent methods into memory. >> >> Tests: vm.runtime.quick.testlist, JPRT >> >> >> Thanks >> Yumin >> >> From christian.tornqvist at oracle.com Fri Mar 27 21:48:54 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 27 Mar 2015 17:48:54 -0400 Subject: RFR(S): 8075438 - [TESTBUG] Hotspot JTREG tests should use unique CDS archive names In-Reply-To: <551471B9.6030107@oracle.com> References: <007501d067f8$31a128a0$94e379e0$@oracle.com> <551471B9.6030107@oracle.com> Message-ID: <085401d068d7$d2bd67f0$783837d0$@oracle.com> Hi David, >Is this because jtreg is deleting the directory contents and windows is preventing the file from being deleted, and so it interferes with the next test? Yes >When a test uses '.' for files what actual directory gets used for that? >JTwork/scratch or JTwork/path/to/test ? The scratch directory will be JTwork\scratch and the file will end up there when specifying '.' Thanks, Christian -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Thursday, March 26, 2015 4:53 PM To: Christian Tornqvist; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8075438 - [TESTBUG] Hotspot JTREG tests should use unique CDS archive names Hi Christian, On 27/03/2015 5:08 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that changes the CDS archive names to > be unique. The theory is that sometimes on Windows, something > (Anti-virus > software?) is keeping the archive file open after the JVM has been > shut down. JTreg will use the same folder for tests in the same folder > and the next test may fail to create the archive (seen in 8067333, > 8075212, 8056944 and 8075212) Is this because jtreg is deleting the directory contents and windows is preventing the file from being deleted, and so it interferes with the next test? When a test uses '.' for files what actual directory gets used for that? JTwork/scratch or JTwork/path/to/test ? Thanks, David > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8075438/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8075438 > > > > Thanks, > > Christian > From ioi.lam at oracle.com Sat Mar 28 04:13:14 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 27 Mar 2015 21:13:14 -0700 Subject: RFR: 8025692: Add trace to find out what methods are used at runtime. In-Reply-To: References: <5514C1CB.7020009@oracle.com> Message-ID: <55162A5A.7000500@oracle.com> On 3/27/15, 6:56 AM, Karen Kinnear wrote: > Yumin, > > Couple of questions > > 1) The bug says "so that infrequently used methods" ... > So I was expecting a use count, rather than what appears to be a table of any entries that are used. > It looks fairly straightforward to add a use count. Hi Karen & Others, I think some background information would be helpful. I should have provided more details when I filed the bug. I guess the wording of this bug (as well as the "TraceMethodUsage", "jcmd VM.method_usage" names) are confusing. We should clean up the terminology to be clear what information we are collecting. There are already other mechanisms for getting method invocation count (such as a profiler). When I filed 8025692, I didn't want to add a duplicated feature. Rather, I wanted to have a very low overhead mechanism to provide the kind of "use" information needed by CDS. The implementation in this RFR has much lower overhead than a profiler, since it doesn't count method invocation in compiled code at all. Why are we collecting the "use" information: When a method inside the CDS archive is ever "used" (even just one time), the page containing the method will be mapped to memory. So, if we can identify all the methods that are used and group them together, it will increase the locality of the CDS pages, and allow more CDS pages to be never mapped. For CDS's optimization purposes, the use count is not so important. Using a method once has the same effect of using a method multiple time -- it's page will be loaded into memory. What does "use" mean for CDS? For CDS, "use of a method" does not necessarily mean "invocation" of a method. Rather, it's any attempt to read the contents of a Method or ConstMethod C++ object. For example, in the case of the compiler .... > 2) You put the hook in ciMethod.cpp -- does this catch interpreter calls to a method? ... the code in ciMethod is intended to catch the case where the compiler looks at a method during compilation, for any purpose. For example, the compile may inline the body of a method into its caller, even if the code in the method is never executed, and may never be executed. This RFR does not alter the compiled methods. Hence, it doesn't know when a piece of compiled code invokes a method M. However, this doesn't matter: * If M is interpreted, the "use" of M will be caught by the interpreter. * If M is compiled code, the "use" of M would have been recorded when M was compiled I'll try to upload this info into the bug as well. I am not sure if we want TraceMethodUsage to be useful for CDS only (and hence provide only information that's interesting to CDS), or whether we could make it more useful for other purposes (without adding more overhead). Any suggestions? Thanks - Ioi > 3) Does the compiler already track profile information of how often a method is called? If so, > is there a way to print that information? > > 4) is this something we would want to be able to turn on remotely, i.e. a writeable flag? So people could > track calls from a given point? > > thanks, > Karen > > On Mar 26, 2015, at 10:34 PM, Yumin Qi wrote: > >> Please review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8025692 >> webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/ >> >> Summary: Add two flags to help list all java methods called in runtime, this is also in product and can help CDS to rearrange methods in shared archive to avoid loading infrequent methods into memory. >> >> Tests: vm.runtime.quick.testlist, JPRT >> >> >> Thanks >> Yumin >> >> From yasuenag at gmail.com Sat Mar 28 04:43:23 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 28 Mar 2015 13:43:23 +0900 Subject: inlining AllocateHeap() In-Reply-To: <5506277B.4000902@oracle.com> References: <5506277B.4000902@oracle.com> Message-ID: <5516316B.6000100@gmail.com> Sorry for the delay. I filed it to JBS and uploaded webrev: JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/ Could you review it? > Yasumasa you will need to file a CR and you will need a sponsor to push > your changeset through JPRT once you have created it. I can do the > latter, just email me the final changeset directly. Thanks, David. I'll send it to you after reviewing. Yasumasa On 2015?03?16? 09:44, David Holmes wrote: > On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >> >> There are other inline and noinline directives in allocation.hpp. We >> always assume that AllocateHeap and others are inlined. NMT is touchy >> with respect to how it walks the stack and it took a bit of work and >> testing to get just the most useful frames saved. I don't really want >> to risk this breaking! >> >> I think the gcc directive is acceptable in this case. > > Okay I'll follow Coleen's guidance on this. The original patch is fine. > > Yasumasa you will need to file a CR and you will need a sponsor to push > your changeset through JPRT once you have created it. I can do the > latter, just email me the final changeset directly. > > Thanks, > David > >> Coleen >> >> >> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>> Hi, >>> >>>> That would require more significant changes to NMT I think >>> >>> I think two changes: >>> >>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>> >>> I think that caller of AllocateHeap() and ReallocateHeap() should >>> give >>> PC to them. >>> However, it is significant changes. >>> Thus I proposed to add always_inline . >>> >>> >>>> I don't see how it will help if you have to know a-priori whether >>>> inlining has occurred or not. ?? >>> >>> I think we can use SA. >>> In case of Linux, >>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>> can lookup symbol from target process - we can check whether the >>> function has been >>> inlined (cannot lookup) or not (can lookup). >>> So I think that we can write jtreg testcase. >>> >>> BTW, should I file it to JBS? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2015/03/13 17:35, David Holmes wrote: >>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>> Hi Yasumasa, David, >>>>> >>>>> Maybe it would make sense to make the >>>>> number-of-frames-to-skip-parameter >>>>> configurable? >>>> >>>> That would require more significant changes to NMT I think - plus I >>>> don't see how it will help if you have to know a-priori whether >>>> inlining has occurred or not. ?? >>>> >>>> Thanks, >>>> David >>>> >>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>> not be >>>>> interesting but still a generic wrapper. So, the user doing the >>>>> allocation trace could finetune this parameter to fit his needs. >>>>> >>>>> Thomas >>>>> >>>>> >>>>> >>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>> oracle.com >>>>> > wrote: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I tried to use NMT with details option on OpenJDK7 on >>>>> RHEL6.6, >>>>> but I got >>>>> address at AllocateHeap() as malloc() caller. >>>>> >>>>> I checked symbol in libjvm.so in >>>>> OracleJDK8u40 Linux >>>>> x64, it has AllocateHeap() >>>>> symbol. >>>>> >>>>> AllocateHeap() is defined as inline function, and it gives >>>>> CURRENT_PC to >>>>> os::malloc(). I guess that implementation expects >>>>> AllocateHeap() >>>>> will be >>>>> inlined. >>>>> >>>>> >>>>> It seems so. >>>>> >>>>> It may occur with GCC (g++) optimization only, however I >>>>> want to >>>>> fix it to >>>>> analyze native memory with NMT on Linux. >>>>> >>>>> >>>>> According to the docs [1]: >>>>> >>>>> "GCC does not inline any functions when not optimizing unless >>>>> you >>>>> specify the ?always_inline? attribute for the function" >>>>> >>>>> I applied patch as below. This patch makes AllocateHeap() >>>>> as >>>>> inline >>>>> function. >>>>> -------------- >>>>> diff -r af3b0db91659 >>>>> src/share/vm/memory/__allocation.inline.hpp >>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar >>>>> 09 >>>>> 09:30:16 2015 >>>>> -0700 >>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar >>>>> 12 >>>>> 20:45:57 2015 >>>>> +0900 >>>>> @@ -62,11 +62,18 @@ >>>>> } >>>>> return p; >>>>> } >>>>> + >>>>> +#ifdef __GNUC__ >>>>> +__attribute__((always_inline)__) >>>>> +#endif >>>>> >>>>> >>>>> I dislike seeing the gcc specific directives in common code. >>>>> I'm >>>>> wondering whether we should perhaps only use CURRENT_PC in >>>>> product >>>>> (and optimized?) builds and use CALLER_PC otherwise. That would >>>>> be >>>>> imperfect of course It also makes me wonder whether the >>>>> inlining is >>>>> occurring as expected on other platforms. >>>>> >>>>> I'd like to get other people's views on this. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>> >>>>> >>>>> >>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>> AllocFailType alloc_failmode = >>>>> AllocFailStrategy::EXIT_OOM) { >>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>> alloc_failmode); >>>>> } >>>>> >>>>> +#ifdef __GNUC__ >>>>> +__attribute__((always_inline)__) >>>>> +#endif >>>>> inline char* ReallocateHeap(char *old, size_t size, >>>>> MEMFLAGS >>>>> flag, >>>>> AllocFailType alloc_failmode = >>>>> AllocFailStrategy::EXIT_OOM) { >>>>> char* p = (char*) os::realloc(old, size, flag, >>>>> CURRENT_PC); >>>>> -------------- >>>>> >>>>> If this patch is accepted, I will file it to JBS and will >>>>> upload >>>>> webrev. >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> From david.holmes at oracle.com Sun Mar 29 20:44:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2015 06:44:57 +1000 Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath In-Reply-To: <5515086B.7050907@oracle.com> References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com> Message-ID: <55186449.4050606@oracle.com> On 27/03/2015 5:36 PM, cheleswer sahu wrote: > Hi, > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 > with fix successfully. As I do not have account for OpenJDK, David Buck > will push > the fix into jdk9/hs-rt/. > > Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ Is it possible to include information about where the class was loaded from in the message that precedes the exit: 121 tty->print_cr("Invalid layout of %s at %s", ik->external_name(), name_symbol->as_C_string()); The main cause of this problem is android.jar on the bootclasspath. It would be good to make that explicit as well. Otherwise we will still get bug reports because noone will know what this error means. Thanks, David > Regards, > Cheleswer > > > > From david.holmes at oracle.com Mon Mar 30 01:39:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2015 11:39:32 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: References: <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> Message-ID: <5518A954.1060009@oracle.com> On 27/03/2015 5:24 PM, Jeremy Manson wrote: > I hate to see legacy cruft deliberately introduced into the codebase. I > guess it is too painful to turn it off in a makefile? Stuff ignored by > compilers in rarely touched code like this tends to turn crufty and > become confusing, e.g., something I saw a month or two ago: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 > > Referring you to a page in what you have to think about for a second > before you realize is JVMS v1, which has been obsolete since 2000, and > is unavailable from the publisher. But happens to be the version you would find sitting on the bookshelves of the Oracle VM team members :) A section reference would be better than a page number, but even they change over time. > Doing it this way seems fine to me, but I don't know anything about > suppressing warnings on Windows, so that's not a firm endorsement. Not > that my non-reviewer endorsement would do you any good. Okay. Still need a second review - calling Coleen! I'd really like to get this out of my repo and pushed :) Thanks, David > Jeremy > > On Wed, Mar 25, 2015 at 11:41 PM, David Holmes > wrote: > > Okay I managed to fix this with: > > --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 > 02:34:35.715892476 -0400 > +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 > 02:34:34.663833288 -0400 > @@ -168,6 +168,8 @@ > GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F > = mtInternal) > : GenericGrowableArray(initial___size, 0, C_heap, F) { > _data = (E*)raw_allocate(sizeof(E)); > +// Needed for Visual Studio 2012 and older > +#pragma warning(suppress: 4345) > for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); > } > > @@ -385,6 +387,8 @@ > E* newData = (E*)raw_allocate(sizeof(E)); > int i = 0; > for ( ; i < _len; i++) ::new ((void*)&newData[i]) E(_data[i]); > +// Needed for Visual Studio 2012 and older > +#pragma warning(suppress: 4345) > for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); > for (i = 0; i < old_max; i++) _data[i].~E(); > if (on_C_heap() && _data != NULL) { > > So unless someone finds this totally objectionable it is what I > propose to go with. Full webrev at: > > http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ > > > Thanks, > David > > > On 25/03/2015 2:24 PM, David Holmes wrote: > > On 24/03/2015 2:56 AM, Jeremy Manson wrote: > > Thanks, Kim. This is a pretty silly warning to have break > the build. > Does anyone have a problem with PODs being default > initialized? That's > required by the standard, so if you do, then you are Doing > It Wrong. > > I assume it is pretty easy to turn the warning off. I'd do > it, but I > don't have the Windows build-fu necessary. Also, do we > think it would > require another bug? > > > Unless someone else can already tell me how I will try to find the > cycles to either disable the warning in that file (if that > works) else > disable it in the build - which will need a new CR I think. > > David > > I'd hate to have to change my (or any) code for this. > > Jeremy > > On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett > > __>> wrote: > > On Mar 23, 2015, at 3:45 AM, David Holmes > > >> wrote: > > > > On 23/03/2015 4:12 PM, David Holmes wrote: > >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: > >>> Argh. Yes. Martin told me not to get involved > with Windows, > but would > >>> I listen? Of course not... > >>> > > >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ > > >> > >> Looks okay to me - running a test job now. > > > > This just isn't meant to be :( It seems that: > > > > GrowableArray options(2, true); > > > > in arguments.cpp is giving the windows compiler some > grief: > > > > > C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) > : error C2220: warning treated as error - no 'object' file > generated > > > C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__168) > : while compiling class template member function > 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' > > with > > [ > > E=JavaVMOption > > ] > > > C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\runtime\__arguments.cpp(3516) > : see reference to class template instantiation > 'GrowableArray' > being compiled > > with > > [ > > E=JavaVMOption > > ] > > > C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) > : warning C4345: behavior change: an object of POD type > constructed > with an initializer of the form () will be default-initialized > > > C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__388) > : warning C4345: behavior change: an object of POD type > constructed > with an initializer of the form () will be default-initialized > > > C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__379) > : while compiling class template member function 'void > GrowableArray::grow(int)' > > with > > [ > > E=JavaVMOption > > ] > > > > I'm guessing it doesn't like the enum as the generic > arg, but > don't know why given that it accepts plain int elsewhere. ??? > > Just suppressing this warning (unconditionally > everywhere) would > probably make sense. > > Microsoft describes it as an obsolete warning: > > https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx > > > "This warning is obsolete. It is only generated in > Visual Studio > 2005 through Visual Studio 2012. It reports a behavior > change from > the Visual C++ compiler that shipped in Visual Studio > .NET when > initializing a POD (plain old data) object with (); the > compiler > default-initializes the object.? > > It?s too bad the JDK9 supported build platform for > Windows is still > lagging. > > > From david.holmes at oracle.com Mon Mar 30 02:17:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2015 12:17:34 +1000 Subject: RFR 8076212: AllocateHeap() and ReallocateHeap() should be inlined. In-Reply-To: <5516316B.6000100@gmail.com> References: <5506277B.4000902@oracle.com> <5516316B.6000100@gmail.com> Message-ID: <5518B23E.3020701@oracle.com> Changing subject to reflect proper RFR. This change looks good to me. Thanks, David On 28/03/2015 2:43 PM, Yasumasa Suenaga wrote: > Sorry for the delay. > > I filed it to JBS and uploaded webrev: > > JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. > http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/ > > Could you review it? > > >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. > > Thanks, David. > I'll send it to you after reviewing. > > > Yasumasa > > > On 2015?03?16? 09:44, David Holmes wrote: >> On 14/03/2015 9:29 AM, Coleen Phillimore wrote: >>> >>> There are other inline and noinline directives in allocation.hpp. We >>> always assume that AllocateHeap and others are inlined. NMT is touchy >>> with respect to how it walks the stack and it took a bit of work and >>> testing to get just the most useful frames saved. I don't really want >>> to risk this breaking! >>> >>> I think the gcc directive is acceptable in this case. >> >> Okay I'll follow Coleen's guidance on this. The original patch is fine. >> >> Yasumasa you will need to file a CR and you will need a sponsor to push >> your changeset through JPRT once you have created it. I can do the >> latter, just email me the final changeset directly. >> >> Thanks, >> David >> >>> Coleen >>> >>> >>> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>>> That would require more significant changes to NMT I think >>>> >>>> I think two changes: >>>> >>>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) . >>>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() . >>>> >>>> I think that caller of AllocateHeap() and ReallocateHeap() should >>>> give >>>> PC to them. >>>> However, it is significant changes. >>>> Thus I proposed to add always_inline . >>>> >>>> >>>>> I don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>> >>>> I think we can use SA. >>>> In case of Linux, >>>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup() >>>> can lookup symbol from target process - we can check whether the >>>> function has been >>>> inlined (cannot lookup) or not (can lookup). >>>> So I think that we can write jtreg testcase. >>>> >>>> BTW, should I file it to JBS? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2015/03/13 17:35, David Holmes wrote: >>>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote: >>>>>> Hi Yasumasa, David, >>>>>> >>>>>> Maybe it would make sense to make the >>>>>> number-of-frames-to-skip-parameter >>>>>> configurable? >>>>> >>>>> That would require more significant changes to NMT I think - plus I >>>>> don't see how it will help if you have to know a-priori whether >>>>> inlining has occurred or not. ?? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Because the direct caller of AllocateHeap or os::malloc may also >>>>>> not be >>>>>> interesting but still a generic wrapper. So, the user doing the >>>>>> allocation trace could finetune this parameter to fit his needs. >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>>> oracle.com >>>>>> > wrote: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I tried to use NMT with details option on OpenJDK7 on >>>>>> RHEL6.6, >>>>>> but I got >>>>>> address at AllocateHeap() as malloc() caller. >>>>>> >>>>>> I checked symbol in libjvm.so in >>>>>> OracleJDK8u40 Linux >>>>>> x64, it has AllocateHeap() >>>>>> symbol. >>>>>> >>>>>> AllocateHeap() is defined as inline function, and it gives >>>>>> CURRENT_PC to >>>>>> os::malloc(). I guess that implementation expects >>>>>> AllocateHeap() >>>>>> will be >>>>>> inlined. >>>>>> >>>>>> >>>>>> It seems so. >>>>>> >>>>>> It may occur with GCC (g++) optimization only, however I >>>>>> want to >>>>>> fix it to >>>>>> analyze native memory with NMT on Linux. >>>>>> >>>>>> >>>>>> According to the docs [1]: >>>>>> >>>>>> "GCC does not inline any functions when not optimizing unless >>>>>> you >>>>>> specify the ?always_inline? attribute for the function" >>>>>> >>>>>> I applied patch as below. This patch makes AllocateHeap() >>>>>> as >>>>>> inline >>>>>> function. >>>>>> -------------- >>>>>> diff -r af3b0db91659 >>>>>> src/share/vm/memory/__allocation.inline.hpp >>>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar >>>>>> 09 >>>>>> 09:30:16 2015 >>>>>> -0700 >>>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar >>>>>> 12 >>>>>> 20:45:57 2015 >>>>>> +0900 >>>>>> @@ -62,11 +62,18 @@ >>>>>> } >>>>>> return p; >>>>>> } >>>>>> + >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> >>>>>> >>>>>> I dislike seeing the gcc specific directives in common code. >>>>>> I'm >>>>>> wondering whether we should perhaps only use CURRENT_PC in >>>>>> product >>>>>> (and optimized?) builds and use CALLER_PC otherwise. That would >>>>>> be >>>>>> imperfect of course It also makes me wonder whether the >>>>>> inlining is >>>>>> occurring as expected on other platforms. >>>>>> >>>>>> I'd like to get other people's views on this. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html >>>>>> >>>>>> >>>>>> >>>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> return AllocateHeap(size, flags, CURRENT_PC, >>>>>> alloc_failmode); >>>>>> } >>>>>> >>>>>> +#ifdef __GNUC__ >>>>>> +__attribute__((always_inline)__) >>>>>> +#endif >>>>>> inline char* ReallocateHeap(char *old, size_t size, >>>>>> MEMFLAGS >>>>>> flag, >>>>>> AllocFailType alloc_failmode = >>>>>> AllocFailStrategy::EXIT_OOM) { >>>>>> char* p = (char*) os::realloc(old, size, flag, >>>>>> CURRENT_PC); >>>>>> -------------- >>>>>> >>>>>> If this patch is accepted, I will file it to JBS and will >>>>>> upload >>>>>> webrev. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> From sgehwolf at redhat.com Mon Mar 30 11:02:10 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Mar 2015 13:02:10 +0200 Subject: RFR(s): 8076181: bytecodeInterpreter.cpp refers to unknown labels. In-Reply-To: <55157E1F.6070009@oracle.com> References: <1427471390.3497.27.camel@redhat.com> <55157E1F.6070009@oracle.com> Message-ID: <1427713330.3437.24.camel@redhat.com> On Fri, 2015-03-27 at 11:58 -0400, Coleen Phillimore wrote: > Yes, this is good. Sorry, I reviewed this and didn't think it would > break anything (obviously wrong). I think this can be checked in > directly by a committer. Thanks, Coleen. I think a second review is still required. Cheers, Severin > Thanks! > Coleen > > On 3/27/15, 11:49 AM, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review and sponsor this change? > > > > JDK-8074345 introduced new jumps to labels which were undefined in > > bytecodeInterpreter.cpp. This makes release builds of Zero fail[1], > > since it uses the computed goto approach rather than a switch statement > > which debug builds use. AFAIK, Zero is the only remaining user of the C > > ++ interpreter. > > > > The fix is to not introduce those unknown labels since they aren't > > implemented anyway. Note: CDS is not implemented in Zero. I'm not > > entirely sure why 8076181 touched bytecodeInterpreter.cpp in the first > > place. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076181 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076181/webrev.01/ > > > > Thanks, > > Severin > > > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014315.html > > > From david.holmes at oracle.com Mon Mar 30 11:36:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 30 Mar 2015 21:36:14 +1000 Subject: RFR(s): 8076181: bytecodeInterpreter.cpp refers to unknown labels. In-Reply-To: <1427713330.3437.24.camel@redhat.com> References: <1427471390.3497.27.camel@redhat.com> <55157E1F.6070009@oracle.com> <1427713330.3437.24.camel@redhat.com> Message-ID: <5519352E.50009@oracle.com> On 30/03/2015 9:02 PM, Severin Gehwolf wrote: > On Fri, 2015-03-27 at 11:58 -0400, Coleen Phillimore wrote: >> Yes, this is good. Sorry, I reviewed this and didn't think it would >> break anything (obviously wrong). I think this can be checked in >> directly by a committer. > > Thanks, Coleen. > > I think a second review is still required. Reviewed. Cheers, David > Cheers, > Severin > >> Thanks! >> Coleen >> >> On 3/27/15, 11:49 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this change? >>> >>> JDK-8074345 introduced new jumps to labels which were undefined in >>> bytecodeInterpreter.cpp. This makes release builds of Zero fail[1], >>> since it uses the computed goto approach rather than a switch statement >>> which debug builds use. AFAIK, Zero is the only remaining user of the C >>> ++ interpreter. >>> >>> The fix is to not introduce those unknown labels since they aren't >>> implemented anyway. Note: CDS is not implemented in Zero. I'm not >>> entirely sure why 8076181 touched bytecodeInterpreter.cpp in the first >>> place. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076181 >>> webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076181/webrev.01/ >>> >>> Thanks, >>> Severin >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014315.html >>> >> > > > From sgehwolf at redhat.com Mon Mar 30 13:37:12 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Mar 2015 15:37:12 +0200 Subject: RFR(s): 8076181: bytecodeInterpreter.cpp refers to unknown labels. In-Reply-To: <5519352E.50009@oracle.com> References: <1427471390.3497.27.camel@redhat.com> <55157E1F.6070009@oracle.com> <1427713330.3437.24.camel@redhat.com> <5519352E.50009@oracle.com> Message-ID: <1427722632.3437.31.camel@redhat.com> On Mon, 2015-03-30 at 21:36 +1000, David Holmes wrote: > On 30/03/2015 9:02 PM, Severin Gehwolf wrote: > > On Fri, 2015-03-27 at 11:58 -0400, Coleen Phillimore wrote: > >> Yes, this is good. Sorry, I reviewed this and didn't think it would > >> break anything (obviously wrong). I think this can be checked in > >> directly by a committer. > > > > Thanks, Coleen. > > > > I think a second review is still required. > > Reviewed. Thanks, David. I'd appreciate if somebody could push the attached hg-exported patch for me. Thanks, Severin > > Cheers, > > Severin > > > >> Thanks! > >> Coleen > >> > >> On 3/27/15, 11:49 AM, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Could somebody please review and sponsor this change? > >>> > >>> JDK-8074345 introduced new jumps to labels which were undefined in > >>> bytecodeInterpreter.cpp. This makes release builds of Zero fail[1], > >>> since it uses the computed goto approach rather than a switch statement > >>> which debug builds use. AFAIK, Zero is the only remaining user of the C > >>> ++ interpreter. > >>> > >>> The fix is to not introduce those unknown labels since they aren't > >>> implemented anyway. Note: CDS is not implemented in Zero. I'm not > >>> entirely sure why 8076181 touched bytecodeInterpreter.cpp in the first > >>> place. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076181 > >>> webrev: > >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076181/webrev.01/ > >>> > >>> Thanks, > >>> Severin > >>> > >>> [1] > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014315.html > >>> > >> > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8076181.export.patch Type: text/x-patch Size: 1610 bytes Desc: not available URL: From coleen.phillimore at oracle.com Mon Mar 30 14:51:36 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 30 Mar 2015 10:51:36 -0400 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5518A954.1060009@oracle.com> References: <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> <5518A954.1060009@oracle.com> Message-ID: <551962F8.6050403@oracle.com> On 3/29/15, 9:39 PM, David Holmes wrote: > On 27/03/2015 5:24 PM, Jeremy Manson wrote: >> I hate to see legacy cruft deliberately introduced into the codebase. I >> guess it is too painful to turn it off in a makefile? Stuff ignored by >> compilers in rarely touched code like this tends to turn crufty and >> become confusing, e.g., something I saw a month or two ago: >> >> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 >> >> >> Referring you to a page in what you have to think about for a second >> before you realize is JVMS v1, which has been obsolete since 2000, and >> is unavailable from the publisher. > > But happens to be the version you would find sitting on the > bookshelves of the Oracle VM team members :) A section reference would > be better than a page number, but even they change over time. > >> Doing it this way seems fine to me, but I don't know anything about >> suppressing warnings on Windows, so that's not a firm endorsement. Not >> that my non-reviewer endorsement would do you any good. > > Okay. Still need a second review - calling Coleen! This seems fine although I think I'd prefer the #pragma nowarnings out of the middle of the functions to not interrupt reading of these functions. I don't think #pragmas are scoped. Coleen > > I'd really like to get this out of my repo and pushed :) > > Thanks, > David > >> Jeremy >> >> On Wed, Mar 25, 2015 at 11:41 PM, David Holmes > > wrote: >> >> Okay I managed to fix this with: >> >> --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >> 02:34:35.715892476 -0400 >> +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >> 02:34:34.663833288 -0400 >> @@ -168,6 +168,8 @@ >> GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F >> = mtInternal) >> : GenericGrowableArray(initial___size, 0, C_heap, F) { >> _data = (E*)raw_allocate(sizeof(E)); >> +// Needed for Visual Studio 2012 and older >> +#pragma warning(suppress: 4345) >> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >> } >> >> @@ -385,6 +387,8 @@ >> E* newData = (E*)raw_allocate(sizeof(E)); >> int i = 0; >> for ( ; i < _len; i++) ::new ((void*)&newData[i]) >> E(_data[i]); >> +// Needed for Visual Studio 2012 and older >> +#pragma warning(suppress: 4345) >> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >> for (i = 0; i < old_max; i++) _data[i].~E(); >> if (on_C_heap() && _data != NULL) { >> >> So unless someone finds this totally objectionable it is what I >> propose to go with. Full webrev at: >> >> http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ >> >> >> Thanks, >> David >> >> >> On 25/03/2015 2:24 PM, David Holmes wrote: >> >> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >> >> Thanks, Kim. This is a pretty silly warning to have break >> the build. >> Does anyone have a problem with PODs being default >> initialized? That's >> required by the standard, so if you do, then you are Doing >> It Wrong. >> >> I assume it is pretty easy to turn the warning off. I'd do >> it, but I >> don't have the Windows build-fu necessary. Also, do we >> think it would >> require another bug? >> >> >> Unless someone else can already tell me how I will try to >> find the >> cycles to either disable the warning in that file (if that >> works) else >> disable it in the build - which will need a new CR I think. >> >> David >> >> I'd hate to have to change my (or any) code for this. >> >> Jeremy >> >> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >> >> > __>> wrote: >> >> On Mar 23, 2015, at 3:45 AM, David Holmes >> >> > >> wrote: >> > >> > On 23/03/2015 4:12 PM, David Holmes wrote: >> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >> >>> Argh. Yes. Martin told me not to get involved >> with Windows, >> but would >> >>> I listen? Of course not... >> >>> >> >> >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ >> >> >> >> >> Looks okay to me - running a test job now. >> > >> > This just isn't meant to be :( It seems that: >> > >> > GrowableArray options(2, true); >> > >> > in arguments.cpp is giving the windows compiler some >> grief: >> > >> > >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >> : error C2220: warning treated as error - no 'object' file >> generated >> > >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__168) >> : while compiling class template member function >> 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\runtime\__arguments.cpp(3516) >> : see reference to class template instantiation >> 'GrowableArray' >> being compiled >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >> : warning C4345: behavior change: an object of POD type >> constructed >> with an initializer of the form () will be >> default-initialized >> > >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__388) >> : warning C4345: behavior change: an object of POD type >> constructed >> with an initializer of the form () will be >> default-initialized >> > >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__379) >> : while compiling class template member function 'void >> GrowableArray::grow(int)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> > I'm guessing it doesn't like the enum as the generic >> arg, but >> don't know why given that it accepts plain int elsewhere. >> ??? >> >> Just suppressing this warning (unconditionally >> everywhere) would >> probably make sense. >> >> Microsoft describes it as an obsolete warning: >> >> https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx >> >> >> "This warning is obsolete. It is only generated in >> Visual Studio >> 2005 through Visual Studio 2012. It reports a behavior >> change from >> the Visual C++ compiler that shipped in Visual Studio >> .NET when >> initializing a POD (plain old data) object with (); the >> compiler >> default-initializes the object.? >> >> It?s too bad the JDK9 supported build platform for >> Windows is still >> lagging. >> >> >> From coleen.phillimore at oracle.com Mon Mar 30 14:55:04 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 30 Mar 2015 10:55:04 -0400 Subject: RFR(s): 8076181: bytecodeInterpreter.cpp refers to unknown labels. In-Reply-To: <1427722632.3437.31.camel@redhat.com> References: <1427471390.3497.27.camel@redhat.com> <55157E1F.6070009@oracle.com> <1427713330.3437.24.camel@redhat.com> <5519352E.50009@oracle.com> <1427722632.3437.31.camel@redhat.com> Message-ID: <551963C8.5030203@oracle.com> Okay, I'll do it. Coleen On 3/30/15, 9:37 AM, Severin Gehwolf wrote: > On Mon, 2015-03-30 at 21:36 +1000, David Holmes wrote: >> On 30/03/2015 9:02 PM, Severin Gehwolf wrote: >>> On Fri, 2015-03-27 at 11:58 -0400, Coleen Phillimore wrote: >>>> Yes, this is good. Sorry, I reviewed this and didn't think it would >>>> break anything (obviously wrong). I think this can be checked in >>>> directly by a committer. >>> Thanks, Coleen. >>> >>> I think a second review is still required. >> Reviewed. > Thanks, David. > > I'd appreciate if somebody could push the attached hg-exported patch for > me. > > Thanks, > Severin > >>> Cheers, >>> Severin >>> >>>> Thanks! >>>> Coleen >>>> >>>> On 3/27/15, 11:49 AM, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Could somebody please review and sponsor this change? >>>>> >>>>> JDK-8074345 introduced new jumps to labels which were undefined in >>>>> bytecodeInterpreter.cpp. This makes release builds of Zero fail[1], >>>>> since it uses the computed goto approach rather than a switch statement >>>>> which debug builds use. AFAIK, Zero is the only remaining user of the C >>>>> ++ interpreter. >>>>> >>>>> The fix is to not introduce those unknown labels since they aren't >>>>> implemented anyway. Note: CDS is not implemented in Zero. I'm not >>>>> entirely sure why 8076181 touched bytecodeInterpreter.cpp in the first >>>>> place. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076181 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8076181/webrev.01/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014315.html >>>>> >>> >>> > From dmitry.samersoff at oracle.com Mon Mar 30 14:58:51 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 30 Mar 2015 17:58:51 +0300 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5518A954.1060009@oracle.com> References: <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> <5518A954.1060009@oracle.com> Message-ID: <551964AB.1050608@oracle.com> David, Could you move this pragma out of a function? -Dmitry On 2015-03-30 04:39, David Holmes wrote: > On 27/03/2015 5:24 PM, Jeremy Manson wrote: >> I hate to see legacy cruft deliberately introduced into the codebase. I >> guess it is too painful to turn it off in a makefile? Stuff ignored by >> compilers in rarely touched code like this tends to turn crufty and >> become confusing, e.g., something I saw a month or two ago: >> >> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 >> >> >> Referring you to a page in what you have to think about for a second >> before you realize is JVMS v1, which has been obsolete since 2000, and >> is unavailable from the publisher. > > But happens to be the version you would find sitting on the bookshelves > of the Oracle VM team members :) A section reference would be better > than a page number, but even they change over time. > >> Doing it this way seems fine to me, but I don't know anything about >> suppressing warnings on Windows, so that's not a firm endorsement. Not >> that my non-reviewer endorsement would do you any good. > > Okay. Still need a second review - calling Coleen! > > I'd really like to get this out of my repo and pushed :) > > Thanks, > David > >> Jeremy >> >> On Wed, Mar 25, 2015 at 11:41 PM, David Holmes > > wrote: >> >> Okay I managed to fix this with: >> >> --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >> 02:34:35.715892476 -0400 >> +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >> 02:34:34.663833288 -0400 >> @@ -168,6 +168,8 @@ >> GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F >> = mtInternal) >> : GenericGrowableArray(initial___size, 0, C_heap, F) { >> _data = (E*)raw_allocate(sizeof(E)); >> +// Needed for Visual Studio 2012 and older >> +#pragma warning(suppress: 4345) >> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >> } >> >> @@ -385,6 +387,8 @@ >> E* newData = (E*)raw_allocate(sizeof(E)); >> int i = 0; >> for ( ; i < _len; i++) ::new ((void*)&newData[i]) >> E(_data[i]); >> +// Needed for Visual Studio 2012 and older >> +#pragma warning(suppress: 4345) >> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >> for (i = 0; i < old_max; i++) _data[i].~E(); >> if (on_C_heap() && _data != NULL) { >> >> So unless someone finds this totally objectionable it is what I >> propose to go with. Full webrev at: >> >> http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ >> >> >> Thanks, >> David >> >> >> On 25/03/2015 2:24 PM, David Holmes wrote: >> >> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >> >> Thanks, Kim. This is a pretty silly warning to have break >> the build. >> Does anyone have a problem with PODs being default >> initialized? That's >> required by the standard, so if you do, then you are Doing >> It Wrong. >> >> I assume it is pretty easy to turn the warning off. I'd do >> it, but I >> don't have the Windows build-fu necessary. Also, do we >> think it would >> require another bug? >> >> >> Unless someone else can already tell me how I will try to find >> the >> cycles to either disable the warning in that file (if that >> works) else >> disable it in the build - which will need a new CR I think. >> >> David >> >> I'd hate to have to change my (or any) code for this. >> >> Jeremy >> >> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >> >> > __>> wrote: >> >> On Mar 23, 2015, at 3:45 AM, David Holmes >> >> > >> wrote: >> > >> > On 23/03/2015 4:12 PM, David Holmes wrote: >> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >> >>> Argh. Yes. Martin told me not to get involved >> with Windows, >> but would >> >>> I listen? Of course not... >> >>> >> >> >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ >> >> >> >> >> Looks okay to me - running a test job now. >> > >> > This just isn't meant to be :( It seems that: >> > >> > GrowableArray options(2, true); >> > >> > in arguments.cpp is giving the windows compiler some >> grief: >> > >> > >> >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >> >> : error C2220: warning treated as error - no 'object' file >> generated >> > >> >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__168) >> >> : while compiling class template member function >> 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\runtime\__arguments.cpp(3516) >> >> : see reference to class template instantiation >> 'GrowableArray' >> being compiled >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >> >> : warning C4345: behavior change: an object of POD type >> constructed >> with an initializer of the form () will be >> default-initialized >> > >> >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__388) >> >> : warning C4345: behavior change: an object of POD type >> constructed >> with an initializer of the form () will be >> default-initialized >> > >> >> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__379) >> >> : while compiling class template member function 'void >> GrowableArray::grow(int)' >> > with >> > [ >> > E=JavaVMOption >> > ] >> > >> > I'm guessing it doesn't like the enum as the generic >> arg, but >> don't know why given that it accepts plain int elsewhere. ??? >> >> Just suppressing this warning (unconditionally >> everywhere) would >> probably make sense. >> >> Microsoft describes it as an obsolete warning: >> >> https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx >> >> >> "This warning is obsolete. It is only generated in >> Visual Studio >> 2005 through Visual Studio 2012. It reports a behavior >> change from >> the Visual C++ compiler that shipped in Visual Studio >> .NET when >> initializing a POD (plain old data) object with (); the >> compiler >> default-initializes the object.? >> >> It?s too bad the JDK9 supported build platform for >> Windows is still >> lagging. >> >> >> -- 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 ron.durbin at oracle.com Mon Mar 30 15:41:15 2015 From: ron.durbin at oracle.com (Ron Durbin) Date: Mon, 30 Mar 2015 08:41:15 -0700 (PDT) Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <550FAEC2.5040908@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> Message-ID: <2a34e7c9-614d-44f8-b354-d49c2ef183c5@default> Ron Durbin> -----Original Message----- Ron Durbin> From: David Holmes Ron Durbin> Sent: Monday, March 23, 2015 12:12 AM Ron Durbin> To: Jeremy Manson Ron Durbin> Cc: hotspot-runtime-dev at openjdk.java.net Ron Durbin> Subject: Re: RFR: 8074895: os::getenv is inadequate Ron Durbin> Ron Durbin> On 21/03/2015 3:32 AM, Jeremy Manson wrote: Ron Durbin> > Argh. Yes. Martin told me not to get involved with Windows, but would Ron Durbin> > I listen? Of course not... Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ Ron Durbin> Ron Durbin> Looks okay to me - running a test job now. Ron Durbin> Ron Durbin> Coleen: can you re-review the os_windows.cpp changes please. Ron Durbin> Ron Durbin> Thanks, Ron Durbin> David Ron Durbin> Ron Durbin> > On Wed, Mar 18, 2015 at 2:39 PM, David Holmes > > wrote: Ron Durbin> > Ron Durbin> > On 19/03/2015 3:04 AM, Jeremy Manson wrote: Ron Durbin> > Ron Durbin> > Okay. Here you go: Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~__jmanson/8074895/webrev.03/__index.html Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > ! if (alt_home_dir != NULL) { Ron Durbin> > ! strcpy(home_dir, alt_home_dir); Ron Durbin> > ! } else { Ron Durbin> > Ron Durbin> > That needs to be strncpy limited by MAX_PATH. Ron Durbin> > Ron Durbin> > David Ron Durbin> > Ron Durbin> > Jeremy Ron Durbin> > Ron Durbin> > On Wed, Mar 18, 2015 at 12:31 AM, David Holmes Ron Durbin> > Ron Durbin> > > >> wrote: Ron Durbin> > Ron Durbin> > On 18/03/2015 4:15 PM, Jeremy Manson wrote: Ron Durbin> > Ron Durbin> > Oops... Should I fix it, post a patch, and hope it Ron Durbin> > compiles? Ron Durbin> > Ron Durbin> > Ron Durbin> > Please :) I can check the compiles part. Ron Durbin> > Ron Durbin> > David Ron Durbin> > Ron Durbin> > On Tue, Mar 17, 2015 at 9:09 PM, David Holmes Ron Durbin> > > Ron Durbin> > > Ron Durbin> > > ____com Ron Durbin> > > >>> wrote: Ron Durbin> > Ron Durbin> > Sorry Jeremy, the patch failed on Windows as there is Ron Durbin> > another usage Ron Durbin> > in os_windows.cpp: Ron Durbin> > Ron Durbin> > void os::init_system_properties_______values() { Ron Durbin> > // sysclasspath, java_home, dll_dir Ron Durbin> > { Ron Durbin> > char *home_path; Ron Durbin> > char *dll_path; Ron Durbin> > char *pslash; Ron Durbin> > char *bin = "\\bin"; Ron Durbin> > char home_dir[MAX_PATH]; Ron Durbin> > Ron Durbin> > if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, Ron Durbin> > MAX_PATH)) { Ron Durbin> > Ron Durbin> > David Ron Durbin> > Ron Durbin> > Ron Durbin> > On 18/03/2015 12:01 PM, David Holmes wrote: Ron Durbin> > Ron Durbin> > Submitting via JPRT. Ron Durbin> > Ron Durbin> > Thanks, Ron Durbin> > David Ron Durbin> > Ron Durbin> > On 18/03/2015 4:13 AM, Jeremy Manson wrote: Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > On Sun, Mar 15, 2015 at 10:04 PM, David Holmes Ron Durbin> > > Ron Durbin> > > > Ron Durbin> > > ____com Ron Durbin> > >> Ron Durbin> > > . Ron Durbin> > > .>______com Ron Durbin> > > ____com Ron Durbin> > > >>>> wrote: Ron Durbin> > Ron Durbin> > Hi Jeremy, Ron Durbin> > Ron Durbin> > On 14/03/2015 3:00 AM, Jeremy Manson Ron Durbin> > wrote: Ron Durbin> > Ron Durbin> > Thanks, David! New rev: Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~________jmanson/8074895/webrev.01/ Ron Durbin> > Ron Durbin> > Ron Durbin> > > > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > >> Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > >>> Ron Durbin> > Ron Durbin> > Ron Durbin> > Looks good. Please update copyright Ron Durbin> > dates in Ron Durbin> > memTracker.cpp and Ron Durbin> > vmError.cpp. Ron Durbin> > Ron Durbin> > Ron Durbin> > Done. Thanks for the review, and for Ron Durbin> > feeding it Ron Durbin> > through the Ron Durbin> > other Ron Durbin> > platforms! Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~______jmanson/8074895/webrev.02/ Ron Durbin> > Ron Durbin> > Ron Durbin> > > > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > >> Ron Durbin> > Ron Durbin> > Jeremy Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > From ron.durbin at oracle.com Mon Mar 30 15:41:18 2015 From: ron.durbin at oracle.com (Ron Durbin) Date: Mon, 30 Mar 2015 08:41:18 -0700 (PDT) Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <550FAEC2.5040908@oracle.com> References: <5500FC48.50503@oracle.com> <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> Message-ID: <7dea9e05-8e6b-42be-8e1d-e1ff780400b7@default> David I can take a look too as I am making another set of changes in this. Ron Ron Durbin> -----Original Message----- Ron Durbin> From: David Holmes Ron Durbin> Sent: Monday, March 23, 2015 12:12 AM Ron Durbin> To: Jeremy Manson Ron Durbin> Cc: hotspot-runtime-dev at openjdk.java.net Ron Durbin> Subject: Re: RFR: 8074895: os::getenv is inadequate Ron Durbin> Ron Durbin> On 21/03/2015 3:32 AM, Jeremy Manson wrote: Ron Durbin> > Argh. Yes. Martin told me not to get involved with Windows, but would Ron Durbin> > I listen? Of course not... Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~jmanson/8074895/webrev.04/ Ron Durbin> Ron Durbin> Looks okay to me - running a test job now. Ron Durbin> Ron Durbin> Coleen: can you re-review the os_windows.cpp changes please. Ron Durbin> Ron Durbin> Thanks, Ron Durbin> David Ron Durbin> Ron Durbin> > On Wed, Mar 18, 2015 at 2:39 PM, David Holmes > > wrote: Ron Durbin> > Ron Durbin> > On 19/03/2015 3:04 AM, Jeremy Manson wrote: Ron Durbin> > Ron Durbin> > Okay. Here you go: Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~__jmanson/8074895/webrev.03/__index.html Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > ! if (alt_home_dir != NULL) { Ron Durbin> > ! strcpy(home_dir, alt_home_dir); Ron Durbin> > ! } else { Ron Durbin> > Ron Durbin> > That needs to be strncpy limited by MAX_PATH. Ron Durbin> > Ron Durbin> > David Ron Durbin> > Ron Durbin> > Jeremy Ron Durbin> > Ron Durbin> > On Wed, Mar 18, 2015 at 12:31 AM, David Holmes Ron Durbin> > Ron Durbin> > > >> wrote: Ron Durbin> > Ron Durbin> > On 18/03/2015 4:15 PM, Jeremy Manson wrote: Ron Durbin> > Ron Durbin> > Oops... Should I fix it, post a patch, and hope it Ron Durbin> > compiles? Ron Durbin> > Ron Durbin> > Ron Durbin> > Please :) I can check the compiles part. Ron Durbin> > Ron Durbin> > David Ron Durbin> > Ron Durbin> > On Tue, Mar 17, 2015 at 9:09 PM, David Holmes Ron Durbin> > > Ron Durbin> > > Ron Durbin> > > ____com Ron Durbin> > > >>> wrote: Ron Durbin> > Ron Durbin> > Sorry Jeremy, the patch failed on Windows as there is Ron Durbin> > another usage Ron Durbin> > in os_windows.cpp: Ron Durbin> > Ron Durbin> > void os::init_system_properties_______values() { Ron Durbin> > // sysclasspath, java_home, dll_dir Ron Durbin> > { Ron Durbin> > char *home_path; Ron Durbin> > char *dll_path; Ron Durbin> > char *pslash; Ron Durbin> > char *bin = "\\bin"; Ron Durbin> > char home_dir[MAX_PATH]; Ron Durbin> > Ron Durbin> > if (!getenv("_ALT_JAVA_HOME_DIR", home_dir, Ron Durbin> > MAX_PATH)) { Ron Durbin> > Ron Durbin> > David Ron Durbin> > Ron Durbin> > Ron Durbin> > On 18/03/2015 12:01 PM, David Holmes wrote: Ron Durbin> > Ron Durbin> > Submitting via JPRT. Ron Durbin> > Ron Durbin> > Thanks, Ron Durbin> > David Ron Durbin> > Ron Durbin> > On 18/03/2015 4:13 AM, Jeremy Manson wrote: Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > On Sun, Mar 15, 2015 at 10:04 PM, David Holmes Ron Durbin> > > Ron Durbin> > > > Ron Durbin> > > ____com Ron Durbin> > >> Ron Durbin> > > . Ron Durbin> > > .>______com Ron Durbin> > > ____com Ron Durbin> > > >>>> wrote: Ron Durbin> > Ron Durbin> > Hi Jeremy, Ron Durbin> > Ron Durbin> > On 14/03/2015 3:00 AM, Jeremy Manson Ron Durbin> > wrote: Ron Durbin> > Ron Durbin> > Thanks, David! New rev: Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~________jmanson/8074895/webrev.01/ Ron Durbin> > Ron Durbin> > Ron Durbin> > > > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > >> Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > >>> Ron Durbin> > Ron Durbin> > Ron Durbin> > Looks good. Please update copyright Ron Durbin> > dates in Ron Durbin> > memTracker.cpp and Ron Durbin> > vmError.cpp. Ron Durbin> > Ron Durbin> > Ron Durbin> > Done. Thanks for the review, and for Ron Durbin> > feeding it Ron Durbin> > through the Ron Durbin> > other Ron Durbin> > platforms! Ron Durbin> > Ron Durbin> > http://cr.openjdk.java.net/~______jmanson/8074895/webrev.02/ Ron Durbin> > Ron Durbin> > Ron Durbin> > > > Ron Durbin> > Ron Durbin> > Ron Durbin> > > Ron Durbin> > Ron Durbin> > > >> Ron Durbin> > Ron Durbin> > Jeremy Ron Durbin> > Ron Durbin> > Ron Durbin> > Ron Durbin> > From daniel.daugherty at oracle.com Mon Mar 30 18:25:37 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Mar 2015 12:25:37 -0600 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5512FA41.3020008@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> <55106018.3020005@oracle.com> <5512FA41.3020008@oracle.com> Message-ID: <55199521.7070005@oracle.com> On 3/25/15 12:11 PM, Yumin Qi wrote: > Hi, all > > I updated the webrev with a new change to test case: > test/runtime/Unsafe/RangeCheck.java > > Add -XX:-CreateCoredumpOnCrash to test, no dump needed on this case. > > new webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev05/ General nit - please update copyright lines to 2015 as needed src/share/vm/runtime/globals.hpp No comments. src/share/vm/runtime/os.hpp line 720: // On Windows this will create an actual minidump, on Linux/Solaris it will simply check core dump limits line 721: static void check_dump_limit(char* buffer, size_t bufferSize); The comment on line 720 no longer matches with the function rename from check_or_create_dump() to check_dump_limit(). You have this comment in vmError.cpp: 943 // check core dump limits on Linux/Solaris, nothing on Windows 944 os::check_dump_limit(buffer, sizeof(buffer)); so the two comments are out of sync. src/share/vm/runtime/arguments.cpp line 3252: } else if (match_option(option, "-XX:+CreateMinidumpOnCrash", &tail)) { line 3256: } else if (match_option(option, "-XX:-CreateMinidumpOnCrash", &tail)) { These two checks should use the match_option() version without a '&tail' parameter. src/share/vm/utilities/vmError.cpp line 217: bool VMError::coredump_status = true; // presume we can dump core file first I don't think you should init this to true. It confuses things with VMError::report_coredump_status(). It will also confuse this code: 526 STEP(63, "(printing core file information)") 529 if (coredump_status) { 530 st->print("Core dump written. Default location: %s", coredump_message); because coredump_status won't accurately reflect whether the coredump_message field has been set. line 943: // check core dump limits on Linux/Solaris, nothing on Windows This updated comment doesn't match the unmodified comment in os.hpp: 720: // On Windows this will create an actual minidump, on Linux/Solaris it will simply check core dump limits src/os/aix/vm/os_aix.cpp No comments. src/os/bsd/vm/os_bsd.cpp No comments. src/os/linux/vm/os_linux.cpp No comments. src/os/posix/vm/os_posix.cpp No comments. src/os/solaris/vm/os_solaris.cpp No comments. src/os/windows/vm/os_windows.cpp line 1008: static char buffer[O_BUFLEN]; Why switch from a buffer parameter to a static buffer? What happens with parallel calls to abort()? Will the static buffer get stomped by the competing threads? line 1015: // If running on a client version of Windows and user has not explicitly enabled dumping line 1016: if (!os::win32::is_windows_server() && !CreateCoredumpOnCrash) { The default for CreateCoredumpOnCrash is now 'true' so the comment and logic are no longer correct here. The Windows Client VM will generate minidumps by default. old line 1007: VMError::report_coredump_status("Minidumps are not enabled by default on client versions of Windows", false); new line 1017: jio_fprintf(stderr, "Minidumps are not enabled by default on client versions of Windows.\n"); There are a number of places where we change from VMError::report_coredump_status() to jio_fprintf() and I'm not quite seeing why this was done. Update: VMError::report_coredump_status() is misnamed. It doesn't report anything in the sense that it doesn't print anything. It does record two pieces of information about core dumps so maybe it should be VMError::record_coredump_status(). line 1100: jio_fprintf(stderr, "%s.\n", buffer); At this point, buffer contains the path to the mini-dump file so the above line simply prints that on stderr. Why? Yes, I see that the old code did something similar: 1090 VMError::report_coredump_status(buffer, true); but report_coredump_status() didn't actually print anything. It just squirreled away these in vmError.cpp: 217 bool VMError::coredump_status; 218 char VMError::coredump_message[O_BUFLEN]; See comments above about how report_coredump_status() is misnamed. At this point, I'm convinced that all the changes from VMError::report_coredump_status() to jio_fprintf() are a bad idea. test/runtime/ErrorHandling/ProblematicFrameTest.java No comments. test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java No comments. test/runtime/ErrorHandling/SecondaryErrorTest.java No comments. test/runtime/Safepoint/AssertSafepointCheckConsistency1.java No comments. test/runtime/Safepoint/AssertSafepointCheckConsistency2.java No comments. test/runtime/Safepoint/AssertSafepointCheckConsistency3.java No comments. test/runtime/Safepoint/AssertSafepointCheckConsistency4.java No comments. test/runtime/Unsafe/RangeCheck.java No comments. test/runtime/memory/ReadFromNoaccessArea.java No comments. > > Thanks > Yumin > > > On 3/23/2015 11:48 AM, Yumin Qi wrote: >> Since Thomas is not a reviewer in open jdk, I need two volunteers (at >> least one "R"eviewer). >> >> Dan, since you already reviewed previous version, could you have a look? >> >> Thanks >> Yumin >> >> On 3/20/2015 3:20 PM, Yumin Qi wrote: >>> Thomas, >>> >>> Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add >>> another test case change: test/runtime/memory/ReadFromNoaccessArea.java >>> (Thanks Dan's update) >>> >>> Thanks >>> Yumin >>> >>> On 3/20/2015 11:55 AM, Thomas St?fe wrote: >>>> >>>> Hi Yumin, >>>> >>>> I think you meant to post webrev.04? >>>> >>>> I looked at 04, and it looks nice. Thank you! >>>> >>>> (still only reviewer with r) >>>> >>>> Thomas >>>> >>>> On Mar 20, 2015 6:20 PM, "Yumin Qi" >>> > wrote: >>>> >>>> Hi, All >>>> >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>> >>>> >>>> This version is based on Thomas' suggestion. >>>> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/18/2015 10:06 AM, Yumin Qi wrote: >>>> >>>> >>>> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >>>> >>>> Hi Yumin, >>>> >>>> - just aesthetics, but on all implementations of >>>> os_abort(), at least on the UNIX variants, maybe we could >>>> consistently rename the parameters to be "siginfo" and >>>> "context" instead of using Windows terms? >>>> >>>> Sure. >>>> >>>> - On check_create_dump_limit(), you do not need >>>> exceptionRecord, contextRecord parameters anymore. The >>>> only parameters now needed are buffer and buffer size, >>>> which is not even an output parameter, just a scratch >>>> buffer for this function to use for printf. For output, it >>>> calls VMError::report_coredump_status(...) at the end to >>>> provide information about the core file. >>>> >>>> - I would rename that function from >>>> check_create_dump_limit() to check_dump_limit() - nothing >>>> is created anymore. >>>> >>>> Yes, no need to carry those two parameters. I tried to keep >>>> less changes, but decided to change now. >>>> >>>> - on Windows, in os::abort(), there is no point anymore in >>>> calling VMError::report_coredump_status(...) because that >>>> information is only used during error log writing which >>>> already happened. It only makes sense to call this >>>> function in check_create_dump_limit(), which happens >>>> before error log writing. >>>> Instead, maybe error messages like "Call to >>>> MiniDumpWriteDump() failed" should just be written to >>>> stderr? This would be consistent with Unix, where the OS >>>> writes a short message on stderr if core file writing >>>> fails. >>>> >>>> Sure, will direct output to stderr. >>>> >>>> - there is now a new test, >>>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>>> - could you please also add "-XX:-CreateCoredumpOnCrash" ? >>>> I just added the test and did not want to add the option >>>> before it was available. >>>> >>>> OK >>>> >>>> Thanks >>>> Yumin >>>> >>>> Thanks for your work! >>>> >>>> Thomas >>>> >>>> >>>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >>>> >>>> >> >>>> wrote: >>>> >>>> Hi, Dan and all >>>> >>>> I have updated webrev at: >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>> >>>> >>>> >>>> 1) bug changed synopsis >>>> 8074354: Make CreateMinidumpOnCrash a new >>>> name and >>>> available on all platforms >>>> 2) tests: JPRT, vm.runtime.quick.testlist (on >>>> Windows), jtreg on >>>> Windows and Linux/Unix. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>>> >>>> I believe there are both JavaTest/JTREG tests in >>>> the hotspot repo >>>> and there are VM/NSK tests from back when we did >>>> phone home... >>>> >>>> Check with Christian or Misha... >>>> >>>> Dan >>>> >>>> >>>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>>> >>>> Thanks, Dan >>>> >>>> Will look at and run those tests. Are they >>>> under nsk? >>>> >>>> Yumin >>>> >>>> On 3/12/2015 12:29 PM, Daniel D. Daugherty >>>> wrote: >>>> >>>> Yumin, >>>> >>>> There are some error handler tests. You >>>> should find >>>> those and make >>>> sure that you run them on Windows since >>>> you're >>>> changing the order >>>> there... >>>> >>>> Dan >>>> >>>> >>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>> >>>> Hi, Thomas and all >>>> >>>> The second version of the change: >>>> webrev: >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>> >>>> >>>> >>>> In this version: >>>> 1) switch order on Windows to first >>>> print log >>>> file as other platform, then dump core >>>> file if >>>> needed. When VMError created after >>>> crash, siginfo >>>> and context which are >>>> ExceptionRecord and >>>> ContextRecord on Windows are recorded, >>>> mini (or >>>> full, due to 'or' used so type will be >>>> mini >>>> anyway) dump creates dump file based >>>> on those two >>>> as before. >>>> 2) to make os::abort to get above >>>> two pointers, >>>> added two more fields to the function >>>> parameters: >>>> 3) changes for >>>> test/runtime/ErrorHandling/SecondaryError.java --- >>>> added "-XX:-CreateCoredumpOnCrash" >>>> >>>> - static void abort(bool >>>> dump_core = true); >>>> + static void abort(bool dump_core >>>> = true, >>>> void *siginfo = NULL, void *context = >>>> NULL); >>>> >>>> Tests: JPRT and manually. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/11/2015 3:47 AM, Thomas St?fe >>>> wrote: >>>> >>>> Hi Yumin, >>>> >>>> There is also >>>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>>> - could you please add >>>> "-XX:-CreateCoredumpOnCrash" ? >>>> Thank you! >>>> >>>> Beyond that, as I wrote in the bug >>>> report >>>> comments: >>>> >>>> "This is also a problem on >>>> Windows - >>>> MiniDumpWriteDump() may hang >>>> infinitly. And on >>>> Windows this is worse than under >>>> UNIX because >>>> we create the Dump before writing >>>> the hs-err >>>> file, so if the Dump hangs, we get >>>> no error >>>> log. I would like to revert the >>>> order: create >>>> the minidump after writing the >>>> error log, the >>>> same way Unix does it. We did this >>>> in our JVM >>>> (SAP) because for us, error logs >>>> are more >>>> useful than minidumps. " >>>> >>>> So, I would like to see os::abort >>>> on Windows >>>> call MiniDumpWriteDump(), and thus >>>> the mini >>>> dump writing moved after the >>>> error log >>>> writing. This would also make the >>>> code way >>>> cleaner because the control flow >>>> would be the >>>> same on all platforms. >>>> >>>> I understand that this may be out >>>> of scope for >>>> your change, but I would like to >>>> know what >>>> others think about this. >>>> >>>> Kind regards, Thomas >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Mar 11, 2015 at 8:02 AM, >>>> Yumin Qi >>>> >>> >>>> >>> > >>>> >>> >>>> >>> >>> wrote: >>>> >>>> Please review: >>>> >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>>> webrev: >>>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>> >>>> >>>> >>>> >>>> Summary: Tests timed out when >>>> VM crashes >>>> and dumping core file >>>> which in the test case is not >>>> needed. To >>>> make core not created, >>>> the fix changed >>>> CreateMinidumpOnCrash to >>>> CreateCoredumpOnCrash, >>>> the former is only used on >>>> Windows and the >>>> latter for all >>>> platforms. When VM crashes on >>>> non Windows, >>>> core file generated as >>>> default if OS sets core dump >>>> allowed. >>>> Default value of >>>> CreateCoredumpOnCrash set to >>>> 'true' to >>>> keep same behavior on non >>>> Windows platforms, but changed >>>> for Windows >>>> --- original is false, >>>> not create minidump on >>>> Windows. With >>>> CreateCoredumpOnCrash turned >>>> off, no core file will be >>>> generated. >>>> CreateMinidumpOnCrash still >>>> can be used on commandline but >>>> only as >>>> alias for the new flag. >>>> >>>> Tests: JPRT, manual tests >>>> setting >>>> CreateMinidumpOnCrash on >>>> commandline to verify flag >>>> change as alias. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > From yumin.qi at oracle.com Mon Mar 30 19:28:23 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 30 Mar 2015 12:28:23 -0700 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <55199521.7070005@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> <55106018.3020005@oracle.com> <5512FA41.3020008@oracle.com> <55199521.7070005@oracle.com> Message-ID: <5519A3D7.4040003@oracle.com> Thanks Dan On 3/30/2015 11:25 AM, Daniel D. Daugherty wrote: > On 3/25/15 12:11 PM, Yumin Qi wrote: >> Hi, all >> >> I updated the webrev with a new change to test case: >> test/runtime/Unsafe/RangeCheck.java >> >> Add -XX:-CreateCoredumpOnCrash to test, no dump needed on this case. >> >> new webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev05/ > > General nit - please update copyright lines to 2015 as needed > > src/share/vm/runtime/globals.hpp > No comments. > > src/share/vm/runtime/os.hpp > line 720: // On Windows this will create an actual minidump, on > Linux/Solaris it will simply check core dump limits > line 721: static void check_dump_limit(char* buffer, size_t > bufferSize); > The comment on line 720 no longer matches with the function > rename from check_or_create_dump() to check_dump_limit(). > > You have this comment in vmError.cpp: > 943 // check core dump limits on Linux/Solaris, nothing on > Windows > 944 os::check_dump_limit(buffer, sizeof(buffer)); > > so the two comments are out of sync. > Will convert them to be consistent. > src/share/vm/runtime/arguments.cpp > line 3252: } else if (match_option(option, > "-XX:+CreateMinidumpOnCrash", &tail)) { > line 3256: } else if (match_option(option, > "-XX:-CreateMinidumpOnCrash", &tail)) { > These two checks should use the match_option() version > without a '&tail' parameter. > Will use version w/o tail. > src/share/vm/utilities/vmError.cpp > line 217: bool VMError::coredump_status = true; // presume > we can dump core file first > I don't think you should init this to true. It confuses > things with VMError::report_coredump_status(). It will also > confuse this code: > > 526 STEP(63, "(printing core file information)") > 529 if (coredump_status) { > 530 st->print("Core dump written. Default location: > %s", coredump_message); > > because coredump_status won't accurately reflect whether > the coredump_message field has been set. > > line 943: // check core dump limits on Linux/Solaris, nothing on > Windows > This updated comment doesn't match the unmodified > comment in os.hpp: > > 720: // On Windows this will create an actual minidump, on > Linux/Solaris it will simply check core dump limits > I will consider your comments, then revise with a new version. I remember here there is a case, if status not set, it will output an inconsistent message. Will check again. > src/os/aix/vm/os_aix.cpp > No comments. > > src/os/bsd/vm/os_bsd.cpp > No comments. > > src/os/linux/vm/os_linux.cpp > No comments. > > src/os/posix/vm/os_posix.cpp > No comments. > > src/os/solaris/vm/os_solaris.cpp > No comments. > > src/os/windows/vm/os_windows.cpp > line 1008: static char buffer[O_BUFLEN]; > Why switch from a buffer parameter to a static buffer? > What happens with parallel calls to abort()? Will the static > buffer get stomped by the competing threads? The original buffer is static too. Carrying an buffer for abort seems not right. This buffer in fact only for storing file name (based on pid) here. abort() will dump the core file, should we prevent multi-thread calling to this function? I did not check this part, will check if it is MT-safe. > > line 1015: // If running on a client version of Windows and user > has not explicitly enabled dumping > line 1016: if (!os::win32::is_windows_server() && > !CreateCoredumpOnCrash) { > The default for CreateCoredumpOnCrash is now 'true' so the > comment and logic are no longer correct here. The Windows > Client VM will generate minidumps by default. > > old line 1007: VMError::report_coredump_status("Minidumps are not > enabled by default on client versions of Windows", false); > new line 1017: jio_fprintf(stderr, "Minidumps are not enabled by > default on client versions of Windows.\n"); > There are a number of places where we change from > VMError::report_coredump_status() to jio_fprintf() > and I'm not quite seeing why this was done. > > Update: VMError::report_coredump_status() is misnamed. It doesn't > report anything in the sense that it doesn't print anything. It > does record two pieces of information about core dumps so maybe > it should be VMError::record_coredump_status(). > > line 1100: jio_fprintf(stderr, "%s.\n", buffer); > At this point, buffer contains the path to the > mini-dump file so the above line simply prints > that on stderr. Why? > > Yes, I see that the old code did something similar: > > 1090 VMError::report_coredump_status(buffer, true); > > but report_coredump_status() didn't actually print > anything. It just squirreled away these in vmError.cpp: > > 217 bool VMError::coredump_status; > 218 char VMError::coredump_message[O_BUFLEN]; > > See comments above about how report_coredump_status() > is misnamed. > > At this point, I'm convinced that all the changes from > VMError::report_coredump_status() to jio_fprintf() are > a bad idea. > Changing to jio_fprintf is because report_coredump_status did not output anything, it is just a logging as you indicated. It is reasonable we change it to record_coredump_status instead. How about add printout to report_coredump_status? So I do not need to use jio_printf here. Other consideration of using jio_fprintf after call shutdown called, the static output stream still exists, but not guaranteed to work as expected. Thanks Yumin > test/runtime/ErrorHandling/ProblematicFrameTest.java > No comments. > > test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java > No comments. > > test/runtime/ErrorHandling/SecondaryErrorTest.java > No comments. > > test/runtime/Safepoint/AssertSafepointCheckConsistency1.java > No comments. > > test/runtime/Safepoint/AssertSafepointCheckConsistency2.java > No comments. > > test/runtime/Safepoint/AssertSafepointCheckConsistency3.java > No comments. > > test/runtime/Safepoint/AssertSafepointCheckConsistency4.java > No comments. > > test/runtime/Unsafe/RangeCheck.java > No comments. > > test/runtime/memory/ReadFromNoaccessArea.java > No comments. > > >> >> Thanks >> Yumin >> >> >> On 3/23/2015 11:48 AM, Yumin Qi wrote: >>> Since Thomas is not a reviewer in open jdk, I need two volunteers >>> (at least one "R"eviewer). >>> >>> Dan, since you already reviewed previous version, could you have a >>> look? >>> >>> Thanks >>> Yumin >>> >>> On 3/20/2015 3:20 PM, Yumin Qi wrote: >>>> Thomas, >>>> >>>> Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add >>>> another test case change: >>>> test/runtime/memory/ReadFromNoaccessArea.java >>>> (Thanks Dan's update) >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/20/2015 11:55 AM, Thomas St?fe wrote: >>>>> >>>>> Hi Yumin, >>>>> >>>>> I think you meant to post webrev.04? >>>>> >>>>> I looked at 04, and it looks nice. Thank you! >>>>> >>>>> (still only reviewer with r) >>>>> >>>>> Thomas >>>>> >>>>> On Mar 20, 2015 6:20 PM, "Yumin Qi" >>>> > wrote: >>>>> >>>>> Hi, All >>>>> >>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>>> >>>>> >>>>> This version is based on Thomas' suggestion. >>>>> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/18/2015 10:06 AM, Yumin Qi wrote: >>>>> >>>>> >>>>> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >>>>> >>>>> Hi Yumin, >>>>> >>>>> - just aesthetics, but on all implementations of >>>>> os_abort(), at least on the UNIX variants, maybe we could >>>>> consistently rename the parameters to be "siginfo" and >>>>> "context" instead of using Windows terms? >>>>> >>>>> Sure. >>>>> >>>>> - On check_create_dump_limit(), you do not need >>>>> exceptionRecord, contextRecord parameters anymore. The >>>>> only parameters now needed are buffer and buffer size, >>>>> which is not even an output parameter, just a scratch >>>>> buffer for this function to use for printf. For >>>>> output, it >>>>> calls VMError::report_coredump_status(...) at the end to >>>>> provide information about the core file. >>>>> >>>>> - I would rename that function from >>>>> check_create_dump_limit() to check_dump_limit() - nothing >>>>> is created anymore. >>>>> >>>>> Yes, no need to carry those two parameters. I tried to keep >>>>> less changes, but decided to change now. >>>>> >>>>> - on Windows, in os::abort(), there is no point >>>>> anymore in >>>>> calling VMError::report_coredump_status(...) because that >>>>> information is only used during error log writing which >>>>> already happened. It only makes sense to call this >>>>> function in check_create_dump_limit(), which happens >>>>> before error log writing. >>>>> Instead, maybe error messages like "Call to >>>>> MiniDumpWriteDump() failed" should just be written to >>>>> stderr? This would be consistent with Unix, where the OS >>>>> writes a short message on stderr if core file writing >>>>> fails. >>>>> >>>>> Sure, will direct output to stderr. >>>>> >>>>> - there is now a new test, >>>>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>>>> - could you please also add >>>>> "-XX:-CreateCoredumpOnCrash" ? >>>>> I just added the test and did not want to add the option >>>>> before it was available. >>>>> >>>>> OK >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> Thanks for your work! >>>>> >>>>> Thomas >>>>> >>>>> >>>>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >>>>> >>>>> >>>> >> >>>>> wrote: >>>>> >>>>> Hi, Dan and all >>>>> >>>>> I have updated webrev at: >>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>>> >>>>> >>>>> >>>>> 1) bug changed synopsis >>>>> 8074354: Make CreateMinidumpOnCrash a new >>>>> name and >>>>> available on all platforms >>>>> 2) tests: JPRT, vm.runtime.quick.testlist (on >>>>> Windows), jtreg on >>>>> Windows and Linux/Unix. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>>>> >>>>> I believe there are both JavaTest/JTREG tests in >>>>> the hotspot repo >>>>> and there are VM/NSK tests from back when we did >>>>> phone home... >>>>> >>>>> Check with Christian or Misha... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>>>> >>>>> Thanks, Dan >>>>> >>>>> Will look at and run those tests. Are they >>>>> under nsk? >>>>> >>>>> Yumin >>>>> >>>>> On 3/12/2015 12:29 PM, Daniel D. Daugherty >>>>> wrote: >>>>> >>>>> Yumin, >>>>> >>>>> There are some error handler tests. You >>>>> should find >>>>> those and make >>>>> sure that you run them on Windows >>>>> since you're >>>>> changing the order >>>>> there... >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>>> >>>>> Hi, Thomas and all >>>>> >>>>> The second version of the change: >>>>> webrev: >>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>>> >>>>> >>>>> >>>>> In this version: >>>>> 1) switch order on Windows to >>>>> first >>>>> print log >>>>> file as other platform, then dump >>>>> core >>>>> file if >>>>> needed. When VMError created after >>>>> crash, siginfo >>>>> and context which are >>>>> ExceptionRecord and >>>>> ContextRecord on Windows are >>>>> recorded, >>>>> mini (or >>>>> full, due to 'or' used so type >>>>> will be >>>>> mini >>>>> anyway) dump creates dump file based >>>>> on those two >>>>> as before. >>>>> 2) to make os::abort to get above >>>>> two pointers, >>>>> added two more fields to the function >>>>> parameters: >>>>> 3) changes for >>>>> test/runtime/ErrorHandling/SecondaryError.java --- >>>>> added "-XX:-CreateCoredumpOnCrash" >>>>> >>>>> - static void abort(bool >>>>> dump_core = true); >>>>> + static void abort(bool >>>>> dump_core >>>>> = true, >>>>> void *siginfo = NULL, void *context = >>>>> NULL); >>>>> >>>>> Tests: JPRT and manually. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/11/2015 3:47 AM, Thomas St?fe >>>>> wrote: >>>>> >>>>> Hi Yumin, >>>>> >>>>> There is also >>>>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>>>> - could you please add >>>>> "-XX:-CreateCoredumpOnCrash" ? >>>>> Thank you! >>>>> >>>>> Beyond that, as I wrote in the >>>>> bug >>>>> report >>>>> comments: >>>>> >>>>> "This is also a problem on >>>>> Windows - >>>>> MiniDumpWriteDump() may hang >>>>> infinitly. And on >>>>> Windows this is worse than under >>>>> UNIX because >>>>> we create the Dump before writing >>>>> the hs-err >>>>> file, so if the Dump hangs, we >>>>> get >>>>> no error >>>>> log. I would like to revert the >>>>> order: create >>>>> the minidump after writing the >>>>> error log, the >>>>> same way Unix does it. We did >>>>> this >>>>> in our JVM >>>>> (SAP) because for us, error logs >>>>> are more >>>>> useful than minidumps. " >>>>> >>>>> So, I would like to see os::abort >>>>> on Windows >>>>> call MiniDumpWriteDump(), and >>>>> thus >>>>> the mini >>>>> dump writing moved after the >>>>> error log >>>>> writing. This would also make the >>>>> code way >>>>> cleaner because the control flow >>>>> would be the >>>>> same on all platforms. >>>>> >>>>> I understand that this may be out >>>>> of scope for >>>>> your change, but I would like to >>>>> know what >>>>> others think about this. >>>>> >>>>> Kind regards, Thomas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Mar 11, 2015 at 8:02 AM, >>>>> Yumin Qi >>>>> >>>> >>>>> >>>> > >>>>> >>>> >>>>> >>>> >>> wrote: >>>>> >>>>> Please review: >>>>> >>>>> bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>> >>>>> >>>>> >>>>> >>>>> Summary: Tests timed out when >>>>> VM crashes >>>>> and dumping core file >>>>> which in the test case is not >>>>> needed. To >>>>> make core not created, >>>>> the fix changed >>>>> CreateMinidumpOnCrash to >>>>> CreateCoredumpOnCrash, >>>>> the former is only used on >>>>> Windows and the >>>>> latter for all >>>>> platforms. When VM crashes on >>>>> non Windows, >>>>> core file generated as >>>>> default if OS sets core dump >>>>> allowed. >>>>> Default value of >>>>> CreateCoredumpOnCrash set to >>>>> 'true' to >>>>> keep same behavior on non >>>>> Windows platforms, but >>>>> changed >>>>> for Windows >>>>> --- original is false, >>>>> not create minidump on >>>>> Windows. With >>>>> CreateCoredumpOnCrash turned >>>>> off, no core file will be >>>>> generated. >>>>> CreateMinidumpOnCrash still >>>>> can be used on commandline >>>>> but >>>>> only as >>>>> alias for the new flag. >>>>> >>>>> Tests: JPRT, manual tests >>>>> setting >>>>> CreateMinidumpOnCrash on >>>>> commandline to verify flag >>>>> change as alias. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Mon Mar 30 19:51:48 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Mar 2015 13:51:48 -0600 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5519A3D7.4040003@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> <55106018.3020005@oracle.com> <5512FA41.3020008@oracle.com> <55199521.7070005@oracle.com> <5519A3D7.4040003@oracle.com> Message-ID: <5519A954.6060504@oracle.com> Re: report_coredump_status() is really record_coredump_status() The report_coredump_status() function is designed to record two things about core dumps for later reporting by the code that generates the hs_err_pid file. That's why the original report_coredump_status() didn't output anything to stderr. By changing the Windows calls to report_coredump_status() into jio_fprintf() calls you have: - put output onto stderr that should go to the hs_err_pid file - made the windows code paths work differently than the non-windows code paths Dan On 3/30/15 1:28 PM, Yumin Qi wrote: > Thanks Dan > > On 3/30/2015 11:25 AM, Daniel D. Daugherty wrote: >> On 3/25/15 12:11 PM, Yumin Qi wrote: >>> Hi, all >>> >>> I updated the webrev with a new change to test case: >>> test/runtime/Unsafe/RangeCheck.java >>> >>> Add -XX:-CreateCoredumpOnCrash to test, no dump needed on this >>> case. >>> >>> new webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev05/ >> >> General nit - please update copyright lines to 2015 as needed >> >> src/share/vm/runtime/globals.hpp >> No comments. >> >> src/share/vm/runtime/os.hpp >> line 720: // On Windows this will create an actual minidump, on >> Linux/Solaris it will simply check core dump limits >> line 721: static void check_dump_limit(char* buffer, size_t >> bufferSize); >> The comment on line 720 no longer matches with the function >> rename from check_or_create_dump() to check_dump_limit(). >> >> You have this comment in vmError.cpp: >> 943 // check core dump limits on Linux/Solaris, nothing >> on Windows >> 944 os::check_dump_limit(buffer, sizeof(buffer)); >> >> so the two comments are out of sync. >> > Will convert them to be consistent. >> src/share/vm/runtime/arguments.cpp >> line 3252: } else if (match_option(option, >> "-XX:+CreateMinidumpOnCrash", &tail)) { >> line 3256: } else if (match_option(option, >> "-XX:-CreateMinidumpOnCrash", &tail)) { >> These two checks should use the match_option() version >> without a '&tail' parameter. >> > Will use version w/o tail. >> src/share/vm/utilities/vmError.cpp >> line 217: bool VMError::coredump_status = true; // presume >> we can dump core file first >> I don't think you should init this to true. It confuses >> things with VMError::report_coredump_status(). It will also >> confuse this code: >> >> 526 STEP(63, "(printing core file information)") >> 529 if (coredump_status) { >> 530 st->print("Core dump written. Default location: >> %s", coredump_message); >> >> because coredump_status won't accurately reflect whether >> the coredump_message field has been set. >> >> line 943: // check core dump limits on Linux/Solaris, nothing on >> Windows >> This updated comment doesn't match the unmodified >> comment in os.hpp: >> >> 720: // On Windows this will create an actual minidump, on >> Linux/Solaris it will simply check core dump limits >> > I will consider your comments, then revise with a new version. I > remember here there is a case, if status not set, it will output an > inconsistent message. Will check again. >> src/os/aix/vm/os_aix.cpp >> No comments. >> >> src/os/bsd/vm/os_bsd.cpp >> No comments. >> >> src/os/linux/vm/os_linux.cpp >> No comments. >> >> src/os/posix/vm/os_posix.cpp >> No comments. >> >> src/os/solaris/vm/os_solaris.cpp >> No comments. >> >> src/os/windows/vm/os_windows.cpp >> line 1008: static char buffer[O_BUFLEN]; >> Why switch from a buffer parameter to a static buffer? >> What happens with parallel calls to abort()? Will the static >> buffer get stomped by the competing threads? > The original buffer is static too. Carrying an buffer for abort seems > not right. This buffer in fact only for storing file name (based on > pid) here. > abort() will dump the core file, should we prevent multi-thread > calling to this function? I did not check this part, will check if it > is MT-safe. > >> >> line 1015: // If running on a client version of Windows and >> user has not explicitly enabled dumping >> line 1016: if (!os::win32::is_windows_server() && >> !CreateCoredumpOnCrash) { >> The default for CreateCoredumpOnCrash is now 'true' so the >> comment and logic are no longer correct here. The Windows >> Client VM will generate minidumps by default. >> >> old line 1007: VMError::report_coredump_status("Minidumps are not >> enabled by default on client versions of Windows", false); >> new line 1017: jio_fprintf(stderr, "Minidumps are not enabled by >> default on client versions of Windows.\n"); >> There are a number of places where we change from >> VMError::report_coredump_status() to jio_fprintf() >> and I'm not quite seeing why this was done. >> >> Update: VMError::report_coredump_status() is misnamed. It >> doesn't >> report anything in the sense that it doesn't print anything. It >> does record two pieces of information about core dumps so maybe >> it should be VMError::record_coredump_status(). >> >> line 1100: jio_fprintf(stderr, "%s.\n", buffer); >> At this point, buffer contains the path to the >> mini-dump file so the above line simply prints >> that on stderr. Why? >> >> Yes, I see that the old code did something similar: >> >> 1090 VMError::report_coredump_status(buffer, true); >> >> but report_coredump_status() didn't actually print >> anything. It just squirreled away these in vmError.cpp: >> >> 217 bool VMError::coredump_status; >> 218 char VMError::coredump_message[O_BUFLEN]; >> >> See comments above about how report_coredump_status() >> is misnamed. >> >> At this point, I'm convinced that all the changes from >> VMError::report_coredump_status() to jio_fprintf() are >> a bad idea. >> > > Changing to jio_fprintf is because report_coredump_status did not > output anything, it is just a logging as you indicated. It is > reasonable we change it to record_coredump_status instead. How about > add printout to report_coredump_status? So I do not need to use > jio_printf here. > > Other consideration of using jio_fprintf after call shutdown called, > the static output stream still exists, but not guaranteed to work as > expected. > > > Thanks > Yumin >> test/runtime/ErrorHandling/ProblematicFrameTest.java >> No comments. >> >> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >> No comments. >> >> test/runtime/ErrorHandling/SecondaryErrorTest.java >> No comments. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >> No comments. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >> No comments. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >> No comments. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >> No comments. >> >> test/runtime/Unsafe/RangeCheck.java >> No comments. >> >> test/runtime/memory/ReadFromNoaccessArea.java >> No comments. >> >> >>> >>> Thanks >>> Yumin >>> >>> >>> On 3/23/2015 11:48 AM, Yumin Qi wrote: >>>> Since Thomas is not a reviewer in open jdk, I need two volunteers >>>> (at least one "R"eviewer). >>>> >>>> Dan, since you already reviewed previous version, could you have a >>>> look? >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/20/2015 3:20 PM, Yumin Qi wrote: >>>>> Thomas, >>>>> >>>>> Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add >>>>> another test case change: >>>>> test/runtime/memory/ReadFromNoaccessArea.java >>>>> (Thanks Dan's update) >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/20/2015 11:55 AM, Thomas St?fe wrote: >>>>>> >>>>>> Hi Yumin, >>>>>> >>>>>> I think you meant to post webrev.04? >>>>>> >>>>>> I looked at 04, and it looks nice. Thank you! >>>>>> >>>>>> (still only reviewer with r) >>>>>> >>>>>> Thomas >>>>>> >>>>>> On Mar 20, 2015 6:20 PM, "Yumin Qi" >>>>> > wrote: >>>>>> >>>>>> Hi, All >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>>>> >>>>>> >>>>>> This version is based on Thomas' suggestion. >>>>>> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/18/2015 10:06 AM, Yumin Qi wrote: >>>>>> >>>>>> >>>>>> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >>>>>> >>>>>> Hi Yumin, >>>>>> >>>>>> - just aesthetics, but on all implementations of >>>>>> os_abort(), at least on the UNIX variants, maybe we >>>>>> could >>>>>> consistently rename the parameters to be "siginfo" and >>>>>> "context" instead of using Windows terms? >>>>>> >>>>>> Sure. >>>>>> >>>>>> - On check_create_dump_limit(), you do not need >>>>>> exceptionRecord, contextRecord parameters anymore. The >>>>>> only parameters now needed are buffer and buffer size, >>>>>> which is not even an output parameter, just a scratch >>>>>> buffer for this function to use for printf. For >>>>>> output, it >>>>>> calls VMError::report_coredump_status(...) at the end to >>>>>> provide information about the core file. >>>>>> >>>>>> - I would rename that function from >>>>>> check_create_dump_limit() to check_dump_limit() - >>>>>> nothing >>>>>> is created anymore. >>>>>> >>>>>> Yes, no need to carry those two parameters. I tried to keep >>>>>> less changes, but decided to change now. >>>>>> >>>>>> - on Windows, in os::abort(), there is no point >>>>>> anymore in >>>>>> calling VMError::report_coredump_status(...) because >>>>>> that >>>>>> information is only used during error log writing which >>>>>> already happened. It only makes sense to call this >>>>>> function in check_create_dump_limit(), which happens >>>>>> before error log writing. >>>>>> Instead, maybe error messages like "Call to >>>>>> MiniDumpWriteDump() failed" should just be written to >>>>>> stderr? This would be consistent with Unix, where the OS >>>>>> writes a short message on stderr if core file writing >>>>>> fails. >>>>>> >>>>>> Sure, will direct output to stderr. >>>>>> >>>>>> - there is now a new test, >>>>>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>>>>> - could you please also add >>>>>> "-XX:-CreateCoredumpOnCrash" ? >>>>>> I just added the test and did not want to add the option >>>>>> before it was available. >>>>>> >>>>>> OK >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> Thanks for your work! >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >>>>>> >>>>>> >>>>> >> >>>>>> wrote: >>>>>> >>>>>> Hi, Dan and all >>>>>> >>>>>> I have updated webrev at: >>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>>>> >>>>>> >>>>>> >>>>>> 1) bug changed synopsis >>>>>> 8074354: Make CreateMinidumpOnCrash a new >>>>>> name and >>>>>> available on all platforms >>>>>> 2) tests: JPRT, vm.runtime.quick.testlist (on >>>>>> Windows), jtreg on >>>>>> Windows and Linux/Unix. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>> I believe there are both JavaTest/JTREG tests in >>>>>> the hotspot repo >>>>>> and there are VM/NSK tests from back when we did >>>>>> phone home... >>>>>> >>>>>> Check with Christian or Misha... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>>>>> >>>>>> Thanks, Dan >>>>>> >>>>>> Will look at and run those tests. Are they >>>>>> under nsk? >>>>>> >>>>>> Yumin >>>>>> >>>>>> On 3/12/2015 12:29 PM, Daniel D. >>>>>> Daugherty wrote: >>>>>> >>>>>> Yumin, >>>>>> >>>>>> There are some error handler tests. You >>>>>> should find >>>>>> those and make >>>>>> sure that you run them on Windows >>>>>> since you're >>>>>> changing the order >>>>>> there... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>>>> >>>>>> Hi, Thomas and all >>>>>> >>>>>> The second version of the change: >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>>>> >>>>>> >>>>>> >>>>>> In this version: >>>>>> 1) switch order on Windows to >>>>>> first >>>>>> print log >>>>>> file as other platform, then dump >>>>>> core >>>>>> file if >>>>>> needed. When VMError created after >>>>>> crash, siginfo >>>>>> and context which are >>>>>> ExceptionRecord and >>>>>> ContextRecord on Windows are >>>>>> recorded, >>>>>> mini (or >>>>>> full, due to 'or' used so type >>>>>> will be >>>>>> mini >>>>>> anyway) dump creates dump file based >>>>>> on those two >>>>>> as before. >>>>>> 2) to make os::abort to get above >>>>>> two pointers, >>>>>> added two more fields to the >>>>>> function >>>>>> parameters: >>>>>> 3) changes for >>>>>> test/runtime/ErrorHandling/SecondaryError.java --- >>>>>> added "-XX:-CreateCoredumpOnCrash" >>>>>> >>>>>> - static void abort(bool >>>>>> dump_core = true); >>>>>> + static void abort(bool >>>>>> dump_core >>>>>> = true, >>>>>> void *siginfo = NULL, void >>>>>> *context = >>>>>> NULL); >>>>>> >>>>>> Tests: JPRT and manually. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/11/2015 3:47 AM, Thomas >>>>>> St?fe wrote: >>>>>> >>>>>> Hi Yumin, >>>>>> >>>>>> There is also >>>>>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>>>>> - could you please add >>>>>> "-XX:-CreateCoredumpOnCrash" ? >>>>>> Thank you! >>>>>> >>>>>> Beyond that, as I wrote in >>>>>> the bug >>>>>> report >>>>>> comments: >>>>>> >>>>>> "This is also a problem on >>>>>> Windows - >>>>>> MiniDumpWriteDump() may hang >>>>>> infinitly. And on >>>>>> Windows this is worse than under >>>>>> UNIX because >>>>>> we create the Dump before >>>>>> writing >>>>>> the hs-err >>>>>> file, so if the Dump hangs, >>>>>> we get >>>>>> no error >>>>>> log. I would like to revert the >>>>>> order: create >>>>>> the minidump after writing the >>>>>> error log, the >>>>>> same way Unix does it. We did >>>>>> this >>>>>> in our JVM >>>>>> (SAP) because for us, error logs >>>>>> are more >>>>>> useful than minidumps. " >>>>>> >>>>>> So, I would like to see >>>>>> os::abort >>>>>> on Windows >>>>>> call MiniDumpWriteDump(), and >>>>>> thus >>>>>> the mini >>>>>> dump writing moved after the >>>>>> error log >>>>>> writing. This would also make >>>>>> the >>>>>> code way >>>>>> cleaner because the control flow >>>>>> would be the >>>>>> same on all platforms. >>>>>> >>>>>> I understand that this may be >>>>>> out >>>>>> of scope for >>>>>> your change, but I would like to >>>>>> know what >>>>>> others think about this. >>>>>> >>>>>> Kind regards, Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 11, 2015 at 8:02 AM, >>>>>> Yumin Qi >>>>>> >>>>> >>>>>> >>>>> > >>>>>> >>>>> >>>>>> >>>>> >>> wrote: >>>>>> >>>>>> Please review: >>>>>> >>>>>> bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary: Tests timed out >>>>>> when >>>>>> VM crashes >>>>>> and dumping core file >>>>>> which in the test case is >>>>>> not >>>>>> needed. To >>>>>> make core not created, >>>>>> the fix changed >>>>>> CreateMinidumpOnCrash to >>>>>> CreateCoredumpOnCrash, >>>>>> the former is only used on >>>>>> Windows and the >>>>>> latter for all >>>>>> platforms. When VM >>>>>> crashes on >>>>>> non Windows, >>>>>> core file generated as >>>>>> default if OS sets core dump >>>>>> allowed. >>>>>> Default value of >>>>>> CreateCoredumpOnCrash set to >>>>>> 'true' to >>>>>> keep same behavior on non >>>>>> Windows platforms, but >>>>>> changed >>>>>> for Windows >>>>>> --- original is false, >>>>>> not create minidump on >>>>>> Windows. With >>>>>> CreateCoredumpOnCrash turned >>>>>> off, no core file will be >>>>>> generated. >>>>>> CreateMinidumpOnCrash still >>>>>> can be used on >>>>>> commandline but >>>>>> only as >>>>>> alias for the new flag. >>>>>> >>>>>> Tests: JPRT, manual tests >>>>>> setting >>>>>> CreateMinidumpOnCrash on >>>>>> commandline to verify flag >>>>>> change as alias. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Mon Mar 30 20:32:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 06:32:09 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <551962F8.6050403@oracle.com> References: <55022B6F.5090104@oracle.com> <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> <5518A954.1060009@oracle.com> <551962F8.6050403@oracle.com> Message-ID: <5519B2C9.8020204@oracle.com> On 31/03/2015 12:51 AM, Coleen Phillimore wrote: > > On 3/29/15, 9:39 PM, David Holmes wrote: >> On 27/03/2015 5:24 PM, Jeremy Manson wrote: >>> I hate to see legacy cruft deliberately introduced into the codebase. I >>> guess it is too painful to turn it off in a makefile? Stuff ignored by >>> compilers in rarely touched code like this tends to turn crufty and >>> become confusing, e.g., something I saw a month or two ago: >>> >>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 >>> >>> >>> Referring you to a page in what you have to think about for a second >>> before you realize is JVMS v1, which has been obsolete since 2000, and >>> is unavailable from the publisher. >> >> But happens to be the version you would find sitting on the >> bookshelves of the Oracle VM team members :) A section reference would >> be better than a page number, but even they change over time. >> >>> Doing it this way seems fine to me, but I don't know anything about >>> suppressing warnings on Windows, so that's not a firm endorsement. Not >>> that my non-reviewer endorsement would do you any good. >> >> Okay. Still need a second review - calling Coleen! > > This seems fine although I think I'd prefer the #pragma nowarnings out > of the middle of the functions to not interrupt reading of these > functions. I don't think #pragmas are scoped. This one is, it applies only to the next line: https://msdn.microsoft.com/en-us/library/2c8f766e.aspx I was attempting to minimize the impact by only disabling the warning where it was occurring. But I can broaden the scope to cover the whole function with a push/pop instead if people really think that would be better. Thanks, David > Coleen > >> >> I'd really like to get this out of my repo and pushed :) >> >> Thanks, >> David >> >>> Jeremy >>> >>> On Wed, Mar 25, 2015 at 11:41 PM, David Holmes >> > wrote: >>> >>> Okay I managed to fix this with: >>> >>> --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>> 02:34:35.715892476 -0400 >>> +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>> 02:34:34.663833288 -0400 >>> @@ -168,6 +168,8 @@ >>> GrowableArray(int initial_size, bool C_heap = false, MEMFLAGS F >>> = mtInternal) >>> : GenericGrowableArray(initial___size, 0, C_heap, F) { >>> _data = (E*)raw_allocate(sizeof(E)); >>> +// Needed for Visual Studio 2012 and older >>> +#pragma warning(suppress: 4345) >>> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >>> } >>> >>> @@ -385,6 +387,8 @@ >>> E* newData = (E*)raw_allocate(sizeof(E)); >>> int i = 0; >>> for ( ; i < _len; i++) ::new ((void*)&newData[i]) >>> E(_data[i]); >>> +// Needed for Visual Studio 2012 and older >>> +#pragma warning(suppress: 4345) >>> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >>> for (i = 0; i < old_max; i++) _data[i].~E(); >>> if (on_C_heap() && _data != NULL) { >>> >>> So unless someone finds this totally objectionable it is what I >>> propose to go with. Full webrev at: >>> >>> http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ >>> >>> >>> Thanks, >>> David >>> >>> >>> On 25/03/2015 2:24 PM, David Holmes wrote: >>> >>> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >>> >>> Thanks, Kim. This is a pretty silly warning to have break >>> the build. >>> Does anyone have a problem with PODs being default >>> initialized? That's >>> required by the standard, so if you do, then you are Doing >>> It Wrong. >>> >>> I assume it is pretty easy to turn the warning off. I'd do >>> it, but I >>> don't have the Windows build-fu necessary. Also, do we >>> think it would >>> require another bug? >>> >>> >>> Unless someone else can already tell me how I will try to >>> find the >>> cycles to either disable the warning in that file (if that >>> works) else >>> disable it in the build - which will need a new CR I think. >>> >>> David >>> >>> I'd hate to have to change my (or any) code for this. >>> >>> Jeremy >>> >>> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >>> >>> >> __>> wrote: >>> >>> On Mar 23, 2015, at 3:45 AM, David Holmes >>> >>> >> >> wrote: >>> > >>> > On 23/03/2015 4:12 PM, David Holmes wrote: >>> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>> >>> Argh. Yes. Martin told me not to get involved >>> with Windows, >>> but would >>> >>> I listen? Of course not... >>> >>> >>> >>> >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ >>> >>> >> >>> >> Looks okay to me - running a test job now. >>> > >>> > This just isn't meant to be :( It seems that: >>> > >>> > GrowableArray options(2, true); >>> > >>> > in arguments.cpp is giving the windows compiler some >>> grief: >>> > >>> > >>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >>> >>> : error C2220: warning treated as error - no 'object' file >>> generated >>> > >>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__168) >>> >>> : while compiling class template member function >>> 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' >>> > with >>> > [ >>> > E=JavaVMOption >>> > ] >>> > >>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\runtime\__arguments.cpp(3516) >>> >>> : see reference to class template instantiation >>> 'GrowableArray' >>> being compiled >>> > with >>> > [ >>> > E=JavaVMOption >>> > ] >>> > >>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >>> >>> : warning C4345: behavior change: an object of POD type >>> constructed >>> with an initializer of the form () will be >>> default-initialized >>> > >>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__388) >>> >>> : warning C4345: behavior change: an object of POD type >>> constructed >>> with an initializer of the form () will be >>> default-initialized >>> > >>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__379) >>> >>> : while compiling class template member function 'void >>> GrowableArray::grow(int)' >>> > with >>> > [ >>> > E=JavaVMOption >>> > ] >>> > >>> > I'm guessing it doesn't like the enum as the generic >>> arg, but >>> don't know why given that it accepts plain int elsewhere. >>> ??? >>> >>> Just suppressing this warning (unconditionally >>> everywhere) would >>> probably make sense. >>> >>> Microsoft describes it as an obsolete warning: >>> >>> https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx >>> >>> >>> "This warning is obsolete. It is only generated in >>> Visual Studio >>> 2005 through Visual Studio 2012. It reports a behavior >>> change from >>> the Visual C++ compiler that shipped in Visual Studio >>> .NET when >>> initializing a POD (plain old data) object with (); the >>> compiler >>> default-initializes the object.? >>> >>> It?s too bad the JDK9 supported build platform for >>> Windows is still >>> lagging. >>> >>> >>> > From coleen.phillimore at oracle.com Mon Mar 30 20:39:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 30 Mar 2015 16:39:00 -0400 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5519B2C9.8020204@oracle.com> References: <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> <5518A954.1060009@oracle.com> <551962F8.6050403@oracle.com> <5519B2C9.8020204@oracle.com> Message-ID: <5519B464.7080901@oracle.com> On 3/30/15, 4:32 PM, David Holmes wrote: > On 31/03/2015 12:51 AM, Coleen Phillimore wrote: >> >> On 3/29/15, 9:39 PM, David Holmes wrote: >>> On 27/03/2015 5:24 PM, Jeremy Manson wrote: >>>> I hate to see legacy cruft deliberately introduced into the >>>> codebase. I >>>> guess it is too painful to turn it off in a makefile? Stuff >>>> ignored by >>>> compilers in rarely touched code like this tends to turn crufty and >>>> become confusing, e.g., something I saw a month or two ago: >>>> >>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 >>>> >>>> >>>> >>>> Referring you to a page in what you have to think about for a second >>>> before you realize is JVMS v1, which has been obsolete since 2000, and >>>> is unavailable from the publisher. >>> >>> But happens to be the version you would find sitting on the >>> bookshelves of the Oracle VM team members :) A section reference would >>> be better than a page number, but even they change over time. >>> >>>> Doing it this way seems fine to me, but I don't know anything about >>>> suppressing warnings on Windows, so that's not a firm endorsement. >>>> Not >>>> that my non-reviewer endorsement would do you any good. >>> >>> Okay. Still need a second review - calling Coleen! >> >> This seems fine although I think I'd prefer the #pragma nowarnings out >> of the middle of the functions to not interrupt reading of these >> functions. I don't think #pragmas are scoped. > > This one is, it applies only to the next line: > > https://msdn.microsoft.com/en-us/library/2c8f766e.aspx > > I was attempting to minimize the impact by only disabling the warning > where it was occurring. But I can broaden the scope to cover the whole > function with a push/pop instead if people really think that would be > better. Oh, bizarre. Okay, leave it then. Coleen > > Thanks, > David > >> Coleen >> >>> >>> I'd really like to get this out of my repo and pushed :) >>> >>> Thanks, >>> David >>> >>>> Jeremy >>>> >>>> On Wed, Mar 25, 2015 at 11:41 PM, David Holmes >>>> >>> > wrote: >>>> >>>> Okay I managed to fix this with: >>>> >>>> --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>>> 02:34:35.715892476 -0400 >>>> +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>>> 02:34:34.663833288 -0400 >>>> @@ -168,6 +168,8 @@ >>>> GrowableArray(int initial_size, bool C_heap = false, >>>> MEMFLAGS F >>>> = mtInternal) >>>> : GenericGrowableArray(initial___size, 0, C_heap, F) { >>>> _data = (E*)raw_allocate(sizeof(E)); >>>> +// Needed for Visual Studio 2012 and older >>>> +#pragma warning(suppress: 4345) >>>> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >>>> } >>>> >>>> @@ -385,6 +387,8 @@ >>>> E* newData = (E*)raw_allocate(sizeof(E)); >>>> int i = 0; >>>> for ( ; i < _len; i++) ::new ((void*)&newData[i]) >>>> E(_data[i]); >>>> +// Needed for Visual Studio 2012 and older >>>> +#pragma warning(suppress: 4345) >>>> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >>>> for (i = 0; i < old_max; i++) _data[i].~E(); >>>> if (on_C_heap() && _data != NULL) { >>>> >>>> So unless someone finds this totally objectionable it is what I >>>> propose to go with. Full webrev at: >>>> >>>> http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 25/03/2015 2:24 PM, David Holmes wrote: >>>> >>>> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >>>> >>>> Thanks, Kim. This is a pretty silly warning to have break >>>> the build. >>>> Does anyone have a problem with PODs being default >>>> initialized? That's >>>> required by the standard, so if you do, then you are Doing >>>> It Wrong. >>>> >>>> I assume it is pretty easy to turn the warning off. I'd do >>>> it, but I >>>> don't have the Windows build-fu necessary. Also, do we >>>> think it would >>>> require another bug? >>>> >>>> >>>> Unless someone else can already tell me how I will try to >>>> find the >>>> cycles to either disable the warning in that file (if that >>>> works) else >>>> disable it in the build - which will need a new CR I think. >>>> >>>> David >>>> >>>> I'd hate to have to change my (or any) code for this. >>>> >>>> Jeremy >>>> >>>> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >>>> >>>> >>> __>> wrote: >>>> >>>> On Mar 23, 2015, at 3:45 AM, David Holmes >>>> >>>> >>> >> wrote: >>>> > >>>> > On 23/03/2015 4:12 PM, David Holmes wrote: >>>> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>>> >>> Argh. Yes. Martin told me not to get involved >>>> with Windows, >>>> but would >>>> >>> I listen? Of course not... >>>> >>> >>>> >>>> >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ >>>> >>>> >> >>>> >> Looks okay to me - running a test job now. >>>> > >>>> > This just isn't meant to be :( It seems >>>> that: >>>> > >>>> > GrowableArray options(2, true); >>>> > >>>> > in arguments.cpp is giving the windows compiler >>>> some >>>> grief: >>>> > >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >>>> >>>> >>>> : error C2220: warning treated as error - no 'object' file >>>> generated >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__168) >>>> >>>> >>>> : while compiling class template member function >>>> 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' >>>> > with >>>> > [ >>>> > E=JavaVMOption >>>> > ] >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\runtime\__arguments.cpp(3516) >>>> >>>> >>>> : see reference to class template instantiation >>>> 'GrowableArray' >>>> being compiled >>>> > with >>>> > [ >>>> > E=JavaVMOption >>>> > ] >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >>>> >>>> >>>> : warning C4345: behavior change: an object of POD type >>>> constructed >>>> with an initializer of the form () will be >>>> default-initialized >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__388) >>>> >>>> >>>> : warning C4345: behavior change: an object of POD type >>>> constructed >>>> with an initializer of the form () will be >>>> default-initialized >>>> > >>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__379) >>>> >>>> >>>> : while compiling class template member function 'void >>>> GrowableArray::grow(int)' >>>> > with >>>> > [ >>>> > E=JavaVMOption >>>> > ] >>>> > >>>> > I'm guessing it doesn't like the enum as the >>>> generic >>>> arg, but >>>> don't know why given that it accepts plain int elsewhere. >>>> ??? >>>> >>>> Just suppressing this warning (unconditionally >>>> everywhere) would >>>> probably make sense. >>>> >>>> Microsoft describes it as an obsolete warning: >>>> >>>> https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx >>>> >>>> >>>> "This warning is obsolete. It is only generated in >>>> Visual Studio >>>> 2005 through Visual Studio 2012. It reports a >>>> behavior >>>> change from >>>> the Visual C++ compiler that shipped in Visual Studio >>>> .NET when >>>> initializing a POD (plain old data) object with >>>> (); the >>>> compiler >>>> default-initializes the object.? >>>> >>>> It?s too bad the JDK9 supported build platform for >>>> Windows is still >>>> lagging. >>>> >>>> >>>> >> From david.holmes at oracle.com Mon Mar 30 21:27:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2015 07:27:31 +1000 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5519B464.7080901@oracle.com> References: <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> <5518A954.1060009@oracle.com> <551962F8.6050403@oracle.com> <5519B2C9.8020204@oracle.com> <5519B464.7080901@oracle.com> Message-ID: <5519BFC3.5060105@oracle.com> On 31/03/2015 6:39 AM, Coleen Phillimore wrote: > > On 3/30/15, 4:32 PM, David Holmes wrote: >> On 31/03/2015 12:51 AM, Coleen Phillimore wrote: >>> >>> On 3/29/15, 9:39 PM, David Holmes wrote: >>>> On 27/03/2015 5:24 PM, Jeremy Manson wrote: >>>>> I hate to see legacy cruft deliberately introduced into the >>>>> codebase. I >>>>> guess it is too painful to turn it off in a makefile? Stuff >>>>> ignored by >>>>> compilers in rarely touched code like this tends to turn crufty and >>>>> become confusing, e.g., something I saw a month or two ago: >>>>> >>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 >>>>> >>>>> >>>>> >>>>> Referring you to a page in what you have to think about for a second >>>>> before you realize is JVMS v1, which has been obsolete since 2000, and >>>>> is unavailable from the publisher. >>>> >>>> But happens to be the version you would find sitting on the >>>> bookshelves of the Oracle VM team members :) A section reference would >>>> be better than a page number, but even they change over time. >>>> >>>>> Doing it this way seems fine to me, but I don't know anything about >>>>> suppressing warnings on Windows, so that's not a firm endorsement. Not >>>>> that my non-reviewer endorsement would do you any good. >>>> >>>> Okay. Still need a second review - calling Coleen! >>> >>> This seems fine although I think I'd prefer the #pragma nowarnings out >>> of the middle of the functions to not interrupt reading of these >>> functions. I don't think #pragmas are scoped. >> >> This one is, it applies only to the next line: >> >> https://msdn.microsoft.com/en-us/library/2c8f766e.aspx >> >> I was attempting to minimize the impact by only disabling the warning >> where it was occurring. But I can broaden the scope to cover the whole >> function with a push/pop instead if people really think that would be >> better. > > Oh, bizarre. Okay, leave it then. I will leave it and push in its current form. Thanks, David > Coleen > >> >> Thanks, >> David >> >>> Coleen >>> >>>> >>>> I'd really like to get this out of my repo and pushed :) >>>> >>>> Thanks, >>>> David >>>> >>>>> Jeremy >>>>> >>>>> On Wed, Mar 25, 2015 at 11:41 PM, David Holmes >>>>> >>>> > wrote: >>>>> >>>>> Okay I managed to fix this with: >>>>> >>>>> --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>>>> 02:34:35.715892476 -0400 >>>>> +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>>>> 02:34:34.663833288 -0400 >>>>> @@ -168,6 +168,8 @@ >>>>> GrowableArray(int initial_size, bool C_heap = false, >>>>> MEMFLAGS F >>>>> = mtInternal) >>>>> : GenericGrowableArray(initial___size, 0, C_heap, F) { >>>>> _data = (E*)raw_allocate(sizeof(E)); >>>>> +// Needed for Visual Studio 2012 and older >>>>> +#pragma warning(suppress: 4345) >>>>> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >>>>> } >>>>> >>>>> @@ -385,6 +387,8 @@ >>>>> E* newData = (E*)raw_allocate(sizeof(E)); >>>>> int i = 0; >>>>> for ( ; i < _len; i++) ::new ((void*)&newData[i]) >>>>> E(_data[i]); >>>>> +// Needed for Visual Studio 2012 and older >>>>> +#pragma warning(suppress: 4345) >>>>> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >>>>> for (i = 0; i < old_max; i++) _data[i].~E(); >>>>> if (on_C_heap() && _data != NULL) { >>>>> >>>>> So unless someone finds this totally objectionable it is what I >>>>> propose to go with. Full webrev at: >>>>> >>>>> http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 25/03/2015 2:24 PM, David Holmes wrote: >>>>> >>>>> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >>>>> >>>>> Thanks, Kim. This is a pretty silly warning to have break >>>>> the build. >>>>> Does anyone have a problem with PODs being default >>>>> initialized? That's >>>>> required by the standard, so if you do, then you are Doing >>>>> It Wrong. >>>>> >>>>> I assume it is pretty easy to turn the warning off. I'd do >>>>> it, but I >>>>> don't have the Windows build-fu necessary. Also, do we >>>>> think it would >>>>> require another bug? >>>>> >>>>> >>>>> Unless someone else can already tell me how I will try to >>>>> find the >>>>> cycles to either disable the warning in that file (if that >>>>> works) else >>>>> disable it in the build - which will need a new CR I think. >>>>> >>>>> David >>>>> >>>>> I'd hate to have to change my (or any) code for this. >>>>> >>>>> Jeremy >>>>> >>>>> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >>>>> >>>>> >>>> __>> wrote: >>>>> >>>>> On Mar 23, 2015, at 3:45 AM, David Holmes >>>>> >>>>> >>>> >> wrote: >>>>> > >>>>> > On 23/03/2015 4:12 PM, David Holmes wrote: >>>>> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>>>> >>> Argh. Yes. Martin told me not to get involved >>>>> with Windows, >>>>> but would >>>>> >>> I listen? Of course not... >>>>> >>> >>>>> >>>>> >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ >>>>> >>>>> >> >>>>> >> Looks okay to me - running a test job now. >>>>> > >>>>> > This just isn't meant to be :( It seems >>>>> that: >>>>> > >>>>> > GrowableArray options(2, true); >>>>> > >>>>> > in arguments.cpp is giving the windows compiler >>>>> some >>>>> grief: >>>>> > >>>>> > >>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >>>>> >>>>> >>>>> : error C2220: warning treated as error - no 'object' file >>>>> generated >>>>> > >>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__168) >>>>> >>>>> >>>>> : while compiling class template member function >>>>> 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' >>>>> > with >>>>> > [ >>>>> > E=JavaVMOption >>>>> > ] >>>>> > >>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\runtime\__arguments.cpp(3516) >>>>> >>>>> >>>>> : see reference to class template instantiation >>>>> 'GrowableArray' >>>>> being compiled >>>>> > with >>>>> > [ >>>>> > E=JavaVMOption >>>>> > ] >>>>> > >>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__171) >>>>> >>>>> >>>>> : warning C4345: behavior change: an object of POD type >>>>> constructed >>>>> with an initializer of the form () will be >>>>> default-initialized >>>>> > >>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__388) >>>>> >>>>> >>>>> : warning C4345: behavior change: an object of POD type >>>>> constructed >>>>> with an initializer of the form () will be >>>>> default-initialized >>>>> > >>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__utilities/growableArray.hpp(__379) >>>>> >>>>> >>>>> : while compiling class template member function 'void >>>>> GrowableArray::grow(int)' >>>>> > with >>>>> > [ >>>>> > E=JavaVMOption >>>>> > ] >>>>> > >>>>> > I'm guessing it doesn't like the enum as the >>>>> generic >>>>> arg, but >>>>> don't know why given that it accepts plain int elsewhere. >>>>> ??? >>>>> >>>>> Just suppressing this warning (unconditionally >>>>> everywhere) would >>>>> probably make sense. >>>>> >>>>> Microsoft describes it as an obsolete warning: >>>>> >>>>> https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx >>>>> >>>>> >>>>> "This warning is obsolete. It is only generated in >>>>> Visual Studio >>>>> 2005 through Visual Studio 2012. It reports a >>>>> behavior >>>>> change from >>>>> the Visual C++ compiler that shipped in Visual Studio >>>>> .NET when >>>>> initializing a POD (plain old data) object with >>>>> (); the >>>>> compiler >>>>> default-initializes the object.? >>>>> >>>>> It?s too bad the JDK9 supported build platform for >>>>> Windows is still >>>>> lagging. >>>>> >>>>> >>>>> >>> > From jeremymanson at google.com Tue Mar 31 03:34:01 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 30 Mar 2015 20:34:01 -0700 Subject: RFR: 8074895: os::getenv is inadequate In-Reply-To: <5519BFC3.5060105@oracle.com> References: <5506645C.4050201@oracle.com> <5508DC97.8040508@oracle.com> <5508FA69.7040004@oracle.com> <550929D6.2050509@oracle.com> <5509F074.70501@oracle.com> <550FAEC2.5040908@oracle.com> <550FC4B2.1000606@oracle.com> <4D8447AC-1D99-4000-B680-8D3CA95C5BCE@oracle.com> <55123889.7080504@oracle.com> <5513AA32.4020901@oracle.com> <5518A954.1060009@oracle.com> <551962F8.6050403@oracle.com> <5519B2C9.8020204@oracle.com> <5519B464.7080901@oracle.com> <5519BFC3.5060105@oracle.com> Message-ID: Thanks, David! I'm sorry it was so much work. Hopefully, I will be able to avoid breaking things on Windows in the future. Jeremy On Mon, Mar 30, 2015 at 2:27 PM, David Holmes wrote: > On 31/03/2015 6:39 AM, Coleen Phillimore wrote: > >> >> On 3/30/15, 4:32 PM, David Holmes wrote: >> >>> On 31/03/2015 12:51 AM, Coleen Phillimore wrote: >>> >>>> >>>> On 3/29/15, 9:39 PM, David Holmes wrote: >>>> >>>>> On 27/03/2015 5:24 PM, Jeremy Manson wrote: >>>>> >>>>>> I hate to see legacy cruft deliberately introduced into the >>>>>> codebase. I >>>>>> guess it is too painful to turn it off in a makefile? Stuff >>>>>> ignored by >>>>>> compilers in rarely touched code like this tends to turn crufty and >>>>>> become confusing, e.g., something I saw a month or two ago: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/ >>>>>> f68d656d1f5e/src/share/vm/oops/instanceKlass.cpp#l784 >>>>>> >>>>>> >>>>>> >>>>>> Referring you to a page in what you have to think about for a second >>>>>> before you realize is JVMS v1, which has been obsolete since 2000, and >>>>>> is unavailable from the publisher. >>>>>> >>>>> >>>>> But happens to be the version you would find sitting on the >>>>> bookshelves of the Oracle VM team members :) A section reference would >>>>> be better than a page number, but even they change over time. >>>>> >>>>> Doing it this way seems fine to me, but I don't know anything about >>>>>> suppressing warnings on Windows, so that's not a firm endorsement. Not >>>>>> that my non-reviewer endorsement would do you any good. >>>>>> >>>>> >>>>> Okay. Still need a second review - calling Coleen! >>>>> >>>> >>>> This seems fine although I think I'd prefer the #pragma nowarnings out >>>> of the middle of the functions to not interrupt reading of these >>>> functions. I don't think #pragmas are scoped. >>>> >>> >>> This one is, it applies only to the next line: >>> >>> https://msdn.microsoft.com/en-us/library/2c8f766e.aspx >>> >>> I was attempting to minimize the impact by only disabling the warning >>> where it was occurring. But I can broaden the scope to cover the whole >>> function with a push/pop instead if people really think that would be >>> better. >>> >> >> Oh, bizarre. Okay, leave it then. >> > > I will leave it and push in its current form. > > Thanks, > David > > > Coleen >> >> >>> Thanks, >>> David >>> >>> Coleen >>>> >>>> >>>>> I'd really like to get this out of my repo and pushed :) >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> Jeremy >>>>>> >>>>>> On Wed, Mar 25, 2015 at 11:41 PM, David Holmes >>>>>> >>>>> > wrote: >>>>>> >>>>>> Okay I managed to fix this with: >>>>>> >>>>>> --- old/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>>>>> 02:34:35.715892476 -0400 >>>>>> +++ new/src/share/vm/utilities/__growableArray.hpp 2015-03-26 >>>>>> 02:34:34.663833288 -0400 >>>>>> @@ -168,6 +168,8 @@ >>>>>> GrowableArray(int initial_size, bool C_heap = false, >>>>>> MEMFLAGS F >>>>>> = mtInternal) >>>>>> : GenericGrowableArray(initial___size, 0, C_heap, F) { >>>>>> _data = (E*)raw_allocate(sizeof(E)); >>>>>> +// Needed for Visual Studio 2012 and older >>>>>> +#pragma warning(suppress: 4345) >>>>>> for (int i = 0; i < _max; i++) ::new ((void*)&_data[i]) E(); >>>>>> } >>>>>> >>>>>> @@ -385,6 +387,8 @@ >>>>>> E* newData = (E*)raw_allocate(sizeof(E)); >>>>>> int i = 0; >>>>>> for ( ; i < _len; i++) ::new ((void*)&newData[i]) >>>>>> E(_data[i]); >>>>>> +// Needed for Visual Studio 2012 and older >>>>>> +#pragma warning(suppress: 4345) >>>>>> for ( ; i < _max; i++) ::new ((void*)&newData[i]) E(); >>>>>> for (i = 0; i < old_max; i++) _data[i].~E(); >>>>>> if (on_C_heap() && _data != NULL) { >>>>>> >>>>>> So unless someone finds this totally objectionable it is what I >>>>>> propose to go with. Full webrev at: >>>>>> >>>>>> http://cr.openjdk.java.net/~__dholmes/8074895/webrev/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> On 25/03/2015 2:24 PM, David Holmes wrote: >>>>>> >>>>>> On 24/03/2015 2:56 AM, Jeremy Manson wrote: >>>>>> >>>>>> Thanks, Kim. This is a pretty silly warning to have break >>>>>> the build. >>>>>> Does anyone have a problem with PODs being default >>>>>> initialized? That's >>>>>> required by the standard, so if you do, then you are Doing >>>>>> It Wrong. >>>>>> >>>>>> I assume it is pretty easy to turn the warning off. I'd do >>>>>> it, but I >>>>>> don't have the Windows build-fu necessary. Also, do we >>>>>> think it would >>>>>> require another bug? >>>>>> >>>>>> >>>>>> Unless someone else can already tell me how I will try to >>>>>> find the >>>>>> cycles to either disable the warning in that file (if that >>>>>> works) else >>>>>> disable it in the build - which will need a new CR I think. >>>>>> >>>>>> David >>>>>> >>>>>> I'd hate to have to change my (or any) code for this. >>>>>> >>>>>> Jeremy >>>>>> >>>>>> On Mon, Mar 23, 2015 at 8:48 AM, Kim Barrett >>>>>> >>>>>> >>>>> __>> wrote: >>>>>> >>>>>> On Mar 23, 2015, at 3:45 AM, David Holmes >>>>>> >>>>>> >>>>> >> wrote: >>>>>> > >>>>>> > On 23/03/2015 4:12 PM, David Holmes wrote: >>>>>> >> On 21/03/2015 3:32 AM, Jeremy Manson wrote: >>>>>> >>> Argh. Yes. Martin told me not to get involved >>>>>> with Windows, >>>>>> but would >>>>>> >>> I listen? Of course not... >>>>>> >>> >>>>>> >>>>>> >>>http://cr.openjdk.java.net/__~jmanson/8074895/webrev.04/ >>>>>> >>>>>> >> >>>>>> >> Looks okay to me - running a test job now. >>>>>> > >>>>>> > This just isn't meant to be :( It seems >>>>>> that: >>>>>> > >>>>>> > GrowableArray options(2, true); >>>>>> > >>>>>> > in arguments.cpp is giving the windows compiler >>>>>> some >>>>>> grief: >>>>>> > >>>>>> > >>>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__ >>>>>> utilities/growableArray.hpp(__171) >>>>>> >>>>>> >>>>>> : error C2220: warning treated as error - no 'object' file >>>>>> generated >>>>>> > >>>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__ >>>>>> utilities/growableArray.hpp(__168) >>>>>> >>>>>> >>>>>> : while compiling class template member function >>>>>> 'GrowableArray::__GrowableArray(int,bool,__MEMFLAGS)' >>>>>> > with >>>>>> > [ >>>>>> > E=JavaVMOption >>>>>> > ] >>>>>> > >>>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\ >>>>>> runtime\__arguments.cpp(3516) >>>>>> >>>>>> >>>>>> : see reference to class template instantiation >>>>>> 'GrowableArray' >>>>>> being compiled >>>>>> > with >>>>>> > [ >>>>>> > E=JavaVMOption >>>>>> > ] >>>>>> > >>>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__ >>>>>> utilities/growableArray.hpp(__171) >>>>>> >>>>>> >>>>>> : warning C4345: behavior change: an object of POD type >>>>>> constructed >>>>>> with an initializer of the form () will be >>>>>> default-initialized >>>>>> > >>>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__ >>>>>> utilities/growableArray.hpp(__388) >>>>>> >>>>>> >>>>>> : warning C4345: behavior change: an object of POD type >>>>>> constructed >>>>>> with an initializer of the form () will be >>>>>> default-initialized >>>>>> > >>>>>> C:\jprt\T\P1\071814.daholme\s\__hotspot\src\share\vm\__ >>>>>> utilities/growableArray.hpp(__379) >>>>>> >>>>>> >>>>>> : while compiling class template member function 'void >>>>>> GrowableArray::grow(int)' >>>>>> > with >>>>>> > [ >>>>>> > E=JavaVMOption >>>>>> > ] >>>>>> > >>>>>> > I'm guessing it doesn't like the enum as the >>>>>> generic >>>>>> arg, but >>>>>> don't know why given that it accepts plain int elsewhere. >>>>>> ??? >>>>>> >>>>>> Just suppressing this warning (unconditionally >>>>>> everywhere) would >>>>>> probably make sense. >>>>>> >>>>>> Microsoft describes it as an obsolete warning: >>>>>> >>>>>> https://msdn.microsoft.com/en-__us/library/wewb47ee.aspx >>>>>> >>>>>> >>>>>> "This warning is obsolete. It is only generated in >>>>>> Visual Studio >>>>>> 2005 through Visual Studio 2012. It reports a >>>>>> behavior >>>>>> change from >>>>>> the Visual C++ compiler that shipped in Visual Studio >>>>>> .NET when >>>>>> initializing a POD (plain old data) object with >>>>>> (); the >>>>>> compiler >>>>>> default-initializes the object.? >>>>>> >>>>>> It?s too bad the JDK9 supported build platform for >>>>>> Windows is still >>>>>> lagging. >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From thomas.stuefe at gmail.com Tue Mar 31 08:25:12 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 31 Mar 2015 10:25:12 +0200 Subject: RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file In-Reply-To: <5519A954.6060504@oracle.com> References: <54FFE885.3010604@oracle.com> <5501DE15.3040700@oracle.com> <5501E900.7040301@oracle.com> <5501EE10.9040208@oracle.com> <5501F017.1000900@oracle.com> <55077D97.2070402@oracle.com> <5509B093.30904@oracle.com> <550C575F.4080102@oracle.com> <550C9D1F.2010007@oracle.com> <55106018.3020005@oracle.com> <5512FA41.3020008@oracle.com> <55199521.7070005@oracle.com> <5519A3D7.4040003@oracle.com> <5519A954.6060504@oracle.com> Message-ID: Hi Daniel, Yumin, sorry, a lot of Yumins changes were based on suggestions from me, so here more background: Yumin reversed the order of error log writing and core dumping. The reason for that are explained in detail at the start of the mail thread, in short: - on Windows core file dumping may hang - its rare but it happens - preventing error logs. Depending on who you ask, error logs are more important than minidumps, so it makes sense to first write the erorr log. - This also brings windows core paths closer to UNIX code paths. See below. About writing to stderr in os::abort(): After this change, calling VmError::report_coredump_status() in os::abort() will not do anything because the error log is already written at that point. I suggested to Yumin writing to stderr instead in os::abort() because that mimicks UNIX behaviour: On UNIX, you call abort(3), which writes a core and aborts. It writes a short message to stderr "Aborted (core dumped)" or just "Aborted". After Yumins change, on Windows os::abort also writes the core, then aborts. It made sense to me that this function should behave the same way as on UNIX: if core writing fails, write to stderr. There is no way otherwise to communicate a core dump writing failure. After writing the core, process stops. --- About the control flows: Before Yumins change: On Windows 1) os::check_or_create_dump(): we wrote the core dump and then information about the dump (file location, success or error) was handed to the misnamed VmError::report_coredump_status(), which just stored that information. 2) VmError::report(): Error log was written and in step 63 information about the core (already written at that point) was added to error log. 3) os::abort() just did an exit(3) On Unix, 1) os::check_or_create_dump(): checks the limits to guess whether core dumping later will succeed. Again, that information is handed to VmError::report_coredump_status() 2) VmError::report(): Error log is written and in step 63, information about the core's probable future location is added to error log. Here, messages use past tense, which is misleading, because the core is not yet written. 3) os::abort() calls abort(3), which stops and writes a core. Yumin pushed core file writing on Windows down to os::abort(). This brings the control flow much closer to Unix: (1) call os::check_dump_limit() to check the prerequisites for core file writing and gather a bit information to put in the error log: On Unix, limit checks, on windows, so far nothing much but precalculating the error file name. (2) VmError::report(): Error log is written and information about the core's probable location is added to error log. (3) os::abort() is called, which on all platforms: - dumps the core - if failing, writes a one-liner to stderr - stops the process. I think, if one agrees that reversing order of core dumping and error log writing on windows is a good thing, this change looks ok to me. Some improvements could make it clearer: - maybe rename "os::check_dump_limit()" (was my suggestion, sorry) to "os::check_core_prerequisites()" - that leaves room to flesh it out a bit more on Windows, where we do not have UNIX limits. - make the messages in VMError::report() future sense: "Will write core file to location.....". - Make the messages written in os::abort() on Windows clearer, and shorter, and we also do not need the buffer to be static here. Actually, if we want to be as on UNIX, just dumping "core file writing succeeded" or "failed" - maybe with an error number from GetLastError() - will be enough because the file location is already printed in the error log. Like on UNIX. Kind Regards, Thomas On Mon, Mar 30, 2015 at 9:51 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Re: report_coredump_status() is really record_coredump_status() > > The report_coredump_status() function is designed to record two > things about core dumps for later reporting by the code that > generates the hs_err_pid file. That's why the original > report_coredump_status() didn't output anything to stderr. > > By changing the Windows calls to report_coredump_status() into > jio_fprintf() calls you have: > > - put output onto stderr that should go to the hs_err_pid file > - made the windows code paths work differently than the non-windows > code paths > > Dan > > > > On 3/30/15 1:28 PM, Yumin Qi wrote: > >> Thanks Dan >> >> On 3/30/2015 11:25 AM, Daniel D. Daugherty wrote: >> >>> On 3/25/15 12:11 PM, Yumin Qi wrote: >>> >>>> Hi, all >>>> >>>> I updated the webrev with a new change to test case: >>>> test/runtime/Unsafe/RangeCheck.java >>>> >>>> Add -XX:-CreateCoredumpOnCrash to test, no dump needed on this case. >>>> >>>> new webrev: http://cr.openjdk.java.net/~minqi/8074354/webrev05/ >>>> >>> >>> General nit - please update copyright lines to 2015 as needed >>> >>> src/share/vm/runtime/globals.hpp >>> No comments. >>> >>> src/share/vm/runtime/os.hpp >>> line 720: // On Windows this will create an actual minidump, on >>> Linux/Solaris it will simply check core dump limits >>> line 721: static void check_dump_limit(char* buffer, size_t >>> bufferSize); >>> The comment on line 720 no longer matches with the function >>> rename from check_or_create_dump() to check_dump_limit(). >>> >>> You have this comment in vmError.cpp: >>> 943 // check core dump limits on Linux/Solaris, nothing on >>> Windows >>> 944 os::check_dump_limit(buffer, sizeof(buffer)); >>> >>> so the two comments are out of sync. >>> >>> Will convert them to be consistent. >> >>> src/share/vm/runtime/arguments.cpp >>> line 3252: } else if (match_option(option, >>> "-XX:+CreateMinidumpOnCrash", &tail)) { >>> line 3256: } else if (match_option(option, >>> "-XX:-CreateMinidumpOnCrash", &tail)) { >>> These two checks should use the match_option() version >>> without a '&tail' parameter. >>> >>> Will use version w/o tail. >> >>> src/share/vm/utilities/vmError.cpp >>> line 217: bool VMError::coredump_status = true; // presume we >>> can dump core file first >>> I don't think you should init this to true. It confuses >>> things with VMError::report_coredump_status(). It will also >>> confuse this code: >>> >>> 526 STEP(63, "(printing core file information)") >>> 529 if (coredump_status) { >>> 530 st->print("Core dump written. Default location: %s", >>> coredump_message); >>> >>> because coredump_status won't accurately reflect whether >>> the coredump_message field has been set. >>> >>> line 943: // check core dump limits on Linux/Solaris, nothing on >>> Windows >>> This updated comment doesn't match the unmodified >>> comment in os.hpp: >>> >>> 720: // On Windows this will create an actual minidump, on >>> Linux/Solaris it will simply check core dump limits >>> >>> I will consider your comments, then revise with a new version. I >> remember here there is a case, if status not set, it will output an >> inconsistent message. Will check again. >> >>> src/os/aix/vm/os_aix.cpp >>> No comments. >>> >>> src/os/bsd/vm/os_bsd.cpp >>> No comments. >>> >>> src/os/linux/vm/os_linux.cpp >>> No comments. >>> >>> src/os/posix/vm/os_posix.cpp >>> No comments. >>> >>> src/os/solaris/vm/os_solaris.cpp >>> No comments. >>> >>> src/os/windows/vm/os_windows.cpp >>> line 1008: static char buffer[O_BUFLEN]; >>> Why switch from a buffer parameter to a static buffer? >>> What happens with parallel calls to abort()? Will the static >>> buffer get stomped by the competing threads? >>> >> The original buffer is static too. Carrying an buffer for abort seems >> not right. This buffer in fact only for storing file name (based on pid) >> here. >> abort() will dump the core file, should we prevent multi-thread calling >> to this function? I did not check this part, will check if it is MT-safe. >> >> >>> line 1015: // If running on a client version of Windows and user >>> has not explicitly enabled dumping >>> line 1016: if (!os::win32::is_windows_server() && >>> !CreateCoredumpOnCrash) { >>> The default for CreateCoredumpOnCrash is now 'true' so the >>> comment and logic are no longer correct here. The Windows >>> Client VM will generate minidumps by default. >>> >>> old line 1007: VMError::report_coredump_status("Minidumps are not >>> enabled by default on client versions of Windows", false); >>> new line 1017: jio_fprintf(stderr, "Minidumps are not enabled by >>> default on client versions of Windows.\n"); >>> There are a number of places where we change from >>> VMError::report_coredump_status() to jio_fprintf() >>> and I'm not quite seeing why this was done. >>> >>> Update: VMError::report_coredump_status() is misnamed. It >>> doesn't >>> report anything in the sense that it doesn't print anything. It >>> does record two pieces of information about core dumps so maybe >>> it should be VMError::record_coredump_status(). >>> >>> line 1100: jio_fprintf(stderr, "%s.\n", buffer); >>> At this point, buffer contains the path to the >>> mini-dump file so the above line simply prints >>> that on stderr. Why? >>> >>> Yes, I see that the old code did something similar: >>> >>> 1090 VMError::report_coredump_status(buffer, true); >>> >>> but report_coredump_status() didn't actually print >>> anything. It just squirreled away these in vmError.cpp: >>> >>> 217 bool VMError::coredump_status; >>> 218 char VMError::coredump_message[O_BUFLEN]; >>> >>> See comments above about how report_coredump_status() >>> is misnamed. >>> >>> At this point, I'm convinced that all the changes from >>> VMError::report_coredump_status() to jio_fprintf() are >>> a bad idea. >>> >>> >> Changing to jio_fprintf is because report_coredump_status did not output >> anything, it is just a logging as you indicated. It is reasonable we change >> it to record_coredump_status instead. How about add printout to >> report_coredump_status? So I do not need to use jio_printf here. >> >> Other consideration of using jio_fprintf after call shutdown called, the >> static output stream still exists, but not guaranteed to work as expected. >> >> >> Thanks >> Yumin >> >>> test/runtime/ErrorHandling/ProblematicFrameTest.java >>> No comments. >>> >>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>> No comments. >>> >>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>> No comments. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >>> No comments. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >>> No comments. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >>> No comments. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >>> No comments. >>> >>> test/runtime/Unsafe/RangeCheck.java >>> No comments. >>> >>> test/runtime/memory/ReadFromNoaccessArea.java >>> No comments. >>> >>> >>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> On 3/23/2015 11:48 AM, Yumin Qi wrote: >>>> >>>>> Since Thomas is not a reviewer in open jdk, I need two volunteers (at >>>>> least one "R"eviewer). >>>>> >>>>> Dan, since you already reviewed previous version, could you have a >>>>> look? >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/20/2015 3:20 PM, Yumin Qi wrote: >>>>> >>>>>> Thomas, >>>>>> >>>>>> Thanks. Yes, it is webrev04. Also, I have updated webrev04 to add >>>>>> another test case change: test/runtime/memory/ >>>>>> ReadFromNoaccessArea.java >>>>>> (Thanks Dan's update) >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/20/2015 11:55 AM, Thomas St?fe wrote: >>>>>> >>>>>>> >>>>>>> Hi Yumin, >>>>>>> >>>>>>> I think you meant to post webrev.04? >>>>>>> >>>>>>> I looked at 04, and it looks nice. Thank you! >>>>>>> >>>>>>> (still only reviewer with r) >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> On Mar 20, 2015 6:20 PM, "Yumin Qi" >>>>>> yumin.qi at oracle.com>> wrote: >>>>>>> >>>>>>> Hi, All >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>>>>> >>>>>>> >>>>>>> This version is based on Thomas' suggestion. >>>>>>> Tests passed vm.runtime.quick.testlist, JPRT and manual tests. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/18/2015 10:06 AM, Yumin Qi wrote: >>>>>>> >>>>>>> >>>>>>> On 3/18/2015 4:26 AM, Thomas St?fe wrote: >>>>>>> >>>>>>> Hi Yumin, >>>>>>> >>>>>>> - just aesthetics, but on all implementations of >>>>>>> os_abort(), at least on the UNIX variants, maybe we could >>>>>>> consistently rename the parameters to be "siginfo" and >>>>>>> "context" instead of using Windows terms? >>>>>>> >>>>>>> Sure. >>>>>>> >>>>>>> - On check_create_dump_limit(), you do not need >>>>>>> exceptionRecord, contextRecord parameters anymore. The >>>>>>> only parameters now needed are buffer and buffer size, >>>>>>> which is not even an output parameter, just a scratch >>>>>>> buffer for this function to use for printf. For output, >>>>>>> it >>>>>>> calls VMError::report_coredump_status(...) at the end to >>>>>>> provide information about the core file. >>>>>>> >>>>>>> - I would rename that function from >>>>>>> check_create_dump_limit() to check_dump_limit() - nothing >>>>>>> is created anymore. >>>>>>> >>>>>>> Yes, no need to carry those two parameters. I tried to keep >>>>>>> less changes, but decided to change now. >>>>>>> >>>>>>> - on Windows, in os::abort(), there is no point anymore >>>>>>> in >>>>>>> calling VMError::report_coredump_status(...) because >>>>>>> that >>>>>>> information is only used during error log writing which >>>>>>> already happened. It only makes sense to call this >>>>>>> function in check_create_dump_limit(), which happens >>>>>>> before error log writing. >>>>>>> Instead, maybe error messages like "Call to >>>>>>> MiniDumpWriteDump() failed" should just be written to >>>>>>> stderr? This would be consistent with Unix, where the OS >>>>>>> writes a short message on stderr if core file writing >>>>>>> fails. >>>>>>> >>>>>>> Sure, will direct output to stderr. >>>>>>> >>>>>>> - there is now a new test, >>>>>>> test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java >>>>>>> - could you please also add "-XX:-CreateCoredumpOnCrash" >>>>>>> ? >>>>>>> I just added the test and did not want to add the option >>>>>>> before it was available. >>>>>>> >>>>>>> OK >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> Thanks for your work! >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 17, 2015 at 2:04 AM, Yumin Qi >>>>>>> >>>>>>> >>>>>> >>> >>>>>>> wrote: >>>>>>> >>>>>>> Hi, Dan and all >>>>>>> >>>>>>> I have updated webrev at: >>>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev03/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1) bug changed synopsis >>>>>>> 8074354: Make CreateMinidumpOnCrash a new >>>>>>> name and >>>>>>> available on all platforms >>>>>>> 2) tests: JPRT, vm.runtime.quick.testlist (on >>>>>>> Windows), jtreg on >>>>>>> Windows and Linux/Unix. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>>>> On 3/12/2015 12:59 PM, Daniel D. Daugherty wrote: >>>>>>> >>>>>>> I believe there are both JavaTest/JTREG tests in >>>>>>> the hotspot repo >>>>>>> and there are VM/NSK tests from back when we did >>>>>>> phone home... >>>>>>> >>>>>>> Check with Christian or Misha... >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 3/12/15 1:50 PM, Yumin Qi wrote: >>>>>>> >>>>>>> Thanks, Dan >>>>>>> >>>>>>> Will look at and run those tests. Are they >>>>>>> under nsk? >>>>>>> >>>>>>> Yumin >>>>>>> >>>>>>> On 3/12/2015 12:29 PM, Daniel D. Daugherty >>>>>>> wrote: >>>>>>> >>>>>>> Yumin, >>>>>>> >>>>>>> There are some error handler tests. You >>>>>>> should find >>>>>>> those and make >>>>>>> sure that you run them on Windows since >>>>>>> you're >>>>>>> changing the order >>>>>>> there... >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 3/12/15 12:42 PM, Yumin Qi wrote: >>>>>>> >>>>>>> Hi, Thomas and all >>>>>>> >>>>>>> The second version of the change: >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev02/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> In this version: >>>>>>> 1) switch order on Windows to >>>>>>> first >>>>>>> print log >>>>>>> file as other platform, then dump >>>>>>> core >>>>>>> file if >>>>>>> needed. When VMError created after >>>>>>> crash, siginfo >>>>>>> and context which are >>>>>>> ExceptionRecord and >>>>>>> ContextRecord on Windows are >>>>>>> recorded, >>>>>>> mini (or >>>>>>> full, due to 'or' used so type will >>>>>>> be >>>>>>> mini >>>>>>> anyway) dump creates dump file based >>>>>>> on those two >>>>>>> as before. >>>>>>> 2) to make os::abort to get above >>>>>>> two pointers, >>>>>>> added two more fields to the function >>>>>>> parameters: >>>>>>> 3) changes for >>>>>>> test/runtime/ErrorHandling/SecondaryError.java --- >>>>>>> added "-XX:-CreateCoredumpOnCrash" >>>>>>> >>>>>>> - static void abort(bool >>>>>>> dump_core = true); >>>>>>> + static void abort(bool >>>>>>> dump_core >>>>>>> = true, >>>>>>> void *siginfo = NULL, void *context = >>>>>>> NULL); >>>>>>> >>>>>>> Tests: JPRT and manually. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/11/2015 3:47 AM, Thomas St?fe >>>>>>> wrote: >>>>>>> >>>>>>> Hi Yumin, >>>>>>> >>>>>>> There is also >>>>>>> test/runtime/ErrorHandling/SecondaryErrorTest.java >>>>>>> - could you please add >>>>>>> "-XX:-CreateCoredumpOnCrash" ? >>>>>>> Thank you! >>>>>>> >>>>>>> Beyond that, as I wrote in the >>>>>>> bug >>>>>>> report >>>>>>> comments: >>>>>>> >>>>>>> "This is also a problem on >>>>>>> Windows - >>>>>>> MiniDumpWriteDump() may hang >>>>>>> infinitly. And on >>>>>>> Windows this is worse than under >>>>>>> UNIX because >>>>>>> we create the Dump before writing >>>>>>> the hs-err >>>>>>> file, so if the Dump hangs, we >>>>>>> get >>>>>>> no error >>>>>>> log. I would like to revert the >>>>>>> order: create >>>>>>> the minidump after writing the >>>>>>> error log, the >>>>>>> same way Unix does it. We did >>>>>>> this >>>>>>> in our JVM >>>>>>> (SAP) because for us, error logs >>>>>>> are more >>>>>>> useful than minidumps. " >>>>>>> >>>>>>> So, I would like to see os::abort >>>>>>> on Windows >>>>>>> call MiniDumpWriteDump(), and >>>>>>> thus >>>>>>> the mini >>>>>>> dump writing moved after the >>>>>>> error log >>>>>>> writing. This would also make the >>>>>>> code way >>>>>>> cleaner because the control flow >>>>>>> would be the >>>>>>> same on all platforms. >>>>>>> >>>>>>> I understand that this may be out >>>>>>> of scope for >>>>>>> your change, but I would like to >>>>>>> know what >>>>>>> others think about this. >>>>>>> >>>>>>> Kind regards, Thomas >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 11, 2015 at 8:02 AM, >>>>>>> Yumin Qi >>>>>>> >>>>>> >>>>>>> >>>>>> > >>>>>>> >>>>>> >>>>>>> >>>>>> >>> wrote: >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8074354 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~minqi/8074354/webrev01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: Tests timed out when >>>>>>> VM crashes >>>>>>> and dumping core file >>>>>>> which in the test case is not >>>>>>> needed. To >>>>>>> make core not created, >>>>>>> the fix changed >>>>>>> CreateMinidumpOnCrash to >>>>>>> CreateCoredumpOnCrash, >>>>>>> the former is only used on >>>>>>> Windows and the >>>>>>> latter for all >>>>>>> platforms. When VM crashes on >>>>>>> non Windows, >>>>>>> core file generated as >>>>>>> default if OS sets core dump >>>>>>> allowed. >>>>>>> Default value of >>>>>>> CreateCoredumpOnCrash set to >>>>>>> 'true' to >>>>>>> keep same behavior on non >>>>>>> Windows platforms, but >>>>>>> changed >>>>>>> for Windows >>>>>>> --- original is false, >>>>>>> not create minidump on >>>>>>> Windows. With >>>>>>> CreateCoredumpOnCrash turned >>>>>>> off, no core file will be >>>>>>> generated. >>>>>>> CreateMinidumpOnCrash still >>>>>>> can be used on commandline >>>>>>> but >>>>>>> only as >>>>>>> alias for the new flag. >>>>>>> >>>>>>> Tests: JPRT, manual tests >>>>>>> setting >>>>>>> CreateMinidumpOnCrash on >>>>>>> commandline to verify flag >>>>>>> change as alias. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >