From stuart.marks at oracle.com Thu May 1 00:08:37 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 30 Apr 2014 17:08:37 -0700 Subject: Draft JEP: JDK Core Libraries Test Stabilization Message-ID: <53619085.6090000@oracle.com> Hi all, Here's a draft JEP for stabilizing the core libraries regression test suite, that is, fixing up the spuriously failing tests. Please review and comment. Thanks! s'marks Title: JDK Core Libraries Test Stabilization Author: Stuart Marks Organization: Oracle Discussion: core-libs-dev at openjdk.java.net [...other metadata elided...] Summary ------- The JDK Regression Test Suite has several thousand fully automated tests. These tests are valuable and effective in that they serve to prevent bugs from entering the code base. However, they suffer from many intermittent failures. Many of these failures are "spurious" in that they are not caused by bugs in the product. Spurious failures add considerable noise to test reports; they make it impossible for developers to ascertain whether a particular change has introduced a bug; and they obscure actual failures. The reliability of the regression suite has improved considerably over the past few years. However, there are perhaps still 100-200 tests that fail intermittently, and most of these failures are spurious. This project aims to reduce the number and frequency of spuriously failing tests to a level where it no longer is an impediment to development. This project targets tests from the regression suite that cover the JDK Core Libraries, including base packages (java.lang, io, nio, util) I18N, Networking, RMI, Security, and Serviceability. JAXP and CORBA are also included, although they have relatively few regression tests at present. Non-Goals --------- Regression tests for other areas, including Hotspot, Langtools, and Client areas, are not included in this project. This project does not address operational issues that might cause builds or test runs to fail or for reports not to be delivered in a timely fashion. This project is not focused on product bugs that cause test failures. Such test failures are "good" in that the test suite is providing valid information about the product. Test runs on embedded platforms are not covered by this project. Success Metrics --------------- The reliability of a successful test run (100% pass) currently stands at approximately 0.5%. The goal is to improve this success rate to 98%, exclusive of true failures (i.e., those caused by bugs in the product). At a 98% success rate, a continuous build system that runs ten jobs per day, five days a week would have one or fewer spurious failures per week. Motivation ---------- Developers are continually hampered by the unreliability of the regression test suite. Intermittently failing tests add significant noise to the results of every test run. The consequence is that developers cannot tell whether test failures were caused by bugs introduced by a recent change or whether they are spurious failures. In addition, the intermittent failures mask actual failures in the product, slowing development and reducing quality. Developers should be able to rely on the test suite telling them accurate information: test failures should indicate the introduction of a bug into the system, and absence of test failures should be usable as evidence that changes are correct. Description ----------- Spurious test failures fall into two broad categories: - test bugs - environmental issues Our working assumption for most intermittent test failures is that they are spurious, and further, that they are caused by bugs in the test itself. While it is possible for a product bug to cause an intermittent failure, this is relatively rare. The majority of intermittent failures encountered so far have indeed proven to be test bugs. "Environmental" issues, such as misconfigured test machines, temporary dysfunction on the machine running the test job (e.g., filesystem full), or transient network failures, also contribute to spurious failures. Test should be made more robust, if possible. Environment issues should be fed back to the infrastructure team for resolution and future infrastructure improvements. A variety of techniques will be employed to diagnose, track, and help develop fixes for intermittently failing tests: - track all test failures in JBS - repeated test runs against the same build - gather statistics about failure rates, # tests with bugs, and track continuously - investigate pathologies for common test failure modes - develop techniques for fixing common test bugs - develop test library code to improve commonality across tests and to avoid typical failure modes - add instrumentation to tests (and to the test suite) to improve diagnosability - exclude tests judiciously, preferably only as a last resort - change reviews - code inspections Alternatives ------------ The most likely alternative to diagnosing and fixing intermittent failures is to aggressively exclude intermittently failing tests from the test suite. This trades off code coverage in favor of test reliability, adding risk of undetected bug introduction. Testing ------- The subject of the project is the test suite itself. The main "testing" of the test suite is running it repeatedly in a variety of environments, including continuous build-and-test systems, as well as recurring "same-binary" test runs on promoted builds. This will help flush out intermittent failures and detect newly introduced failures. Risks and Assumptions --------------------- We are working on a long tail of intermittent failures, which may become increasingly frustrating as time goes on, resulting in the project stalling out. New intermittent failures may be introduced or discovered more quickly than they can be resolved. The main work of fixing up the tests will be spread across several development groups. This requires good cross-group coordination and focus. The culture in the development group has (mostly) been to ignore test failures, or to find ways to cope with them. As intermittent failures are removed, we hope to decrease the group's tolerance of test failures. Dependences ----------- No dependences on other JEPs or components. Impact ------ No impact on specific parts of the platform or product, except for developer time and effort being spent on it, across various component teams. ========== From joe.darcy at oracle.com Thu May 1 00:20:16 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 17:20:16 -0700 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> <535689DC.6060907@redhat.com> Message-ID: <53619340.6010505@oracle.com> Hello, I'm reminded of Professor Knuth's observation that "Premature optimization is the root of all evil." If from an API perspective the new code is preferable, I would say that should take precedence over an at most marginal performance degradation. If performance of is a high concern in that area, perhaps a jmh experiment could help tease about the difference in speed. -Joe On 04/27/2014 04:08 PM, Richard Warburton wrote: > Hi, > > There are multiple possible targets for invokevirtual >>> position:(I)Ljava/nio/Buffer; - all the methods that override it in all >>> subclasses loaded. It doesn't matter if they are final or not (only if >>> they are effectively final or not). The non-finality of a method has a >>> performance impact only if the method *is* overridden in any of the >>> loaded subclasses, otherwise it is effectively final and treated as such >>> by JIT (at least that's how I understand it - any hotspot JIT expert >>> please debunk my claims). >>> >> That is only true if you are calling the method on the base class, which >> is normally seldom done (though it will be nearly always in legacy code, >> but see below). >> >> That might also be the answer to why the synthetic method need not be >>> marked as final if the covariant method is. The synthetic method can >>> never be overridden in a sub-class (at least not by javac) - only the >>> covariant method can be. >>> >> Doesn't sound quite right to me, but I'll defer to any experts who might >> wish to discuss it on compiler-dev. >> >> >> But as Paul noted, the methods on Buffer are probably not used in hot >>> loops alone, since they are just for reading/adjusting >>> position/limit/mark. The hot loops probably also contain methods for >>> reading/writing the buffer and those are only defined on particular >>> sub-types of java.nio.Buffer, so it can reasonably be expected that the >>> static (guaranteed) type of target upon which methods are called in hot >>> loops is a particular subtype of java.nio.Buffer and JIT only has one >>> method to choose from in this case. >>> >> Yeah new code will call the covariant final method directly in almost all >> cases for sure, having been compiled against it. The tricky case is old >> code - even if the JIT can figure out that it is really a subclass being >> invoked upon, it'd still be forced to target the non-covariant synthetic >> method due to the specific method reference in the bytecode. Hopefully at >> this point though, as you say, the lack of overriding classes will be >> enough to optimize the dispatch. >> > So interestingly the original patch didn't add final to the covariant > overrides. I've updated the patch to do this. > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-1/ > > I'm not sure what would satisfy people on the performance front. Some > guidance would be most appreciated here. > > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto From jeremymanson at google.com Thu May 1 00:24:17 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 30 Apr 2014 17:24:17 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: Did the new bugs get filed for this? I'm triggering this check with a redefined class (from the bootclasspath, if that matters). To investigate it a little, I instrumented StackTraceElement::create thus: oop java_lang_StackTraceElement::create(methodHandle method, int bci, TRAPS) { Handle mirror (THREAD, method->method_holder()->java_mirror()); int method_id = method->method_idnum(); InstanceKlass* holder = method->method_holder(); Method* m = holder->method_with_idnum(method_id); Method* mp = holder->find_method(method->name(), method->signature()); method->print_name(); fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, mp); return create(mirror, method_id, method->constants()->version(), bci, THREAD); } m is null, and mp isn't. method->print_name works fine. This makes me feel that the idnum array is out of date somehow. Before I go down the rabbit hole and try to figure out why that is, does someone else know why? Thanks! Jeremy On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > Summary: Redefined class in stack trace may not be found by method_idnum > so handle null. > > This is a simple change. I had another change to save the method name (as > u2) in the backtrace, but it's not worth the extra footprint in backtraces > for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and deallocated. > I made a change to InstanceKlass::method_from_idnum() to return null > rather than the last method in the list, which causes this crash. Dan and > I went down the long rabbit-hole of why method_idnum is changed for > obsolete methods and we think there's some cleanup and potential bugs in > this area. But this is not that change. I'll file another bug to continue > this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review request. > Also tested with all of the vm testbase tests, mlvm tests, and > java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen > From coleen.phillimore at oracle.com Thu May 1 01:34:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Apr 2014 21:34:02 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: References: <524DB145.5030109@oracle.com> Message-ID: <5361A48A.6090104@oracle.com> We didn't file any bugs because I don't remember finding anything specific, other than "gosh that code is scary" and "I wish we didn't have to do this". If you find a null 'm' below and call m->print() is the method "obsolete"? Coleen On 4/30/14, 8:24 PM, Jeremy Manson wrote: > Did the new bugs get filed for this? > > I'm triggering this check with a redefined class (from the > bootclasspath, if that matters). To investigate it a little, I > instrumented StackTraceElement::create thus: > > oop java_lang_StackTraceElement::create(methodHandle method, int bci, > TRAPS) { > Handle mirror (THREAD, method->method_holder()->java_mirror()); > int method_id = method->method_idnum(); > > InstanceKlass* holder = method->method_holder(); > Method* m = holder->method_with_idnum(method_id); > Method* mp = holder->find_method(method->name(), method->signature()); > method->print_name(); > fprintf(stderr, " method = %p id = %d method' = %p \n", m, > method_id, mp); > return create(mirror, method_id, method->constants()->version(), > bci, THREAD); > } > > m is null, and mp isn't. method->print_name works fine. This makes > me feel that the idnum array is out of date somehow. Before I go down > the rabbit hole and try to figure out why that is, does someone else > know why? > > Thanks! > > Jeremy > > > > On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore > > > wrote: > > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method > name (as u2) in the backtrace, but it's not worth the extra > footprint in backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace > (u2) instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to > InstanceKlass::method_from_idnum() to return null rather than the > last method in the list, which causes this crash. Dan and I went > down the long rabbit-hole of why method_idnum is changed for > obsolete methods and we think there's some cleanup and potential > bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm > tests, and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > > Thanks, > Coleen > > From jeremymanson at google.com Thu May 1 05:13:01 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 30 Apr 2014 22:13:01 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <5361A48A.6090104@oracle.com> References: <524DB145.5030109@oracle.com> <5361A48A.6090104@oracle.com> Message-ID: I'll have to check tomorrow, but it's not unreasonable to think that it is. It is a stack frame on a thread that was started before the class redefinition happened. I guess the question is: what makes sense to do here? I put in a workaround such that, if m is null, method_id is replaced by the method_id from mp. I could refactor the code a little, such that the full version of create() took the Method* instead of taking the method_id, and pass it mp if m is null. It'll be hard to get you a reproducible test case, though. This only happens in an integration test in our test cluster. Debugging was painful. Jeremy On Wed, Apr 30, 2014 at 6:34 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > We didn't file any bugs because I don't remember finding anything > specific, other than "gosh that code is scary" and "I wish we didn't have > to do this". > > If you find a null 'm' below and call m->print() is the method "obsolete"? > > Coleen > > > On 4/30/14, 8:24 PM, Jeremy Manson wrote: > > Did the new bugs get filed for this? > > I'm triggering this check with a redefined class (from the > bootclasspath, if that matters). To investigate it a little, I > instrumented StackTraceElement::create thus: > > oop java_lang_StackTraceElement::create(methodHandle method, int bci, > TRAPS) { > Handle mirror (THREAD, method->method_holder()->java_mirror()); > int method_id = method->method_idnum(); > > InstanceKlass* holder = method->method_holder(); > Method* m = holder->method_with_idnum(method_id); > Method* mp = holder->find_method(method->name(), method->signature()); > method->print_name(); > fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, > mp); > return create(mirror, method_id, method->constants()->version(), bci, > THREAD); > } > > m is null, and mp isn't. method->print_name works fine. This makes me > feel that the idnum array is out of date somehow. Before I go down the > rabbit hole and try to figure out why that is, does someone else know why? > > Thanks! > > Jeremy > > > > On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> Summary: Redefined class in stack trace may not be found by method_idnum >> so handle null. >> >> This is a simple change. I had another change to save the method name >> (as u2) in the backtrace, but it's not worth the extra footprint in >> backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and deallocated. >> I made a change to InstanceKlass::method_from_idnum() to return null >> rather than the last method in the list, which causes this crash. Dan and >> I went down the long rabbit-hole of why method_idnum is changed for >> obsolete methods and we think there's some cleanup and potential bugs in >> this area. But this is not that change. I'll file another bug to continue >> this investigation for jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review request. >> Also tested with all of the vm testbase tests, mlvm tests, and >> java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen >> > > > From david.dehaven at oracle.com Thu May 1 15:05:52 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 1 May 2014 08:05:52 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <53617C50.80409@oracle.com> References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> <53617C50.80409@oracle.com> Message-ID: Do we care about the 1 in more than 80 trillion case where the third party Main-Class would be named "LauncherHelper$FXHelper"? I think the probability is extremely unlikely so I'm fine with it the way it's written. LauncherHelper.java: 590 return; Redundant return statement? -DrD- > For completeness the bugid line needs the bugid as shown, otherwise SQE will open > another bug to have you fix this. > > -26 * @bug 8001533 8004547 > +26 * @bug 8001533 8004547 8035782 > > other than that it looks good, I can push this with the above change. > > Anyone else have any concerns with this change before I push ? > > Thanks > Kumar > > > On 4/30/2014 1:47 PM, Neil Toda wrote: >> >> Please review Launcher change and test. >> >> I've added to the Launcher test : FXLauncherTest.java >> The test will now check that LauncherHelper$FXHelper is not loaded for non-JavaFX class and jar files. >> >> webrev.02 contains only review suggestions from webrev.01 and the new test class. >> >> http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ >> >> for bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8035782 >> >> Thanks >> >> -neil >> >> > From mandy.chung at oracle.com Thu May 1 17:55:36 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 01 May 2014 10:55:36 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <53617C50.80409@oracle.com> References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> <53617C50.80409@oracle.com> Message-ID: <53628A98.902@oracle.com> Looks fine to me. Nit: line 528: space after "(" and before "mainClass" can be removed Mandy On 4/30/14 3:42 PM, Kumar Srinivasan wrote: > For completeness the bugid line needs the bugid as shown, otherwise > SQE will open > another bug to have you fix this. > > -26 * @bug 8001533 8004547 > +26 * @bug 8001533 8004547 8035782 > > > other than that it looks good, I can push this with the above change. > > Anyone else have any concerns with this change before I push ? > > Thanks > Kumar > > > On 4/30/2014 1:47 PM, Neil Toda wrote: >> >> Please review Launcher change and test. >> >> I've added to the Launcher test : FXLauncherTest.java >> The test will now check that LauncherHelper$FXHelper is not loaded >> for non-JavaFX class and jar files. >> >> webrev.02 contains only review suggestions from webrev.01 and the new >> test class. >> >> http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ >> >> for bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8035782 >> >> Thanks >> >> -neil >> >> > From neil.toda at oracle.com Thu May 1 20:20:57 2014 From: neil.toda at oracle.com (Neil Toda) Date: Thu, 01 May 2014 13:20:57 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <53628A98.902@oracle.com> References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> <53617C50.80409@oracle.com> <53628A98.902@oracle.com> Message-ID: <5362ACA9.5060102@oracle.com> Thanks Mandy. Done. On 5/1/2014 10:55 AM, Mandy Chung wrote: > Looks fine to me. > > Nit: line 528: space after "(" and before "mainClass" can be removed > > Mandy > > On 4/30/14 3:42 PM, Kumar Srinivasan wrote: >> For completeness the bugid line needs the bugid as shown, otherwise >> SQE will open >> another bug to have you fix this. >> >> -26 * @bug 8001533 8004547 >> +26 * @bug 8001533 8004547 8035782 >> >> >> other than that it looks good, I can push this with the above change. >> >> Anyone else have any concerns with this change before I push ? >> >> Thanks >> Kumar >> >> >> On 4/30/2014 1:47 PM, Neil Toda wrote: >>> >>> Please review Launcher change and test. >>> >>> I've added to the Launcher test : FXLauncherTest.java >>> The test will now check that LauncherHelper$FXHelper is not loaded >>> for non-JavaFX class and jar files. >>> >>> webrev.02 contains only review suggestions from webrev.01 and the >>> new test class. >>> >>> http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ >>> >>> for bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>> >>> Thanks >>> >>> -neil >>> >>> >> > From neil.toda at oracle.com Thu May 1 20:59:06 2014 From: neil.toda at oracle.com (Neil Toda) Date: Thu, 01 May 2014 13:59:06 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> <53617C50.80409@oracle.com> Message-ID: <5362B59A.8050808@oracle.com> 1) Redundant return removed. 2) Kumar and I talked: Ever since the pentium bug, 1 in 80 trillion seems a big risk .. so the code was changed to check for equality with the whole class name: private static final String JAVAFX_FXHELPER_CLASS_NAME_SUFFIX = "sun.launcher.LauncherHelper$FXHelper"; ... if (JAVAFX_FXHELPER_CLASS_NAME_SUFFIX.equals(mainClass.getName()) || doesExtendFXApplication(mainClass)) { // Will abort() if there are problems with FX runtime FXHelper.setFXLaunchParameters(what, mode); return FXHelper.class; } Thanks -neil On 5/1/2014 8:05 AM, David DeHaven wrote: > Do we care about the 1 in more than 80 trillion case where the third party Main-Class would be named "LauncherHelper$FXHelper"? I think the probability is extremely unlikely so I'm fine with it the way it's written. > > > LauncherHelper.java: > 590 return; > > Redundant return statement? > > -DrD- > > >> For completeness the bugid line needs the bugid as shown, otherwise SQE will open >> another bug to have you fix this. >> >> -26 * @bug 8001533 8004547 >> +26 * @bug 8001533 8004547 8035782 >> >> other than that it looks good, I can push this with the above change. >> >> Anyone else have any concerns with this change before I push ? >> >> Thanks >> Kumar >> >> >> On 4/30/2014 1:47 PM, Neil Toda wrote: >>> Please review Launcher change and test. >>> >>> I've added to the Launcher test : FXLauncherTest.java >>> The test will now check that LauncherHelper$FXHelper is not loaded for non-JavaFX class and jar files. >>> >>> webrev.02 contains only review suggestions from webrev.01 and the new test class. >>> >>> http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ >>> >>> for bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>> >>> Thanks >>> >>> -neil >>> >>> From kumar.x.srinivasan at oracle.com Fri May 2 13:17:47 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 02 May 2014 06:17:47 -0700 Subject: RFR: 8042266: [launcher] create test groups for launcher regression tests Message-ID: <53639AFB.20604@oracle.com> Hi, Simple changes to add jdk_launcher to the jdk's Test.groups, this allows anyone working on the launcher to run a set of regression tests which historically have helped shake out launcher regressions. http://cr.openjdk.java.net/~ksrini/8042266/webrev.00/ Usage: jtreg ...... /blah/de/blah/jdk/test:jdk_launcher Thanks Kumar From Alan.Bateman at oracle.com Fri May 2 13:30:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 May 2014 14:30:54 +0100 Subject: RFR: 8042266: [launcher] create test groups for launcher regression tests In-Reply-To: <53639AFB.20604@oracle.com> References: <53639AFB.20604@oracle.com> Message-ID: <53639E0E.90905@oracle.com> On 02/05/2014 14:17, Kumar Srinivasan wrote: > Hi, > > Simple changes to add jdk_launcher to the jdk's Test.groups, this > allows anyone working > on the launcher to run a set of regression tests which historically have > helped shake out launcher regressions. > http://cr.openjdk.java.net/~ksrini/8042266/webrev.00/ > > Usage: > jtreg ...... /blah/de/blah/jdk/test:jdk_launcher The tools are deliberately split into core_tools and svc_tools. If I read this correctly then it looks like core_tools will now run a bunch of other tools (overlap with svc_tools). If jdk_launcher is really needed then maybe just add that group and don't adjust the others? -Alan. From kumar.x.srinivasan at oracle.com Fri May 2 15:40:38 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 02 May 2014 08:40:38 -0700 Subject: RFR: 8042266: [launcher] create test groups for launcher regression tests In-Reply-To: <53639E0E.90905@oracle.com> References: <53639AFB.20604@oracle.com> <53639E0E.90905@oracle.com> Message-ID: <5363BC76.10903@oracle.com> Point taken, I just added jdk_launcher for now. http://cr.openjdk.java.net/~ksrini/8042266/webrev.01/ Thanks On 5/2/2014 6:30 AM, Alan Bateman wrote: > On 02/05/2014 14:17, Kumar Srinivasan wrote: >> Hi, >> >> Simple changes to add jdk_launcher to the jdk's Test.groups, this >> allows anyone working >> on the launcher to run a set of regression tests which historically have >> helped shake out launcher regressions. >> http://cr.openjdk.java.net/~ksrini/8042266/webrev.00/ >> >> Usage: >> jtreg ...... /blah/de/blah/jdk/test:jdk_launcher > The tools are deliberately split into core_tools and svc_tools. If I > read this correctly then it looks like core_tools will now run a bunch > of other tools (overlap with svc_tools). If jdk_launcher is really > needed then maybe just add that group and don't adjust the others? > > -Alan. From Alan.Bateman at oracle.com Fri May 2 15:44:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 May 2014 16:44:15 +0100 Subject: RFR: 8042266: [launcher] create test groups for launcher regression tests In-Reply-To: <5363BC76.10903@oracle.com> References: <53639AFB.20604@oracle.com> <53639E0E.90905@oracle.com> <5363BC76.10903@oracle.com> Message-ID: <5363BD4F.2000301@oracle.com> On 02/05/2014 16:40, Kumar Srinivasan wrote: > Point taken, I just added jdk_launcher for now. > http://cr.openjdk.java.net/~ksrini/8042266/webrev.01/ That seems okay now although it means that :jdk_launcher will run the tests for a bunch of tools that someone working on the launcher might not be interested in. One suggestion is to include a comment to make it clear its intention (and to avoid someone thing there is a mistake that it's not grouped into one of the top-level groups). -Alan. From Ulf.Zibis at CoSoCo.de Fri May 2 16:10:11 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 02 May 2014 18:10:11 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <53619340.6010505@oracle.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> <535689DC.6060907@redhat.com> <53619340.6010505@oracle.com> Message-ID: <5363C363.5020708@CoSoCo.de> Am 01.05.2014 02:20, schrieb Joe Darcy: > Hello, > > I'm reminded of Professor Knuth's observation that "Premature optimization is the root of all evil." > > If from an API perspective the new code is preferable, I would say that should take precedence > over an at most marginal performance degradation. I guess you meant: ... marginal performance _gain_. -Ulf From david.dehaven at oracle.com Fri May 2 16:10:59 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 2 May 2014 09:10:59 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <5362B59A.8050808@oracle.com> References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> <53617C50.80409@oracle.com> <5362B59A.8050808@oracle.com> Message-ID: <58FD43D3-9BC3-4C9B-A8C9-B37C8A0687CC@oracle.com> That's the first time the pentium bug ever worked in my favor... ;) The changes look good to me. approved (with a lower case 'a', since I'm not a Reviewer with an upper case 'R'). -DrD- > 1) Redundant return removed. > > 2) Kumar and I talked: Ever since the pentium bug, 1 in 80 trillion seems a big risk .. so the code was changed to > check for equality with the whole class name: > > private static final String JAVAFX_FXHELPER_CLASS_NAME_SUFFIX = > "sun.launcher.LauncherHelper$FXHelper"; > ... > > if (JAVAFX_FXHELPER_CLASS_NAME_SUFFIX.equals(mainClass.getName()) || > doesExtendFXApplication(mainClass)) { > // Will abort() if there are problems with FX runtime > FXHelper.setFXLaunchParameters(what, mode); > return FXHelper.class; > } > > > Thanks > > -neil > > On 5/1/2014 8:05 AM, David DeHaven wrote: >> Do we care about the 1 in more than 80 trillion case where the third party Main-Class would be named "LauncherHelper$FXHelper"? I think the probability is extremely unlikely so I'm fine with it the way it's written. >> >> >> LauncherHelper.java: >> 590 return; >> >> Redundant return statement? >> >> -DrD- >> >> >>> For completeness the bugid line needs the bugid as shown, otherwise SQE will open >>> another bug to have you fix this. >>> >>> -26 * @bug 8001533 8004547 >>> +26 * @bug 8001533 8004547 8035782 >>> >>> other than that it looks good, I can push this with the above change. >>> >>> Anyone else have any concerns with this change before I push ? >>> >>> Thanks >>> Kumar >>> >>> >>> On 4/30/2014 1:47 PM, Neil Toda wrote: >>>> Please review Launcher change and test. >>>> >>>> I've added to the Launcher test : FXLauncherTest.java >>>> The test will now check that LauncherHelper$FXHelper is not loaded for non-JavaFX class and jar files. >>>> >>>> webrev.02 contains only review suggestions from webrev.01 and the new test class. >>>> >>>> http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ >>>> >>>> for bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>>> >>>> Thanks >>>> >>>> -neil >>>> >>>> > From joe.darcy at oracle.com Fri May 2 16:13:07 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 02 May 2014 09:13:07 -0700 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5363C363.5020708@CoSoCo.de> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> <535689DC.6060907@redhat.com> <53619340.6010505@oracle.com> <5363C363.5020708@CoSoCo.de> Message-ID: <5363C413.9000607@oracle.com> On 5/2/2014 9:10 AM, Ulf Zibis wrote: > Am 01.05.2014 02:20, schrieb Joe Darcy: >> Hello, >> >> I'm reminded of Professor Knuth's observation that "Premature >> optimization is the root of all evil." >> >> If from an API perspective the new code is preferable, I would say >> that should take precedence over an at most marginal performance >> degradation. > > I guess you meant: ... marginal performance _gain_. > No, I actually meant degradation. If the new API is easier to use, captures more type information, etc., in my estimation that is more important than a whisker thin performance penalty in an area that is not performance critical. -Joe From joe.darcy at oracle.com Fri May 2 18:06:04 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 02 May 2014 11:06:04 -0700 Subject: JDK 9 RFC on 8032016: Optimizations of Math.next{After, Up}({float, double}) In-Reply-To: <017489FE-FF2E-4DD4-B7F6-359EA69AC602@oracle.com> References: <017489FE-FF2E-4DD4-B7F6-359EA69AC602@oracle.com> Message-ID: <5363DE8C.8060400@oracle.com> Hi Brian, Looks fine; cheers, -Joe On 04/29/2014 12:06 PM, Brian Burkhalter wrote: > Hello, > > Issue: https://bugs.openjdk.java.net/browse/JDK-8032016 > Patch: http://cr.openjdk.java.net/~bpb/8032016/webrev.00/ > > The performance improvements of this change are marginal but the logic seems reasonable and the code looks cleaner so I am posting this as an RFC. > > Comments? > > Thanks, > > Brian From neil.toda at oracle.com Fri May 2 18:25:08 2014 From: neil.toda at oracle.com (Neil Toda) Date: Fri, 02 May 2014 11:25:08 -0700 Subject: 8035782 : sun/launcher/LauncherHelper$FXHelper loaded unnecessarily In-Reply-To: <58FD43D3-9BC3-4C9B-A8C9-B37C8A0687CC@oracle.com> References: <536029F0.9000406@oracle.com> <53616152.9070600@oracle.com> <53617C50.80409@oracle.com> <5362B59A.8050808@oracle.com> <58FD43D3-9BC3-4C9B-A8C9-B37C8A0687CC@oracle.com> Message-ID: <5363E304.6050002@oracle.com> "T"hanks DrD. -neil On 5/2/2014 9:10 AM, David DeHaven wrote: > That's the first time the pentium bug ever worked in my favor... ;) > > The changes look good to me. approved (with a lower case 'a', since I'm not a Reviewer with an upper case 'R'). > > -DrD- > >> 1) Redundant return removed. >> >> 2) Kumar and I talked: Ever since the pentium bug, 1 in 80 trillion seems a big risk .. so the code was changed to >> check for equality with the whole class name: >> >> private static final String JAVAFX_FXHELPER_CLASS_NAME_SUFFIX = >> "sun.launcher.LauncherHelper$FXHelper"; >> ... >> >> if (JAVAFX_FXHELPER_CLASS_NAME_SUFFIX.equals(mainClass.getName()) || >> doesExtendFXApplication(mainClass)) { >> // Will abort() if there are problems with FX runtime >> FXHelper.setFXLaunchParameters(what, mode); >> return FXHelper.class; >> } >> >> >> Thanks >> >> -neil >> >> On 5/1/2014 8:05 AM, David DeHaven wrote: >>> Do we care about the 1 in more than 80 trillion case where the third party Main-Class would be named "LauncherHelper$FXHelper"? I think the probability is extremely unlikely so I'm fine with it the way it's written. >>> >>> >>> LauncherHelper.java: >>> 590 return; >>> >>> Redundant return statement? >>> >>> -DrD- >>> >>> >>>> For completeness the bugid line needs the bugid as shown, otherwise SQE will open >>>> another bug to have you fix this. >>>> >>>> -26 * @bug 8001533 8004547 >>>> +26 * @bug 8001533 8004547 8035782 >>>> >>>> other than that it looks good, I can push this with the above change. >>>> >>>> Anyone else have any concerns with this change before I push ? >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> On 4/30/2014 1:47 PM, Neil Toda wrote: >>>>> Please review Launcher change and test. >>>>> >>>>> I've added to the Launcher test : FXLauncherTest.java >>>>> The test will now check that LauncherHelper$FXHelper is not loaded for non-JavaFX class and jar files. >>>>> >>>>> webrev.02 contains only review suggestions from webrev.01 and the new test class. >>>>> >>>>> http://cr.openjdk.java.net/~ntoda/8035782/webrev.02/ >>>>> >>>>> for bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8035782 >>>>> >>>>> Thanks >>>>> >>>>> -neil >>>>> >>>>> From mike.duigou at oracle.com Fri May 2 19:22:18 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 2 May 2014 12:22:18 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> <534E9F8B.6070302@geomatys.fr> <18370F8A-191D-4586-9162-FD94F65FB48F@oracle.com> Message-ID: Thanks Martin and Martin; I have corrected this along with some additional documentation updates: http://cr.openjdk.java.net/~mduigou/JDK-8020860/3/webrev/ Mike On Apr 16 2014, at 10:47 , Martin Buchholz wrote: > Here you access elementCount outside the synchronized block, which is a data race > + public boolean addAll(int index, Collection c) { > if (index < 0 || index > elementCount) > throw new ArrayIndexOutOfBoundsException(index); > > > > On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou wrote: > Yes. This has been corrected. > > Mike > > On Apr 16 2014, at 08:19 , Martin Desruisseaux wrote: > > > Hello all > > > > Le 15/04/14 18:14, Mike Duigou a ?crit : > >> I have updated the webrev with what I hope is the final form: > >> > >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ > > > > The first changes in the javadoc contains "{@code #keys keys}" and > > "{@code #elements elements}". I presume that you mean {@link} instead of > > {@code}? > > > > Martin > > > > From brian.burkhalter at oracle.com Fri May 2 21:22:03 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 2 May 2014 14:22:03 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> Message-ID: <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> Prod! On Apr 28, 2014, at 4:02 PM, Brian Burkhalter wrote: > Here is an updated patch > > http://cr.openjdk.java.net/~bpb/8026236/webrev.02/ > > which has been revised to obviate the need for a file source of prime numbers. > > Thanks, > > Brian > > On Apr 24, 2014, at 5:12 PM, Brian Burkhalter wrote: > >> I have posted an updated patch here: >> >> http://cr.openjdk.java.net/~bpb/8026236/webrev.01/ >> >> Thanks for your comments. From jeremymanson at google.com Fri May 2 23:02:20 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 2 May 2014 16:02:20 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: References: <524DB145.5030109@oracle.com> <5361A48A.6090104@oracle.com> Message-ID: Finally had a chance to look at this again. The method is not marked obsolete. I can't refactor the code so that the full version of create takes the Method *, because it is called to resolve stack traces from Throwables, and there is no way to map back to Method * from the method_ids that are stored in Throwables. So, my workaround (below) works fine to deal with getAllStackTraces, but doesn't work if there is an obsolete method in a Throwable's stack trace. I can't reproduce that, but that doesn't mean it won't happen. The only thing I can think to do about this is to keep track of obsolete method_ids. For example, when we do a retransform, InstanceKlass.methods could keep the old method around. Or, Methods could keep track of previous method ids (or a subclass of Method could keep track of previous method ids, so that most Methods don't suffer from bloat issues keeping track of something that is rarely / never there). I assume that there is a reason we don't do this, though. Here's my diff. I think it is fair to call it a crude hack. If there is something else you would like me to try, I'm happy to do so. diff --git a/src/share/vm/classfile/javaClasses.cpp b/src/share/vm/classfile/javaClasses.cpp --- a/src/share/vm/classfile/javaClasses.cpp +++ b/src/share/vm/classfile/javaClasses.cpp @@ -1857,6 +1857,14 @@ oop java_lang_StackTraceElement::create(methodHandle method, int bci, TRAPS) { Handle mirror (THREAD, method->method_holder()->java_mirror()); int method_id = method->method_idnum(); + InstanceKlass* holder = method->method_holder(); + Method* m = holder->method_with_idnum(method_id); + if (m == NULL) { + Method* mp = holder->find_method(method->name(), method->signature()); + if (mp != NULL) { + method_id = mp->method_idnum(); + } + } return create(mirror, method_id, method->constants()->version(), bci, THREAD); } Jeremy On Wed, Apr 30, 2014 at 10:13 PM, Jeremy Manson wrote: > I'll have to check tomorrow, but it's not unreasonable to think that it > is. It is a stack frame on a thread that was started before the class > redefinition happened. > > I guess the question is: what makes sense to do here? I put in a > workaround such that, if m is null, method_id is replaced by the method_id > from mp. I could refactor the code a little, such that the full version of > create() took the Method* instead of taking the method_id, and pass it mp > if m is null. > > It'll be hard to get you a reproducible test case, though. This only > happens in an integration test in our test cluster. Debugging was painful. > > Jeremy > > > On Wed, Apr 30, 2014 at 6:34 PM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> We didn't file any bugs because I don't remember finding anything >> specific, other than "gosh that code is scary" and "I wish we didn't have >> to do this". >> >> If you find a null 'm' below and call m->print() is the method "obsolete"? >> >> Coleen >> >> >> On 4/30/14, 8:24 PM, Jeremy Manson wrote: >> >> Did the new bugs get filed for this? >> >> I'm triggering this check with a redefined class (from the >> bootclasspath, if that matters). To investigate it a little, I >> instrumented StackTraceElement::create thus: >> >> oop java_lang_StackTraceElement::create(methodHandle method, int bci, >> TRAPS) { >> Handle mirror (THREAD, method->method_holder()->java_mirror()); >> int method_id = method->method_idnum(); >> >> InstanceKlass* holder = method->method_holder(); >> Method* m = holder->method_with_idnum(method_id); >> Method* mp = holder->find_method(method->name(), method->signature()); >> method->print_name(); >> fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, >> mp); >> return create(mirror, method_id, method->constants()->version(), bci, >> THREAD); >> } >> >> m is null, and mp isn't. method->print_name works fine. This makes me >> feel that the idnum array is out of date somehow. Before I go down the >> rabbit hole and try to figure out why that is, does someone else know why? >> >> Thanks! >> >> Jeremy >> >> >> >> On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore < >> coleen.phillimore at oracle.com> wrote: >> >>> Summary: Redefined class in stack trace may not be found by method_idnum >>> so handle null. >>> >>> This is a simple change. I had another change to save the method name >>> (as u2) in the backtrace, but it's not worth the extra footprint in >>> backtraces for this rare case. >>> >>> The root problem was that we save method_idnum in the backtrace (u2) >>> instead of Method* to avoid Method* from being redefined and deallocated. >>> I made a change to InstanceKlass::method_from_idnum() to return null >>> rather than the last method in the list, which causes this crash. Dan and >>> I went down the long rabbit-hole of why method_idnum is changed for >>> obsolete methods and we think there's some cleanup and potential bugs in >>> this area. But this is not that change. I'll file another bug to continue >>> this investigation for jdk9 (or 8uN). >>> >>> Staffan created a test - am including core-libs for the review request. >>> Also tested with all of the vm testbase tests, mlvm tests, and >>> java/lang/instrument tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>> >>> test case for jdk8 repository: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>> >>> Thanks, >>> Coleen >>> >> >> >> > From ecki at zusammenkunft.net Sat May 3 00:04:32 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 3 May 2014 02:04:32 +0200 Subject: FilterOutputStream.close() throws exception from flush() Message-ID: <20140503020432.0000230d.ecki@zusammenkunft.net> Hello, back in 2011 there was a discussion about the new changed behavior of FilterOutputStream (and BufferedOutputStream) in regards to not anymore swalloging IOExceptions from flush() on this list (thats where I got the subject from). This was generally a very good improvement (and I am glad that https://bugs.openjdk.java.net/browse/JDK-6335274 thereby got fixed). However the implementation with the try-with-resource has a problem: when flush() and close() report the same exception instance the construction of the suppressed exception will actually fail with an IllegalArgumentException. This IllegalArgumentException of Throwable.addSuppressed is very unfortunate (it would be better simply ignore it). Anyway, this new behavior broke a Unit-Test for Apache VFS as you can see here: https://issues.apache.org/jira/browse/VFS-521 I think this can only be fixed in Throwable by avoiding this IllegalArgumentException or by the close() method not using try-with-resource. For reference, according to this changeset other locations are affected as well: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf Gruss Bernd PS: I wrote a german blogpost about the FilterOutputStream here: http://itblog.eckenfels.net/archives/505-FOS-considered-harmfull.html The following exception is produced by the testcode: Exception in thread "main" java.lang.IllegalArgumentException: Self-suppression not permitted at java.lang.Throwable.addSuppressed(Throwable.java:1043) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at testfos.Main.main(Main.java:6) Caused by: java.io.IOException: remebered IO Exception at testfos.FailingOS.(FailingOS.java:10) at testfos.Main.main(Main.java:5) package testfos; public class Main { public static void main(String[] args) throws java.io.IOException { java.io.BufferedOutputStream buf = new java.io.BufferedOutputStream(new testfos.FailingOS()); buf.close(); // expected: IOException } } package testfos; public class FailingOS extends java.io.OutputStream { private java.io.IOException ex; public FailingOS() { ex = new java.io.IOException("remebered IO Exception"); } public void write(int b) throws java.io.IOException { } public void flush() throws java.io.IOException { throw ex; } public void close() throws java.io.IOException { throw ex; } } From joe.darcy at oracle.com Sat May 3 16:55:36 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 03 May 2014 09:55:36 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> Message-ID: <53651F88.2080607@oracle.com> Hi Brian, I think the parsePrimes method would be better with a different name since no parsing is occurring anymore. I think someone in this test the fact that Integer.MAX_VALUE is a prime should be mentioned in taken advantage of :-) How about adding another test method which tests some Mersenne primes for primality? [1] I'd prefer to see some comments on the primes method briefly explaining it methodology. Would the running time be unacceptable (or memory usage too large) if the limit were set to Integer.MAX_VALUE? Thanks, -Joe [1] http://en.wikipedia.org/wiki/Mersenne_prime On 5/2/2014 2:22 PM, Brian Burkhalter wrote: > Prod! > > On Apr 28, 2014, at 4:02 PM, Brian Burkhalter wrote: > >> Here is an updated patch >> >> http://cr.openjdk.java.net/~bpb/8026236/webrev.02/ >> >> which has been revised to obviate the need for a file source of prime numbers. >> >> Thanks, >> >> Brian >> >> On Apr 24, 2014, at 5:12 PM, Brian Burkhalter wrote: >> >>> I have posted an updated patch here: >>> >>> http://cr.openjdk.java.net/~bpb/8026236/webrev.01/ >>> >>> Thanks for your comments. From peter.levart at gmail.com Sun May 4 10:12:52 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 04 May 2014 12:12:52 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> Message-ID: <536612A4.6090406@gmail.com> Hi Alan, Martin, Thanks for reviews. I have prepared another webrev based on your feedback: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.08/ Comments inline... On 04/30/2014 05:17 PM, Alan Bateman wrote: > I reviewed previous rounds and you've addressed my points so I think > I'm mostly happy with this. As some point I think we should look at > Platform again as there may be an opportunity later in JDK 9 to move > it out of UNIXProcess. > > One thing that I wasn't sure about is the additions to the @author > tags as we've mostly been trying not to grow these (contentious topic, > I don't have a strong opinion as I never use @author). I have removed myself, but left all the others (merged from all 4 files). It's true that mercurial keeps track of authors and it's not hard to find out who's responsible for what part of code in case someone needs to ask the author about the not so obvious things, but refactorings like this, which eliminate entire files and move their content to other places, make this tracking harder. > > A minor comment looking at the latest webrev.07 is that some of the > lines are very long. It's not a problem now but I could image future > side-by-side reviews needing a scroll > bar.DeferredCloseProcessPipeInputStream is very long too. I split the longer lines now. The DeferredCloseProcessPipeInputStream is admittedly a long name, but it's not public and I tried to express the fact that it is a class that merges the functionalities of DeferedCloseInputStream and ProcessPipeInputStream (in .aix file it was called ProcessPipeInputStream as it was derived from it, but we can't have two with same names in common file). I hope in further re-factoring we can merge/consolidate these wrapper streams too and at that time I think they could be renamed. For now I wanted to keep the functionality as-is. But I can rename it if so desired, I just can't think of a suitable name. On 04/30/2014 06:25 PM, Martin Buchholz wrote: > Belated review. > > Peter, thank you very much for taking on this difficult unification > task. This is great work! > Comments: > --- > --- > + case SOLARIS: > + if (osArch.equals("x86")) { osArch = "i386"; } > > It's very sad that ... there's no portable way of getting the name of > libarchdir. I thought os.arch system property would suffice, but > apparently not on Solaris? ...and BSD (OS X). Is OS X missing the architecture sub-directories because it only supports one architecture now or because it used to employ "fat" (multi-architecture) binaries? > > --- > To avoid repetition, I would iniitalize with a vararg list of launch > mechanisms, of which the first one is always the default. > + LINUX(LaunchMechanism.VFORK, EnumSet.of(LaunchMechanism.FORK, > LaunchMechanism.VFORK)), > > LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), I've done that. It looks nicer now. > --- > Never use toUpperCase without a Locale, to avoid the "Turkish i problem" > + lm = > LaunchMechanism.valueOf(s.toUpperCase()); > toUpperCase(Locale.ENGLISH) Oops, thanks for spotting this. Fixed. Regards, Peter > > > > > On Wed, Apr 30, 2014 at 8:17 AM, Alan Bateman > wrote: > > On 25/04/2014 17:47, roger riggs wrote: > > Hi Peter, > > Including the test update with the updated changeset is fine. > > (I think Alan had some comments on the refactoring and has not > yet had a chance to comment). > > Thanks, Roger > > I reviewed previous rounds and you've addressed my points so I > think I'm mostly happy with this. As some point I think we should > look at Platform again as there may be an opportunity later in JDK > 9 to move it out of UNIXProcess. > > One thing that I wasn't sure about is the additions to the @author > tags as we've mostly been trying not to grow these (contentious > topic, I don't have a strong opinion as I never use @author). > > A minor comment looking at the latest webrev.07 is that some of > the lines are very long. It's not a problem now but I could image > future side-by-side reviews needing a scroll > bar.DeferredCloseProcessPipeInputStream is very long too. > > -Alan. > > From peter.levart at gmail.com Sun May 4 10:26:34 2014 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 04 May 2014 12:26:34 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <536612A4.6090406@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> Message-ID: <536615DA.2080808@gmail.com> On 05/04/2014 12:12 PM, Peter Levart wrote: > Hi Alan, Martin, > > Thanks for reviews. I have prepared another webrev based on your feedback: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.08/ > Ah, I've forgotten to mention the most important change from webrev.07. Original code wraps the processReaperExecutor construction into the doPrivileged() call. I think this was not needed. The Executors.newCachedThreadPool() does not need any special privileges. And construction of nested class ProcessReaperThreadFactory also didn't need any special privileges - apart from static initialization which called the getRootThreadGroup() method. But that method did it's own doPrivileged() wrapping in order to be able to climb the ThreadGroup hierarchy (which requires privilege). In webrev.07 I followed original code and wrapped the construction of a processReaperExecutor into a doPrivileged() although in webrev.07 the rootThreadGroup search happens as part of UNIXProcess static initialization and is already wrapped in doPrivileged(). In webrev.08 I removed this superfluous doPrivileged(). I think this is correct. SecurityManagerClinit test passes. Regards, Peter * * > Comments inline... > > On 04/30/2014 05:17 PM, Alan Bateman wrote: >> I reviewed previous rounds and you've addressed my points so I think >> I'm mostly happy with this. As some point I think we should look at >> Platform again as there may be an opportunity later in JDK 9 to move >> it out of UNIXProcess. >> >> One thing that I wasn't sure about is the additions to the @author >> tags as we've mostly been trying not to grow these (contentious >> topic, I don't have a strong opinion as I never use @author). > > I have removed myself, but left all the others (merged from all 4 > files). It's true that mercurial keeps track of authors and it's not > hard to find out who's responsible for what part of code in case > someone needs to ask the author about the not so obvious things, but > refactorings like this, which eliminate entire files and move their > content to other places, make this tracking harder. > >> >> A minor comment looking at the latest webrev.07 is that some of the >> lines are very long. It's not a problem now but I could image future >> side-by-side reviews needing a scroll >> bar.DeferredCloseProcessPipeInputStream is very long too. > > I split the longer lines now. The DeferredCloseProcessPipeInputStream > is admittedly a long name, but it's not public and I tried to express > the fact that it is a class that merges the functionalities of > DeferedCloseInputStream and ProcessPipeInputStream (in .aix file it > was called ProcessPipeInputStream as it was derived from it, but we > can't have two with same names in common file). I hope in further > re-factoring we can merge/consolidate these wrapper streams too and at > that time I think they could be renamed. For now I wanted to keep the > functionality as-is. But I can rename it if so desired, I just can't > think of a suitable name. > > > On 04/30/2014 06:25 PM, Martin Buchholz wrote: >> Belated review. >> >> Peter, thank you very much for taking on this difficult unification >> task. This is great work! >> Comments: >> --- >> --- >> + case SOLARIS: >> + if (osArch.equals("x86")) { osArch = "i386"; } >> >> It's very sad that ... there's no portable way of getting the name of >> libarchdir. I thought os.arch system property would suffice, but >> apparently not on Solaris? > > ...and BSD (OS X). Is OS X missing the architecture sub-directories > because it only supports one architecture now or because it used to > employ "fat" (multi-architecture) binaries? > >> >> --- >> To avoid repetition, I would iniitalize with a vararg list of launch >> mechanisms, of which the first one is always the default. >> + LINUX(LaunchMechanism.VFORK, >> EnumSet.of(LaunchMechanism.FORK, LaunchMechanism.VFORK)), >> >> LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > > I've done that. It looks nicer now. > >> --- >> Never use toUpperCase without a Locale, to avoid the "Turkish i problem" >> + lm = >> LaunchMechanism.valueOf(s.toUpperCase()); >> toUpperCase(Locale.ENGLISH) > > Oops, thanks for spotting this. Fixed. > > > Regards, Peter > >> >> >> >> >> On Wed, Apr 30, 2014 at 8:17 AM, Alan Bateman >> > wrote: >> >> On 25/04/2014 17:47, roger riggs wrote: >> >> Hi Peter, >> >> Including the test update with the updated changeset is fine. >> >> (I think Alan had some comments on the refactoring and has >> not yet had a chance to comment). >> >> Thanks, Roger >> >> I reviewed previous rounds and you've addressed my points so I >> think I'm mostly happy with this. As some point I think we should >> look at Platform again as there may be an opportunity later in >> JDK 9 to move it out of UNIXProcess. >> >> One thing that I wasn't sure about is the additions to the >> @author tags as we've mostly been trying not to grow these >> (contentious topic, I don't have a strong opinion as I never use >> @author). >> >> A minor comment looking at the latest webrev.07 is that some of >> the lines are very long. It's not a problem now but I could image >> future side-by-side reviews needing a scroll >> bar.DeferredCloseProcessPipeInputStream is very long too. >> >> -Alan. >> >> > From solo-java-core-libs at goeswhere.com Sun May 4 16:56:23 2014 From: solo-java-core-libs at goeswhere.com (solo-java-core-libs at goeswhere.com) Date: Sun, 4 May 2014 17:56:23 +0100 Subject: DecimalFormat rounding changes in 8 (JEP 177)? Message-ID: <20140504165623.GA20173@goeswhere.com> Hey, Could someone please help me understand what changes have happened in rounding in DecimalFormat in Java 8? new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and Oracle build 1.8.0-b132 win64 tested). My understanding of the RoundingMode.HALF_EVEN (the default) documentation is that 1.04 is the correct answer. In fact, (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware that floating point is more complex than this, and I am by no means an expert. It seems that this may be new code, with a known breaking change in it: http://openjdk.java.net/jeps/177: > Compatibility: On JDK 7, (correct) but altered numerical behavior will > only be enabled under an aggressive optimization flag to limit > behavioral compatibility impact in that release train. In Java SE 8, > the correct numerical behavior will always be required by the > specification. Did this materialise somewhere, and, if so, where's it documented? In summary: My tests fail on Java 8 and I'm not sure they're wrong. Any help would be appreciated, thanks. From joe.darcy at oracle.com Sun May 4 18:41:08 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 04 May 2014 11:41:08 -0700 Subject: DecimalFormat rounding changes in 8 (JEP 177)? In-Reply-To: <20140504165623.GA20173@goeswhere.com> References: <20140504165623.GA20173@goeswhere.com> Message-ID: <536689C4.7060700@oracle.com> Hello, On 5/4/2014 9:56 AM, solo-java-core-libs at goeswhere.com wrote: > Hey, > > Could someone please help me understand what changes have happened in > rounding in DecimalFormat in Java 8? > > new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on > Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and > Oracle build 1.8.0-b132 win64 tested). > > My understanding of the RoundingMode.HALF_EVEN (the default) > documentation is that 1.04 is the correct answer. In fact, > (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware > that floating point is more complex than this, and I am by no > means an expert. There are several inexact processes going on here. The first is the decimal to binary conversion of 1.035 to a binary double value. In general, decimal fractions are not exactly representable in binary. Java's semantics require that on decimal to binary conversion, the double value with a numerical value closest to the exact value be used, the round to nearest even policy. The exact numerical value of the double closest to 1.035 is 1.0349999999999999200639422269887290894985198974609375 a value slightly *less than* 1.035. When this value is rounded to two digits after the decimal point using the round to nearest even rounding mode, the numerically correct answer is 1.03 *not* 1.04. A range of numbers of the real line will get converted to a particular floating-point value. Some of these ranges straddle half-way points in decimal. For example, the range of values that will get converted to the floating-point value in question includes [1.0349999999999999200639422269887290894985198974609375, 1.035] The full range is [1.03499999999999980904163976447307504713535308837890625, 1.03500000000000003108624468950438313186168670654296875] This range is a one-ulp (unit in the last place, see Math.ulp) wide region centered on the exact floating-point value. When a decimal to binary conversion occurs, the original decimal text value is lost. Therefore, after the conversion, the binary double value doesn't "know" it came from "1.035" or "1.03499999999999981" or something else. The numerically correct behavior is the new behavior in JDK 8. HTH, -Joe > > > It seems that this may be new code, with a known breaking change in it: > > http://openjdk.java.net/jeps/177: >> Compatibility: On JDK 7, (correct) but altered numerical behavior will >> only be enabled under an aggressive optimization flag to limit >> behavioral compatibility impact in that release train. In Java SE 8, >> the correct numerical behavior will always be required by the >> specification. > Did this materialise somewhere, and, if so, where's it documented? > > > In summary: My tests fail on Java 8 and I'm not sure they're wrong. > Any help would be appreciated, thanks. > From wasserman.louis at gmail.com Sun May 4 19:29:59 2014 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Sun, 4 May 2014 12:29:59 -0700 Subject: DecimalFormat rounding changes in 8 (JEP 177)? In-Reply-To: <20140504165623.GA20173@goeswhere.com> References: <20140504165623.GA20173@goeswhere.com> Message-ID: What does new BigDecimal(1.035).toString() print? I suspect your issue is related to the fact that 1.035 is not, in fact, the value represented as a double; new DecimalFormat("0.00").format(1.035) formats the closest value representable as a double to the exact value 1.035. Louis Wasserman wasserman.louis at gmail.com http://profiles.google.com/wasserman.louis On Sun, May 4, 2014 at 9:56 AM, wrote: > Hey, > > Could someone please help me understand what changes have happened in > rounding in DecimalFormat in Java 8? > > new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on > Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and > Oracle build 1.8.0-b132 win64 tested). > > My understanding of the RoundingMode.HALF_EVEN (the default) > documentation is that 1.04 is the correct answer. In fact, > (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware > that floating point is more complex than this, and I am by no > means an expert. > > > It seems that this may be new code, with a known breaking change in it: > > http://openjdk.java.net/jeps/177: > > Compatibility: On JDK 7, (correct) but altered numerical behavior will > > only be enabled under an aggressive optimization flag to limit > > behavioral compatibility impact in that release train. In Java SE 8, > > the correct numerical behavior will always be required by the > > specification. > > Did this materialise somewhere, and, if so, where's it documented? > > > In summary: My tests fail on Java 8 and I'm not sure they're wrong. > Any help would be appreciated, thanks. > > From xueming.shen at oracle.com Mon May 5 06:16:20 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 04 May 2014 23:16:20 -0700 Subject: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb Message-ID: <53672CB4.3050708@oracle.com> Hi Please help review the change for #8042369 Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so most of these duplicated classes are no longer needed, with ZoneRules as the only exception. The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the serialization forms of those transitions and rules. The proposed change here is to remove those unneeded duplicated classes. I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler and and straightforward implementation, with the goal of migrating it into a second default ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the IANA directly. One of the benefits of such a provider is that the end user may just drop the latest timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from Oracle. Here is the webrev for the idea http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ The only disadvantage appears to be the possible "slowdown" of startup time because of the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for j.u.TimeZone, if we go with this direction) Thanks! -Sherman From olivier.lagneau at oracle.com Mon May 5 06:55:53 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Mon, 05 May 2014 08:55:53 +0200 Subject: DecimalFormat rounding changes in 8 (JEP 177)? In-Reply-To: <536689C4.7060700@oracle.com> References: <20140504165623.GA20173@goeswhere.com> <536689C4.7060700@oracle.com> Message-ID: <536735F9.4000401@oracle.com> Hello, On 04/05/2014 20:41, Joe Darcy wrote: > Hello, > > On 5/4/2014 9:56 AM, solo-java-core-libs at goeswhere.com wrote: >> Hey, >> >> Could someone please help me understand what changes have happened in >> rounding in DecimalFormat in Java 8? >> >> new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on >> Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and >> Oracle build 1.8.0-b132 win64 tested). >> >> My understanding of the RoundingMode.HALF_EVEN (the default) >> documentation is that 1.04 is the correct answer. In fact, >> (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware >> that floating point is more complex than this, and I am by no >> means an expert. > > There are several inexact processes going on here. The first is the > decimal to binary conversion of 1.035 to a binary double value. In > general, decimal fractions are not exactly representable in binary. > Java's semantics require that on decimal to binary conversion, the > double value with a numerical value closest to the exact value be > used, the round to nearest even policy. > > The exact numerical value of the double closest to 1.035 is > > 1.0349999999999999200639422269887290894985198974609375 > > a value slightly *less than* 1.035. When this value is rounded to two > digits after the decimal point using the round to nearest even > rounding mode, the numerically correct answer is 1.03 *not* 1.04. > > A range of numbers of the real line will get converted to a particular > floating-point value. Some of these ranges straddle half-way points in > decimal. For example, the range of values that will get converted to > the floating-point value in question includes > > [1.0349999999999999200639422269887290894985198974609375, 1.035] > > The full range is > > [1.03499999999999980904163976447307504713535308837890625, > 1.03500000000000003108624468950438313186168670654296875] > > This range is a one-ulp (unit in the last place, see Math.ulp) wide > region centered on the exact floating-point value. > > When a decimal to binary conversion occurs, the original decimal text > value is lost. Therefore, after the conversion, the binary double > value doesn't "know" it came from "1.035" or "1.03499999999999981" or > something else. > > The numerically correct behavior is the new behavior in JDK 8. > > HTH, > > -Joe Just to insist on Joe's words (Thanks Joe for the detailed reply): with floating-point "What You See *Is Not* What You Get" in most cases, and this is true with DecimalFormat when formatting double or float values. Don't expect exactness with floating-point. This is even true with constant values inside you source code like 1.035 here (which cannot be represented exactly in binary format). JDK8 fixes a bug that was discovered during JDK7 dev. Hope that helps, Olivier. > >> >> >> It seems that this may be new code, with a known breaking change in it: >> >> http://openjdk.java.net/jeps/177: >>> Compatibility: On JDK 7, (correct) but altered numerical behavior will >>> only be enabled under an aggressive optimization flag to limit >>> behavioral compatibility impact in that release train. In Java SE 8, >>> the correct numerical behavior will always be required by the >>> specification. >> Did this materialise somewhere, and, if so, where's it documented? >> >> >> In summary: My tests fail on Java 8 and I'm not sure they're wrong. >> Any help would be appreciated, thanks. >> > From ecki at zusammenkunft.net Mon May 5 07:59:27 2014 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 5 May 2014 09:59:27 +0200 Subject: DecimalFormat rounding changes in 8 (JEP 177)? In-Reply-To: <536735F9.4000401@oracle.com> References: <20140504165623.GA20173@goeswhere.com> <536689C4.7060700@oracle.com> <536735F9.4000401@oracle.com> Message-ID: Hello, Can you maybe point to the commit or Bug Number for this? The outcome of this correctness fit is pretty unfortunate (at least for the Number in question). I could imagine a new RoundingMode could help for users which insist on convieningly shoot themself in the foot. Greetings Bernd Hello, On 04/05/2014 20:41, Joe Darcy wrote: > Hello, > > On 5/4/2014 9:56 AM, solo-java-core-libs at goeswhere.com wrote: > >> Hey, >> >> Could someone please help me understand what changes have happened in >> rounding in DecimalFormat in Java 8? >> >> new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on >> Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and >> Oracle build 1.8.0-b132 win64 tested). >> >> My understanding of the RoundingMode.HALF_EVEN (the default) >> documentation is that 1.04 is the correct answer. In fact, >> (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware >> that floating point is more complex than this, and I am by no >> means an expert. >> > > There are several inexact processes going on here. The first is the > decimal to binary conversion of 1.035 to a binary double value. In general, > decimal fractions are not exactly representable in binary. Java's semantics > require that on decimal to binary conversion, the double value with a > numerical value closest to the exact value be used, the round to nearest > even policy. > > The exact numerical value of the double closest to 1.035 is > > 1.0349999999999999200639422269887290894985198974609375 > > a value slightly *less than* 1.035. When this value is rounded to two > digits after the decimal point using the round to nearest even rounding > mode, the numerically correct answer is 1.03 *not* 1.04. > > A range of numbers of the real line will get converted to a particular > floating-point value. Some of these ranges straddle half-way points in > decimal. For example, the range of values that will get converted to the > floating-point value in question includes > > [1.0349999999999999200639422269887290894985198974609375, 1.035] > > The full range is > > [1.03499999999999980904163976447307504713535308837890625, > 1.03500000000000003108624468950438313186168670654296875] > > This range is a one-ulp (unit in the last place, see Math.ulp) wide region > centered on the exact floating-point value. > > When a decimal to binary conversion occurs, the original decimal text > value is lost. Therefore, after the conversion, the binary double value > doesn't "know" it came from "1.035" or "1.03499999999999981" or something > else. > > The numerically correct behavior is the new behavior in JDK 8. > > HTH, > > -Joe > Just to insist on Joe's words (Thanks Joe for the detailed reply): with floating-point "What You See *Is Not* What You Get" in most cases, and this is true with DecimalFormat when formatting double or float values. Don't expect exactness with floating-point. This is even true with constant values inside you source code like 1.035 here (which cannot be represented exactly in binary format). JDK8 fixes a bug that was discovered during JDK7 dev. Hope that helps, Olivier. > >> >> It seems that this may be new code, with a known breaking change in it: >> >> http://openjdk.java.net/jeps/177: >> >>> Compatibility: On JDK 7, (correct) but altered numerical behavior will >>> only be enabled under an aggressive optimization flag to limit >>> behavioral compatibility impact in that release train. In Java SE 8, >>> the correct numerical behavior will always be required by the >>> specification. >>> >> Did this materialise somewhere, and, if so, where's it documented? >> >> >> In summary: My tests fail on Java 8 and I'm not sure they're wrong. >> Any help would be appreciated, thanks. >> >> > From olivier.lagneau at oracle.com Mon May 5 08:22:34 2014 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Mon, 05 May 2014 10:22:34 +0200 Subject: DecimalFormat rounding changes in 8 (JEP 177)? In-Reply-To: References: <20140504165623.GA20173@goeswhere.com> <536689C4.7060700@oracle.com> <536735F9.4000401@oracle.com> Message-ID: <53674A4A.1010400@oracle.com> On 05/05/2014 09:59, Bernd wrote: > Hello, > > Can you maybe point to the commit or Bug Number for this? The outcome of > this correctness fit is pretty unfortunate (at least for the Number in > question). Initial bug Number in JDK7 is JDK-7131459: https://bugs.openjdk.java.net/browse/JDK-7131459 related JDK8 bug is : https://bugs.openjdk.java.net/browse/JDK-8000978 Hth, Olivier > > I could imagine a new RoundingMode could help for users which insist on > convieningly shoot themself in the foot. > > Greetings > Bernd > Hello, > > On 04/05/2014 20:41, Joe Darcy wrote: > >> Hello, >> >> On 5/4/2014 9:56 AM, solo-java-core-libs at goeswhere.com wrote: >> >>> Hey, >>> >>> Could someone please help me understand what changes have happened in >>> rounding in DecimalFormat in Java 8? >>> >>> new DecimalFormat("0.00").format(1.035) is 1.04 on Java 7, and 1.03 on >>> Java 8. (7u25-2.3.10-1~deb7u1, openjdk build 1.8.0_05-b13 debian and >>> Oracle build 1.8.0-b132 win64 tested). >>> >>> My understanding of the RoundingMode.HALF_EVEN (the default) >>> documentation is that 1.04 is the correct answer. In fact, >>> (0.000, 1.0035) is 1.004, and (0.0, 1.35) is 1.4. I am aware >>> that floating point is more complex than this, and I am by no >>> means an expert. >>> >> There are several inexact processes going on here. The first is the >> decimal to binary conversion of 1.035 to a binary double value. In general, >> decimal fractions are not exactly representable in binary. Java's semantics >> require that on decimal to binary conversion, the double value with a >> numerical value closest to the exact value be used, the round to nearest >> even policy. >> >> The exact numerical value of the double closest to 1.035 is >> >> 1.0349999999999999200639422269887290894985198974609375 >> >> a value slightly *less than* 1.035. When this value is rounded to two >> digits after the decimal point using the round to nearest even rounding >> mode, the numerically correct answer is 1.03 *not* 1.04. >> >> A range of numbers of the real line will get converted to a particular >> floating-point value. Some of these ranges straddle half-way points in >> decimal. For example, the range of values that will get converted to the >> floating-point value in question includes >> >> [1.0349999999999999200639422269887290894985198974609375, 1.035] >> >> The full range is >> >> [1.03499999999999980904163976447307504713535308837890625, >> 1.03500000000000003108624468950438313186168670654296875] >> >> This range is a one-ulp (unit in the last place, see Math.ulp) wide region >> centered on the exact floating-point value. >> >> When a decimal to binary conversion occurs, the original decimal text >> value is lost. Therefore, after the conversion, the binary double value >> doesn't "know" it came from "1.035" or "1.03499999999999981" or something >> else. >> >> The numerically correct behavior is the new behavior in JDK 8. >> >> HTH, >> >> -Joe >> > Just to insist on Joe's words (Thanks Joe for the detailed reply): > with floating-point "What You See *Is Not* What You Get" in most cases, > and this is true with DecimalFormat when formatting double or float values. > > Don't expect exactness with floating-point. This is even true with constant > values inside you source code like 1.035 here (which cannot be represented > exactly in binary format). > > JDK8 fixes a bug that was discovered during JDK7 dev. > > Hope that helps, > Olivier. > > > >>> It seems that this may be new code, with a known breaking change in it: >>> >>> http://openjdk.java.net/jeps/177: >>> >>>> Compatibility: On JDK 7, (correct) but altered numerical behavior will >>>> only be enabled under an aggressive optimization flag to limit >>>> behavioral compatibility impact in that release train. In Java SE 8, >>>> the correct numerical behavior will always be required by the >>>> specification. >>>> >>> Did this materialise somewhere, and, if so, where's it documented? >>> >>> >>> In summary: My tests fail on Java 8 and I'm not sure they're wrong. >>> Any help would be appreciated, thanks. >>> >>> From paul.sandoz at oracle.com Mon May 5 08:49:19 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 May 2014 10:49:19 +0200 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> <534E9F8B.6070302@geomatys.fr> <18370F8A-191D-4586-9162-FD94F65FB48F@oracle.com> Message-ID: On May 2, 2014, at 9:22 PM, Mike Duigou wrote: > Thanks Martin and Martin; > > I have corrected this along with some additional documentation updates: > > http://cr.openjdk.java.net/~mduigou/JDK-8020860/3/webrev/ > +1. Paul. From paul.sandoz at oracle.com Mon May 5 09:11:54 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 May 2014 11:11:54 +0200 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <53651F88.2080607@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> Message-ID: <8A8A9769-8671-4A99-BF58-E2E36DAEE555@oracle.com> On May 3, 2014, at 6:55 PM, Joe Darcy wrote: > Hi Brian, > > I think the parsePrimes method would be better with a different name since no parsing is occurring anymore. > Yes, and there is no need for the try block. (The use of BitSet.stream() also reminds me we can implement a spliterator with size estimates based on the words in use, currently the stream() is created from an iterator.) > I think someone in this test the fact that Integer.MAX_VALUE is a prime should be mentioned in taken advantage of :-) How about adding another test method which tests some Mersenne primes for primality? [1] > > I'd prefer to see some comments on the primes method briefly explaining it methodology. Would the running time be unacceptable (or memory usage too large) if the limit were set to Integer.MAX_VALUE? > +1 to both of those, although perhaps the former could be done as a second iteration to get this code in? Also, probably better to create the "NavigableSet primes" just once in "main", rather than creating it twice for both tests. Still skeptical about the use of a PRNG in the tests, see my comments in a previous email: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026579.html Paul. From Alan.Bateman at oracle.com Mon May 5 09:31:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 May 2014 10:31:55 +0100 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <20140503020432.0000230d.ecki@zusammenkunft.net> References: <20140503020432.0000230d.ecki@zusammenkunft.net> Message-ID: <53675A8B.7060107@oracle.com> On 03/05/2014 01:04, Bernd Eckenfels wrote: > Hello, > > back in 2011 there was a discussion about the new changed behavior of > FilterOutputStream (and BufferedOutputStream) in regards to not anymore > swalloging IOExceptions from flush() on this list (thats where I got > the subject from). > > This was generally a very good improvement (and I am glad that > https://bugs.openjdk.java.net/browse/JDK-6335274 thereby got fixed). > However the implementation with the try-with-resource has a problem: > when flush() and close() report the same exception instance the > construction of the suppressed exception will actually fail with an > IllegalArgumentException. > > This IllegalArgumentException of Throwable.addSuppressed is very > unfortunate (it would be better simply ignore it). > > Anyway, this new behavior broke a Unit-Test for Apache VFS as you can > see here: https://issues.apache.org/jira/browse/VFS-521 > > I think this can only be fixed in Throwable by avoiding this > IllegalArgumentException or by the close() method not using > try-with-resource. > > For reference, according to this changeset other locations are affected > as well: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf > Thanks this bug report, I've created JDK-8042377 to track it. I don't think this has come up before, probably because flush and close are more likely to throw new exceptions rather than equal (cached) exceptions. I don't see this issue as driver to changing Throwable to support self suppression but we can change BufferedWriter and FilteredOuputStream to only add the suppressed exception when they are not equal. -Alan. From ecki at zusammenkunft.net Mon May 5 09:44:49 2014 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 5 May 2014 11:44:49 +0200 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <53675A8B.7060107@oracle.com> References: <20140503020432.0000230d.ecki@zusammenkunft.net> <53675A8B.7060107@oracle.com> Message-ID: Thanks Alan, I just want to add that I think the IAE is quite in a unfortunate location when it is caused by TWR. Especially for that usecase silently ignoring the add is more robust. If you look at Stackoverflow or Google there ard already other People confused by it, it happens all over the place. https://www.google.de/search?q=close+IllegalArgumentException+self-suppression Bernd Am 05.05.2014 11:32 schrieb "Alan Bateman" : > On 03/05/2014 01:04, Bernd Eckenfels wrote: > >> Hello, >> >> back in 2011 there was a discussion about the new changed behavior of >> FilterOutputStream (and BufferedOutputStream) in regards to not anymore >> swalloging IOExceptions from flush() on this list (thats where I got >> the subject from). >> >> This was generally a very good improvement (and I am glad that >> https://bugs.openjdk.java.net/browse/JDK-6335274 thereby got fixed). >> However the implementation with the try-with-resource has a problem: >> when flush() and close() report the same exception instance the >> construction of the suppressed exception will actually fail with an >> IllegalArgumentException. >> >> This IllegalArgumentException of Throwable.addSuppressed is very >> unfortunate (it would be better simply ignore it). >> >> Anyway, this new behavior broke a Unit-Test for Apache VFS as you can >> see here: https://issues.apache.org/jira/browse/VFS-521 >> >> I think this can only be fixed in Throwable by avoiding this >> IllegalArgumentException or by the close() method not using >> try-with-resource. >> >> For reference, according to this changeset other locations are affected >> as well: >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf >> >> Thanks this bug report, I've created JDK-8042377 to track it. I don't > think this has come up before, probably because flush and close are more > likely to throw new exceptions rather than equal (cached) exceptions. > > I don't see this issue as driver to changing Throwable to support self > suppression but we can change BufferedWriter and FilteredOuputStream to > only add the suppressed exception when they are not equal. > > -Alan. > From Ulf.Zibis at CoSoCo.de Mon May 5 10:03:00 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 05 May 2014 12:03:00 +0200 Subject: Covariant overrides on the Buffer Hierachy In-Reply-To: <5363C413.9000607@oracle.com> References: <534CF1D5.70605@oracle.com> <5350142D.8040706@oracle.com> <5354FC9F.1020409@gmail.com> <53559572.2080004@redhat.com> <535633C2.5090501@gmail.com> <5356650F.5020909@redhat.com> <53568254.3010106@gmail.com> <535689DC.6060907@redhat.com> <53619340.6010505@oracle.com> <5363C363.5020708@CoSoCo.de> <5363C413.9000607@oracle.com> Message-ID: <536761D4.9000403@CoSoCo.de> Am 02.05.2014 18:13, schrieb Joe Darcy: > On 5/2/2014 9:10 AM, Ulf Zibis wrote: >> Am 01.05.2014 02:20, schrieb Joe Darcy: >>> If from an API perspective the new code is preferable, I would say that should take precedence >>> over an at most marginal performance degradation. >> >> I guess you meant: ... marginal performance _gain_. >> > > No, I actually meant degradation. > > If the new API is easier to use, captures more type information, etc., in my estimation that is > more important than a whisker thin performance penalty in an area that is not performance critical. Hi Joe, Ok I see, I have stumbled over the semantical grammar of your sentence. English is not my mother tongue. You set the benefit and the disadvantage of 1 approach in concurrence. I have read the concurrence of 2 possible benefits of the 2 possible approaches: - better API - better performance Thanks, Ulf From volker.simonis at gmail.com Mon May 5 12:57:31 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 May 2014 14:57:31 +0200 Subject: Draft JEP: JDK Core Libraries Test Stabilization In-Reply-To: <53619085.6090000@oracle.com> References: <53619085.6090000@oracle.com> Message-ID: Hi Stuart, great proposal. You can count on me when it comes to testing on exotic platforms like for example AIX:) Regards, Volker On Thu, May 1, 2014 at 2:08 AM, Stuart Marks wrote: > Hi all, > > Here's a draft JEP for stabilizing the core libraries regression test suite, > that is, fixing up the spuriously failing tests. Please review and comment. > > Thanks! > > s'marks > > > > > Title: JDK Core Libraries Test Stabilization > Author: Stuart Marks > Organization: Oracle > Discussion: core-libs-dev at openjdk.java.net > [...other metadata elided...] > > Summary > ------- > > The JDK Regression Test Suite has several thousand fully automated > tests. These tests are valuable and effective in that they serve to > prevent bugs from entering the code base. However, they suffer from > many intermittent failures. Many of these failures are "spurious" in > that they are not caused by bugs in the product. Spurious failures add > considerable noise to test reports; they make it impossible for > developers to ascertain whether a particular change has introduced a > bug; and they obscure actual failures. > > The reliability of the regression suite has improved considerably over > the past few years. However, there are perhaps still 100-200 tests > that fail intermittently, and most of these failures are spurious. > This project aims to reduce the number and frequency of spuriously > failing tests to a level where it no longer is an impediment to > development. > > This project targets tests from the regression suite that cover the > JDK Core Libraries, including base packages (java.lang, io, nio, util) > I18N, Networking, RMI, Security, and Serviceability. JAXP and CORBA > are also included, although they have relatively few regression tests > at present. > > > Non-Goals > --------- > > Regression tests for other areas, including Hotspot, Langtools, and > Client areas, are not included in this project. > > This project does not address operational issues that might cause > builds or test runs to fail or for reports not to be delivered in a > timely fashion. > > This project is not focused on product bugs that cause test > failures. Such test failures are "good" in that the test suite is > providing valid information about the product. > > Test runs on embedded platforms are not covered by this project. > > > Success Metrics > --------------- > > The reliability of a successful test run (100% pass) currently stands > at approximately 0.5%. The goal is to improve this success rate to > 98%, exclusive of true failures (i.e., those caused by bugs in the > product). At a 98% success rate, a continuous build system that runs ten > jobs per day, five days a week would have one or fewer spurious > failures per week. > > > Motivation > ---------- > > Developers are continually hampered by the unreliability of the > regression test suite. Intermittently failing tests add significant > noise to the results of every test run. The consequence is that > developers cannot tell whether test failures were caused by bugs > introduced by a recent change or whether they are spurious > failures. In addition, the intermittent failures mask actual failures > in the product, slowing development and reducing quality. Developers > should be able to rely on the test suite telling them accurate > information: test failures should indicate the introduction of a bug > into the system, and absence of test failures should be usable as > evidence that changes are correct. > > > Description > ----------- > > Spurious test failures fall into two broad categories: > > - test bugs > - environmental issues > > Our working assumption for most intermittent test failures is that > they are spurious, and further, that they are caused by bugs in the > test itself. While it is possible for a product bug to cause an > intermittent failure, this is relatively rare. The majority of > intermittent failures encountered so far have indeed proven to be test > bugs. > > "Environmental" issues, such as misconfigured test machines, temporary > dysfunction on the machine running the test job (e.g., filesystem > full), or transient network failures, also contribute to spurious > failures. Test should be made more robust, if possible. Environment > issues should be fed back to the infrastructure team for resolution > and future infrastructure improvements. > > A variety of techniques will be employed to diagnose, track, and help > develop fixes for intermittently failing tests: > > - track all test failures in JBS > - repeated test runs against the same build > - gather statistics about failure rates, # tests with bugs, and track > continuously > - investigate pathologies for common test failure modes > - develop techniques for fixing common test bugs > - develop test library code to improve commonality across tests and to > avoid typical failure modes > - add instrumentation to tests (and to the test suite) to improve > diagnosability > - exclude tests judiciously, preferably only as a last resort > - change reviews > - code inspections > > > Alternatives > ------------ > > The most likely alternative to diagnosing and fixing intermittent > failures is to aggressively exclude intermittently failing tests from > the test suite. This trades off code coverage in favor of test > reliability, adding risk of undetected bug introduction. > > > Testing > ------- > > The subject of the project is the test suite itself. The main > "testing" of the test suite is running it repeatedly in a variety of > environments, including continuous build-and-test systems, as well as > recurring "same-binary" test runs on promoted builds. This will help > flush out intermittent failures and detect newly introduced failures. > > > Risks and Assumptions > --------------------- > > We are working on a long tail of intermittent failures, which may > become increasingly frustrating as time goes on, resulting in the > project stalling out. > > New intermittent failures may be introduced or discovered more quickly > than they can be resolved. > > The main work of fixing up the tests will be spread across several > development groups. This requires good cross-group coordination and > focus. > > The culture in the development group has (mostly) been to ignore test > failures, or to find ways to cope with them. As intermittent failures > are removed, we hope to decrease the group's tolerance of test failures. > > > Dependences > ----------- > > No dependences on other JEPs or components. > > > Impact > ------ > > No impact on specific parts of the platform or product, except for > developer time and effort being spent on it, across various component > teams. > > ========== From paul.sandoz at oracle.com Mon May 5 13:16:02 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 May 2014 15:16:02 +0200 Subject: JDK-8042355 stream with sorted() causes downstream ops not to be lazy Message-ID: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> Hi, https://bugs.openjdk.java.net/browse/JDK-8042355 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/ This is an optimization to ensure that sorted() in sequential pipelines does not aggressively push all sorted elements downstream if the pipeline is known to be short-circuiting. Note that it is not an error that more elements, than strictly required to produce a result, may flow through the pipeline. This can occur, in general (not restricted to just sorting), for short-circuiting parallel pipelines. Paul. From peter.levart at gmail.com Mon May 5 14:40:30 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 05 May 2014 16:40:30 +0200 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <53675A8B.7060107@oracle.com> References: <20140503020432.0000230d.ecki@zusammenkunft.net> <53675A8B.7060107@oracle.com> Message-ID: <5367A2DE.8090100@gmail.com> On 05/05/2014 11:31 AM, Alan Bateman wrote: > On 03/05/2014 01:04, Bernd Eckenfels wrote: >> Hello, >> >> back in 2011 there was a discussion about the new changed behavior of >> FilterOutputStream (and BufferedOutputStream) in regards to not anymore >> swalloging IOExceptions from flush() on this list (thats where I got >> the subject from). >> >> This was generally a very good improvement (and I am glad that >> https://bugs.openjdk.java.net/browse/JDK-6335274 thereby got fixed). >> However the implementation with the try-with-resource has a problem: >> when flush() and close() report the same exception instance the >> construction of the suppressed exception will actually fail with an >> IllegalArgumentException. >> >> This IllegalArgumentException of Throwable.addSuppressed is very >> unfortunate (it would be better simply ignore it). >> >> Anyway, this new behavior broke a Unit-Test for Apache VFS as you can >> see here: https://issues.apache.org/jira/browse/VFS-521 >> >> I think this can only be fixed in Throwable by avoiding this >> IllegalArgumentException or by the close() method not using >> try-with-resource. >> >> For reference, according to this changeset other locations are affected >> as well: >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf >> > Thanks this bug report, I've created JDK-8042377 to track it. I don't > think this has come up before, probably because flush and close are > more likely to throw new exceptions rather than equal (cached) > exceptions. Hi Alan, There has been a discussion about a year ago on this list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015947.html > > I don't see this issue as driver to changing Throwable to support self > suppression but we can change BufferedWriter and FilteredOuputStream > to only add the suppressed exception when they are not equal. It's try-with-resources construct that adds suppressed exceptions to other exceptions, OuputStreams are just throwing them. And (Buffered)FilteredOuputStream doesn't do any exception caching - it just propagates exceptions thrown by underlying OuputStream. If underlying OuputStream is throwing the same instance on flush() and on close() than we have problem. The only thing a FilteredOuputStream could do was to actually cache the exception thrown by underlying stream's flush() method and compare it by reference with the exception thrown by underlying stream's close() method and clone it if it happens to be the same instance before throwing it. But that's probably not a very clean approach and it would only be effective for FilteredOuputStreams and subclasses. I think it would be better to just change the Throwable.addSuppressed() method to treat self-suppression as a no-op. Or change javac to generate code that only calls target.addSuppressed(t) when t != target ... Regards, Peter > > -Alan. From Alan.Bateman at oracle.com Mon May 5 14:47:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 May 2014 15:47:40 +0100 Subject: FilterOutputStream.close() throws exception from flush() In-Reply-To: <5367A2DE.8090100@gmail.com> References: <20140503020432.0000230d.ecki@zusammenkunft.net> <53675A8B.7060107@oracle.com> <5367A2DE.8090100@gmail.com> Message-ID: <5367A48C.9010303@oracle.com> On 05/05/2014 15:40, Peter Levart wrote: > > Hi Alan, > > There has been a discussion about a year ago on this list: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015947.html > Yes, I remember this and also reviewed it for Joe. My point about it not coming up before was in the context of BufferedWriter/etc where close needs to flush. In that case then I think it would be more typically to throw a new IOException each time. I'll leave to Joe to comment on suggestion to drop self suppression. -Alan From roger.riggs at oracle.com Mon May 5 15:41:19 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 05 May 2014 11:41:19 -0400 Subject: RFR 9: 8034906: Fix typos, errors and Javadoc differences in java.time Message-ID: <5367B11F.5070906@oracle.com> Please review for JDK 9, editorial corrections and cleanup for java.time classes. The grammar has been improved and some redundant @throws NPE clauses removed. Javadoc links have been corrected. Original patch from Stephen Colebourne, some additions and corrections by me. webrev: http://cr.openjdk.java.net/~rriggs/webrev-typos-8034906.patch/ Issue: https://bugs.openjdk.java.net/browse/JDK-8034906 Thanks, Roger From paul.sandoz at oracle.com Mon May 5 16:26:52 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 May 2014 18:26:52 +0200 Subject: RFR 9: 8034906: Fix typos, errors and Javadoc differences in java.time In-Reply-To: <5367B11F.5070906@oracle.com> References: <5367B11F.5070906@oracle.com> Message-ID: <826AB2FC-7520-434A-894D-77BB88DE24D5@oracle.com> On May 5, 2014, at 5:41 PM, roger riggs wrote: > Please review for JDK 9, editorial corrections and cleanup for java.time classes. > The grammar has been improved and some redundant @throws NPE clauses removed. > Javadoc links have been corrected. Original patch from Stephen Colebourne, > some additions and corrections by me. > > webrev: http://cr.openjdk.java.net/~rriggs/webrev-typos-8034906.patch/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8034906 > Looks good to me. Paul. From mike.duigou at oracle.com Mon May 5 16:33:55 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 5 May 2014 09:33:55 -0700 Subject: JDK-8042355 stream with sorted() causes downstream ops not to be lazy In-Reply-To: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> References: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> Message-ID: <941E8FE4-6C6B-474F-9809-C6CED6322BAE@oracle.com> Looks good to me. On May 5 2014, at 06:16 , Paul Sandoz wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-8042355 > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/ > > This is an optimization to ensure that sorted() in sequential pipelines does not aggressively push all sorted elements downstream if the pipeline is known to be short-circuiting. > > Note that it is not an error that more elements, than strictly required to produce a result, may flow through the pipeline. This can occur, in general (not restricted to just sorting), for short-circuiting parallel pipelines. > > Paul. > > From ivan.gerasimov at oracle.com Mon May 5 16:56:31 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 05 May 2014 20:56:31 +0400 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException In-Reply-To: <53565D04.7010905@oracle.com> References: <53565D04.7010905@oracle.com> Message-ID: <5367C2BF.6090208@oracle.com> Hello! This is a friendly reminder. Could a Reviewer please review/approve this fix? The problem is that a BitSet can have bit # MAX_VALUE set, but trying to convert it to String throws an exception. Sincerely yours, Ivan On 22.04.2014 16:13, Ivan Gerasimov wrote: > Hello! > > If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() > will throw an exception. > The same thing happens if the bit (Integer.MAX_VALUE-1) is set. > > Would you please help review the fix for this issue? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 > WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ > > Sincerely yours, > Ivan > From mike.duigou at oracle.com Mon May 5 17:37:40 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 5 May 2014 10:37:40 -0700 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException In-Reply-To: <5367C2BF.6090208@oracle.com> References: <53565D04.7010905@oracle.com> <5367C2BF.6090208@oracle.com> Message-ID: The fix looks good though I wonder if the conditional checks can be optimized a bit. I am concerned that the suggested iteration method provided in the nextSetBit() javadoc induces the same failure we just corrected. Perhaps we should revise that advice? Mike On May 5 2014, at 09:56 , Ivan Gerasimov wrote: > Hello! > > This is a friendly reminder. > Could a Reviewer please review/approve this fix? > > The problem is that a BitSet can have bit # MAX_VALUE set, but trying to convert it to String throws an exception. > > Sincerely yours, > Ivan > > On 22.04.2014 16:13, Ivan Gerasimov wrote: >> Hello! >> >> If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() will throw an exception. >> The same thing happens if the bit (Integer.MAX_VALUE-1) is set. >> >> Would you please help review the fix for this issue? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ >> >> Sincerely yours, >> Ivan >> > From ivan.gerasimov at oracle.com Mon May 5 18:54:51 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 05 May 2014 22:54:51 +0400 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException In-Reply-To: References: <53565D04.7010905@oracle.com> <5367C2BF.6090208@oracle.com> Message-ID: <5367DE7B.7010205@oracle.com> Thank you Mike! On 05.05.2014 21:37, Mike Duigou wrote: > The fix looks good though I wonder if the conditional checks can be optimized a bit. Hm. I don't see lots of room for optimization here without revising nexSetBit() and nextClearBit() implementation. The first check at 1190 is already used to catch two cases: - at the first entrance into the loop, when i was MAX_VALUE, - at the other cycles, when endOfRun was either MAX_VALUE or -1. > I am concerned that the suggested iteration method provided in the nextSetBit() javadoc induces the same failure we just corrected. Perhaps we should revise that advice? Yes. I added a check into the loop. It seems to be the simplest way to make the sample correct. Would you please take a look at the updated webrev? http://cr.openjdk.java.net/~igerasim/8040806/1/webrev/ Sincerely yours, Ivan > Mike > > On May 5 2014, at 09:56 , Ivan Gerasimov wrote: > >> Hello! >> >> This is a friendly reminder. >> Could a Reviewer please review/approve this fix? >> >> The problem is that a BitSet can have bit # MAX_VALUE set, but trying to convert it to String throws an exception. >> >> Sincerely yours, >> Ivan >> >> On 22.04.2014 16:13, Ivan Gerasimov wrote: >>> Hello! >>> >>> If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() will throw an exception. >>> The same thing happens if the bit (Integer.MAX_VALUE-1) is set. >>> >>> Would you please help review the fix for this issue? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> > > From mike.duigou at oracle.com Mon May 5 19:03:48 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 5 May 2014 12:03:48 -0700 Subject: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException In-Reply-To: <5367DE7B.7010205@oracle.com> References: <53565D04.7010905@oracle.com> <5367C2BF.6090208@oracle.com> <5367DE7B.7010205@oracle.com> Message-ID: <25C2E7CE-7F20-42EA-A8B7-623F739E8E4B@oracle.com> On May 5 2014, at 11:54 , Ivan Gerasimov wrote: > Thank you Mike! > > On 05.05.2014 21:37, Mike Duigou wrote: >> The fix looks good though I wonder if the conditional checks can be optimized a bit. > > Hm. I don't see lots of room for optimization here without revising nexSetBit() and nextClearBit() implementation. > > The first check at 1190 is already used to catch two cases: > - at the first entrance into the loop, when i was MAX_VALUE, > - at the other cycles, when endOfRun was either MAX_VALUE or -1. OK. (I was just musing, I hadn't thought too hard whether there practical improvements possible) > >> I am concerned that the suggested iteration method provided in the nextSetBit() javadoc induces the same failure we just corrected. Perhaps we should revise that advice? > Yes. I added a check into the loop. It seems to be the simplest way to make the sample correct. Agreed. > > Would you please take a look at the updated webrev? > > http://cr.openjdk.java.net/~igerasim/8040806/1/webrev/ Looks good. > > Sincerely yours, > Ivan > >> Mike >> >> On May 5 2014, at 09:56 , Ivan Gerasimov wrote: >> >>> Hello! >>> >>> This is a friendly reminder. >>> Could a Reviewer please review/approve this fix? >>> >>> The problem is that a BitSet can have bit # MAX_VALUE set, but trying to convert it to String throws an exception. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 22.04.2014 16:13, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> If a BitSet has the bit Integer.MAX_VALUE set, then calling toString() will throw an exception. >>>> The same thing happens if the bit (Integer.MAX_VALUE-1) is set. >>>> >>>> Would you please help review the fix for this issue? >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8040806/0/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >> >> > From brian.burkhalter at oracle.com Mon May 5 21:17:27 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 5 May 2014 14:17:27 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <53651F88.2080607@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> Message-ID: Joe / Paul, Thanks for the comments. This an aggregate response to your two messages. An updated version of the patch is here: http://cr.openjdk.java.net/~bpb/8026236/webrev.03/ I believe that it addresses all the points of concern aside from testing Mersenne primes. Please see more comments in line. Thanks, Brian On May 3, 2014, at 9:55 AM, Joe Darcy wrote: > Hi Brian, > > I think the parsePrimes method would be better with a different name since no parsing is occurring anymore. Renamed methods to createPrimes() and getPrimes(). > I think someone in this test the fact that Integer.MAX_VALUE is a prime should be mentioned in taken advantage of :-) Done. Simply appended this one value to the list. ;-) > How about adding another test method which tests some Mersenne primes for primality? [1] No done. > I'd prefer to see some comments on the primes method briefly explaining it methodology. Done via a link to Wikipedia. > Would the running time be unacceptable (or memory usage too large) if the limit were set to Integer.MAX_VALUE? Yes, I tried it. Still running after at least ten minutes when I killed it. > Thanks, > > -Joe > > [1] http://en.wikipedia.org/wiki/Mersenne_prime On May 5, 2014, at 2:11 AM, Paul Sandoz wrote: > On May 3, 2014, at 6:55 PM, Joe Darcy wrote: > >> Hi Brian, >> >> I think the parsePrimes method would be better with a different name since no parsing is occurring anymore. >> > > Yes, and there is no need for the try block. Removed. > (The use of BitSet.stream() also reminds me we can implement a spliterator with size estimates based on the words in use, currently the stream() is created from an iterator.) Made no change based on this comment (which I interpreted as an aside). > >> I think someone in this test the fact that Integer.MAX_VALUE is a prime should be mentioned in taken advantage of :-) How about adding another test method which tests some Mersenne primes for primality? [1] >> >> I'd prefer to see some comments on the primes method briefly explaining it methodology. Would the running time be unacceptable (or memory usage too large) if the limit were set to Integer.MAX_VALUE? >> > > +1 to both of those, although perhaps the former could be done as a second iteration to get this code in? This is what I did: +1 on the both but not the Mersennes. > Also, probably better to create the "NavigableSet primes" just once in "main", rather than creating it twice for both tests. Done. > Still skeptical about the use of a PRNG in the tests, see my comments in a previous email: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026579.html Changed to SplittableRandom but collected the intermediate stream into a list which is inspected upon failure to find the value which exposed the misbehavior. From yumin.qi at oracle.com Mon May 5 23:15:29 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 05 May 2014 16:15:29 -0700 Subject: RFR: 8042243: Map shared archive to preallocated static address Message-ID: <53681B91.1080105@oracle.com> Hi, Please have codereview for 8042243: Map shared archive to preallocated static address webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ bug: https://bugs.openjdk.java.net/browse/JDK-8042243 Summary: Mapping shared archive (jsa) some time fail due to ASLR (Address space layout randomization) on 32bit Linux platforms. To solve we come up with mapping shared archive to preallocated static space since with Linux and the GCC compiler, the BSS section in the main executable is not randomized, instead, the variable address in the BSS section is fixed at build time. The tests also showed the extra 32M space will NOT affect java memory setting though it seems 32M virtual address space always allocated no matter it is used or not (If -XX:ShareBaseAddress supply alternative address for dumping, the static address will be ignored.) Note the changes is for 32 bit Linux only. Tests: JPRT, manual test for archive sharing. Thanks Yumin From david.holmes at oracle.com Tue May 6 02:59:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 May 2014 12:59:46 +1000 Subject: RFR: 8042243: Map shared archive to preallocated static address In-Reply-To: <53681B91.1080105@oracle.com> References: <53681B91.1080105@oracle.com> Message-ID: <53685022.9020508@oracle.com> Hi Yumin, For something that only addresses one platform this adds a lot of platform specific code to a bunch of shared files. Are there plans to extend this to other platforms? Otherwise can we make this more platform agnostic? Perhaps move the os specific code to the os class? Seems the changes in filemap.cpp and metaspace.cpp could easily be factored into an os method that returns a boolean to indicate whether there is a fixed mapping. And perhaps define set_static_shared_space in the os class and always expose it via jni.cpp. Actually, why are we exposing this via jni.cpp rather than jvm.cpp? This is not part of the JNI interface to the VM. Thanks, David On 6/05/2014 9:15 AM, Yumin Qi wrote: > Hi, Please have codereview for > > 8042243: Map shared archive to preallocated static address > > webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8042243 > > Summary: Mapping shared archive (jsa) some time fail due to ASLR > (Address space layout randomization) on 32bit Linux platforms. To solve > we come up with mapping shared archive to preallocated static space > since with Linux and the GCC compiler, the BSS section in the main > executable is not randomized, instead, the variable address in the BSS > section is fixed at build time. The tests also showed the extra 32M > space will NOT affect java memory setting though it seems 32M virtual > address space always allocated no matter it is used or not (If > -XX:ShareBaseAddress supply alternative address for dumping, the static > address will be ignored.) Note the changes is for 32 bit Linux only. > > Tests: JPRT, manual test for archive sharing. > > Thanks > Yumin From yumin.qi at oracle.com Tue May 6 04:46:17 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 05 May 2014 21:46:17 -0700 Subject: RFR: 8042243: Map shared archive to preallocated static address In-Reply-To: <53685022.9020508@oracle.com> References: <53681B91.1080105@oracle.com> <53685022.9020508@oracle.com> Message-ID: <53686919.8040803@oracle.com> David, Thanks for the review. On 5/5/2014 7:59 PM, David Holmes wrote: > Hi Yumin, > > For something that only addresses one platform this adds a lot of > platform specific code to a bunch of shared files. Are there plans to > extend this to other platforms? Otherwise can we make this more > platform agnostic? Perhaps move the os specific code to the os class? > Seems the changes in filemap.cpp and metaspace.cpp could easily be > factored into an os method that returns a boolean to indicate whether > there is a fixed mapping. > Let me rethink and reorganize the code. > And perhaps define set_static_shared_space in the os class and always > expose it via jni.cpp. Actually, why are we exposing this via jni.cpp > rather than jvm.cpp? This is not part of the JNI interface to the VM. I think I can use JVM_LEAF, other entries all call to get current JavaThread which is not available at the time this function called since VM is not init'ed. But using this entry is dangerous too. verify_stack_alignment() will be called in JVM_LEAF_BASE, it won't have effect since it is empty function for debug version. It may become problematic in future I think, so i decided to have a plain JNI function so put it in jni.cpp. This function is more like a private function. Thanks Yumin > > Thanks, > David > > On 6/05/2014 9:15 AM, Yumin Qi wrote: >> Hi, Please have codereview for >> >> 8042243: Map shared archive to preallocated static address >> >> webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8042243 >> >> Summary: Mapping shared archive (jsa) some time fail due to ASLR >> (Address space layout randomization) on 32bit Linux platforms. To solve >> we come up with mapping shared archive to preallocated static space >> since with Linux and the GCC compiler, the BSS section in the main >> executable is not randomized, instead, the variable address in the BSS >> section is fixed at build time. The tests also showed the extra 32M >> space will NOT affect java memory setting though it seems 32M virtual >> address space always allocated no matter it is used or not (If >> -XX:ShareBaseAddress supply alternative address for dumping, the static >> address will be ignored.) Note the changes is for 32 bit Linux only. >> >> Tests: JPRT, manual test for archive sharing. >> >> Thanks >> Yumin From paul.sandoz at oracle.com Tue May 6 08:25:17 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 May 2014 10:25:17 +0200 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> Message-ID: <27C161DF-A79C-470C-93C7-5BB2E7E42588@oracle.com> On May 5, 2014, at 11:17 PM, Brian Burkhalter wrote: > Joe / Paul, > > Thanks for the comments. This an aggregate response to your two messages. An updated version of the patch is here: > > http://cr.openjdk.java.net/~bpb/8026236/webrev.03/ > > I believe that it addresses all the points of concern aside from testing Mersenne primes. > +1 Pau. From fweimer at redhat.com Tue May 6 08:59:04 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 10:59:04 +0200 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> Message-ID: <5368A458.20704@redhat.com> On 05/05/2014 11:17 PM, Brian Burkhalter wrote: > Joe / Paul, > > Thanks for the comments. This an aggregate response to your two > messages. An updated version of the patch is here: > > http://cr.openjdk.java.net/~bpb/8026236/webrev.03/ The command line parsing is off by one, I think, it should check for >= instead of >: 54 // Prepare arguments 55 int upperBound = args.length > 1 ? Integer.valueOf(args[0]) : DEFAULT_UPPER_BOUND; 56 int certainty = args.length > 2 ? Integer.valueOf(args[1]) : DEFAULT_CERTAINTY; 57 boolean parallel = args.length > 3 ? Boolean.valueOf(args[2]) : true; I think this line should go, it doesn't match the shifted indexing: 98 //bs.set(0, 2, true); There are some very long lines: 120 NavigableSet primes = bs.stream().mapToObj(p -> BigInteger.valueOf(p + 2)).collect(toCollection(TreeSet::new)); 180 List bigInts = (new SplittableRandom()).ints(NUM_NON_PRIMES, 2, maxPrime).mapToObj(BigInteger::valueOf).filter(b -> !b.isProbablePrime(certainty)).collect(toList()); The arithmetic in checkPrime() is unnecessary because isProbablePrime() will never report a prime as a non-prime (the Monte-Carlo vs Las Vegas thing), so the count will always be exact because you feed it only primes. It is impossible to check for the expected number of failures (non-primes reported as primes) in checkNonPrimes() because this would result in a test that fails sporadically. -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Tue May 6 09:30:25 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 11:30:25 +0200 Subject: JDK-8042355 stream with sorted() causes downstream ops not to be lazy In-Reply-To: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> References: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> Message-ID: <5368ABB1.3010800@redhat.com> On 05/05/2014 03:16 PM, Paul Sandoz wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-8042355 > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/ > > This is an optimization to ensure that sorted() in sequential pipelines does not aggressively push all sorted elements downstream if the pipeline is known to be short-circuiting. Would it be possible to use something like heap sort to avoid sorting the entire input stream if only the first few smallest items are needed? -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Tue May 6 11:02:42 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 May 2014 13:02:42 +0200 Subject: JDK-8042355 stream with sorted() causes downstream ops not to be lazy In-Reply-To: <5368ABB1.3010800@redhat.com> References: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> <5368ABB1.3010800@redhat.com> Message-ID: On May 6, 2014, at 11:30 AM, Florian Weimer wrote: > On 05/05/2014 03:16 PM, Paul Sandoz wrote: >> Hi, >> >> https://bugs.openjdk.java.net/browse/JDK-8042355 >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/ >> >> This is an optimization to ensure that sorted() in sequential pipelines does not aggressively push all sorted elements downstream if the pipeline is known to be short-circuiting. > > Would it be possible to use something like heap sort to avoid sorting the entire input stream if only the first few smallest items are needed? > For ordered streams the sort is required to be stable, and the sorted op does not know in advanced at most how many elements are required to be pushed downstream (although it might be possible to fix the latter by back-propagating more information upstream i am not sure it is worth it). Paul. From fweimer at redhat.com Tue May 6 11:00:18 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 13:00:18 +0200 Subject: How to mount a volume with file owners being nobody? In-Reply-To: <5B438ACC-51B7-44A9-8952-E5A1CD2E823A@oracle.com> References: <5B438ACC-51B7-44A9-8952-E5A1CD2E823A@oracle.com> Message-ID: <5368C0C2.6070905@redhat.com> On 04/18/2014 05:28 AM, Wang Weijun wrote: > I have seen such things before but cannot create one now. I would like to simulate a problematic environment on my own machines. Any suggestion is welcomed, I have Mac OS X and Windows at hand but Linux and Solaris are also OK. I'm not sure what you need, but with file systems such as vfat which do not store owner information, you can specify an arbitrary user/group combination at mount (on Linux). -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Tue May 6 11:22:13 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 13:22:13 +0200 Subject: Fedora sun.misc.Unsafe statistics In-Reply-To: <409CB24B-1960-46BF-9660-D664A14994C0@oracle.com> References: <53163614.2070802@redhat.com> <409CB24B-1960-46BF-9660-D664A14994C0@oracle.com> Message-ID: <5368C5E5.3000708@redhat.com> On 03/12/2014 10:45 AM, Paul Sandoz wrote: > Hi Florian, > > Thanks for doing this. Sorry, I missed your follow-up until now. > Do you have any more context on what RPMs/jars are using what methods of Unsafe? Attached. Columns are package NEVRA, JAR name, method and descriptor in Unsafe. I used CSV this time to reduce file size (there's no column padding). Hopefully the attachment is below the mailing list size limit. > It might be useful to obtain the number of (transitive) dependencies on such jars. I don't have data yet from maven central but i know some jars that use Unsafe are quite popular. Yes, I see a few rather well-known packages in the list. We do not have good dependency information in Fedora (the Powers That Be refuse to use Class-Path entries in manifests), so I'm not sure if I should try to come up with a WITH RECURSIVE query (CONNECT BY for you guys :-) that counts the reverse dependencies. I plan to file Fedora bugs for the sun.misc.* changes as they hit JDK 9, provided that the Fedora folks do not object. -- Florian Weimer / Red Hat Product Security Team From david.holmes at oracle.com Tue May 6 12:13:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 May 2014 22:13:15 +1000 Subject: Fedora sun.misc.Unsafe statistics In-Reply-To: <5368C5E5.3000708@redhat.com> References: <53163614.2070802@redhat.com> <409CB24B-1960-46BF-9660-D664A14994C0@oracle.com> <5368C5E5.3000708@redhat.com> Message-ID: <5368D1DB.60802@oracle.com> On 6/05/2014 9:22 PM, Florian Weimer wrote: > On 03/12/2014 10:45 AM, Paul Sandoz wrote: >> Hi Florian, >> >> Thanks for doing this. > > Sorry, I missed your follow-up until now. > >> Do you have any more context on what RPMs/jars are using what methods >> of Unsafe? > > Attached. Columns are package NEVRA, JAR name, method and descriptor in > Unsafe. I used CSV this time to reduce file size (there's no column > padding). Hopefully the attachment is below the mailing list size limit. Either too big or not an accepted MIME type. :( David >> It might be useful to obtain the number of (transitive) dependencies >> on such jars. I don't have data yet from maven central but i know some >> jars that use Unsafe are quite popular. > > Yes, I see a few rather well-known packages in the list. We do not have > good dependency information in Fedora (the Powers That Be refuse to use > Class-Path entries in manifests), so I'm not sure if I should try to > come up with a WITH RECURSIVE query (CONNECT BY for you guys :-) that > counts the reverse dependencies. > > I plan to file Fedora bugs for the sun.misc.* changes as they hit JDK 9, > provided that the Fedora folks do not object. > From fweimer at redhat.com Tue May 6 12:23:43 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 14:23:43 +0200 Subject: Fedora sun.misc.Unsafe statistics In-Reply-To: <5368D1DB.60802@oracle.com> References: <53163614.2070802@redhat.com> <409CB24B-1960-46BF-9660-D664A14994C0@oracle.com> <5368C5E5.3000708@redhat.com> <5368D1DB.60802@oracle.com> Message-ID: <5368D44F.5090206@redhat.com> On 05/06/2014 02:13 PM, David Holmes wrote: > On 6/05/2014 9:22 PM, Florian Weimer wrote: >> On 03/12/2014 10:45 AM, Paul Sandoz wrote: >>> Hi Florian, >>> >>> Thanks for doing this. >> >> Sorry, I missed your follow-up until now. >> >>> Do you have any more context on what RPMs/jars are using what methods >>> of Unsafe? >> >> Attached. Columns are package NEVRA, JAR name, method and descriptor in >> Unsafe. I used CSV this time to reduce file size (there's no column >> padding). Hopefully the attachment is below the mailing list size limit. > > Either too big or not an accepted MIME type. :( Meh. I put the CSV file here: -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Tue May 6 11:30:32 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 13:30:32 +0200 Subject: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes In-Reply-To: <531A569C.7070003@oracle.com> References: <5318E454.107@oracle.com> <5319AE20.9010003@oracle.com> <5319DFD1.7060006@oracle.com> <531A29CB.3030307@oracle.com> <531A461E.6000801@oracle.com> <531A569C.7070003@oracle.com> Message-ID: <5368C7D8.8000008@redhat.com> On 03/08/2014 12:30 AM, Mandy Chung wrote: > On 3/7/14 2:20 PM, Sergey Bylokhov wrote: >> But after this fix: size of class files are increased, instead of >> usage of one or two classes we get 50 new lambdas, and of course this >> horrible cast. >> new GetPropertyAction("user.home")); >> vs >> (PrivilegedAction) () -> System.getProperty("user.home")); > > I don't like the cast either and can leave with it as the explicit > method call is actually a plus. JDK-8019851 will re-examine this in 9 > to bring something better. > > I'll need to find out from the performance team if the footprint is an > issue. I'll follow this up and if it turns out to be an issue, we will > fix it differently. The main fix here is to remove the dependency. A javac optimization could avoid generating the helper method that contains the System.getProperty("user.home") call and build the lambda directly off System.getProperty(String). The bytecode is likely still a bit larger than what we had before, but not by as much. -- Florian Weimer / Red Hat Product Security Team From ivan.gerasimov at oracle.com Tue May 6 13:56:24 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 06 May 2014 17:56:24 +0400 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException Message-ID: <5368EA08.9020705@oracle.com> Hello! The interrupted status of a thread gets cleared with a call to Path.register(). This is due to call to Object.wait(). Below is the fix with an updated regtest. Would you please help review it? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8011537 WEBREV: http://cr.openjdk.java.net/~igerasim/8011537/0/webrev/ Sincerely yours, Ivan From Alan.Bateman at oracle.com Tue May 6 14:38:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 May 2014 15:38:26 +0100 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368EA08.9020705@oracle.com> References: <5368EA08.9020705@oracle.com> Message-ID: <5368F3E2.7090802@oracle.com> On 06/05/2014 14:56, Ivan Gerasimov wrote: > Hello! > > The interrupted status of a thread gets cleared with a call to > Path.register(). > This is due to call to Object.wait(). > > Below is the fix with an updated regtest. > Would you please help review it? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8011537 > WEBREV: http://cr.openjdk.java.net/~igerasim/8011537/0/webrev/ The change looks good, an oversight in the original implementation. A minor comment on the test is that we can using try-with-resources (as WatchService is Closeable). The register could also use the varargs variant to avoid creating the array explicitly but either way is fine. -Alan From ivan.gerasimov at oracle.com Tue May 6 14:52:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 06 May 2014 18:52:08 +0400 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368F3E2.7090802@oracle.com> References: <5368EA08.9020705@oracle.com> <5368F3E2.7090802@oracle.com> Message-ID: <5368F718.8050405@oracle.com> Thank you Alan! >> >> The interrupted status of a thread gets cleared with a call to >> Path.register(). >> This is due to call to Object.wait(). >> >> Below is the fix with an updated regtest. >> Would you please help review it? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8011537 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8011537/0/webrev/ > The change looks good, an oversight in the original implementation. > > A minor comment on the test is that we can using try-with-resources > (as WatchService is Closeable). The register could also use the > varargs variant to avoid creating the array explicitly but either way > is fine. > I tried to make the added test consistent with the rest of the code. I can surely rewrite it, but should I refactor other code as well then? Sincerely yours, Ivan From Alan.Bateman at oracle.com Tue May 6 15:02:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 May 2014 16:02:09 +0100 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368F718.8050405@oracle.com> References: <5368EA08.9020705@oracle.com> <5368F3E2.7090802@oracle.com> <5368F718.8050405@oracle.com> Message-ID: <5368F971.40906@oracle.com> On 06/05/2014 15:52, Ivan Gerasimov wrote: > I tried to make the added test consistent with the rest of the code. > I can surely rewrite it, but should I refactor other code as well then? I think the the existing tests pre-date the vararg variant of register, there isn't a big need to change those. For the new test then it would be good to use try-with-resources here. It would be good to change testExceptions too but not important for this change. -Alan. From brian.goetz at oracle.com Tue May 6 15:03:33 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 06 May 2014 11:03:33 -0400 Subject: JDK-8042355 stream with sorted() causes downstream ops not to be lazy In-Reply-To: <5368ABB1.3010800@redhat.com> References: <1EAC1B71-CE45-4389-812D-34701B0719E6@oracle.com> <5368ABB1.3010800@redhat.com> Message-ID: <5368F9C5.2090601@oracle.com> This is an optimization that is theoretically possible (and was anticipated in the design), but in reality is likely to be so low-priority that it would be a really long time before it was worth putting engineering resources on this. It would have to be an unordered stream, and we'd have to know that the downstream pipeline is short-circuiting. (There is some back-propagation of characteristics for situations like this, but we have to be careful not to tax startup of common pipelines like filter-map-reduce just to support weird pipelines like this.) On 5/6/2014 5:30 AM, Florian Weimer wrote: > On 05/05/2014 03:16 PM, Paul Sandoz wrote: >> Hi, >> >> https://bugs.openjdk.java.net/browse/JDK-8042355 >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/ >> >> >> This is an optimization to ensure that sorted() in sequential >> pipelines does not aggressively push all sorted elements downstream if >> the pipeline is known to be short-circuiting. > > Would it be possible to use something like heap sort to avoid sorting > the entire input stream if only the first few smallest items are needed? > From roger.riggs at oracle.com Tue May 6 16:01:24 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 06 May 2014 12:01:24 -0400 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <536615DA.2080808@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> Message-ID: <53690754.1030305@oracle.com> Hi Peter, Looks fine to me. Many thanks, Roger On 5/4/2014 6:26 AM, Peter Levart wrote: > > On 05/04/2014 12:12 PM, Peter Levart wrote: >> Hi Alan, Martin, >> >> Thanks for reviews. I have prepared another webrev based on your >> feedback: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.08/ >> > > Ah, I've forgotten to mention the most important change from webrev.07. > > Original code wraps the processReaperExecutor construction into the > doPrivileged() call. I think this was not needed. > > The Executors.newCachedThreadPool() does not need any special > privileges. And construction of nested class > ProcessReaperThreadFactory also didn't need any special privileges - > apart from static initialization which called the getRootThreadGroup() > method. But that method did it's own doPrivileged() wrapping in order > to be able to climb the ThreadGroup hierarchy (which requires > privilege). In webrev.07 I followed original code and wrapped the > construction of a processReaperExecutor into a doPrivileged() although > in webrev.07 the rootThreadGroup search happens as part of UNIXProcess > static initialization and is already wrapped in doPrivileged(). In > webrev.08 I removed this superfluous doPrivileged(). I think this is > correct. SecurityManagerClinit test passes. > > Regards, Peter > * > * >> Comments inline... >> >> On 04/30/2014 05:17 PM, Alan Bateman wrote: >>> I reviewed previous rounds and you've addressed my points so I think >>> I'm mostly happy with this. As some point I think we should look at >>> Platform again as there may be an opportunity later in JDK 9 to move >>> it out of UNIXProcess. >>> >>> One thing that I wasn't sure about is the additions to the @author >>> tags as we've mostly been trying not to grow these (contentious >>> topic, I don't have a strong opinion as I never use @author). >> >> I have removed myself, but left all the others (merged from all 4 >> files). It's true that mercurial keeps track of authors and it's not >> hard to find out who's responsible for what part of code in case >> someone needs to ask the author about the not so obvious things, but >> refactorings like this, which eliminate entire files and move their >> content to other places, make this tracking harder. >> >>> >>> A minor comment looking at the latest webrev.07 is that some of the >>> lines are very long. It's not a problem now but I could image future >>> side-by-side reviews needing a scroll >>> bar.DeferredCloseProcessPipeInputStream is very long too. >> >> I split the longer lines now. The DeferredCloseProcessPipeInputStream >> is admittedly a long name, but it's not public and I tried to express >> the fact that it is a class that merges the functionalities of >> DeferedCloseInputStream and ProcessPipeInputStream (in .aix file it >> was called ProcessPipeInputStream as it was derived from it, but we >> can't have two with same names in common file). I hope in further >> re-factoring we can merge/consolidate these wrapper streams too and >> at that time I think they could be renamed. For now I wanted to keep >> the functionality as-is. But I can rename it if so desired, I just >> can't think of a suitable name. >> >> >> On 04/30/2014 06:25 PM, Martin Buchholz wrote: >>> Belated review. >>> >>> Peter, thank you very much for taking on this difficult unification >>> task. This is great work! >>> Comments: >>> --- >>> --- >>> + case SOLARIS: >>> + if (osArch.equals("x86")) { osArch = "i386"; } >>> >>> It's very sad that ... there's no portable way of getting the name >>> of libarchdir. I thought os.arch system property would suffice, but >>> apparently not on Solaris? >> >> ...and BSD (OS X). Is OS X missing the architecture sub-directories >> because it only supports one architecture now or because it used to >> employ "fat" (multi-architecture) binaries? >> >>> >>> --- >>> To avoid repetition, I would iniitalize with a vararg list of launch >>> mechanisms, of which the first one is always the default. >>> + LINUX(LaunchMechanism.VFORK, >>> EnumSet.of(LaunchMechanism.FORK, LaunchMechanism.VFORK)), >>> >>> LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), >> >> I've done that. It looks nicer now. >> >>> --- >>> Never use toUpperCase without a Locale, to avoid the "Turkish i >>> problem" >>> + lm = >>> LaunchMechanism.valueOf(s.toUpperCase()); >>> toUpperCase(Locale.ENGLISH) >> >> Oops, thanks for spotting this. Fixed. >> >> >> Regards, Peter >> >>> >>> >>> >>> >>> On Wed, Apr 30, 2014 at 8:17 AM, Alan Bateman >>> > wrote: >>> >>> On 25/04/2014 17:47, roger riggs wrote: >>> >>> Hi Peter, >>> >>> Including the test update with the updated changeset is fine. >>> >>> (I think Alan had some comments on the refactoring and has >>> not yet had a chance to comment). >>> >>> Thanks, Roger >>> >>> I reviewed previous rounds and you've addressed my points so I >>> think I'm mostly happy with this. As some point I think we should >>> look at Platform again as there may be an opportunity later in >>> JDK 9 to move it out of UNIXProcess. >>> >>> One thing that I wasn't sure about is the additions to the >>> @author tags as we've mostly been trying not to grow these >>> (contentious topic, I don't have a strong opinion as I never use >>> @author). >>> >>> A minor comment looking at the latest webrev.07 is that some of >>> the lines are very long. It's not a problem now but I could image >>> future side-by-side reviews needing a scroll >>> bar.DeferredCloseProcessPipeInputStream is very long too. >>> >>> -Alan. >>> >>> >> > From brian.burkhalter at oracle.com Tue May 6 16:38:10 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 6 May 2014 09:38:10 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <5368A458.20704@redhat.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> <5368A458.20704@redhat.com> Message-ID: <7635E575-0195-44DD-8D7E-4B9863C83480@oracle.com> Paul / Florian, This is a combined response. I am making the corrections pointed out by Florian. Unless I hear otherwise, I am going to assume that Paul?s approval is still valid with these corrections included and will push the path on Wednesday. Please see the updated patch: http://cr.openjdk.java.net/~bpb/8026236/webrev.04/ Thanks, Brian On May 6, 2014, at 1:25 AM, Paul Sandoz wrote: > On May 5, 2014, at 11:17 PM, Brian Burkhalter wrote: > >> Joe / Paul, >> >> Thanks for the comments. This an aggregate response to your two messages. An updated version of the patch is here: >> >> http://cr.openjdk.java.net/~bpb/8026236/webrev.03/ >> >> I believe that it addresses all the points of concern aside from testing Mersenne primes. >> > > +1 > > Paul On May 6, 2014, at 1:59 AM, Florian Weimer wrote: > On 05/05/2014 11:17 PM, Brian Burkhalter wrote: >> Joe / Paul, >> >> Thanks for the comments. This an aggregate response to your two >> messages. An updated version of the patch is here: >> >> http://cr.openjdk.java.net/~bpb/8026236/webrev.03/ > > The command line parsing is off by one, I think, it should check for >= instead of >: > > 54 // Prepare arguments > 55 int upperBound = args.length > 1 ? Integer.valueOf(args[0]) : DEFAULT_UPPER_BOUND; > 56 int certainty = args.length > 2 ? Integer.valueOf(args[1]) : DEFAULT_CERTAINTY; > 57 boolean parallel = args.length > 3 ? Boolean.valueOf(args[2]) : true; I think this happened when I replaced the primes file input with programmatic generation of primes. > I think this line should go, it doesn't match the shifted indexing: > > 98 //bs.set(0, 2, true); I forgot to delete it when I changed to shifted indexing. > There are some very long lines: > > 120 NavigableSet primes = bs.stream().mapToObj(p -> BigInteger.valueOf(p + 2)).collect(toCollection(TreeSet::new)); > > 180 List bigInts = (new SplittableRandom()).ints(NUM_NON_PRIMES, 2, maxPrime).mapToObj(BigInteger::valueOf).filter(b -> !b.isProbablePrime(certainty)).collect(toList()); Lines split into several at worst not much longer than 80 characters. > The arithmetic in checkPrime() is unnecessary because isProbablePrime() will never report a prime as a non-prime (the Monte-Carlo vs Las Vegas thing), so the count will always be exact because you feed it only primes. Good point: check removed. > It is impossible to check for the expected number of failures (non-primes reported as primes) in checkNonPrimes() because this would result in a test that fails sporadically. There is no change as a result of this comment. From joe.darcy at oracle.com Tue May 6 16:42:24 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 May 2014 09:42:24 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> Message-ID: <536910F0.2050408@oracle.com> Hi Brian, I've filed a follow-up bug: JDK-8042478: Include Mersenne primes in BigInteger primality testing Cheers, -Joe On 5/5/2014 2:17 PM, Brian Burkhalter wrote: > Joe / Paul, > > Thanks for the comments. This an aggregate response to your two > messages. An updated version of the patch is here: > > http://cr.openjdk.java.net/~bpb/8026236/webrev.03/ > > > I believe that it addresses all the points of concern aside from > testing Mersenne primes. > > Please see more comments in line. > > Thanks, > > Brian > > On May 3, 2014, at 9:55 AM, Joe Darcy > wrote: > >> Hi Brian, >> >> I think the parsePrimes method would be better with a different name >> since no parsing is occurring anymore. > > Renamed methods to createPrimes() and getPrimes(). > >> I think someone in this test the fact that Integer.MAX_VALUE is a >> prime should be mentioned in taken advantage of :-) > > Done. Simply appended this one value to the list. ;-) > >> How about adding another test method which tests some Mersenne primes >> for primality? [1] > > No done. > >> I'd prefer to see some comments on the primes method briefly >> explaining it methodology. > > Done via a link to Wikipedia. > >> Would the running time be unacceptable (or memory usage too large) if >> the limit were set to Integer.MAX_VALUE? > > Yes, I tried it. Still running after at least ten minutes when I > killed it. > >> Thanks, >> >> -Joe >> >> [1]http://en.wikipedia.org/wiki/Mersenne_prime > > On May 5, 2014, at 2:11 AM, Paul Sandoz > wrote: > >> On May 3, 2014, at 6:55 PM, Joe Darcy > > wrote: >> >>> Hi Brian, >>> >>> I think the parsePrimes method would be better with a different name >>> since no parsing is occurring anymore. >>> >> >> Yes, and there is no need for the try block. > > Removed. > >> (The use of BitSet.stream() also reminds me we can implement a >> spliterator with size estimates based on the words in use, currently >> the stream() is created from an iterator.) > > Made no change based on this comment (which I interpreted as an aside). > >> >>> I think someone in this test the fact that Integer.MAX_VALUE is a >>> prime should be mentioned in taken advantage of :-) How about >>> adding another test method which tests some Mersenne primes for >>> primality? [1] >>> >>> I'd prefer to see some comments on the primes method briefly >>> explaining it methodology. Would the running time be unacceptable >>> (or memory usage too large) if the limit were set to Integer.MAX_VALUE? >>> >> >> +1 to both of those, although perhaps the former could be done as a >> second iteration to get this code in? > > This is what I did: +1 on the both but not the Mersennes. > >> Also, probably better to create the "NavigableSet primes" >> just once in "main", rather than creating it twice for both tests. > > Done. > >> Still skeptical about the use of a PRNG in the tests, see my comments >> in a previous email: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026579.html > > Changed to SplittableRandom but collected the intermediate stream into > a list which is inspected upon failure to find the value which exposed > the misbehavior. From martinrb at google.com Tue May 6 17:41:10 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 May 2014 10:41:10 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <536615DA.2080808@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> Message-ID: On Sun, May 4, 2014 at 3:26 AM, Peter Levart wrote: > > Ah, I've forgotten to mention the most important change from webrev.07. > > Original code wraps the processReaperExecutor construction into the > doPrivileged() call. I think this was not needed. > > The Executors.newCachedThreadPool() does not need any special privileges. > And construction of nested class ProcessReaperThreadFactory also didn't > need any special privileges - apart from static initialization which called > the getRootThreadGroup() method. But that method did it's own > doPrivileged() wrapping in order to be able to climb the ThreadGroup > hierarchy (which requires privilege). In webrev.07 I followed original code > and wrapped the construction of a processReaperExecutor into a > doPrivileged() although in webrev.07 the rootThreadGroup search happens as > part of UNIXProcess static initialization and is already wrapped in > doPrivileged(). In webrev.08 I removed this superfluous doPrivileged(). I > think this is correct. SecurityManagerClinit test passes. > Although I think you're right with the current implementation, it seems too brittle to me to remove the doPrivileged, since you have no idea what future changes to newCachedThreadPool() might do (or what other JDK implementations might do); notably it might instantiate some kind of micro-manager thread or do some other privileged operation. If you want to have only one call to doPrivileged, you can cause both rootThreadGroup and processReaperExecutor to be initialized in one static block, although you will need to jump through some hoops to keep these fields final. --- As it stands, Executors.newCachedThreadPool(grimReaper -> { doesn't mention either the type ThreadFactory or Runnable. It might be clearer (more verbosity in the spirit of Java) if you used explicit ThreadFactory type ThreadFactory factory = grimReaper -> ... From ioi.lam at oracle.com Tue May 6 18:14:50 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 06 May 2014 11:14:50 -0700 Subject: RFR: 8042243: Map shared archive to preallocated static address In-Reply-To: <53685022.9020508@oracle.com> References: <53681B91.1080105@oracle.com> <53685022.9020508@oracle.com> Message-ID: <5369269A.8070104@oracle.com> So backgrounds: The C code in HotSpot is platform-independent, and will take no effect if jdk/src/share/bin/main.c does not call JLI_SetStaticSharedSpace(). Since the code inside HotSpot is pretty small, we could always leave it in (compiled unconditionally for both 32-bit and 64-bit) and push the platform-dependent decision to the JDK layer. The need for this fix is only for 32-bit VMs, where ASLR would more easily cause address conflicts with the predefined SharedBaseAddress (see globals.hpp). On 64-bit VM, mapping failure due to ASLR is very rare. The fix is based on the idea that a variable defined in the BSS section of the main executable is not randomized on some platforms: static char staticSharedSpace[32*1024*1024]; so far, we found this is true only in Linux. (And perhaps Solaris as well, but since we only supported 64-bit on Solaris, I didn't investigate further). On MacOS and Windows, the BSS section of the main executable is also randomized, so this fix will not reduce mapping failures. - Ioi On 5/5/14, 7:59 PM, David Holmes wrote: > Hi Yumin, > > For something that only addresses one platform this adds a lot of > platform specific code to a bunch of shared files. Are there plans to > extend this to other platforms? Otherwise can we make this more > platform agnostic? Perhaps move the os specific code to the os class? > Seems the changes in filemap.cpp and metaspace.cpp could easily be > factored into an os method that returns a boolean to indicate whether > there is a fixed mapping. > > And perhaps define set_static_shared_space in the os class and always > expose it via jni.cpp. Actually, why are we exposing this via jni.cpp > rather than jvm.cpp? This is not part of the JNI interface to the VM. > > Thanks, > David > > On 6/05/2014 9:15 AM, Yumin Qi wrote: >> Hi, Please have codereview for >> >> 8042243: Map shared archive to preallocated static address >> >> webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8042243 >> >> Summary: Mapping shared archive (jsa) some time fail due to ASLR >> (Address space layout randomization) on 32bit Linux platforms. To solve >> we come up with mapping shared archive to preallocated static space >> since with Linux and the GCC compiler, the BSS section in the main >> executable is not randomized, instead, the variable address in the BSS >> section is fixed at build time. The tests also showed the extra 32M >> space will NOT affect java memory setting though it seems 32M virtual >> address space always allocated no matter it is used or not (If >> -XX:ShareBaseAddress supply alternative address for dumping, the static >> address will be ignored.) Note the changes is for 32 bit Linux only. >> >> Tests: JPRT, manual test for archive sharing. >> >> Thanks >> Yumin From martinrb at google.com Tue May 6 18:30:12 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 May 2014 11:30:12 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <536612A4.6090406@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> Message-ID: On Sun, May 4, 2014 at 3:12 AM, Peter Levart wrote: > > --- > --- > + case SOLARIS: > + if (osArch.equals("x86")) { osArch = "i386"; } > > It's very sad that ... there's no portable way of getting the name of > libarchdir. I thought os.arch system property would suffice, but > apparently not on Solaris? > > > ...and BSD (OS X). Is OS X missing the architecture sub-directories > because it only supports one architecture now or because it used to employ > "fat" (multi-architecture) binaries? > The JDK should have a non-public API to get the "libarchdir" of the current JDK, perhaps in the jdk.internal package. From ecki at zusammenkunft.net Tue May 6 18:38:25 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 6 May 2014 20:38:25 +0200 Subject: How to mount a volume with file owners being nobody? In-Reply-To: <5368C0C2.6070905@redhat.com> References: <5B438ACC-51B7-44A9-8952-E5A1CD2E823A@oracle.com> <5368C0C2.6070905@redhat.com> Message-ID: <69A0DD20-4913-47E0-BAFA-84700505F7A6@zusammenkunft.net> Nobody is no different than any other user, so your test can be done with any files you dont have write access to. What is a bit different is root-squash, where you are root user, the file system (server) however treats you as not-priveledged. To test this it is best to loop mount nfs. In all cases you can expect Java APIS like File.isWriteable to lie to you, for many reasons (read only fa, ACL, mac, rootsquash). Always be prepared to get exceptions on access and handle those proper. Bernd > Am 06.05.2014 um 13:00 schrieb Florian Weimer : > >> On 04/18/2014 05:28 AM, Wang Weijun wrote: >> I have seen such things before but cannot create one now. I would like to simulate a problematic environment on my own machines. Any suggestion is welcomed, I have Mac OS X and Windows at hand but Linux and Solaris are also OK. > > I'm not sure what you need, but with file systems such as vfat which do not store owner information, you can specify an arbitrary user/group combination at mount (on Linux). > > -- > Florian Weimer / Red Hat Product Security Team From martinrb at google.com Tue May 6 19:04:45 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 May 2014 12:04:45 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> Message-ID: I notice the ThreadGroup docs don't say "root thread group", they say "system" or "initial". If you could go ahead and fix my old use of root s/root/system/g that would be great. From ivan.gerasimov at oracle.com Tue May 6 19:17:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 06 May 2014 23:17:10 +0400 Subject: RFR [8011537]: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException In-Reply-To: <5368F971.40906@oracle.com> References: <5368EA08.9020705@oracle.com> <5368F3E2.7090802@oracle.com> <5368F718.8050405@oracle.com> <5368F971.40906@oracle.com> Message-ID: <53693536.8070505@oracle.com> Thank you Alan! On 06.05.2014 19:02, Alan Bateman wrote: > On 06/05/2014 15:52, Ivan Gerasimov wrote: >> I tried to make the added test consistent with the rest of the code. >> I can surely rewrite it, but should I refactor other code as well then? > I think the the existing tests pre-date the vararg variant of > register, there isn't a big need to change those. > > For the new test then it would be good to use try-with-resources here. > Okay, changed it. > It would be good to change testExceptions too but not important for > this change. > I think it can be changed with the upcoming fix for 8042470, which will include modifications to this test anyways. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8011537/1/webrev/ Sincerely yours, Ivan From bruno.do.medeiros at gmail.com Tue May 6 20:20:52 2014 From: bruno.do.medeiros at gmail.com (Bruno Medeiros) Date: Tue, 6 May 2014 21:20:52 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: References: Message-ID: After much chopping, I have finally narrowed it down to a single source file, and no external dependencies (other than starting Windows' cmd.exe process) : https://github.com/bruno-medeiros/Scratchpad/blob/jvm-processio-issue/jvm_process_bug/src/JVMProcessBug.java In this final form, I am now able to replicated the bug in my machine on many different runs of the program even beyond the first one after booting. But it doesn't occur every time, only about two thirds the time. Tried running it again with JVM 8 several times but never got it to reproduce there. Maybe it really isn't present in JVM 8, only 7. Hopefully this should be enough for JVM developers to replicate it. -- Bruno Medeiros https://twitter.com/brunodomedeiros From peter.levart at gmail.com Wed May 7 07:42:21 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 May 2014 09:42:21 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> Message-ID: <5369E3DD.4020102@gmail.com> Hi Martin, I have restructured the processReaperExecutor construction. It now incorporates system thread group search and thread pool construction in one doPrivileged call. I also extracted the creation of ThreadFactory into a local variable so it's more explicit now. Here's the webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.09/ ...java/lang/ProcessBuilder tests still pass. Regards, Peter P.S. I don't belive Executors.newCachedTreadPool() could strengthen security in future, since this would break existing user code. The javadoc does not specify any SecurityExceptions. But anyway - wrapping the whole logic of processReaperExecutor construction in one doPrivileged call allowed me to use local variables instead of private static final fields for systemThreadGroup and threadFactory, so this looks nicer too. On 05/06/2014 07:41 PM, Martin Buchholz wrote: > > > > On Sun, May 4, 2014 at 3:26 AM, Peter Levart > wrote: > > > Ah, I've forgotten to mention the most important change from > webrev.07. > > Original code wraps the processReaperExecutor construction into > the doPrivileged() call. I think this was not needed. > > The Executors.newCachedThreadPool() does not need any special > privileges. And construction of nested class > ProcessReaperThreadFactory also didn't need any special privileges > - apart from static initialization which called the > getRootThreadGroup() method. But that method did it's own > doPrivileged() wrapping in order to be able to climb the > ThreadGroup hierarchy (which requires privilege). In webrev.07 I > followed original code and wrapped the construction of a > processReaperExecutor into a doPrivileged() although in webrev.07 > the rootThreadGroup search happens as part of UNIXProcess static > initialization and is already wrapped in doPrivileged(). In > webrev.08 I removed this superfluous doPrivileged(). I think this > is correct. SecurityManagerClinit test passes. > > > Although I think you're right with the current implementation, it > seems too brittle to me to remove the doPrivileged, since you have no > idea what future changes to newCachedThreadPool() might do (or what > other JDK implementations might do); notably it might instantiate some > kind of micro-manager thread or do some other privileged operation. > > If you want to have only one call to doPrivileged, you can cause both > rootThreadGroup and processReaperExecutor to be initialized in one > static block, although you will need to jump through some hoops to > keep these fields final. > > --- > > As it stands, > > Executors.newCachedThreadPool(grimReaper -> { > > doesn't mention either the type ThreadFactory or Runnable. > > It might be clearer (more verbosity in the spirit of Java) if you used > explicit ThreadFactory type > > ThreadFactory factory = grimReaper -> ... From david.holmes at oracle.com Wed May 7 09:55:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 May 2014 19:55:05 +1000 Subject: RFR: 8042243: Map shared archive to preallocated static address In-Reply-To: <5369269A.8070104@oracle.com> References: <53681B91.1080105@oracle.com> <53685022.9020508@oracle.com> <5369269A.8070104@oracle.com> Message-ID: <536A02F9.4000001@oracle.com> Hi Ioi, Thanks for the background. I understand this only applies to Linux but that is the reason it should be confined to Linux-specific files as much as possible. This wouldn't be the first time we introduced an os method that only had a non-trivial implementation on one platform. Thanks, David On 7/05/2014 4:14 AM, Ioi Lam wrote: > So backgrounds: > > The C code in HotSpot is platform-independent, and will take no effect > if jdk/src/share/bin/main.c does not call JLI_SetStaticSharedSpace(). > Since the code inside HotSpot is pretty small, we could always leave it > in (compiled unconditionally for both 32-bit and 64-bit) and push the > platform-dependent decision to the JDK layer. > > The need for this fix is only for 32-bit VMs, where ASLR would more > easily cause address conflicts with the predefined SharedBaseAddress > (see globals.hpp). On 64-bit VM, mapping failure due to ASLR is very rare. > > The fix is based on the idea that a variable defined in the BSS section > of the main executable is not randomized on some platforms: > > static char staticSharedSpace[32*1024*1024]; > > so far, we found this is true only in Linux. (And perhaps Solaris as > well, but since we only supported 64-bit on Solaris, I didn't > investigate further). > > On MacOS and Windows, the BSS section of the main executable is also > randomized, so this fix will not reduce mapping failures. > > - Ioi > > On 5/5/14, 7:59 PM, David Holmes wrote: >> Hi Yumin, >> >> For something that only addresses one platform this adds a lot of >> platform specific code to a bunch of shared files. Are there plans to >> extend this to other platforms? Otherwise can we make this more >> platform agnostic? Perhaps move the os specific code to the os class? >> Seems the changes in filemap.cpp and metaspace.cpp could easily be >> factored into an os method that returns a boolean to indicate whether >> there is a fixed mapping. >> >> And perhaps define set_static_shared_space in the os class and always >> expose it via jni.cpp. Actually, why are we exposing this via jni.cpp >> rather than jvm.cpp? This is not part of the JNI interface to the VM. >> >> Thanks, >> David >> >> On 6/05/2014 9:15 AM, Yumin Qi wrote: >>> Hi, Please have codereview for >>> >>> 8042243: Map shared archive to preallocated static address >>> >>> webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8042243 >>> >>> Summary: Mapping shared archive (jsa) some time fail due to ASLR >>> (Address space layout randomization) on 32bit Linux platforms. To solve >>> we come up with mapping shared archive to preallocated static space >>> since with Linux and the GCC compiler, the BSS section in the main >>> executable is not randomized, instead, the variable address in the BSS >>> section is fixed at build time. The tests also showed the extra 32M >>> space will NOT affect java memory setting though it seems 32M virtual >>> address space always allocated no matter it is used or not (If >>> -XX:ShareBaseAddress supply alternative address for dumping, the static >>> address will be ignored.) Note the changes is for 32 bit Linux only. >>> >>> Tests: JPRT, manual test for archive sharing. >>> >>> Thanks >>> Yumin > From peter.levart at gmail.com Wed May 7 11:20:34 2014 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 May 2014 13:20:34 +0200 Subject: How to mount a volume with file owners being nobody? In-Reply-To: <5B438ACC-51B7-44A9-8952-E5A1CD2E823A@oracle.com> References: <5B438ACC-51B7-44A9-8952-E5A1CD2E823A@oracle.com> Message-ID: <536A1702.5080906@gmail.com> On 04/18/2014 05:28 AM, Wang Weijun wrote: > I have seen such things before but cannot create one now. I would like to simulate a problematic environment on my own machines. Any suggestion is welcomed, I have Mac OS X and Windows at hand but Linux and Solaris are also OK. > > Thanks > Max > Hi Max, One particular unusual environment I have observed is such that on a NFS client, files are reported as having owner/group being nobody/nobody, but actual access to files is correctly handled by the NFS server using UIDs/GIDs. Correctly meaning that the effective UID/GID of the process executing on NFS client is handled by the NFS server when granting particular operations on files/directories as they appear on NFS server. These are the mount options reported on NFS client, which is Linux (CentOS 6.5): server:/directory on /directory_nfs type nfs (rw,vers=4,addr=192.168.xxx.xxx,clientaddr=192.168.xxx.xxx) The NFS server is a Solaris box (Solaris 10, sparc) which speaks NFSv4 and runs the nfsmapid daemon, but the client is not running the idmapd. Hope this helps. Regards, Peter From joel.franck at oracle.com Wed May 7 17:43:21 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 7 May 2014 19:43:21 +0200 Subject: RFR 9 and 8u: JDK-8029674: (reflect) getMethods returns default methods that are not members of the class Message-ID: Hi, Since Java 8 the methods Class.getMethod() and Class.getMethods() can in some circumstances return methods that are not members of the class. This is due to a spec change in 8 not due to a code change. For this to happen you need to have an interface hierarchy that looks something like: interface I { void m(); } interface J extends I { void m(); } and either one of: interface K extends ***I,*** J {} class C implements ***I,*** J {} In Java 7 K.class.getMethods() would return [ I.m, J.m ]. The 7 spec is a bit vague but I have been convinced by experts that this is actually correct in 7. However this was changed in the spec for 8, now only J.m() is a member of K or C so the result should only contain [ J.m() ]. See the bug: https://bugs.openjdk.java.net/browse/JDK-8029674 for a more thorough discussion of this. The fix proposed for 8u (and 9 at first) is a partial fix that ensures that: - a concrete class does not have any abstract methods - nothing is changed unless someone introduces default methods into the interface hierarchy This is to minimise the behavioural compatibility concerns in a minor release. For 9 we might implement the full solution. (See the 9 bug: https://bugs.openjdk.java.net/browse/JDK-8029459). Basically in the fix proposed for 8u, default methods prune less specific methods from the result if they have the same discriptor. There are some complications due to preserving the old lookup order and the fact that we don?t want different results depending on the order of pairwise comparisons. Since this work and MethodArray in general is comparing descriptors bridges should not interact with this patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8029674 Patch: http://cr.openjdk.java.net/~jfranck/8029674/webrev.02/ *** Testing *** I made a test with a bit over 100 cases where 40 of the tests test behaviour that shouldn?t change (IE they pass both with and without the patch). The test is a bit vast, but I have commented some of the more interesting results. *** Performance *** The time complexity of this is O(defaultMethods * methods). getMethods() is already somewhat quadratic in complexity due to removing interface methods that have a concrete implementation. Also the result is cached so this is a one time increase per Class. I have done some experiments on a patched jdk without the cache and the performance looks decent: - Loading every class in rt.jar and calling getMethods() on every Class takes 8s on my laptop both before and after the patch. Perhaps not that surprising since there aren?t that many default methods in the jdk and this is probably dominated by IO. - Calling getMethods on a Class with 16K methods, 10% which are default methods, seem to take roughly 50% longer on my laptop (2,4 instead of 1,7 seconds). I?m working on converting this benchmark to JMH, but at least I don?t think I have made the most basic benchmark errors. If this turns out to be a performance problem I have an idea for an index that will make this O(methods sharing name * methods) for an addition of a few allocations, but I don?t expect this to be necessary. Thanks in advance cheers /Joel From ioi.lam at oracle.com Wed May 7 18:32:13 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 07 May 2014 11:32:13 -0700 Subject: RFR: 8042243: Map shared archive to preallocated static address In-Reply-To: <536A02F9.4000001@oracle.com> References: <53681B91.1080105@oracle.com> <53685022.9020508@oracle.com> <5369269A.8070104@oracle.com> <536A02F9.4000001@oracle.com> Message-ID: <536A7C2D.2060208@oracle.com> All we need is to store two variables (base and size) and use them if the define a suitable range. So the code is completely platform agnostic. We found this useful for Linux only for the standard JDK platforms, but maybe when people port to other platforms they would find this useful as well? Thanks - Ioi On 5/7/14, 2:55 AM, David Holmes wrote: > Hi Ioi, > > Thanks for the background. I understand this only applies to Linux but > that is the reason it should be confined to Linux-specific files as > much as possible. This wouldn't be the first time we introduced an os > method that only had a non-trivial implementation on one platform. > > Thanks, > David > > On 7/05/2014 4:14 AM, Ioi Lam wrote: >> So backgrounds: >> >> The C code in HotSpot is platform-independent, and will take no effect >> if jdk/src/share/bin/main.c does not call JLI_SetStaticSharedSpace(). >> Since the code inside HotSpot is pretty small, we could always leave it >> in (compiled unconditionally for both 32-bit and 64-bit) and push the >> platform-dependent decision to the JDK layer. >> >> The need for this fix is only for 32-bit VMs, where ASLR would more >> easily cause address conflicts with the predefined SharedBaseAddress >> (see globals.hpp). On 64-bit VM, mapping failure due to ASLR is very >> rare. >> >> The fix is based on the idea that a variable defined in the BSS section >> of the main executable is not randomized on some platforms: >> >> static char staticSharedSpace[32*1024*1024]; >> >> so far, we found this is true only in Linux. (And perhaps Solaris as >> well, but since we only supported 64-bit on Solaris, I didn't >> investigate further). >> >> On MacOS and Windows, the BSS section of the main executable is also >> randomized, so this fix will not reduce mapping failures. >> >> - Ioi >> >> On 5/5/14, 7:59 PM, David Holmes wrote: >>> Hi Yumin, >>> >>> For something that only addresses one platform this adds a lot of >>> platform specific code to a bunch of shared files. Are there plans to >>> extend this to other platforms? Otherwise can we make this more >>> platform agnostic? Perhaps move the os specific code to the os class? >>> Seems the changes in filemap.cpp and metaspace.cpp could easily be >>> factored into an os method that returns a boolean to indicate whether >>> there is a fixed mapping. >>> >>> And perhaps define set_static_shared_space in the os class and always >>> expose it via jni.cpp. Actually, why are we exposing this via jni.cpp >>> rather than jvm.cpp? This is not part of the JNI interface to the VM. >>> >>> Thanks, >>> David >>> >>> On 6/05/2014 9:15 AM, Yumin Qi wrote: >>>> Hi, Please have codereview for >>>> >>>> 8042243: Map shared archive to preallocated static address >>>> >>>> webrev: http://cr.openjdk.java.net/~minqi/8042243/webrev00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8042243 >>>> >>>> Summary: Mapping shared archive (jsa) some time fail due to ASLR >>>> (Address space layout randomization) on 32bit Linux platforms. To >>>> solve >>>> we come up with mapping shared archive to preallocated static space >>>> since with Linux and the GCC compiler, the BSS section in the main >>>> executable is not randomized, instead, the variable address in the BSS >>>> section is fixed at build time. The tests also showed the extra 32M >>>> space will NOT affect java memory setting though it seems 32M virtual >>>> address space always allocated no matter it is used or not (If >>>> -XX:ShareBaseAddress supply alternative address for dumping, the >>>> static >>>> address will be ignored.) Note the changes is for 32 bit Linux only. >>>> >>>> Tests: JPRT, manual test for archive sharing. >>>> >>>> Thanks >>>> Yumin >> From martinrb at google.com Wed May 7 21:04:57 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 May 2014 14:04:57 -0700 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <5369E3DD.4020102@gmail.com> References: <5332F00D.1020806@gmail.com> <5332FDD5.8030801@oracle.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> <5369E3DD.4020102@gmail.com> Message-ID: Hi Peter, Your last version version looks very good. Approved! I'm reduced to asking you to fix ancient buglets of mine. *"I'd spell creat with an e.*" 188 * Create a process. Depending on the mode flag, this is done by *"I'd spell Create with an s.*" On Wed, May 7, 2014 at 12:42 AM, Peter Levart wrote: > Hi Martin, > > I have restructured the processReaperExecutor construction. It now > incorporates system thread group search and thread pool construction in one > doPrivileged call. I also extracted the creation of ThreadFactory into a > local variable so it's more explicit now. Here's the webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.09/ > > ...java/lang/ProcessBuilder tests still pass. > > Regards, Peter > > P.S. I don't belive Executors.newCachedTreadPool() could strengthen > security in future, since this would break existing user code. The javadoc > does not specify any SecurityExceptions. But anyway - wrapping the whole > logic of processReaperExecutor construction in one doPrivileged call > allowed me to use local variables instead of private static final fields > for systemThreadGroup and threadFactory, so this looks nicer too. > > > > On 05/06/2014 07:41 PM, Martin Buchholz wrote: > > > > > On Sun, May 4, 2014 at 3:26 AM, Peter Levart wrote: > >> >> Ah, I've forgotten to mention the most important change from webrev.07. >> >> Original code wraps the processReaperExecutor construction into the >> doPrivileged() call. I think this was not needed. >> >> The Executors.newCachedThreadPool() does not need any special privileges. >> And construction of nested class ProcessReaperThreadFactory also didn't >> need any special privileges - apart from static initialization which called >> the getRootThreadGroup() method. But that method did it's own >> doPrivileged() wrapping in order to be able to climb the ThreadGroup >> hierarchy (which requires privilege). In webrev.07 I followed original code >> and wrapped the construction of a processReaperExecutor into a >> doPrivileged() although in webrev.07 the rootThreadGroup search happens as >> part of UNIXProcess static initialization and is already wrapped in >> doPrivileged(). In webrev.08 I removed this superfluous doPrivileged(). I >> think this is correct. SecurityManagerClinit test passes. >> > > Although I think you're right with the current implementation, it seems > too brittle to me to remove the doPrivileged, since you have no idea what > future changes to newCachedThreadPool() might do (or what other JDK > implementations might do); notably it might instantiate some kind of > micro-manager thread or do some other privileged operation. > > If you want to have only one call to doPrivileged, you can cause both > rootThreadGroup and processReaperExecutor to be initialized in one static > block, although you will need to jump through some hoops to keep these > fields final. > > --- > > As it stands, > > Executors.newCachedThreadPool(grimReaper -> { > > doesn't mention either the type ThreadFactory or Runnable. > > It might be clearer (more verbosity in the spirit of Java) if you used > explicit ThreadFactory type > > ThreadFactory factory = grimReaper -> ... > > > From martinrb at google.com Wed May 7 21:35:49 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 May 2014 14:35:49 -0700 Subject: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour In-Reply-To: References: <533255B1.7020400@oracle.com> <49611DAB-4F8C-4DBF-9EB1-F63B69E3E6FD@oracle.com> <7742CCC4-D651-4E0F-9DAF-AEBACD0DF35E@oracle.com> <75162C95-8D8C-49D0-B911-708133D75CC7@oracle.com> <534E9F8B.6070302@geomatys.fr> <18370F8A-191D-4586-9162-FD94F65FB48F@oracle.com> Message-ID: I would prefer having separate changes that address different concerns. Here's a spec update that is not quite correct because the ArrayStoreException depends on the runtime types (i.e. the Class objects available at runtime), but these may be different from the compile-time type parameters T and E. The fact that arrays are incorrectly covariant at compile time adds to the confusion. There's also a confusion between the type of a and the component type of a. You could improve matters by introducing the word "component type" in these sorts of specs. I again think this kind of change should be done across all the jdk classes. http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html All the components of an array have the same type, called the*component type* of the array. - * @throws ArrayStoreException if the runtime type of a is not a supertype - * of the runtime type of every element in this Vector + * @throws ArrayStoreException if the runtime type of a, {@code }, is not + * a supertype of the runtime type, {@code }, of every element in this + * Vector On Fri, May 2, 2014 at 12:22 PM, Mike Duigou wrote: > Thanks Martin and Martin; > > I have corrected this along with some additional documentation updates: > > http://cr.openjdk.java.net/~mduigou/JDK-8020860/3/webrev/ > > Mike > > > On Apr 16 2014, at 10:47 , Martin Buchholz wrote: > > Here you access elementCount outside the synchronized block, which is a data race > > + public boolean addAll(int index, Collection c) { > if (index < 0 || index > elementCount) > throw new ArrayIndexOutOfBoundsException(index); > > > > > On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou wrote: > >> Yes. This has been corrected. >> >> Mike >> >> On Apr 16 2014, at 08:19 , Martin Desruisseaux < >> martin.desruisseaux at geomatys.fr> wrote: >> >> > Hello all >> > >> > Le 15/04/14 18:14, Mike Duigou a ?crit : >> >> I have updated the webrev with what I hope is the final form: >> >> >> >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/ >> > >> > The first changes in the javadoc contains "{@code #keys keys}" and >> > "{@code #elements elements}". I presume that you mean {@link} instead of >> > {@code}? >> > >> > Martin >> > >> >> > > From fuyou001 at gmail.com Thu May 8 12:55:24 2014 From: fuyou001 at gmail.com (fuyou) Date: Thu, 8 May 2014 20:55:24 +0800 Subject: about Selector.select is block ,but jstack thread is runnable Message-ID: the jstack: NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00000000136d3800 nid=0x75dc runnable [0x00000000499be000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked <0x000000076ce96e58> (a io.netty.channel.nio.SelectedSelectionKeySet) - locked <0x000000076ce96658> (a java.util.Collections$UnmodifiableSet) - locked <0x000000076ce85be0> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) at java.lang.Thread.run(Thread.java:745) the select doc : /** * Selects a set of keys whose corresponding channels are ready for I/O * operations. * *

This method performs a blocking selection * operation. It returns only after at least one channel is selected, * this selector's {@link #wakeup wakeup} method is invoked, or the current * thread is interrupted, whichever comes first.

* * @return The number of keys, possibly zero, * whose ready-operation sets were updated * * @throws IOException * If an I/O error occurs * * @throws ClosedSelectorException * If this selector is closed */ public abstract int select() throws IOException; so the select is blocck unitl a channel is selected, but the jstack java.lang.Thread.State: is RUNNABLE,why not is BLOCKED. the offical api explain BLOCKED : public static final Thread.State BLOCKEDThread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait. because that's Select block until a channel is selected(not blocked waiting for a monitor lock) ,so it not the thread state BLOCKED. am i right ? -- ============================================= fuyou001 Best Regards From ecki at zusammenkunft.net Thu May 8 15:09:38 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 8 May 2014 17:09:38 +0200 Subject: about Selector.select is block ,but jstack thread is runnable In-Reply-To: References: Message-ID: <5FC32641-C452-416F-ABEC-42E4375B1BFC@zusammenkunft.net> All Code which blocks inside native methods on native objects (like blocking read on file descriptors or sockets, as well as waits on selectors are not blocking with Java concurrency features and therefore (a bit missleading) in RUNABLE state. Greetings Bernd > Am 08.05.2014 um 14:55 schrieb fuyou : > > the jstack: > > NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00000000136d3800 > nid=0x75dc runnable [0x00000000499be000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) > - locked <0x000000076ce96e58> (a > io.netty.channel.nio.SelectedSelectionKeySet) > - locked <0x000000076ce96658> (a java.util.Collections$UnmodifiableSet) > - locked <0x000000076ce85be0> (a sun.nio.ch.EPollSelectorImpl) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) > at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:618) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:306) > at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116) > at java.lang.Thread.run(Thread.java:745) > > the select doc : > > /** > * Selects a set of keys whose corresponding channels are ready for I/O > * operations. > * > *

This method performs a blocking selection > * operation. It returns only after at least one channel is selected, > * this selector's {@link #wakeup wakeup} method is invoked, or the current > * thread is interrupted, whichever comes first.

> * > * @return The number of keys, possibly zero, > * whose ready-operation sets were updated > * > * @throws IOException > * If an I/O error occurs > * > * @throws ClosedSelectorException > * If this selector is closed > */ > public abstract int select() throws IOException; > > so the select is blocck unitl a channel is selected, but the jstack > java.lang.Thread.State: is RUNNABLE,why not is BLOCKED. > > the offical api explain BLOCKED : > > public static final Thread.State BLOCKEDThread state for a thread > blocked waiting for a monitor lock. A thread in the blocked state is > waiting for a monitor lock to enter a > > synchronized block/method or reenter a synchronized block/method after > calling Object.wait. > > because that's Select block until a channel is selected(not blocked > waiting for a monitor lock) ,so it not the thread state BLOCKED. > > am i right ? > > -- > ============================================= > > fuyou001 > Best Regards From brian.burkhalter at oracle.com Thu May 8 22:28:33 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 May 2014 15:28:33 -0700 Subject: JDK 9 RFR of 8042478: Include Mersenne primes in BigInteger primality testing Message-ID: Hello, This follows from a prior discussion thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026771.html. Issue: https://bugs.openjdk.java.net/browse/JDK-8042478 Patch: http://cr.openjdk.java.net/~bpb/8042478/webrev.00/ Adds a test of the first 19 Mersenne primes. The remainder of the exponent list is commented out as it takes too long to run. The value 19 appears to give a reasonable execution time. The largest Mersenne prime tested is 285542542228902608580607. Thanks, Brian From joe.darcy at oracle.com Thu May 8 22:42:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 May 2014 15:42:33 -0700 Subject: JDK 9 RFR of 8042478: Include Mersenne primes in BigInteger primality testing In-Reply-To: References: Message-ID: <536C0859.6040209@oracle.com> On 05/08/2014 03:28 PM, Brian Burkhalter wrote: > Hello, > > This follows from a prior discussion thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026771.html. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8042478 > Patch: http://cr.openjdk.java.net/~bpb/8042478/webrev.00/ > > Adds a test of the first 19 Mersenne primes. The remainder of the exponent list is commented out as it takes too long to run. The value 19 appears to give a reasonable execution time. The largest Mersenne prime tested is 285542542228902608580607. > > Thanks, > > Brian Hi Brian, Generally looks good. However, I think it would be better structured if the array of Mersenne exponents was with the Mersenne testing method. Thanks, -Joe From brian.burkhalter at oracle.com Thu May 8 22:39:37 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 May 2014 15:39:37 -0700 Subject: JDK 9 RFR of 8042478: Include Mersenne primes in BigInteger primality testing In-Reply-To: <536C0859.6040209@oracle.com> References: <536C0859.6040209@oracle.com> Message-ID: <1B7F35C5-E9AA-4A37-A4CE-AA6E5FA2B347@oracle.com> Hi Joe, Moved the array of Mersenne exponents inside the Mersenne testing method: http://cr.openjdk.java.net/~bpb/8042478/webrev.01/ Thanks, Brian On May 8, 2014, at 3:42 PM, Joe Darcy wrote: > Hi Brian, > > Generally looks good. However, I think it would be better structured if the array of Mersenne exponents was with the Mersenne testing method. > > Thanks, > > -Joe From joe.darcy at oracle.com Thu May 8 23:09:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 May 2014 16:09:33 -0700 Subject: JDK 9 RFR of 8042478: Include Mersenne primes in BigInteger primality testing In-Reply-To: <1B7F35C5-E9AA-4A37-A4CE-AA6E5FA2B347@oracle.com> References: <536C0859.6040209@oracle.com> <1B7F35C5-E9AA-4A37-A4CE-AA6E5FA2B347@oracle.com> Message-ID: <536C0EAD.4030601@oracle.com> Looks good Brian; thanks, -Joe On 05/08/2014 03:39 PM, Brian Burkhalter wrote: > Hi Joe, > > Moved the array of Mersenne exponents inside the Mersenne testing method: > > http://cr.openjdk.java.net/~bpb/8042478/webrev.01/ > > > Thanks, > > Brian > > On May 8, 2014, at 3:42 PM, Joe Darcy wrote: > >> Hi Brian, >> >> Generally looks good. However, I think it would be better structured >> if the array of Mersenne exponents was with the Mersenne testing method. >> >> Thanks, >> >> -Joe > From fuyou001 at gmail.com Fri May 9 03:14:20 2014 From: fuyou001 at gmail.com (fuyou) Date: Fri, 9 May 2014 11:14:20 +0800 Subject: epollWait blocks ,but why consume cpu Message-ID: My program is build on Netty4 . In benchmark,i find the epollWait consume many cpu,the jstack is The stack of busy(10.4%) thread(30873/0x7899) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-9" prio=10 tid=0x00002aaac418a000 nid=0x7899 runnable [0x0000000045f9a000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4cf1e0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30866/0x7892) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-2" prio=10 tid=0x00002aaac4252800 nid=0x7892 runnable [0x0000000045893000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4d1990> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30865/0x7891) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-1" prio=10 tid=0x00002aaab95c0800 nid=0x7891 runnable [0x0000000045792000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c47c0f0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30871/0x7897) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-7" prio=10 tid=0x00002aaac417f800 nid=0x7897 runnable [0x0000000045d98000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c676820> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30869/0x7895) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-5" prio=10 tid=0x00002aaac4061800 nid=0x7895 runnable [0x0000000045b96000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c528d90> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30867/0x7893) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-3" prio=10 tid=0x00002aaac4254800 nid=0x7893 runnable [0x0000000045994000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.NativeThread.current(Native Method) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:333) - locked <0x000000076c4c90c8> (a java.lang.Object) - locked <0x000000076c4c90b0> (a java.lang.Object) at io.netty.buffer.PooledUnsafeDirectByteBuf.getBytes(PooledUnsafeDirectByteBuf.java:208) -- The stack of busy(10.2%) thread(30874/0x789a) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-10" prio=10 tid=0x00002aaac418c800 nid=0x789a runnable [0x000000004609b000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c5a70b0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30872/0x7898) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-8" prio=10 tid=0x00002aaac4187800 nid=0x7898 runnable [0x0000000045e99000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c62f290> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30870/0x7896) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-6" prio=10 tid=0x00002aaac4190800 nid=0x7896 runnable [0x0000000045c97000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c45e320> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30868/0x7894) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00002aaac405b000 nid=0x7894 runnable [0x0000000045a95000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c6c2660> (a io.netty.channel.nio.SelectedSelectionKeySet) [yubao.fyb at vkvm169051 ~]$ cat busy_thread_20140509104529|grep 'NETTYSERVER-WORKER' -A6 -B2 The stack of busy(10.4%) thread(30873/0x7899) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-9" prio=10 tid=0x00002aaac418a000 nid=0x7899 runnable [0x0000000045f9a000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4cf1e0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30866/0x7892) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-2" prio=10 tid=0x00002aaac4252800 nid=0x7892 runnable [0x0000000045893000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c4d1990> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.4%) thread(30865/0x7891) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-1" prio=10 tid=0x00002aaab95c0800 nid=0x7891 runnable [0x0000000045792000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c47c0f0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30871/0x7897) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-7" prio=10 tid=0x00002aaac417f800 nid=0x7897 runnable [0x0000000045d98000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c676820> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30869/0x7895) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-5" prio=10 tid=0x00002aaac4061800 nid=0x7895 runnable [0x0000000045b96000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c528d90> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.3%) thread(30867/0x7893) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-3" prio=10 tid=0x00002aaac4254800 nid=0x7893 runnable [0x0000000045994000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.NativeThread.current(Native Method) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:333) - locked <0x000000076c4c90c8> (a java.lang.Object) - locked <0x000000076c4c90b0> (a java.lang.Object) at io.netty.buffer.PooledUnsafeDirectByteBuf.getBytes(PooledUnsafeDirectByteBuf.java:208) -- The stack of busy(10.2%) thread(30874/0x789a) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-10" prio=10 tid=0x00002aaac418c800 nid=0x789a runnable [0x000000004609b000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c5a70b0> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30872/0x7898) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-8" prio=10 tid=0x00002aaac4187800 nid=0x7898 runnable [0x0000000045e99000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c62f290> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30870/0x7896) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-6" prio=10 tid=0x00002aaac4190800 nid=0x7896 runnable [0x0000000045c97000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c45e320> (a io.netty.channel.nio.SelectedSelectionKeySet) -- The stack of busy(10.2%) thread(30868/0x7894) of java process(30757) of user(fuyou): "NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00002aaac405b000 nid=0x7894 runnable [0x0000000045a95000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) - locked <0x000000076c6c2660> (a io.netty.channel.nio.SelectedSelectionKeySet) epollWait(...) blocks.why the consume cpu? has any idea to reduce cpu I also asked the question in Netty github ============================================= fuyou001 Best Regards From fuyou001 at gmail.com Fri May 9 07:28:30 2014 From: fuyou001 at gmail.com (fuyou) Date: Fri, 9 May 2014 15:28:30 +0800 Subject: epollWait blocks ,but why consume cpu In-Reply-To: References: Message-ID: I use the NetBeans profiler ,the result in attach. 2014-05-09 11:14 GMT+08:00 fuyou : > My program is build on Netty4 . > In benchmark,i find the epollWait consume many cpu,the jstack is > > > The stack of busy(10.4%) thread(30873/0x7899) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-9" prio=10 tid=0x00002aaac418a000 nid=0x7899 runnable [0x0000000045f9a000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c4cf1e0> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.4%) thread(30866/0x7892) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-2" prio=10 tid=0x00002aaac4252800 nid=0x7892 runnable [0x0000000045893000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c4d1990> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.4%) thread(30865/0x7891) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-1" prio=10 tid=0x00002aaab95c0800 nid=0x7891 runnable [0x0000000045792000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c47c0f0> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.3%) thread(30871/0x7897) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-7" prio=10 tid=0x00002aaac417f800 nid=0x7897 runnable [0x0000000045d98000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c676820> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.3%) thread(30869/0x7895) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-5" prio=10 tid=0x00002aaac4061800 nid=0x7895 runnable [0x0000000045b96000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c528d90> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.3%) thread(30867/0x7893) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-3" prio=10 tid=0x00002aaac4254800 nid=0x7893 runnable [0x0000000045994000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.NativeThread.current(Native Method) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:333) > - locked <0x000000076c4c90c8> (a java.lang.Object) > - locked <0x000000076c4c90b0> (a java.lang.Object) > at io.netty.buffer.PooledUnsafeDirectByteBuf.getBytes(PooledUnsafeDirectByteBuf.java:208) > -- > The stack of busy(10.2%) thread(30874/0x789a) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-10" prio=10 tid=0x00002aaac418c800 nid=0x789a runnable [0x000000004609b000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c5a70b0> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.2%) thread(30872/0x7898) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-8" prio=10 tid=0x00002aaac4187800 nid=0x7898 runnable [0x0000000045e99000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c62f290> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.2%) thread(30870/0x7896) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-6" prio=10 tid=0x00002aaac4190800 nid=0x7896 runnable [0x0000000045c97000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c45e320> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > The stack of busy(10.2%) thread(30868/0x7894) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00002aaac405b000 nid=0x7894 runnable [0x0000000045a95000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c6c2660> (a io.netty.channel.nio.SelectedSelectionKeySet) > [yubao.fyb at vkvm169051 ~]$ cat busy_thread_20140509104529|grep 'NETTYSERVER-WORKER' -A6 -B2 > The stack of busy(10.4%) thread(30873/0x7899) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-9" prio=10 tid=0x00002aaac418a000 nid=0x7899 runnable [0x0000000045f9a000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c4cf1e0> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.4%) thread(30866/0x7892) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-2" prio=10 tid=0x00002aaac4252800 nid=0x7892 runnable [0x0000000045893000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c4d1990> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.4%) thread(30865/0x7891) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-1" prio=10 tid=0x00002aaab95c0800 nid=0x7891 runnable [0x0000000045792000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c47c0f0> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.3%) thread(30871/0x7897) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-7" prio=10 tid=0x00002aaac417f800 nid=0x7897 runnable [0x0000000045d98000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c676820> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.3%) thread(30869/0x7895) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-5" prio=10 tid=0x00002aaac4061800 nid=0x7895 runnable [0x0000000045b96000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c528d90> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.3%) thread(30867/0x7893) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-3" prio=10 tid=0x00002aaac4254800 nid=0x7893 runnable [0x0000000045994000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.NativeThread.current(Native Method) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:333) > - locked <0x000000076c4c90c8> (a java.lang.Object) > - locked <0x000000076c4c90b0> (a java.lang.Object) > at io.netty.buffer.PooledUnsafeDirectByteBuf.getBytes(PooledUnsafeDirectByteBuf.java:208) > -- > > The stack of busy(10.2%) thread(30874/0x789a) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-10" prio=10 tid=0x00002aaac418c800 nid=0x789a runnable [0x000000004609b000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c5a70b0> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.2%) thread(30872/0x7898) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-8" prio=10 tid=0x00002aaac4187800 nid=0x7898 runnable [0x0000000045e99000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c62f290> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.2%) thread(30870/0x7896) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-6" prio=10 tid=0x00002aaac4190800 nid=0x7896 runnable [0x0000000045c97000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c45e320> (a io.netty.channel.nio.SelectedSelectionKeySet) > -- > > The stack of busy(10.2%) thread(30868/0x7894) of java process(30757) of user(fuyou): > "NETTYSERVER-WORKER-19-thread-4" prio=10 tid=0x00002aaac405b000 nid=0x7894 runnable [0x0000000045a95000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69) > - locked <0x000000076c6c2660> (a io.netty.channel.nio.SelectedSelectionKeySet) > > epollWait(...) blocks.why the consume cpu? has any idea to reduce cpu > > I also asked the question in Netty github > ============================================= > > fuyou001 > Best Regards > > -- ============================================= fuyou001 Best Regards From Alan.Bateman at oracle.com Fri May 9 08:26:40 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 May 2014 09:26:40 +0100 Subject: epollWait blocks ,but why consume cpu In-Reply-To: References: Message-ID: <536C9140.60602@oracle.com> On 09/05/2014 08:28, fuyou wrote: > I use the NetBeans profiler ,the result in attach. > > Which JDK build is this? I don't think we've had any reports of Selector spinning issues in some time. -Alan. From fweimer at redhat.com Fri May 9 08:48:50 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 09 May 2014 10:48:50 +0200 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <7635E575-0195-44DD-8D7E-4B9863C83480@oracle.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> <5368A458.20704@redhat.com> <7635E575-0195-44DD-8D7E-4B9863C83480@oracle.com> Message-ID: <536C9672.7080902@redhat.com> On 05/06/2014 06:38 PM, Brian Burkhalter wrote: > Paul / Florian, > > This is a combined response. I am making the corrections pointed out by > Florian. Unless I hear otherwise, I am going to assume that Paul?s > approval is still valid with these corrections included and will push > the path on Wednesday. Please see the updated patch: > > http://cr.openjdk.java.net/~bpb/8026236/webrev.04/ Looks good to me now (but I'm not an official reviewer). -- Florian Weimer / Red Hat Product Security Team From yekaterina.kantserova at oracle.com Fri May 9 10:43:39 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 09 May 2014 12:43:39 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> Message-ID: <536CB15B.8070908@oracle.com> Hi, The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks, Katja On 03/25/2014 01:14 PM, Staffan Larsen wrote: > I?ve looked at a random sample of these changes and they look ok. > > Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. > > I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. > > Thanks, > /Staffan > > On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 >> >> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >> >> Verified locally since no JTreg with fix has been promoted yet. >> >> >> Thanks, >> Katja From staffan.larsen at oracle.com Fri May 9 10:48:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 May 2014 12:48:56 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <536CB15B.8070908@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <536CB15B.8070908@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > Thanks, > Katja > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: >> I?ve looked at a random sample of these changes and they look ok. >> >> Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. >> >> I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. >> >> Thanks, >> /Staffan >> >> On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 >>> >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >>> >>> Verified locally since no JTreg with fix has been promoted yet. >>> >>> >>> Thanks, >>> Katja > From Alan.Bateman at oracle.com Fri May 9 11:07:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 May 2014 12:07:20 +0100 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <536CB15B.8070908@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <536CB15B.8070908@oracle.com> Message-ID: <536CB6E8.4070607@oracle.com> On 09/05/2014 11:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which contains > https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been > promoted. So it seems to be time to push the fix for JDK-8034960. I've > made a new webrev to be sure the changes fit in in the latest jdk9 > source. The webrev can be found here: > cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks for doing this, it should make concurrent test runs a lot more stable. I've skimmed over the changes and they look good to me too. -Alan From yekaterina.kantserova at oracle.com Fri May 9 11:32:08 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 09 May 2014 13:32:08 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <536CB6E8.4070607@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <536CB15B.8070908@oracle.com> <536CB6E8.4070607@oracle.com> Message-ID: <536CBCB8.4030804@oracle.com> Staffan, Alan, thanks for reviews! I will wait with pushing it until Monday to make sure no one has objections. // Katja On 05/09/2014 01:07 PM, Alan Bateman wrote: > On 09/05/2014 11:43, Yekaterina Kantserova wrote: >> Hi, >> >> The version b09 of JTreg which contains >> https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been >> promoted. So it seems to be time to push the fix for JDK-8034960. >> I've made a new webrev to be sure the changes fit in in the latest >> jdk9 source. The webrev can be found here: >> cr.openjdk.java.net/~ykantser/8034960/webrev.01. > Thanks for doing this, it should make concurrent test runs a lot more > stable. I've skimmed over the changes and they look good to me too. > > -Alan From Alan.Bateman at oracle.com Fri May 9 15:28:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 May 2014 16:28:08 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <5369E3DD.4020102@gmail.com> References: <5332F00D.1020806@gmail.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> <5369E3DD.4020102@gmail.com> Message-ID: <536CF408.5030405@oracle.com> On 07/05/2014 08:42, Peter Levart wrote: > Hi Martin, > > I have restructured the processReaperExecutor construction. It now > incorporates system thread group search and thread pool construction > in one doPrivileged call. I also extracted the creation of > ThreadFactory into a local variable so it's more explicit now. Here's > the webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.09/ > > ...java/lang/ProcessBuilder tests still pass. Sorry for the delay but I finally got time to look at webrev.09. I'm happy too! -Alan From eric.mccorkle at oracle.com Fri May 9 18:08:32 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 14:08:32 -0400 Subject: Build failures on solaris Message-ID: <536D19A0.40804@oracle.com> I am currently seeing build failures on solaris, coming from within the JDK repo: /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED -DRELEASE='"1.9.0-internal"' -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal -KPIC -xstrconst -xregs=no%appl -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp -o /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", line 1: empty character constant "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", line 1: syntax error before or at: '' gmake[2]: *** [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] Error 1 This is blocking integration of patches that need to go in promptly. This needs to be addressed ASAP. From eric.mccorkle at oracle.com Fri May 9 18:16:03 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 14:16:03 -0400 Subject: Build failures on solaris In-Reply-To: <536D19A0.40804@oracle.com> References: <536D19A0.40804@oracle.com> Message-ID: <536D1B63.3060705@oracle.com> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 This patch seems to be the culprit: changeset: 9908:7426549b1e3b tag: tip user: sla date: Fri May 09 12:06:13 2014 +0200 summary: 8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework On 05/09/14 14:08, Eric McCorkle wrote: > I am currently seeing build failures on solaris, coming from within the > JDK repo: > > /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING > -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS > -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED > -DRELEASE='"1.9.0-internal"' > -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include > -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris > -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export > -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export > -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common > -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 > -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal > -KPIC -xstrconst -xregs=no%appl > -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers > -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 > -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF > /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp > -o > /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o > /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", > line 1: empty character constant > "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", > line 1: syntax error before or at: '' > gmake[2]: *** > [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] > Error 1 > > This is blocking integration of patches that need to go in promptly. > This needs to be addressed ASAP. > From alejandro.murillo at oracle.com Fri May 9 18:48:12 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 09 May 2014 12:48:12 -0600 Subject: Build failures on solaris In-Reply-To: <536D1B63.3060705@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> Message-ID: <536D22EC.9090209@oracle.com> Definitively a P1. This is also blocking this week hotspot snapshot: http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log please fix ASAP Thanks Alejandro On 5/9/2014 12:16 PM, Eric McCorkle wrote: > Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 > > This patch seems to be the culprit: > > changeset: 9908:7426549b1e3b > tag: tip > user: sla > date: Fri May 09 12:06:13 2014 +0200 > summary: 8039173: Propagate errors from Diagnostic Commands as > exceptions in the attach framework > > > On 05/09/14 14:08, Eric McCorkle wrote: >> I am currently seeing build failures on solaris, coming from within the >> JDK repo: >> >> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >> -DRELEASE='"1.9.0-internal"' >> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >> -KPIC -xstrconst -xregs=no%appl >> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >> -o >> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >> line 1: empty character constant >> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >> line 1: syntax error before or at: '' >> gmake[2]: *** >> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >> Error 1 >> >> This is blocking integration of patches that need to go in promptly. >> This needs to be addressed ASAP. >> -- Alejandro From eric.mccorkle at oracle.com Fri May 9 19:01:52 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 15:01:52 -0400 Subject: Build failures on solaris In-Reply-To: <536D22EC.9090209@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> <536D22EC.9090209@oracle.com> Message-ID: <536D2620.6060601@oracle.com> The problem is a stray '' as the first two characters in the file. I have posted a patch that removes it to serviceability-dev. All we need is someone with Reviewer/committer rights to step in and apply it. On 05/09/14 14:48, Alejandro E Murillo wrote: > > Definitively a P1. > This is also blocking this week hotspot snapshot: > http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log > > please fix ASAP > > Thanks > Alejandro > > On 5/9/2014 12:16 PM, Eric McCorkle wrote: >> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 >> >> This patch seems to be the culprit: >> >> changeset: 9908:7426549b1e3b >> tag: tip >> user: sla >> date: Fri May 09 12:06:13 2014 +0200 >> summary: 8039173: Propagate errors from Diagnostic Commands as >> exceptions in the attach framework >> >> >> On 05/09/14 14:08, Eric McCorkle wrote: >>> I am currently seeing build failures on solaris, coming from within the >>> JDK repo: >>> >>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >>> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >>> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >>> -DRELEASE='"1.9.0-internal"' >>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >>> >>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >>> >>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >>> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >>> -KPIC -xstrconst -xregs=no%appl >>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >>> >>> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >>> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >>> >>> -o >>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >>> >>> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>> >>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>> >>> line 1: empty character constant >>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>> >>> line 1: syntax error before or at: '' >>> gmake[2]: *** >>> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >>> >>> Error 1 >>> >>> This is blocking integration of patches that need to go in promptly. >>> This needs to be addressed ASAP. >>> > From eric.mccorkle at oracle.com Fri May 9 19:08:06 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 15:08:06 -0400 Subject: Build failures on solaris In-Reply-To: <536D2620.6060601@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> <536D22EC.9090209@oracle.com> <536D2620.6060601@oracle.com> Message-ID: <536D2796.2060100@oracle.com> The following patch will fix it: diff -r 7426549b1e3b src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c --- a/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c +++ b/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c @@ -1,4 +1,4 @@ -''/* +/* * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * On 05/09/14 15:01, Eric McCorkle wrote: > The problem is a stray '' as the first two characters in the file. > > I have posted a patch that removes it to serviceability-dev. > > All we need is someone with Reviewer/committer rights to step in and > apply it. > > On 05/09/14 14:48, Alejandro E Murillo wrote: >> >> Definitively a P1. >> This is also blocking this week hotspot snapshot: >> http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log >> >> please fix ASAP >> >> Thanks >> Alejandro >> >> On 5/9/2014 12:16 PM, Eric McCorkle wrote: >>> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 >>> >>> This patch seems to be the culprit: >>> >>> changeset: 9908:7426549b1e3b >>> tag: tip >>> user: sla >>> date: Fri May 09 12:06:13 2014 +0200 >>> summary: 8039173: Propagate errors from Diagnostic Commands as >>> exceptions in the attach framework >>> >>> >>> On 05/09/14 14:08, Eric McCorkle wrote: >>>> I am currently seeing build failures on solaris, coming from within the >>>> JDK repo: >>>> >>>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >>>> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >>>> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >>>> -DRELEASE='"1.9.0-internal"' >>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >>>> >>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >>>> >>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >>>> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >>>> -KPIC -xstrconst -xregs=no%appl >>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >>>> >>>> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >>>> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >>>> >>>> -o >>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >>>> >>>> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>>> >>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>> >>>> line 1: empty character constant >>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>> >>>> line 1: syntax error before or at: '' >>>> gmake[2]: *** >>>> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >>>> >>>> Error 1 >>>> >>>> This is blocking integration of patches that need to go in promptly. >>>> This needs to be addressed ASAP. >>>> >> From chris.hegarty at oracle.com Fri May 9 19:09:17 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 May 2014 20:09:17 +0100 Subject: Build failures on solaris In-Reply-To: <536D2796.2060100@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> <536D22EC.9090209@oracle.com> <536D2620.6060601@oracle.com> <536D2796.2060100@oracle.com> Message-ID: <3EEC4149-E72E-44FA-A7EC-C2033BE5C577@oracle.com> Approved. -Chris. On 9 May 2014, at 20:08, Eric McCorkle wrote: > The following patch will fix it: > > diff -r 7426549b1e3b > src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > --- a/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > +++ b/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > @@ -1,4 +1,4 @@ > -''/* > +/* > * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > > On 05/09/14 15:01, Eric McCorkle wrote: >> The problem is a stray '' as the first two characters in the file. >> >> I have posted a patch that removes it to serviceability-dev. >> >> All we need is someone with Reviewer/committer rights to step in and >> apply it. >> >> On 05/09/14 14:48, Alejandro E Murillo wrote: >>> >>> Definitively a P1. >>> This is also blocking this week hotspot snapshot: >>> http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log >>> >>> please fix ASAP >>> >>> Thanks >>> Alejandro >>> >>> On 5/9/2014 12:16 PM, Eric McCorkle wrote: >>>> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 >>>> >>>> This patch seems to be the culprit: >>>> >>>> changeset: 9908:7426549b1e3b >>>> tag: tip >>>> user: sla >>>> date: Fri May 09 12:06:13 2014 +0200 >>>> summary: 8039173: Propagate errors from Diagnostic Commands as >>>> exceptions in the attach framework >>>> >>>> >>>> On 05/09/14 14:08, Eric McCorkle wrote: >>>>> I am currently seeing build failures on solaris, coming from within the >>>>> JDK repo: >>>>> >>>>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >>>>> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >>>>> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >>>>> -DRELEASE='"1.9.0-internal"' >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >>>>> >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >>>>> >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >>>>> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >>>>> -KPIC -xstrconst -xregs=no%appl >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >>>>> >>>>> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >>>>> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >>>>> >>>>> -o >>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >>>>> >>>>> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>>>> >>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>> >>>>> line 1: empty character constant >>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>> >>>>> line 1: syntax error before or at: '' >>>>> gmake[2]: *** >>>>> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >>>>> >>>>> Error 1 >>>>> >>>>> This is blocking integration of patches that need to go in promptly. >>>>> This needs to be addressed ASAP. >>>>> >>> From staffan.larsen at oracle.com Fri May 9 19:12:21 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 May 2014 21:12:21 +0200 Subject: Build failures on solaris In-Reply-To: <536D2796.2060100@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> <536D22EC.9090209@oracle.com> <536D2620.6060601@oracle.com> <536D2796.2060100@oracle.com> Message-ID: <6AE9613C-2550-42FE-98A9-C19FA25D2B9E@oracle.com> Looks good. Many apologies. /Staffan On 9 maj 2014, at 21:08, Eric McCorkle wrote: > The following patch will fix it: > > diff -r 7426549b1e3b > src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > --- a/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > +++ b/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c > @@ -1,4 +1,4 @@ > -''/* > +/* > * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > > On 05/09/14 15:01, Eric McCorkle wrote: >> The problem is a stray '' as the first two characters in the file. >> >> I have posted a patch that removes it to serviceability-dev. >> >> All we need is someone with Reviewer/committer rights to step in and >> apply it. >> >> On 05/09/14 14:48, Alejandro E Murillo wrote: >>> >>> Definitively a P1. >>> This is also blocking this week hotspot snapshot: >>> http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log >>> >>> please fix ASAP >>> >>> Thanks >>> Alejandro >>> >>> On 5/9/2014 12:16 PM, Eric McCorkle wrote: >>>> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 >>>> >>>> This patch seems to be the culprit: >>>> >>>> changeset: 9908:7426549b1e3b >>>> tag: tip >>>> user: sla >>>> date: Fri May 09 12:06:13 2014 +0200 >>>> summary: 8039173: Propagate errors from Diagnostic Commands as >>>> exceptions in the attach framework >>>> >>>> >>>> On 05/09/14 14:08, Eric McCorkle wrote: >>>>> I am currently seeing build failures on solaris, coming from within the >>>>> JDK repo: >>>>> >>>>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >>>>> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >>>>> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >>>>> -DRELEASE='"1.9.0-internal"' >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >>>>> >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >>>>> >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >>>>> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >>>>> -KPIC -xstrconst -xregs=no%appl >>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >>>>> >>>>> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >>>>> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >>>>> >>>>> -o >>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >>>>> >>>>> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>>>> >>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>> >>>>> line 1: empty character constant >>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>> >>>>> line 1: syntax error before or at: '' >>>>> gmake[2]: *** >>>>> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >>>>> >>>>> Error 1 >>>>> >>>>> This is blocking integration of patches that need to go in promptly. >>>>> This needs to be addressed ASAP. >>>>> >>> From eric.mccorkle at oracle.com Fri May 9 19:28:30 2014 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 09 May 2014 15:28:30 -0400 Subject: Build failures on solaris In-Reply-To: <6AE9613C-2550-42FE-98A9-C19FA25D2B9E@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> <536D22EC.9090209@oracle.com> <536D2620.6060601@oracle.com> <536D2796.2060100@oracle.com> <6AE9613C-2550-42FE-98A9-C19FA25D2B9E@oracle.com> Message-ID: <536D2C5E.2000502@oracle.com> Pushed. You may now resume normal integration activities. On 05/09/14 15:12, Staffan Larsen wrote: > Looks good. > > Many apologies. > > /Staffan > > > On 9 maj 2014, at 21:08, Eric McCorkle wrote: > >> The following patch will fix it: >> >> diff -r 7426549b1e3b >> src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >> --- a/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >> +++ b/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >> @@ -1,4 +1,4 @@ >> -''/* >> +/* >> * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> >> On 05/09/14 15:01, Eric McCorkle wrote: >>> The problem is a stray '' as the first two characters in the file. >>> >>> I have posted a patch that removes it to serviceability-dev. >>> >>> All we need is someone with Reviewer/committer rights to step in and >>> apply it. >>> >>> On 05/09/14 14:48, Alejandro E Murillo wrote: >>>> >>>> Definitively a P1. >>>> This is also blocking this week hotspot snapshot: >>>> http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log >>>> >>>> please fix ASAP >>>> >>>> Thanks >>>> Alejandro >>>> >>>> On 5/9/2014 12:16 PM, Eric McCorkle wrote: >>>>> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 >>>>> >>>>> This patch seems to be the culprit: >>>>> >>>>> changeset: 9908:7426549b1e3b >>>>> tag: tip >>>>> user: sla >>>>> date: Fri May 09 12:06:13 2014 +0200 >>>>> summary: 8039173: Propagate errors from Diagnostic Commands as >>>>> exceptions in the attach framework >>>>> >>>>> >>>>> On 05/09/14 14:08, Eric McCorkle wrote: >>>>>> I am currently seeing build failures on solaris, coming from within the >>>>>> JDK repo: >>>>>> >>>>>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >>>>>> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >>>>>> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >>>>>> -DRELEASE='"1.9.0-internal"' >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >>>>>> >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >>>>>> >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >>>>>> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >>>>>> -KPIC -xstrconst -xregs=no%appl >>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >>>>>> >>>>>> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >>>>>> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >>>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >>>>>> >>>>>> -o >>>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >>>>>> >>>>>> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>>>>> >>>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>>> >>>>>> line 1: empty character constant >>>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>>> >>>>>> line 1: syntax error before or at: '' >>>>>> gmake[2]: *** >>>>>> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >>>>>> >>>>>> Error 1 >>>>>> >>>>>> This is blocking integration of patches that need to go in promptly. >>>>>> This needs to be addressed ASAP. >>>>>> >>>> > From alejandro.murillo at oracle.com Fri May 9 19:56:26 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 09 May 2014 13:56:26 -0600 Subject: Build failures on solaris In-Reply-To: <536D2C5E.2000502@oracle.com> References: <536D19A0.40804@oracle.com> <536D1B63.3060705@oracle.com> <536D22EC.9090209@oracle.com> <536D2620.6060601@oracle.com> <536D2796.2060100@oracle.com> <6AE9613C-2550-42FE-98A9-C19FA25D2B9E@oracle.com> <536D2C5E.2000502@oracle.com> Message-ID: <536D32EA.7070906@oracle.com> Thanks for the quick fix! Alejandro On 5/9/2014 1:28 PM, Eric McCorkle wrote: > Pushed. You may now resume normal integration activities. > > On 05/09/14 15:12, Staffan Larsen wrote: >> Looks good. >> >> Many apologies. >> >> /Staffan >> >> >> On 9 maj 2014, at 21:08, Eric McCorkle wrote: >> >>> The following patch will fix it: >>> >>> diff -r 7426549b1e3b >>> src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>> --- a/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>> +++ b/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>> @@ -1,4 +1,4 @@ >>> -''/* >>> +/* >>> * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights >>> reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> >>> On 05/09/14 15:01, Eric McCorkle wrote: >>>> The problem is a stray '' as the first two characters in the file. >>>> >>>> I have posted a patch that removes it to serviceability-dev. >>>> >>>> All we need is someone with Reviewer/committer rights to step in and >>>> apply it. >>>> >>>> On 05/09/14 14:48, Alejandro E Murillo wrote: >>>>> Definitively a P1. >>>>> This is also blocking this week hotspot snapshot: >>>>> http://prt-web.us.oracle.com//archive/2014/05/2014-05-09-174238.amurillo.jdk9-hs-2014-05-09-jdk9-dev-control/logs/solaris_sparcv9_5.10-fastdebug.log.FAILED.log >>>>> >>>>> please fix ASAP >>>>> >>>>> Thanks >>>>> Alejandro >>>>> >>>>> On 5/9/2014 12:16 PM, Eric McCorkle wrote: >>>>>> Bug created: https://bugs.openjdk.java.net/browse/JDK-8042859 >>>>>> >>>>>> This patch seems to be the culprit: >>>>>> >>>>>> changeset: 9908:7426549b1e3b >>>>>> tag: tip >>>>>> user: sla >>>>>> date: Fri May 09 12:06:13 2014 +0200 >>>>>> summary: 8039173: Propagate errors from Diagnostic Commands as >>>>>> exceptions in the attach framework >>>>>> >>>>>> >>>>>> On 05/09/14 14:08, Eric McCorkle wrote: >>>>>>> I am currently seeing build failures on solaris, coming from within the >>>>>>> JDK repo: >>>>>>> >>>>>>> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/cc -DTRACING >>>>>>> -DMACRO_MEMSYS_OPS -DBREAKPTS -D_BIG_ENDIAN= -DSOLARIS >>>>>>> -DARCH='"sparcv9"' -Dsparcv9 -DNDEBUG -DTRIMMED >>>>>>> -DRELEASE='"1.9.0-internal"' >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include >>>>>>> >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/include/solaris >>>>>>> >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/javavm/export >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/javavm/export >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/share/native/common >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/common -m64 >>>>>>> -D__solaris__ -xc99=%none -xCC -errshort=tags -Xa -v -mt -W0,-noglobal >>>>>>> -KPIC -xstrconst -xregs=no%appl >>>>>>> -I/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/gensrc_headers >>>>>>> >>>>>>> -errtags -errwarn=%all -g -xs -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 >>>>>>> -DTHIS_FILE='"SolarisVirtualMachine.c"' -c -xMMD -xMF >>>>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.d.tmp >>>>>>> >>>>>>> -o >>>>>>> /tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o >>>>>>> >>>>>>> /tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c >>>>>>> >>>>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>>>> >>>>>>> line 1: empty character constant >>>>>>> "/tmp/jprt/P1/173806.emccorkl/s/jdk/src/solaris/native/sun/tools/attach/SolarisVirtualMachine.c", >>>>>>> >>>>>>> line 1: syntax error before or at: '' >>>>>>> gmake[2]: *** >>>>>>> [/tmp/jprt/P1/173806.emccorkl/s/build/solaris-sparcv9-normal-server-release/jdk/objs/libattach/SolarisVirtualMachine.o] >>>>>>> >>>>>>> Error 1 >>>>>>> >>>>>>> This is blocking integration of patches that need to go in promptly. >>>>>>> This needs to be addressed ASAP. >>>>>>> -- Alejandro From jeremymanson at google.com Sat May 10 04:44:56 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 9 May 2014 21:44:56 -0700 Subject: epollWait blocks ,but why consume cpu In-Reply-To: <536C9140.60602@oracle.com> References: <536C9140.60602@oracle.com> Message-ID: Are you sure it consumes CPU? I've always found that epollwait blocks, but the JVM doesn't know it is supposed to change the state of the thread. This is one of the major reasons that thread dump based profilers are awful. Jeremy On Fri, May 9, 2014 at 1:26 AM, Alan Bateman wrote: > On 09/05/2014 08:28, fuyou wrote: > >> I use the NetBeans profiler ,the result in attach. >> >> >> Which JDK build is this? I don't think we've had any reports of Selector > spinning issues in some time. > > -Alan. > From sean.coffey at oracle.com Sun May 11 20:56:00 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Sun, 11 May 2014 21:56:00 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB Message-ID: <536FE3E0.5080809@oracle.com> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can remove use of reflection in ORB code to access the applet context. bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ regards, Sean. From me at sandipan.net Sun May 11 22:35:42 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Sun, 11 May 2014 18:35:42 -0400 Subject: JDK-8037382 Sequence and SequenceSet interface Message-ID: Hi all, I'm looking to get started making contributions :-) I figured I'd start with something that was fairly prescriptive and mechanical just to get the hang of the process. Two questions if I may, as per the contribution guide: * Is anyone already working on the above item? (I do not wish to duplicate effort.) * Are there any objections to the changes already laid out in the ticket? If all is well, I shall get started with a patch for review. Cheers, SR https://bugs.openjdk.java.net/browse/JDK-8037382 Sandipan Razzaque | www.sandipan.net From forax at univ-mlv.fr Sun May 11 22:56:00 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 May 2014 00:56:00 +0200 Subject: JDK-8037382 Sequence and SequenceSet interface In-Reply-To: References: Message-ID: <53700000.8010801@univ-mlv.fr> On 05/12/2014 12:35 AM, Sandipan Razzaque wrote: > Hi all, > > I'm looking to get started making contributions :-) I figured I'd start > with something that was fairly prescriptive and mechanical just to get the > hang of the process. Two questions if I may, as per the contribution guide: > > * Is anyone already working on the above item? (I do not wish to duplicate > effort.) > * Are there any objections to the changes already laid out in the ticket? > > If all is well, I shall get started with a patch for review. > > Cheers, > SR > > https://bugs.openjdk.java.net/browse/JDK-8037382 > > Sandipan Razzaque | www.sandipan.net Hi Sandipan, I suppose that you have already sign the OCA. In my opinion, this bug is too big for a first contribution, any change to java.util collection require coordination between several people. I think you should start with something smaller, what do you think about this one: https://bugs.openjdk.java.net/browse/JDK-8037343 cheers, R?mi From chris.hegarty at oracle.com Mon May 12 05:35:54 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 May 2014 06:35:54 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <536FE3E0.5080809@oracle.com> References: <536FE3E0.5080809@oracle.com> Message-ID: Sean, It is nice to see this code being cleaned up, and I agree with the changes. You can use computeIfAbsent here, rather than, putIfAbsent, to avoid evaluating the result of setupPresentationManager() when there is already a mapping. pmContexts.computeIfAbsent(appletContext, PresentationManage::setupPresentationManager); -Chris. On 11 May 2014, at 21:56, Se?n Coffey wrote: > Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can remove use of reflection in ORB code to access the applet context. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ > > regards, > Sean. From Alan.Bateman at oracle.com Mon May 12 06:17:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 May 2014 07:17:04 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <536FE3E0.5080809@oracle.com> References: <536FE3E0.5080809@oracle.com> Message-ID: <53706760.5040101@oracle.com> On 11/05/2014 21:56, Se?n Coffey wrote: > Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can > remove use of reflection in ORB code to access the applet context. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ I agree with Chris that computeIfAbsent is best here, that was also the suggestion back in early April before the bootstrapping issue came up. In any case, it's good you are re-visiting this to clean it up. -Alan From daniel.fuchs at oracle.com Mon May 12 07:49:31 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 May 2014 09:49:31 +0200 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <536FE3E0.5080809@oracle.com> References: <536FE3E0.5080809@oracle.com> Message-ID: <53707D0B.30808@oracle.com> I Se?n, I wonder whether it would be better to use a ConcurrentHashMap in place of the plain HashMap and remove the synchronized lock around putIfAbsent/computeIfAbsent? best regards, -- daniel On 5/11/14 10:56 PM, Se?n Coffey wrote: > Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can > remove use of reflection in ORB code to access the applet context. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ > > regards, > Sean. From sean.coffey at oracle.com Mon May 12 07:52:32 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 12 May 2014 08:52:32 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <53706760.5040101@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> Message-ID: <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> Good tip Alan/Chris. I'll make that change and push. Regards, Sean. On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman wrote: >On 11/05/2014 21:56, Se?n Coffey wrote: >> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can >> remove use of reflection in ORB code to access the applet context. >> >> bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ >I agree with Chris that computeIfAbsent is best here, that was also the > >suggestion back in early April before the bootstrapping issue came up. >In any case, it's good you are re-visiting this to clean it up. > >-Alan From yekaterina.kantserova at oracle.com Mon May 12 08:28:19 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 12 May 2014 10:28:19 +0200 Subject: Fwd: Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: References: Message-ID: <53708623.60006@oracle.com> Staffan, could you please be my sponsor and push this fix? I have discovered three more tests that should bechanged: sun/management/jmxremote/bootstrap/CustomLauncherTest.java java/lang/management/MemoryMXBean/CollectionUsageThreshold.java java/lang/management/MemoryMXBean/LowMemoryTest.java The webrev that includes them can be found here: http://cr.openjdk.java.net/~ykantser/8034960/webrev.02/ Thanks, Katja -------- Original Message -------- Subject: Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError Date: Fri, 9 May 2014 12:48:56 +0200 From: Staffan Larsen To: Yekaterina Kantserova CC: Alan Bateman , "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" , core-libs-dev Libs Looks good! Thanks, /Staffan On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which containshttps://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > Thanks, > Katja > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: >> I?ve looked at a random sample of these changes and they look ok. >> >> Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. >> >> I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. >> >> Thanks, >> /Staffan >> >> On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev:http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-8034960 >>> >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >>> >>> Verified locally since no JTreg with fix has been promoted yet. >>> >>> >>> Thanks, >>> Katja > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8034960.open.patch Type: text/x-patch Size: 9519 bytes Desc: not available URL: From staffan.larsen at oracle.com Mon May 12 08:38:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 12 May 2014 10:38:55 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <53708623.60006@oracle.com> References: <53708623.60006@oracle.com> Message-ID: Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05e9c9216e26 Thanks, /Staffan On 12 maj 2014, at 10:28, Yekaterina Kantserova wrote: > Staffan, > > could you please be my sponsor and push this fix? > > I have discovered three more tests that should be changed: > sun/management/jmxremote/bootstrap/CustomLauncherTest.java > java/lang/management/MemoryMXBean/CollectionUsageThreshold.java > java/lang/management/MemoryMXBean/LowMemoryTest.java > > The webrev that includes them can be found here: http://cr.openjdk.java.net/~ykantser/8034960/webrev.02/ > > Thanks, > Katja > > > > -------- Original Message -------- > Subject: Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError > Date: Fri, 9 May 2014 12:48:56 +0200 > From: Staffan Larsen > To: Yekaterina Kantserova > CC: Alan Bateman , "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" , core-libs-dev Libs > > Looks good! > > Thanks, > /Staffan > > On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > > > Hi, > > > > The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > > > Thanks, > > Katja > > > > > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: > >> I?ve looked at a random sample of these changes and they look ok. > >> > >> Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. > >> > >> I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. > >> > >> Thanks, > >> /Staffan > >> > >> On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: > >> > >>> Hi, > >>> > >>> Could I please have a review of this fix. > >>> > >>> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 > >>> > >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. > >>> > >>> Verified locally since no JTreg with fix has been promoted yet. > >>> > >>> > >>> Thanks, > >>> Katja > > > > > > <8034960.open.patch> From paul.sandoz at oracle.com Mon May 12 10:03:03 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 12:03:03 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK Message-ID: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Hi, This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. - Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). Paul. - core http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ - io http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ - management http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ - rmi http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ - security http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ - tools http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ - graphics/media http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ - asm http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From otaviopolianasantana at gmail.com Mon May 12 10:23:54 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 12 May 2014 07:23:54 -0300 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_buffer_string_builder.zip On Mon, May 12, 2014 at 7:03 AM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer with > StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to aid > reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it out. Many > files are touched but there are not many changes to each file and changes > are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull in > ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now be > supported by the email server). > > Paul. > > - core > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > -- Cheers!. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- diff -r 3e8e199e23b2 src/share/classes/com/sun/crypto/provider/DHParameters.java --- a/src/share/classes/com/sun/crypto/provider/DHParameters.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/crypto/provider/DHParameters.java Mon May 12 07:17:17 2014 -0300 @@ -131,14 +131,14 @@ protected String engineToString() { String LINE_SEP = System.getProperty("line.separator"); - StringBuffer strbuf - = new StringBuffer("SunJCE Diffie-Hellman Parameters:" + StringBuilder sb + = new StringBuilder("SunJCE Diffie-Hellman Parameters:" + LINE_SEP + "p:" + LINE_SEP + Debug.toHexString(this.p) + LINE_SEP + "g:" + LINE_SEP + Debug.toHexString(this.g)); if (this.l != 0) - strbuf.append(LINE_SEP + "l:" + LINE_SEP + " " + this.l); - return strbuf.toString(); + sb.append(LINE_SEP + "l:" + LINE_SEP + " " + this.l); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/com/sun/crypto/provider/DHPublicKey.java --- a/src/share/classes/com/sun/crypto/provider/DHPublicKey.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/crypto/provider/DHPublicKey.java Mon May 12 07:17:17 2014 -0300 @@ -260,8 +260,8 @@ public String toString() { String LINE_SEP = System.getProperty("line.separator"); - StringBuffer strbuf - = new StringBuffer("SunJCE Diffie-Hellman Public Key:" + StringBuilder sb + = new StringBuilder("SunJCE Diffie-Hellman Public Key:" + LINE_SEP + "y:" + LINE_SEP + Debug.toHexString(this.y) + LINE_SEP + "p:" + LINE_SEP @@ -269,8 +269,8 @@ + LINE_SEP + "g:" + LINE_SEP + Debug.toHexString(this.g)); if (this.l != 0) - strbuf.append(LINE_SEP + "l:" + LINE_SEP + " " + this.l); - return strbuf.toString(); + sb.append(LINE_SEP + "l:" + LINE_SEP + " " + this.l); + return sb.toString(); } private void parseKeyBits() throws InvalidKeyException { diff -r 3e8e199e23b2 src/share/classes/com/sun/crypto/provider/OAEPParameters.java --- a/src/share/classes/com/sun/crypto/provider/OAEPParameters.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/crypto/provider/OAEPParameters.java Mon May 12 07:17:17 2014 -0300 @@ -238,7 +238,7 @@ } protected String engineToString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("MD: " + mdName + "\n"); sb.append("MGF: MGF1" + mgfSpec.getDigestAlgorithm() + "\n"); sb.append("PSource: PSpecified " + diff -r 3e8e199e23b2 src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java --- a/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Mon May 12 07:17:17 2014 -0300 @@ -509,7 +509,7 @@ byte[] signature = new byte[6]; stream.readFully(signature); - StringBuffer version = new StringBuffer(3); + StringBuilder version = new StringBuilder(3); version.append((char)signature[3]); version.append((char)signature[4]); version.append((char)signature[5]); diff -r 3e8e199e23b2 src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java --- a/src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java Mon May 12 07:17:17 2014 -0300 @@ -900,7 +900,7 @@ if (times == 1) { return s; } - StringBuffer sb = new StringBuffer((s.length() + 1)*times - 1); + StringBuilder sb = new StringBuilder((s.length() + 1)*times - 1); sb.append(s); for (int i = 1; i < times; i++) { sb.append(" "); diff -r 3e8e199e23b2 src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java --- a/src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Mon May 12 07:17:17 2014 -0300 @@ -169,23 +169,23 @@ result.add(typedInName); } - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); len = result.size(); // construct the resulting string for (int i=0; i 0) { - buf.append(" "); + sb.append(" "); } if (len > 1) { - buf.append("\""); + sb.append("\""); } - buf.append(result.get(i)); + sb.append(result.get(i)); if (len > 1) { - buf.append("\""); + sb.append("\""); } } - return buf.toString(); + return sb.toString(); } public void setFileName(String fileName) { diff -r 3e8e199e23b2 src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Mon May 12 07:17:17 2014 -0300 @@ -533,13 +533,13 @@ // Pending: verify character encoding spec for gconf Reader reader = new InputStreamReader(url.openStream(), "ISO-8859-1"); char[] buf = new char[1024]; - StringBuffer strBuf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); int n; while ((n = reader.read(buf)) >= 0) { - strBuf.append(buf, 0, n); + sb.append(buf, 0, n); } reader.close(); - String str = strBuf.toString(); + String str = sb.toString(); if (str != null) { String strLowerCase = str.toLowerCase(); int i = strLowerCase.indexOf(" 0) { - buf.append(" "); + sb.append(" "); } if (files.length > 1) { - buf.append("\""); + sb.append("\""); } - buf.append(fileNameString(files[i])); + sb.append(fileNameString(files[i])); if (files.length > 1) { - buf.append("\""); + sb.append("\""); } } - return buf.toString(); + return sb.toString(); } public MotifFileChooserUI(JFileChooser filechooser) { diff -r 3e8e199e23b2 src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java --- a/src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Mon May 12 07:17:17 2014 -0300 @@ -690,7 +690,7 @@ } private String fileNameString(File[] files) { - StringBuffer buf = new StringBuffer(); + StringBuilder buf = new StringBuilder(); for (int i = 0; files != null && i < files.length; i++) { if (i > 0) { buf.append(" "); diff -r 3e8e199e23b2 src/share/classes/com/sun/java/util/jar/pack/BandStructure.java --- a/src/share/classes/com/sun/java/util/jar/pack/BandStructure.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/java/util/jar/pack/BandStructure.java Mon May 12 07:17:17 2014 -0300 @@ -628,7 +628,7 @@ } if (metaCoding.length > 0 && (verbose > 2 || verbose > 1 && metaCoding.length > 1)) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < metaCoding.length; i++) { if (i == 1) sb.append(" /"); sb.append(" ").append(metaCoding[i] & 0xFF); @@ -756,7 +756,7 @@ " size="+outputSize()+ irr+" coding="+bandCoding); if (metaCoding != noMetaCoding) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < metaCoding.length; i++) { if (i == 1) sb.append(" /"); sb.append(" ").append(metaCoding[i] & 0xFF); diff -r 3e8e199e23b2 src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Mon May 12 07:17:17 2014 -0300 @@ -1026,7 +1026,7 @@ } static String stringValueOf(MethodHandleEntry bsmRef, Entry[] argRefs) { - StringBuffer sb = new StringBuffer(bsmRef.stringValue()); + StringBuilder sb = new StringBuilder(bsmRef.stringValue()); // Arguments are formatted as "" instead of "[foo,bar,baz]". // This ensures there will be no confusion if "[,]" appear inside of names. char nextSep = '<'; diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java Mon May 12 07:17:17 2014 -0300 @@ -63,12 +63,12 @@ if (SNMP_LOGGER.isLoggable(Level.FINEST)) { SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), "extractSubNet", "BINARY ARRAY :"); - StringBuffer buff = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for(int i =0; i < addrLength; i++) { - buff.append((b[i] &0xFF) +":"); + sb.append((b[i] & 0xFF) + ":"); } SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), - "extractSubNet", buff.toString()); + "extractSubNet", sb.toString()); } // 8 is a byte size. Common to any InetAddress (V4 or V6). diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/IPAcl/ParseException.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/ParseException.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/ParseException.java Mon May 12 07:17:17 2014 -0300 @@ -170,7 +170,7 @@ * string literal. */ protected String add_escapes(String str) { - StringBuffer retval = new StringBuffer(); + StringBuilder retval = new StringBuilder(); char ch; for (int i = 0; i < str.length(); i++) { switch (str.charAt(i)) diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java Mon May 12 07:17:17 2014 -0300 @@ -186,8 +186,8 @@ public static String getDefaultAclFileName() { final String fileSeparator = System.getProperty("file.separator"); - final StringBuffer defaultAclName = - new StringBuffer(System.getProperty("java.home")). + final StringBuilder defaultAclName = + new StringBuilder(System.getProperty("java.home")). append(fileSeparator).append("lib").append(fileSeparator). append("snmp.acl"); return defaultAclName.toString(); diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java Mon May 12 07:17:17 2014 -0300 @@ -65,7 +65,7 @@ * equivalents in the given string */ protected static final String addEscapes(String str) { - StringBuffer retval = new StringBuffer(); + StringBuilder retval = new StringBuilder(); char ch; for (int i = 0; i < str.length(); i++) { switch (str.charAt(i)) diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/SnmpMessage.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpMessage.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpMessage.java Mon May 12 07:17:17 2014 -0300 @@ -347,7 +347,7 @@ * @return The string containing the dump. */ public String printMessage() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (community == null) { sb.append("Community: null") ; } diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/SnmpMsg.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpMsg.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpMsg.java Mon May 12 07:17:17 2014 -0300 @@ -181,22 +181,22 @@ * @return The string containing the dump. */ public static String dumpHexBuffer(byte [] b, int offset, int len) { - StringBuffer buf = new StringBuffer(len << 1) ; + StringBuilder sb = new StringBuilder(len << 1) ; int k = 1 ; int flen = offset + len ; for (int i = offset; i < flen ; i++) { int j = b[i] & 0xFF ; - buf.append(Character.forDigit((j >>> 4) , 16)) ; - buf.append(Character.forDigit((j & 0x0F), 16)) ; + sb.append(Character.forDigit((j >>> 4), 16)) ; + sb.append(Character.forDigit((j & 0x0F), 16)) ; k++ ; if (k%16 == 0) { - buf.append('\n') ; + sb.append('\n') ; k = 1 ; } else - buf.append(' ') ; + sb.append(' ') ; } - return buf.toString() ; + return sb.toString() ; } /** @@ -205,7 +205,7 @@ * @return The string containing the dump. */ public String printMessage() { - StringBuffer sb = new StringBuffer() ; + StringBuilder sb = new StringBuilder() ; sb.append("Version: ") ; sb.append(version) ; sb.append("\n") ; diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/SnmpOpaque.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpOpaque.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpOpaque.java Mon May 12 07:17:17 2014 -0300 @@ -73,7 +73,7 @@ * @return The String representation of the value. */ public String toString() { - StringBuffer result = new StringBuffer() ; + StringBuilder result = new StringBuilder() ; for (int i = 0 ; i < value.length ; i++) { byte b = value[i] ; int n = (b >= 0) ? b : b + 256 ; diff -r 3e8e199e23b2 src/share/classes/com/sun/jmx/snmp/SnmpV3Message.java --- a/src/share/classes/com/sun/jmx/snmp/SnmpV3Message.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jmx/snmp/SnmpV3Message.java Mon May 12 07:17:17 2014 -0300 @@ -478,7 +478,7 @@ * @return The string containing the dump. */ public String printMessage() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("msgId : " + msgId + "\n"); sb.append("msgMaxSize : " + msgMaxSize + "\n"); sb.append("msgFlags : " + msgFlags + "\n"); diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java --- a/src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/cosnaming/CNNameParser.java Mon May 12 07:17:17 2014 -0300 @@ -96,7 +96,7 @@ * Used by CNCtx.getNameInNamespace(), CNCompoundName.toString(). */ static String cosNameToInsString(NameComponent[] cname) { - StringBuffer str = new StringBuffer(); + StringBuilder str = new StringBuilder(); for ( int i = 0; i < cname.length; i++) { if ( i > 0) { str.append(compSeparator); @@ -254,7 +254,7 @@ } private static String stringifyComponent(NameComponent comp) { - StringBuffer one = new StringBuffer(escape(comp.id)); + StringBuilder one = new StringBuilder(escape(comp.id)); if (comp.kind != null && !comp.kind.equals("")) { one.append(kindSeparator + escape(comp.kind)); } diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/dns/DnsContextFactory.java --- a/src/share/classes/com/sun/jndi/dns/DnsContextFactory.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/dns/DnsContextFactory.java Mon May 12 07:17:17 2014 -0300 @@ -198,14 +198,14 @@ } } - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < servers.length; i++) { if (i > 0) { - buf.append(' '); + sb.append(' '); } - buf.append("dns://").append(servers[i]).append(path); + sb.append("dns://").append(servers[i]).append(path); } - return buf.toString(); + return sb.toString(); } /* diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/dns/DnsName.java --- a/src/share/classes/com/sun/jndi/dns/DnsName.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/dns/DnsName.java Mon May 12 07:17:17 2014 -0300 @@ -415,7 +415,7 @@ */ private void parse(String name) throws InvalidNameException { - StringBuffer label = new StringBuffer(); // label being parsed + StringBuilder label = new StringBuilder(); // label being parsed for (int i = 0; i < name.length(); i++) { char c = name.charAt(i); @@ -564,15 +564,15 @@ * into account. See compareLabels(). */ private static String keyForLabel(String label) { - StringBuffer buf = new StringBuffer(label.length()); + StringBuilder sb = new StringBuilder(label.length()); for (int i = 0; i < label.length(); i++) { char c = label.charAt(i); if (c >= 'A' && c <= 'Z') { c += 'a' - 'A'; // to lower case } - buf.append(c); + sb.append(c); } - return buf.toString(); + return sb.toString(); } diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/dns/ResourceRecord.java --- a/src/share/classes/com/sun/jndi/dns/ResourceRecord.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/dns/ResourceRecord.java Mon May 12 07:17:17 2014 -0300 @@ -596,21 +596,21 @@ // If bestBase != -1, compress zeros in [bestBase, bestBase+bestLen) boolean compress = (bestBase != -1); - StringBuffer buf = new StringBuffer(40); + StringBuilder sb = new StringBuilder(40); if (bestBase == 0) { - buf.append(':'); + sb.append(':'); } for (int i = 0; i < 8; i++) { if (!compress || (i < bestBase) || (i >= bestBase + bestLen)) { - buf.append(Integer.toHexString(addr6[i])); + sb.append(Integer.toHexString(addr6[i])); if (i < 7) { - buf.append(':'); + sb.append(':'); } } else if (compress && (i == bestBase)) { // first compressed zero - buf.append(':'); + sb.append(':'); } } - return buf.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/ldap/ClientId.java --- a/src/share/classes/com/sun/jndi/ldap/ClientId.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/ClientId.java Mon May 12 07:17:17 2014 -0300 @@ -210,7 +210,7 @@ if (ctls == null) { return ""; } - StringBuffer str = new StringBuffer(); + StringBuilder str = new StringBuilder(); for (int i = 0; i < ctls.length; i++) { str.append(ctls[i].getID()); str.append(' '); diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/ldap/DigestClientId.java --- a/src/share/classes/com/sun/jndi/ldap/DigestClientId.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/DigestClientId.java Mon May 12 07:17:17 2014 -0300 @@ -103,14 +103,14 @@ public String toString() { if (propvals != null) { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < propvals.length; i++) { - buf.append(':'); + sb.append(':'); if (propvals[i] != null) { - buf.append(propvals[i]); + sb.append(propvals[i]); } } - return super.toString() + buf.toString(); + return super.toString() + sb.toString(); } else { return super.toString(); } diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java --- a/src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java Mon May 12 07:17:17 2014 -0300 @@ -767,7 +767,7 @@ final private String classDef2ObjectDesc(Attributes attrs) throws NamingException { - StringBuffer objectDesc = new StringBuffer("( "); + StringBuilder objectDesc = new StringBuilder("( "); Attribute attr = null; int count = 0; @@ -879,7 +879,7 @@ final private String attrDef2AttrDesc(Attributes attrs) throws NamingException { - StringBuffer attrDesc = new StringBuffer("( "); // opening parens + StringBuilder attrDesc = new StringBuilder("( "); // opening parens Attribute attr = null; int count = 0; @@ -1012,7 +1012,7 @@ final private String syntaxDef2SyntaxDesc(Attributes attrs) throws NamingException { - StringBuffer syntaxDesc = new StringBuffer("( "); // opening parens + StringBuilder syntaxDesc = new StringBuilder("( "); // opening parens Attribute attr = null; int count = 0; @@ -1068,7 +1068,7 @@ final private String matchRuleDef2MatchRuleDesc(Attributes attrs) throws NamingException { - StringBuffer matchRuleDesc = new StringBuffer("( "); // opening parens + StringBuilder matchRuleDesc = new StringBuilder("( "); // opening parens Attribute attr = null; int count = 0; @@ -1196,7 +1196,7 @@ // write QDList - StringBuffer qdList = new StringBuffer(attr.getID()); + StringBuilder qdList = new StringBuilder(attr.getID()); qdList.append(WHSP); qdList.append(OID_LIST_BEGIN); @@ -1233,7 +1233,7 @@ // write OID List - StringBuffer oidList = new StringBuffer(oidsAttr.getID()); + StringBuilder oidList = new StringBuilder(oidsAttr.getID()); oidList.append(WHSP); oidList.append(OID_LIST_BEGIN); diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/ldap/ServiceLocator.java --- a/src/share/classes/com/sun/jndi/ldap/ServiceLocator.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/ServiceLocator.java Mon May 12 07:17:17 2014 -0300 @@ -68,7 +68,7 @@ if (dn == null) { return null; } - StringBuffer domain = new StringBuffer(); + StringBuilder domain = new StringBuilder(); LdapName ldapName = new LdapName(dn); // process RDNs left-to-right diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java Mon May 12 07:17:17 2014 -0300 @@ -88,7 +88,7 @@ } } if (selected == -1) { - StringBuffer allChoices = new StringBuffer(); + StringBuilder allChoices = new StringBuilder(); for (int j = 0; j < choices.length; j++) { allChoices.append(choices[j] + ","); } diff -r 3e8e199e23b2 src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java --- a/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java Mon May 12 07:17:17 2014 -0300 @@ -520,30 +520,30 @@ str = (String)obj; } int len = str.length(); - StringBuffer buf = new StringBuffer(len); + StringBuilder sb = new StringBuilder(len); char ch; for (int i = 0; i < len; i++) { switch (ch=str.charAt(i)) { case '*': - buf.append("\\2a"); + sb.append("\\2a"); break; case '(': - buf.append("\\28"); + sb.append("\\28"); break; case ')': - buf.append("\\29"); + sb.append("\\29"); break; case '\\': - buf.append("\\5c"); + sb.append("\\5c"); break; case 0: - buf.append("\\00"); + sb.append("\\00"); break; default: - buf.append(ch); + sb.append(ch); } } - return buf.toString(); + return sb.toString(); } @@ -585,7 +585,7 @@ int param; int where = 0, start = 0; - StringBuffer answer = new StringBuffer(expr.length()); + StringBuilder answer = new StringBuilder(expr.length()); while ((where = findUnescaped('{', expr, start)) >= 0) { int pstart = where + 1; // skip '{' diff -r 3e8e199e23b2 src/share/classes/com/sun/media/sound/SoftPerformer.java --- a/src/share/classes/com/sun/media/sound/SoftPerformer.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/media/sound/SoftPerformer.java Mon May 12 07:17:17 2014 -0300 @@ -326,7 +326,7 @@ private static KeySortComparator keySortComparator = new KeySortComparator(); private String extractKeys(ModelConnectionBlock conn) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (conn.getSources() != null) { sb.append("["); ModelSource[] srcs = conn.getSources(); diff -r 3e8e199e23b2 src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java Mon May 12 07:17:17 2014 -0300 @@ -162,7 +162,7 @@ 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71); private String decodeChannelMask(long channelmask) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); long m = 1; for (int i = 0; i < allchannelnames.length; i++) { if ((channelmask & m) != 0L) { diff -r 3e8e199e23b2 src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java Mon May 12 07:17:17 2014 -0300 @@ -257,7 +257,7 @@ public static final byte[] decode(Element element) throws Base64DecodingException { Node sibling = element.getFirstChild(); - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); while (sibling != null) { if (sibling.getNodeType() == Node.TEXT_NODE) { diff -r 3e8e199e23b2 src/share/classes/com/sun/security/sasl/CramMD5Base.java --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java Mon May 12 07:17:17 2014 -0300 @@ -195,7 +195,7 @@ digest = md5.digest(); // Get character representation of digest - StringBuffer digestString = new StringBuffer(); + StringBuilder digestString = new StringBuilder(); for (i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { diff -r 3e8e199e23b2 src/share/classes/com/sun/security/sasl/CramMD5Server.java --- a/src/share/classes/com/sun/security/sasl/CramMD5Server.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/CramMD5Server.java Mon May 12 07:17:17 2014 -0300 @@ -117,15 +117,15 @@ long rand = random.nextLong(); long timestamp = System.currentTimeMillis(); - StringBuffer buf = new StringBuffer(); - buf.append('<'); - buf.append(rand); - buf.append('.'); - buf.append(timestamp); - buf.append('@'); - buf.append(fqdn); - buf.append('>'); - String challengeStr = buf.toString(); + StringBuilder sb = new StringBuilder(); + sb.append('<'); + sb.append(rand); + sb.append('.'); + sb.append(timestamp); + sb.append('@'); + sb.append(fqdn); + sb.append('>'); + String challengeStr = sb.toString(); logger.log(Level.FINE, "CRAMSRV01:Generated challenge: {0}", challengeStr); diff -r 3e8e199e23b2 src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java Mon May 12 07:17:17 2014 -0300 @@ -387,7 +387,7 @@ protected byte[] binaryToHex(byte[] digest) throws UnsupportedEncodingException { - StringBuffer digestString = new StringBuffer(); + StringBuilder digestString = new StringBuilder(); for (int i = 0; i < digest.length; i ++) { if ((digest[i] & 0x000000ff) < 0x10) { @@ -598,7 +598,7 @@ protected static String nonceCountToHex(int count) { String str = Integer.toHexString(count); - StringBuffer pad = new StringBuffer(); + StringBuilder pad = new StringBuilder(); if (str.length() < 8) { for (int i = 0; i < 8-str.length(); i ++) { diff -r 3e8e199e23b2 src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java Mon May 12 07:17:17 2014 -0300 @@ -203,19 +203,19 @@ String supportedCiphers = null; if ((allQop&PRIVACY_PROTECTION) != 0) { myCiphers = getPlatformCiphers(); - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); // myCipher[i] is a byte that indicates whether CIPHER_TOKENS[i] // is supported for (int i = 0; i < CIPHER_TOKENS.length; i++) { if (myCiphers[i] != 0) { - if (buf.length() > 0) { - buf.append(','); + if (sb.length() > 0) { + sb.append(','); } - buf.append(CIPHER_TOKENS[i]); + sb.append(CIPHER_TOKENS[i]); } } - supportedCiphers = buf.toString(); + supportedCiphers = sb.toString(); } try { diff -r 3e8e199e23b2 src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java --- a/src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java Mon May 12 07:17:17 2014 -0300 @@ -80,13 +80,13 @@ "SASLIMPL02:Preferred qop mask: {0}", new Byte(allQop)); if (qop.length > 0) { - StringBuffer qopbuf = new StringBuffer(); + StringBuilder str = new StringBuilder(); for (int i = 0; i < qop.length; i++) { - qopbuf.append(Byte.toString(qop[i])); - qopbuf.append(' '); + str.append(Byte.toString(qop[i])); + str.append(' '); } logger.logp(Level.FINE, myClassName, "constructor", - "SASLIMPL03:Preferred qops : {0}", qopbuf.toString()); + "SASLIMPL03:Preferred qops : {0}", str.toString()); } } @@ -95,13 +95,13 @@ logger.logp(Level.FINE, myClassName, "constructor", "SASLIMPL04:Preferred strength property: {0}", prop); if (logger.isLoggable(Level.FINE) && strength.length > 0) { - StringBuffer strbuf = new StringBuffer(); + StringBuilder str = new StringBuilder(); for (int i = 0; i < strength.length; i++) { - strbuf.append(Byte.toString(strength[i])); - strbuf.append(' '); + str.append(Byte.toString(strength[i])); + str.append(' '); } logger.logp(Level.FINE, myClassName, "constructor", - "SASLIMPL05:Cipher strengths: {0}", strbuf.toString()); + "SASLIMPL05:Cipher strengths: {0}", str.toString()); } // Max receive buffer size diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java --- a/src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java Mon May 12 07:17:17 2014 -0300 @@ -102,8 +102,8 @@ @Override public String toString() { - StringBuffer buffer = new StringBuffer("exception catch "); - buffer.append(refSpec.toString()); - return buffer.toString(); + StringBuilder sb = new StringBuilder("exception catch "); + sb.append(refSpec.toString()); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java --- a/src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java Mon May 12 07:17:17 2014 -0300 @@ -118,13 +118,13 @@ @Override public String toString() { - StringBuffer buffer = new StringBuffer("breakpoint "); - buffer.append(refSpec.toString()); - buffer.append(':'); - buffer.append(lineNumber); - buffer.append(" ("); - buffer.append(getStatusString()); - buffer.append(')'); - return buffer.toString(); + StringBuilder sb = new StringBuilder("breakpoint "); + sb.append(refSpec.toString()); + sb.append(':'); + sb.append(lineNumber); + sb.append(" ("); + sb.append(getStatusString()); + sb.append(')'); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java --- a/src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java Mon May 12 07:17:17 2014 -0300 @@ -126,26 +126,26 @@ @Override public String toString() { - StringBuffer buffer = new StringBuffer("breakpoint "); - buffer.append(refSpec.toString()); - buffer.append('.'); - buffer.append(methodId); + StringBuilder sb = new StringBuilder("breakpoint "); + sb.append(refSpec.toString()); + sb.append('.'); + sb.append(methodId); if (methodArgs != null) { boolean first = true; - buffer.append('('); + sb.append('('); for (String name : methodArgs) { if (!first) { - buffer.append(','); + sb.append(','); } - buffer.append(name); + sb.append(name); first = false; } - buffer.append(")"); + sb.append(")"); } - buffer.append(" ("); - buffer.append(getStatusString()); - buffer.append(')'); - return buffer.toString(); + sb.append(" ("); + sb.append(getStatusString()); + sb.append(')'); + return sb.toString(); } private boolean isValidMethodName(String s) { @@ -225,8 +225,8 @@ * stripping whitespace after the name ends. */ int i = 0; - StringBuffer typePart = new StringBuffer(); - StringBuffer arrayPart = new StringBuffer(); + StringBuilder typePart = new StringBuilder(); + StringBuilder arrayPart = new StringBuilder(); name = name.trim(); int nameLength = name.length(); /* diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java --- a/src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java Mon May 12 07:17:17 2014 -0300 @@ -185,7 +185,7 @@ } final public String Name() throws ParseException { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); jj_consume_token(IDENTIFIER); sb.append(token); label_2: diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/expr/ParseException.java --- a/src/share/classes/com/sun/tools/example/debug/expr/ParseException.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/expr/ParseException.java Mon May 12 07:17:17 2014 -0300 @@ -114,7 +114,7 @@ int[][] expectedTokenSequences, String[] tokenImage) { String eol = System.getProperty("line.separator", "\n"); - StringBuffer expected = new StringBuffer(); + StringBuilder expected = new StringBuilder(); int maxSize = 0; for (int i = 0; i < expectedTokenSequences.length; i++) { if (maxSize < expectedTokenSequences[i].length) { @@ -164,7 +164,7 @@ * string literal. */ static String add_escapes(String str) { - StringBuffer retval = new StringBuffer(); + StringBuilder retval = new StringBuilder(); char ch; for (int i = 0; i < str.length(); i++) { switch (str.charAt(i)) diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java --- a/src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java Mon May 12 07:17:17 2014 -0300 @@ -73,7 +73,7 @@ * equivalents in the given string */ protected static final String addEscapes(String str) { - StringBuffer retval = new StringBuffer(); + StringBuilder retval = new StringBuilder(); char ch; for (int i = 0; i < str.length(); i++) { switch (str.charAt(i)) diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java --- a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Mon May 12 07:17:17 2014 -0300 @@ -267,7 +267,7 @@ buf[j] = ' '; } buf[79] = '\0'; - StringBuffer sbOut = new StringBuffer(); + StringBuilder sbOut = new StringBuilder(); sbOut.append(buf); // Right-justify the thread number at start of output string @@ -381,16 +381,16 @@ } } else { clname = t.nextToken(); - StringBuffer sbuf = new StringBuffer(); + StringBuilder str = new StringBuilder(); // Allow VM arguments to be specified here? while (t.hasMoreTokens()) { String tok = t.nextToken(); - sbuf.append(tok); + str.append(tok); if (t.hasMoreTokens()) { - sbuf.append(' '); + str.append(' '); } } - String args = sbuf.toString(); + String args = str.toString(); try { String vmArgs = context.getVmArguments(); runtime.run(suspended, vmArgs, clname, args); diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java Mon May 12 07:17:17 2014 -0300 @@ -333,7 +333,7 @@ private String processClasspathDefaults(String javaArgs) { if (javaArgs.indexOf("-classpath ") == -1) { - StringBuffer munged = new StringBuffer(javaArgs); + StringBuilder munged = new StringBuilder(javaArgs); SearchPath classpath = classManager.getClassPath(); if (classpath.isEmpty()) { String envcp = System.getProperty("env.class.path"); diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java --- a/src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java Mon May 12 07:17:17 2014 -0300 @@ -236,7 +236,7 @@ private String expandTabs(String s) { int col = 0; int len = s.length(); - StringBuffer sb = new StringBuffer(132); + StringBuilder sb = new StringBuilder(132); for (int i = 0; i < len; i++) { char c = s.charAt(i); sb.append(c); diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java --- a/src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java Mon May 12 07:17:17 2014 -0300 @@ -154,27 +154,27 @@ @Override public String toString() { - StringBuffer buffer = new StringBuffer(refSpec.toString()); + StringBuilder sb = new StringBuilder(refSpec.toString()); if (isMethodBreakpoint()) { - buffer.append('.'); - buffer.append(methodId); + sb.append('.'); + sb.append(methodId); if (methodArgs != null) { boolean first = true; - buffer.append('('); + sb.append('('); for (String arg : methodArgs) { if (!first) { - buffer.append(','); + sb.append(','); } - buffer.append(arg); + sb.append(arg); first = false; } - buffer.append(")"); + sb.append(")"); } } else { - buffer.append(':'); - buffer.append(lineNumber); + sb.append(':'); + sb.append(lineNumber); } - return MessageOutput.format("breakpoint", buffer.toString()); + return MessageOutput.format("breakpoint", sb.toString()); } private Location location(ReferenceType refType) throws @@ -275,8 +275,8 @@ * stripping whitespace after the name ends */ int i = 0; - StringBuffer typePart = new StringBuffer(); - StringBuffer arrayPart = new StringBuffer(); + StringBuilder typePart = new StringBuilder(); + StringBuilder arrayPart = new StringBuilder(); name = name.trim(); int nameLength = name.length(); /* diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Mon May 12 07:17:17 2014 -0300 @@ -164,30 +164,30 @@ } String typedName(Method method) { - StringBuffer buf = new StringBuffer(); - buf.append(method.name()); - buf.append("("); + StringBuilder sb = new StringBuilder(); + sb.append(method.name()); + sb.append("("); List args = method.argumentTypeNames(); int lastParam = args.size() - 1; // output param types except for the last for (int ii = 0; ii < lastParam; ii++) { - buf.append(args.get(ii)); - buf.append(", "); + sb.append(args.get(ii)); + sb.append(", "); } if (lastParam >= 0) { // output the last param String lastStr = args.get(lastParam); if (method.isVarArgs()) { // lastParam is an array. Replace the [] with ... - buf.append(lastStr.substring(0, lastStr.length() - 2)); - buf.append("..."); + sb.append(lastStr.substring(0, lastStr.length() - 2)); + sb.append("..."); } else { - buf.append(lastStr); + sb.append(lastStr); } } - buf.append(")"); - return buf.toString(); + sb.append(")"); + return sb.toString(); } void commandConnectors(VirtualMachineManager vmm) { @@ -226,7 +226,7 @@ } void commandClasses() { - StringBuffer classList = new StringBuffer(); + StringBuilder classList = new StringBuilder(); for (ReferenceType refType : Env.vm().allClasses()) { classList.append(refType.name()); classList.append("\n"); @@ -309,7 +309,7 @@ String idClass = t.nextToken(); ReferenceType cls = Env.getReferenceTypeFromToken(idClass); if (cls != null) { - StringBuffer methodsList = new StringBuffer(); + StringBuilder methodsList = new StringBuilder(); for (Method method : cls.allMethods()) { methodsList.append(method.declaringType().name()); methodsList.append(" "); @@ -333,7 +333,7 @@ if (cls != null) { List fields = cls.allFields(); List visible = cls.visibleFields(); - StringBuffer fieldsList = new StringBuffer(); + StringBuilder fieldsList = new StringBuilder(); for (Field field : fields) { String s; if (!visible.contains(field)) { @@ -391,11 +391,11 @@ * very long thread names, at the possible cost of lines * being wrapped by the display device. */ - StringBuffer idBuffer = new StringBuffer(Env.description(thr)); + StringBuilder idBuffer = new StringBuilder(Env.description(thr)); for (int i = idBuffer.length(); i < maxIdLength; i++) { idBuffer.append(" "); } - StringBuffer nameBuffer = new StringBuffer(thr.name()); + StringBuilder nameBuffer = new StringBuilder(thr.name()); for (int i = nameBuffer.length(); i < maxNameLength; i++) { nameBuffer.append(" "); } @@ -1606,16 +1606,16 @@ private void dump(ObjectReference obj, ReferenceType refType, ReferenceType refTypeBase) { for (Field field : refType.fields()) { - StringBuffer o = new StringBuffer(); - o.append(" "); + StringBuilder sb = new StringBuilder(); + sb.append(" "); if (!refType.equals(refTypeBase)) { - o.append(refType.name()); - o.append("."); + sb.append(refType.name()); + sb.append("."); } - o.append(field.name()); - o.append(MessageOutput.format("colon space")); - o.append(obj.getValue(field)); - MessageOutput.printDirectln(o.toString()); // Special case: use printDirectln() + sb.append(field.name()); + sb.append(MessageOutput.format("colon space")); + sb.append(obj.getValue(field)); + MessageOutput.printDirectln(sb.toString()); // Special case: use printDirectln() } if (refType instanceof ClassType) { ClassType sup = ((ClassType)refType).superclass(); @@ -1954,7 +1954,7 @@ } } - StringBuffer line = new StringBuffer(80); + StringBuilder line = new StringBuilder(80); line.append("0000: "); for (int i = 0; i < bytecodes.length; i++) { if ((i > 0) && (i % 16 == 0)) { diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/tty/Env.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Env.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Env.java Mon May 12 07:17:17 2014 -0300 @@ -114,12 +114,12 @@ } static String excludesString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (String pattern : excludes()) { - buffer.append(pattern); - buffer.append(","); + sb.append(pattern); + sb.append(","); } - return buffer.toString(); + return sb.toString(); } static void addExcludes(StepRequest request) { diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/debug/tty/TTY.java --- a/src/share/classes/com/sun/tools/example/debug/tty/TTY.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/TTY.java Mon May 12 07:17:17 2014 -0300 @@ -827,17 +827,17 @@ private static String addArgument(String string, String argument) { if (hasWhitespace(argument) || argument.indexOf(',') != -1) { // Quotes were stripped out for this argument, add 'em back. - StringBuffer buffer = new StringBuffer(string); - buffer.append('"'); + StringBuilder sb = new StringBuilder(string); + sb.append('"'); for (int i = 0; i < argument.length(); i++) { char c = argument.charAt(i); if (c == '"') { - buffer.append('\\'); + sb.append('\\'); } - buffer.append(c); + sb.append(c); } - buffer.append("\" "); - return buffer.toString(); + sb.append("\" "); + return sb.toString(); } else { return string + argument + ' '; } diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/example/trace/Trace.java --- a/src/share/classes/com/sun/tools/example/trace/Trace.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/trace/Trace.java Mon May 12 07:17:17 2014 -0300 @@ -121,7 +121,7 @@ usage(); System.exit(1); } - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(args[inx]); for (++inx; inx < args.length; ++inx) { sb.append(' '); diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/hat/internal/util/Misc.java --- a/src/share/classes/com/sun/tools/hat/internal/util/Misc.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/util/Misc.java Mon May 12 07:17:17 2014 -0300 @@ -83,30 +83,30 @@ public static String encodeHtml(String str) { final int len = str.length(); - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < len; i++) { char ch = str.charAt(i); if (ch == '<') { - buf.append("<"); + sb.append("<"); } else if (ch == '>') { - buf.append(">"); + sb.append(">"); } else if (ch == '"') { - buf.append("""); + sb.append("""); } else if (ch == '\'') { - buf.append("'"); + sb.append("'"); } else if (ch == '&') { - buf.append("&"); + sb.append("&"); } else if (ch < ' ') { - buf.append("&#" + Integer.toString(ch) + ";"); + sb.append("&#" + Integer.toString(ch) + ";"); } else { int c = (ch & 0xFFFF); if (c > 127) { - buf.append("&#" + Integer.toString(c) + ";"); + sb.append("&#" + Integer.toString(c) + ";"); } else { - buf.append(ch); + sb.append(ch); } } } - return buf.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/FieldImpl.java --- a/src/share/classes/com/sun/tools/jdi/FieldImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/FieldImpl.java Mon May 12 07:17:17 2014 -0300 @@ -95,12 +95,12 @@ } public String toString() { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buf.append(declaringType().name()); - buf.append('.'); - buf.append(name()); + sb.append(declaringType().name()); + sb.append('.'); + sb.append(name()); - return buf.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/JNITypeParser.java --- a/src/share/classes/com/sun/tools/jdi/JNITypeParser.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/JNITypeParser.java Mon May 12 07:17:17 2014 -0300 @@ -44,11 +44,11 @@ } static String typeNameToSignature(String signature) { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); int firstIndex = signature.indexOf('['); int index = firstIndex; while (index != -1) { - buffer.append('['); + sb.append('['); index = signature.indexOf('[', index + 1); } @@ -57,28 +57,28 @@ } if (signature.equals("boolean")) { - buffer.append('Z'); + sb.append('Z'); } else if (signature.equals("byte")) { - buffer.append('B'); + sb.append('B'); } else if (signature.equals("char")) { - buffer.append('C'); + sb.append('C'); } else if (signature.equals("short")) { - buffer.append('S'); + sb.append('S'); } else if (signature.equals("int")) { - buffer.append('I'); + sb.append('I'); } else if (signature.equals("long")) { - buffer.append('J'); + sb.append('J'); } else if (signature.equals("float")) { - buffer.append('F'); + sb.append('F'); } else if (signature.equals("double")) { - buffer.append('D'); + sb.append('D'); } else { - buffer.append('L'); - buffer.append(signature.replace('.', '/')); - buffer.append(';'); + sb.append('L'); + sb.append(signature.replace('.', '/')); + sb.append(';'); } - return buffer.toString(); + return sb.toString(); } String typeName() { diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/MethodImpl.java --- a/src/share/classes/com/sun/tools/jdi/MethodImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/MethodImpl.java Mon May 12 07:17:17 2014 -0300 @@ -380,7 +380,7 @@ } public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(declaringType().name()); sb.append("."); sb.append(name()); diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java --- a/src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java Mon May 12 07:17:17 2014 -0300 @@ -751,7 +751,7 @@ String baseSourceDir() { if (baseSourceDir == null) { String typeName = name(); - StringBuffer sb = new StringBuffer(typeName.length() + 10); + StringBuilder sb = new StringBuilder(typeName.length() + 10); int index = 0; int nextIndex; diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/SDE.java --- a/src/share/classes/com/sun/tools/jdi/SDE.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/SDE.java Mon May 12 07:17:17 2014 -0300 @@ -56,16 +56,16 @@ if (sourcePath == null) { sourcePath = refType.baseSourceDir() + sourceName; } else { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < sourcePath.length(); ++i) { char ch = sourcePath.charAt(i); if (ch == '/') { - buf.append(File.separatorChar); + sb.append(File.separatorChar); } else { - buf.append(ch); + sb.append(ch); } } - sourcePath = buf.toString(); + sourcePath = sb.toString(); } isConverted = true; } @@ -327,7 +327,7 @@ } String readLine() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); char ch; ignoreWhite(); diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/TargetVM.java --- a/src/share/classes/com/sun/tools/jdi/TargetVM.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/TargetVM.java Mon May 12 07:17:17 2014 -0300 @@ -78,7 +78,7 @@ ", errorCode=" + packet.errorCode + ", flags=" + packet.flags); } - StringBuffer line = new StringBuffer(80); + StringBuilder line = new StringBuilder(80); line.append("0000: "); for (int i = 0; i < packet.data.length; i++) { if ((i > 0) && (i % 16 == 0)) { diff -r 3e8e199e23b2 src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Mon May 12 07:17:17 2014 -0300 @@ -742,7 +742,7 @@ } void printReceiveTrace(int depth, String string) { - StringBuffer sb = new StringBuffer("Receiving:"); + StringBuilder sb = new StringBuilder("Receiving:"); for (int i = depth; i > 0; --i) { sb.append(" "); } @@ -872,7 +872,7 @@ ReferenceTypeImpl referenceType(long id, int tag, String signature) { if ((vm.traceFlags & VirtualMachine.TRACE_REFTYPES) != 0) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("Looking up "); if (tag == JDWP.TypeTag.CLASS) { sb.append("Class"); diff -r 3e8e199e23b2 src/share/classes/java/beans/Introspector.java --- a/src/share/classes/java/beans/Introspector.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/beans/Introspector.java Mon May 12 07:17:17 2014 -0300 @@ -1282,7 +1282,7 @@ * Creates a key for a method in a method cache. */ private static String makeQualifiedMethodName(String name, String[] params) { - StringBuffer sb = new StringBuffer(name); + StringBuilder sb = new StringBuilder(name); sb.append('='); for (int i = 0; i < params.length; i++) { sb.append(':'); diff -r 3e8e199e23b2 src/share/classes/java/beans/Statement.java --- a/src/share/classes/java/beans/Statement.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/beans/Statement.java Mon May 12 07:17:17 2014 -0300 @@ -340,7 +340,7 @@ if (arguments == null) { arguments = emptyArray; } - StringBuffer result = new StringBuffer(instanceName(target) + "." + methodName + "("); + StringBuilder result = new StringBuilder(instanceName(target) + "." + methodName + "("); int n = arguments.length; for(int i = 0; i < n; i++) { result.append(instanceName(arguments[i])); diff -r 3e8e199e23b2 src/share/classes/java/io/RandomAccessFile.java --- a/src/share/classes/java/io/RandomAccessFile.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/io/RandomAccessFile.java Mon May 12 07:17:17 2014 -0300 @@ -890,7 +890,7 @@ */ public final String readLine() throws IOException { - StringBuffer input = new StringBuffer(); + StringBuilder input = new StringBuilder(); int c = -1; boolean eol = false; diff -r 3e8e199e23b2 src/share/classes/java/net/IDN.java --- a/src/share/classes/java/net/IDN.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/IDN.java Mon May 12 07:17:17 2014 -0300 @@ -111,7 +111,7 @@ public static String toASCII(String input, int flag) { int p = 0, q = 0; - StringBuffer out = new StringBuffer(); + StringBuilder out = new StringBuilder(); if (isRootLabel(input)) { return "."; @@ -172,7 +172,7 @@ */ public static String toUnicode(String input, int flag) { int p = 0, q = 0; - StringBuffer out = new StringBuffer(); + StringBuilder out = new StringBuilder(); if (isRootLabel(input)) { return "."; diff -r 3e8e199e23b2 src/share/classes/java/net/SocketPermission.java --- a/src/share/classes/java/net/SocketPermission.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/SocketPermission.java Mon May 12 07:17:17 2014 -0300 @@ -733,7 +733,7 @@ InetAddress auth; try { - StringBuffer sb = new StringBuffer(39); + StringBuilder sb = new StringBuilder(39); for (int i = 15; i >= 0; i--) { sb.append(Integer.toHexString(((addr[i]) & 0x0f))); diff -r 3e8e199e23b2 src/share/classes/java/net/URI.java --- a/src/share/classes/java/net/URI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/URI.java Mon May 12 07:17:17 2014 -0300 @@ -1957,7 +1957,7 @@ private void defineString() { if (string != null) return; - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (scheme != null) { sb.append(scheme); sb.append(':'); @@ -2015,7 +2015,7 @@ if (i >= 0) path = base.substring(0, i + 1); } else { - StringBuffer sb = new StringBuffer(base.length() + cn); + StringBuilder sb = new StringBuilder(base.length() + cn); // 5.2 (6a) if (i >= 0) sb.append(base.substring(0, i + 1)); @@ -2778,7 +2778,7 @@ if (s.indexOf('%') < 0) return s; - StringBuffer sb = new StringBuffer(n); + StringBuilder sb = new StringBuilder(n); ByteBuffer bb = ByteBuffer.allocate(n); CharBuffer cb = CharBuffer.allocate(n); CharsetDecoder dec = ThreadLocalCoders.decoderFor("UTF-8") diff -r 3e8e199e23b2 src/share/classes/java/net/URISyntaxException.java --- a/src/share/classes/java/net/URISyntaxException.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/URISyntaxException.java Mon May 12 07:17:17 2014 -0300 @@ -121,7 +121,7 @@ * @return A string describing the parse error */ public String getMessage() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(getReason()); if (index > -1) { sb.append(" at index "); diff -r 3e8e199e23b2 src/share/classes/java/net/URLDecoder.java --- a/src/share/classes/java/net/URLDecoder.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/URLDecoder.java Mon May 12 07:17:17 2014 -0300 @@ -134,7 +134,7 @@ boolean needToChange = false; int numChars = s.length(); - StringBuffer sb = new StringBuffer(numChars > 500 ? numChars / 2 : numChars); + StringBuilder sb = new StringBuilder(numChars > 500 ? numChars / 2 : numChars); int i = 0; if (enc.length() == 0) { diff -r 3e8e199e23b2 src/share/classes/java/net/URLEncoder.java --- a/src/share/classes/java/net/URLEncoder.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/URLEncoder.java Mon May 12 07:17:17 2014 -0300 @@ -201,7 +201,7 @@ throws UnsupportedEncodingException { boolean needToChange = false; - StringBuffer out = new StringBuffer(s.length()); + StringBuilder out = new StringBuilder(s.length()); Charset charset; CharArrayWriter charArrayWriter = new CharArrayWriter(); diff -r 3e8e199e23b2 src/share/classes/java/net/URLStreamHandler.java --- a/src/share/classes/java/net/URLStreamHandler.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/net/URLStreamHandler.java Mon May 12 07:17:17 2014 -0300 @@ -486,7 +486,7 @@ if (u.getRef() != null) len += 1 + u.getRef().length(); - StringBuffer result = new StringBuffer(len); + StringBuilder result = new StringBuilder(len); result.append(u.getProtocol()); result.append(":"); if (u.getAuthority() != null && u.getAuthority().length() > 0) { diff -r 3e8e199e23b2 src/share/classes/java/nio/file/InvalidPathException.java --- a/src/share/classes/java/nio/file/InvalidPathException.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/nio/file/InvalidPathException.java Mon May 12 07:17:17 2014 -0300 @@ -117,7 +117,7 @@ * @return a string describing the error */ public String getMessage() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(getReason()); if (index > -1) { sb.append(" at index "); diff -r 3e8e199e23b2 src/share/classes/java/rmi/dgc/VMID.java --- a/src/share/classes/java/rmi/dgc/VMID.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/rmi/dgc/VMID.java Mon May 12 07:17:17 2014 -0300 @@ -120,15 +120,15 @@ * Return string representation of this VMID. */ public String toString() { - StringBuffer result = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (addr != null) for (int i = 0; i < addr.length; ++ i) { int x = addr[i] & 0xFF; - result.append((x < 0x10 ? "0" : "") + - Integer.toString(x, 16)); + sb.append((x < 0x10 ? "0" : "") + + Integer.toString(x, 16)); } - result.append(':'); - result.append(uid.toString()); - return result.toString(); + sb.append(':'); + sb.append(uid.toString()); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/java/security/CodeSigner.java --- a/src/share/classes/java/security/CodeSigner.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/CodeSigner.java Mon May 12 07:17:17 2014 -0300 @@ -154,7 +154,7 @@ * if present. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("("); sb.append("Signer: " + signerCertPath.getCertificates().get(0)); if (timestamp != null) { diff -r 3e8e199e23b2 src/share/classes/java/security/Timestamp.java --- a/src/share/classes/java/security/Timestamp.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/Timestamp.java Mon May 12 07:17:17 2014 -0300 @@ -141,7 +141,7 @@ * its signer's certificate. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("("); sb.append("timestamp: " + timestamp); List certs = signerCertPath.getCertificates(); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/CertPath.java --- a/src/share/classes/java/security/cert/CertPath.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/CertPath.java Mon May 12 07:17:17 2014 -0300 @@ -220,7 +220,7 @@ * @return a string representation of this certification path */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); Iterator stringIterator = getCertificates().iterator(); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/CollectionCertStoreParameters.java --- a/src/share/classes/java/security/cert/CollectionCertStoreParameters.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/CollectionCertStoreParameters.java Mon May 12 07:17:17 2014 -0300 @@ -132,7 +132,7 @@ * @return a formatted string describing the parameters */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("CollectionCertStoreParameters: [\n"); sb.append(" collection: " + coll + "\n"); sb.append("]"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/LDAPCertStoreParameters.java --- a/src/share/classes/java/security/cert/LDAPCertStoreParameters.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/LDAPCertStoreParameters.java Mon May 12 07:17:17 2014 -0300 @@ -138,7 +138,7 @@ * @return a formatted string describing the parameters */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("LDAPCertStoreParameters: [\n"); sb.append(" serverName: " + serverName + "\n"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/PKIXBuilderParameters.java --- a/src/share/classes/java/security/cert/PKIXBuilderParameters.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/PKIXBuilderParameters.java Mon May 12 07:17:17 2014 -0300 @@ -189,7 +189,7 @@ * @return a formatted string describing the parameters */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("[\n"); sb.append(super.toString()); sb.append(" Maximum Path Length: " + maxPathLength + "\n"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java --- a/src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java Mon May 12 07:17:17 2014 -0300 @@ -107,7 +107,7 @@ * {@code PKIXCertPathBuilderResult} */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("PKIXCertPathBuilderResult: [\n"); sb.append(" Certification Path: " + certPath + "\n"); sb.append(" Trust Anchor: " + getTrustAnchor().toString() + "\n"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java --- a/src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java Mon May 12 07:17:17 2014 -0300 @@ -148,7 +148,7 @@ * {@code PKIXCertPathValidatorResult} */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("PKIXCertPathValidatorResult: [\n"); sb.append(" Trust Anchor: " + trustAnchor.toString() + "\n"); sb.append(" Policy Tree: " + String.valueOf(policyTree) + "\n"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/PKIXParameters.java --- a/src/share/classes/java/security/cert/PKIXParameters.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/PKIXParameters.java Mon May 12 07:17:17 2014 -0300 @@ -693,7 +693,7 @@ * @return a formatted string describing the parameters. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("[\n"); /* start with trusted anchor info */ diff -r 3e8e199e23b2 src/share/classes/java/security/cert/PolicyQualifierInfo.java --- a/src/share/classes/java/security/cert/PolicyQualifierInfo.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/PolicyQualifierInfo.java Mon May 12 07:17:17 2014 -0300 @@ -161,7 +161,7 @@ if (pqiString != null) return pqiString; HexDumpEncoder enc = new HexDumpEncoder(); - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("PolicyQualifierInfo: [\n"); sb.append(" qualifierID: " + mId + "\n"); sb.append(" qualifier: " + diff -r 3e8e199e23b2 src/share/classes/java/security/cert/TrustAnchor.java --- a/src/share/classes/java/security/cert/TrustAnchor.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/TrustAnchor.java Mon May 12 07:17:17 2014 -0300 @@ -317,7 +317,7 @@ * @return a formatted string describing the {@code TrustAnchor} */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("[\n"); if (pubKey != null) { sb.append(" Trusted CA Public Key: " + pubKey.toString() + "\n"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/X509CRLSelector.java --- a/src/share/classes/java/security/cert/X509CRLSelector.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/X509CRLSelector.java Mon May 12 07:17:17 2014 -0300 @@ -566,7 +566,7 @@ * {@code X509CRLSelector}. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("X509CRLSelector: [\n"); if (issuerNames != null) { sb.append(" IssuerNames:\n"); diff -r 3e8e199e23b2 src/share/classes/java/security/cert/X509CertSelector.java --- a/src/share/classes/java/security/cert/X509CertSelector.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/security/cert/X509CertSelector.java Mon May 12 07:17:17 2014 -0300 @@ -1811,7 +1811,7 @@ * {@code CertSelector} */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("X509CertSelector: [\n"); if (x509Cert != null) { sb.append(" Certificate: " + x509Cert.toString() + "\n"); diff -r 3e8e199e23b2 src/share/classes/java/text/AttributedString.java --- a/src/share/classes/java/text/AttributedString.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/text/AttributedString.java Mon May 12 07:17:17 2014 -0300 @@ -243,11 +243,11 @@ throw new IllegalArgumentException("Invalid substring range"); // Copy the given string - StringBuffer textBuffer = new StringBuffer(); + StringBuilder textBuilder = new StringBuilder(); text.setIndex(beginIndex); for (char c = text.current(); text.getIndex() < endIndex; c = text.next()) - textBuffer.append(c); - this.text = textBuffer.toString(); + textBuilder.append(c); + this.text = textBuilder.toString(); if (beginIndex == endIndex) return; diff -r 3e8e199e23b2 src/share/classes/java/text/ChoiceFormat.java --- a/src/share/classes/java/text/ChoiceFormat.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/text/ChoiceFormat.java Mon May 12 07:17:17 2014 -0300 @@ -259,7 +259,7 @@ * @return the pattern string */ public String toPattern() { - StringBuffer result = new StringBuffer(); + StringBuilder result = new StringBuilder(); for (int i = 0; i < choiceLimits.length; ++i) { if (i != 0) { result.append('|'); diff -r 3e8e199e23b2 src/share/classes/java/util/Properties.java --- a/src/share/classes/java/util/Properties.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/java/util/Properties.java Mon May 12 07:17:17 2014 -0300 @@ -602,7 +602,7 @@ if (bufLen < 0) { bufLen = Integer.MAX_VALUE; } - StringBuffer outBuffer = new StringBuffer(bufLen); + StringBuilder outBuffer = new StringBuilder(bufLen); for(int x=0; x= 0) { sb.append(" near index "); diff -r 3e8e199e23b2 src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java --- a/src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java Mon May 12 07:17:17 2014 -0300 @@ -289,7 +289,7 @@ } public String readLine() throws IOException { - StringBuffer input = new StringBuffer(); + StringBuilder input = new StringBuilder(); int c = -1; boolean eol = false; diff -r 3e8e199e23b2 src/share/classes/javax/naming/BinaryRefAddr.java --- a/src/share/classes/javax/naming/BinaryRefAddr.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/naming/BinaryRefAddr.java Mon May 12 07:17:17 2014 -0300 @@ -165,7 +165,7 @@ * @return The non-null string representation of this address. */ public String toString(){ - StringBuffer str = new StringBuffer("Address Type: " + addrType + "\n"); + StringBuilder str = new StringBuilder("Address Type: " + addrType + "\n"); str.append("AddressContents: "); for (int i = 0; i"i-j" otherwise. */ public String toString() { - StringBuffer result = new StringBuffer(); + StringBuilder result = new StringBuilder(); int n = members.length; for (int i = 0; i < n; i++) { if (i > 0) { diff -r 3e8e199e23b2 src/share/classes/javax/print/attribute/Size2DSyntax.java --- a/src/share/classes/javax/print/attribute/Size2DSyntax.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/print/attribute/Size2DSyntax.java Mon May 12 07:17:17 2014 -0300 @@ -257,7 +257,7 @@ * (unchecked exception) Thrown if {@code units < 1}. */ public String toString(int units, String unitsName) { - StringBuffer result = new StringBuffer(); + StringBuilder result = new StringBuilder(); result.append(getX (units)); result.append('x'); result.append(getY (units)); @@ -312,12 +312,12 @@ * The values are reported in the internal units of micrometers. */ public String toString() { - StringBuffer result = new StringBuffer(); - result.append(x); - result.append('x'); - result.append(y); - result.append(" um"); - return result.toString(); + StringBuilder sb = new StringBuilder(); + sb.append(x); + sb.append('x'); + sb.append(y); + sb.append(" um"); + return sb.toString(); } /** diff -r 3e8e199e23b2 src/share/classes/javax/security/auth/kerberos/KerberosTicket.java --- a/src/share/classes/javax/security/auth/kerberos/KerberosTicket.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/security/auth/kerberos/KerberosTicket.java Mon May 12 07:17:17 2014 -0300 @@ -636,11 +636,11 @@ public String toString() { if (destroyed) throw new IllegalStateException("This ticket is no longer valid"); - StringBuffer caddrBuf = new StringBuffer(); + StringBuilder caddrString = new StringBuilder(); if (clientAddresses != null) { for (int i = 0; i < clientAddresses.length; i++) { - caddrBuf.append("clientAddresses[" + i + "] = " + - clientAddresses[i].toString()); + caddrString.append("clientAddresses[" + i + "] = " + + clientAddresses[i].toString()); } } return ("Ticket (hex) = " + "\n" + @@ -660,7 +660,7 @@ "End Time = " + endTime.toString() + "\n" + "Renew Till = " + String.valueOf(renewTill) + "\n" + "Client Addresses " + - (clientAddresses == null ? " Null " : caddrBuf.toString() + + (clientAddresses == null ? " Null " : caddrString.toString() + "\n")); } diff -r 3e8e199e23b2 src/share/classes/javax/sound/sampled/CompoundControl.java --- a/src/share/classes/javax/sound/sampled/CompoundControl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/sound/sampled/CompoundControl.java Mon May 12 07:17:17 2014 -0300 @@ -94,18 +94,18 @@ */ public String toString() { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < controls.length; i++) { if (i != 0) { - buf.append(", "); + sb.append(", "); if ((i + 1) == controls.length) { - buf.append("and "); + sb.append("and "); } } - buf.append(controls[i].getType()); + sb.append(controls[i].getType()); } - return new String(getType() + " Control containing " + buf + " Controls."); + return new String(getType() + " Control containing " + sb + " Controls."); } diff -r 3e8e199e23b2 src/share/classes/javax/sound/sampled/DataLine.java --- a/src/share/classes/javax/sound/sampled/DataLine.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/sound/sampled/DataLine.java Mon May 12 07:17:17 2014 -0300 @@ -471,23 +471,23 @@ */ public String toString() { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if ( (formats.length == 1) && (formats[0] != null) ) { - buf.append(" supporting format " + formats[0]); + sb.append(" supporting format " + formats[0]); } else if (getFormats().length > 1) { - buf.append(" supporting " + getFormats().length + " audio formats"); + sb.append(" supporting " + getFormats().length + " audio formats"); } if ( (minBufferSize != AudioSystem.NOT_SPECIFIED) && (maxBufferSize != AudioSystem.NOT_SPECIFIED) ) { - buf.append(", and buffers of " + minBufferSize + " to " + maxBufferSize + " bytes"); + sb.append(", and buffers of " + minBufferSize + " to " + maxBufferSize + " bytes"); } else if ( (minBufferSize != AudioSystem.NOT_SPECIFIED) && (minBufferSize > 0) ) { - buf.append(", and buffers of at least " + minBufferSize + " bytes"); + sb.append(", and buffers of at least " + minBufferSize + " bytes"); } else if (maxBufferSize != AudioSystem.NOT_SPECIFIED) { - buf.append(", and buffers of up to " + minBufferSize + " bytes"); + sb.append(", and buffers of up to " + minBufferSize + " bytes"); } - return new String(super.toString() + buf); + return new String(super.toString() + sb); } } // class Info diff -r 3e8e199e23b2 src/share/classes/javax/swing/JColorChooser.java --- a/src/share/classes/javax/swing/JColorChooser.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/JColorChooser.java Mon May 12 07:17:17 2014 -0300 @@ -542,7 +542,7 @@ * @return a string representation of this JColorChooser */ protected String paramString() { - StringBuffer chooserPanelsString = new StringBuffer(""); + StringBuilder chooserPanelsString = new StringBuilder(""); for (int i=0; i 1) { - buf.delete(length-2, length); + sb.delete(length-2, length); } - buf.append("}"); - return buf.toString(); + sb.append("}"); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/javax/swing/RepaintManager.java --- a/src/share/classes/javax/swing/RepaintManager.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/RepaintManager.java Mon May 12 07:17:17 2014 -0300 @@ -975,7 +975,7 @@ * @return a String representation of this object */ public synchronized String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if(dirtyComponents != null) sb.append("" + dirtyComponents); return sb.toString(); diff -r 3e8e199e23b2 src/share/classes/javax/swing/event/TreeModelEvent.java --- a/src/share/classes/javax/swing/event/TreeModelEvent.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/event/TreeModelEvent.java Mon May 12 07:17:17 2014 -0300 @@ -292,24 +292,24 @@ * @return a String representation of this object */ public String toString() { - StringBuffer retBuffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - retBuffer.append(getClass().getName() + " " + - Integer.toString(hashCode())); + sb.append(getClass().getName() + " " + + Integer.toString(hashCode())); if(path != null) - retBuffer.append(" path " + path); + sb.append(" path " + path); if(childIndices != null) { - retBuffer.append(" indices [ "); + sb.append(" indices [ "); for(int counter = 0; counter < childIndices.length; counter++) - retBuffer.append(Integer.toString(childIndices[counter])+ " "); - retBuffer.append("]"); + sb.append(Integer.toString(childIndices[counter])+ " "); + sb.append("]"); } if(children != null) { - retBuffer.append(" children [ "); + sb.append(" children [ "); for(int counter = 0; counter < children.length; counter++) - retBuffer.append(children[counter] + " "); - retBuffer.append("]"); + sb.append(children[counter] + " "); + sb.append("]"); } - return retBuffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java --- a/src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Mon May 12 07:17:17 2014 -0300 @@ -1322,8 +1322,8 @@ return null; } - StringBuffer plainBuf = new StringBuffer(); - StringBuffer htmlBuf = new StringBuffer(); + StringBuilder plainBuf = new StringBuilder(); + StringBuilder htmlBuf = new StringBuilder(); htmlBuf.append("\n\n
    \n"); diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/basic/BasicListUI.java --- a/src/share/classes/javax/swing/plaf/basic/BasicListUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/basic/BasicListUI.java Mon May 12 07:17:17 2014 -0300 @@ -2855,23 +2855,23 @@ return null; } - StringBuffer plainBuf = new StringBuffer(); - StringBuffer htmlBuf = new StringBuffer(); + StringBuilder plainStr = new StringBuilder(); + StringBuilder htmlStr = new StringBuilder(); - htmlBuf.append("\n\n
      \n"); + htmlStr.append("\n\n
        \n"); for (int i = 0; i < values.length; i++) { Object obj = values[i]; String val = ((obj == null) ? "" : obj.toString()); - plainBuf.append(val + "\n"); - htmlBuf.append("
      • " + val + "\n"); + plainStr.append(val + "\n"); + htmlStr.append("
      • " + val + "\n"); } // remove the last newline - plainBuf.deleteCharAt(plainBuf.length() - 1); - htmlBuf.append("
      \n\n"); + plainStr.deleteCharAt(plainStr.length() - 1); + htmlStr.append("
    \n\n"); - return new BasicTransferable(plainBuf.toString(), htmlBuf.toString()); + return new BasicTransferable(plainStr.toString(), htmlStr.toString()); } return null; diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/basic/BasicTableUI.java --- a/src/share/classes/javax/swing/plaf/basic/BasicTableUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/basic/BasicTableUI.java Mon May 12 07:17:17 2014 -0300 @@ -2182,29 +2182,29 @@ return null; } - StringBuffer plainBuf = new StringBuffer(); - StringBuffer htmlBuf = new StringBuffer(); + StringBuilder plainStr = new StringBuilder(); + StringBuilder htmlStr = new StringBuilder(); - htmlBuf.append("\n\n\n"); + htmlStr.append("\n\n
    \n"); for (int row = 0; row < rows.length; row++) { - htmlBuf.append("\n"); + htmlStr.append("\n"); for (int col = 0; col < cols.length; col++) { Object obj = table.getValueAt(rows[row], cols[col]); String val = ((obj == null) ? "" : obj.toString()); - plainBuf.append(val + "\t"); - htmlBuf.append(" \n"); + plainStr.append(val + "\t"); + htmlStr.append(" \n"); } // we want a newline at the end of each line and not a tab - plainBuf.deleteCharAt(plainBuf.length() - 1).append("\n"); - htmlBuf.append("\n"); + plainStr.deleteCharAt(plainStr.length() - 1).append("\n"); + htmlStr.append("\n"); } // remove the last newline - plainBuf.deleteCharAt(plainBuf.length() - 1); - htmlBuf.append("
    " + val + "" + val + "
    \n\n"); + plainStr.deleteCharAt(plainStr.length() - 1); + htmlStr.append("\n\n"); - return new BasicTransferable(plainBuf.toString(), htmlBuf.toString()); + return new BasicTransferable(plainStr.toString(), htmlStr.toString()); } return null; diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java --- a/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Mon May 12 07:17:17 2014 -0300 @@ -3213,10 +3213,10 @@ return null; } - StringBuffer plainBuf = new StringBuffer(); - StringBuffer htmlBuf = new StringBuffer(); - - htmlBuf.append("\n\n
      \n"); + StringBuilder plainStr = new StringBuilder(); + StringBuilder htmlStr = new StringBuilder(); + + htmlStr.append("\n\n
        \n"); TreeModel model = tree.getModel(); TreePath lastPath = null; @@ -3227,17 +3227,17 @@ boolean leaf = model.isLeaf(node); String label = getDisplayString(path, true, leaf); - plainBuf.append(label + "\n"); - htmlBuf.append("
      • " + label + "\n"); + plainStr.append(label + "\n"); + htmlStr.append("
      • " + label + "\n"); } // remove the last newline - plainBuf.deleteCharAt(plainBuf.length() - 1); - htmlBuf.append("
      \n\n"); + plainStr.deleteCharAt(plainStr.length() - 1); + htmlStr.append("
    \n\n"); tree = null; - return new BasicTransferable(plainBuf.toString(), htmlBuf.toString()); + return new BasicTransferable(plainStr.toString(), htmlStr.toString()); } return null; diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java --- a/src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java Mon May 12 07:17:17 2014 -0300 @@ -618,20 +618,20 @@ } private String fileNameString(File[] files) { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; files != null && i < files.length; i++) { if (i > 0) { - buf.append(" "); + sb.append(" "); } if (files.length > 1) { - buf.append("\""); + sb.append("\""); } - buf.append(fileNameString(files[i])); + sb.append(fileNameString(files[i])); if (files.length > 1) { - buf.append("\""); + sb.append("\""); } } - return buf.toString(); + return sb.toString(); } /* The following methods are used by the PropertyChange Listener */ diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/nimbus/State.java --- a/src/share/classes/javax/swing/plaf/nimbus/State.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/nimbus/State.java Mon May 12 07:17:17 2014 -0300 @@ -179,35 +179,35 @@ } private static String toString(int state) { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if ((state & SynthConstants.DEFAULT) == SynthConstants.DEFAULT) { - buffer.append("Default"); + sb.append("Default"); } if ((state & SynthConstants.DISABLED) == SynthConstants.DISABLED) { - if (buffer.length() > 0) buffer.append("+"); - buffer.append("Disabled"); + if (sb.length() > 0) sb.append("+"); + sb.append("Disabled"); } if ((state & SynthConstants.ENABLED) == SynthConstants.ENABLED) { - if (buffer.length() > 0) buffer.append("+"); - buffer.append("Enabled"); + if (sb.length() > 0) sb.append("+"); + sb.append("Enabled"); } if ((state & SynthConstants.FOCUSED) == SynthConstants.FOCUSED) { - if (buffer.length() > 0) buffer.append("+"); - buffer.append("Focused"); + if (sb.length() > 0) sb.append("+"); + sb.append("Focused"); } if ((state & SynthConstants.MOUSE_OVER) == SynthConstants.MOUSE_OVER) { - if (buffer.length() > 0) buffer.append("+"); - buffer.append("MouseOver"); + if (sb.length() > 0) sb.append("+"); + sb.append("MouseOver"); } if ((state & SynthConstants.PRESSED) == SynthConstants.PRESSED) { - if (buffer.length() > 0) buffer.append("+"); - buffer.append("Pressed"); + if (sb.length() > 0) sb.append("+"); + sb.append("Pressed"); } if ((state & SynthConstants.SELECTED) == SynthConstants.SELECTED) { - if (buffer.length() > 0) buffer.append("+"); - buffer.append("Selected"); + if (sb.length() > 0) sb.append("+"); + sb.append("Selected"); } - return buffer.toString(); + return sb.toString(); } } } diff -r 3e8e199e23b2 src/share/classes/javax/swing/plaf/synth/ParsedSynthStyle.java --- a/src/share/classes/javax/swing/plaf/synth/ParsedSynthStyle.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/plaf/synth/ParsedSynthStyle.java Mon May 12 07:17:17 2014 -0300 @@ -156,7 +156,7 @@ } public String toString() { - StringBuffer text = new StringBuffer(super.toString()); + StringBuilder text = new StringBuilder(super.toString()); if (_painters != null) { text.append(",painters=["); for (int i = 0; i < +_painters.length; i++) { @@ -208,7 +208,7 @@ } public String toString() { - StringBuffer text = new StringBuffer(super.toString()); + StringBuilder text = new StringBuilder(super.toString()); text.append(",painters=["); if (_painterInfo != null) { for (int i = 0; i < +_painterInfo.length; i++) { diff -r 3e8e199e23b2 src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java --- a/src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Mon May 12 07:17:17 2014 -0300 @@ -1137,23 +1137,23 @@ */ public String toString() { int selCount = getSelectionCount(); - StringBuffer retBuffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); int[] rows; if(rowMapper != null) rows = rowMapper.getRowsForPaths(selection); else rows = null; - retBuffer.append(getClass().getName() + " " + hashCode() + " [ "); + sb.append(getClass().getName() + " " + hashCode() + " [ "); for(int counter = 0; counter < selCount; counter++) { if(rows != null) - retBuffer.append(selection[counter].toString() + "@" + + sb.append(selection[counter].toString() + "@" + Integer.toString(rows[counter])+ " "); else - retBuffer.append(selection[counter].toString() + " "); + sb.append(selection[counter].toString() + " "); } - retBuffer.append("]"); - return retBuffer.toString(); + sb.append("]"); + return sb.toString(); } /** diff -r 3e8e199e23b2 src/share/classes/javax/swing/tree/TreePath.java --- a/src/share/classes/javax/swing/tree/TreePath.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/javax/swing/tree/TreePath.java Mon May 12 07:17:17 2014 -0300 @@ -347,7 +347,7 @@ * @return a String representation of this object */ public String toString() { - StringBuffer tempSpot = new StringBuffer("["); + StringBuilder tempSpot = new StringBuilder("["); for(int counter = 0, maxCounter = getPathCount();counter < maxCounter; counter++) { diff -r 3e8e199e23b2 src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java Mon May 12 07:17:17 2014 -0300 @@ -1987,43 +1987,43 @@ stackMap.putByte(v); } } else { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); d >>= 28; while (d-- > 0) { - buf.append('['); + sb.append('['); } if ((t & Frame.BASE_KIND) == Frame.OBJECT) { - buf.append('L'); - buf.append(cw.typeTable[t & Frame.BASE_VALUE].strVal1); - buf.append(';'); + sb.append('L'); + sb.append(cw.typeTable[t & Frame.BASE_VALUE].strVal1); + sb.append(';'); } else { switch (t & 0xF) { case 1: - buf.append('I'); + sb.append('I'); break; case 2: - buf.append('F'); + sb.append('F'); break; case 3: - buf.append('D'); + sb.append('D'); break; case 9: - buf.append('Z'); + sb.append('Z'); break; case 10: - buf.append('B'); + sb.append('B'); break; case 11: - buf.append('C'); + sb.append('C'); break; case 12: - buf.append('S'); + sb.append('S'); break; default: - buf.append('J'); + sb.append('J'); } } - stackMap.putByte(7).putShort(cw.newClass(buf.toString())); + stackMap.putByte(7).putShort(cw.newClass(sb.toString())); } } } diff -r 3e8e199e23b2 src/share/classes/jdk/internal/org/objectweb/asm/Type.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/Type.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/Type.java Mon May 12 07:17:17 2014 -0300 @@ -585,11 +585,11 @@ case DOUBLE: return "double"; case ARRAY: - StringBuffer b = new StringBuffer(getElementType().getClassName()); + StringBuilder sb = new StringBuilder(getElementType().getClassName()); for (int i = getDimensions(); i > 0; --i) { - b.append("[]"); + sb.append("[]"); } - return b.toString(); + return sb.toString(); case OBJECT: return new String(buf, off, len).replace('/', '.'); default: diff -r 3e8e199e23b2 src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java Mon May 12 07:17:17 2014 -0300 @@ -205,7 +205,7 @@ } String returnType = method.substring(0, space); String methodName = method.substring(space + 1, start - 1).trim(); - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append('('); int p; do { @@ -229,7 +229,7 @@ return type; } - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); int index = 0; while ((index = type.indexOf("[]", index) + 1) > 0) { sb.append('['); diff -r 3e8e199e23b2 src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java Mon May 12 07:17:17 2014 -0300 @@ -147,17 +147,17 @@ } Type[] args = Type.getArgumentTypes(desc); - StringBuffer s = new StringBuffer("("); + StringBuilder sb = new StringBuilder("("); for (int i = 0; i < args.length; i++) { - s.append(mapDesc(args[i].getDescriptor())); + sb.append(mapDesc(args[i].getDescriptor())); } Type returnType = Type.getReturnType(desc); if (returnType == Type.VOID_TYPE) { - s.append(")V"); - return s.toString(); + sb.append(")V"); + return sb.toString(); } - s.append(')').append(mapDesc(returnType.getDescriptor())); - return s.toString(); + sb.append(')').append(mapDesc(returnType.getDescriptor())); + return sb.toString(); } public Object mapValue(Object value) { diff -r 3e8e199e23b2 src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java Mon May 12 07:17:17 2014 -0300 @@ -754,14 +754,14 @@ */ @Override public String toString() { - StringBuffer b = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < getLocals(); ++i) { - b.append(getLocal(i)); + sb.append(getLocal(i)); } - b.append(' '); + sb.append(' '); for (int i = 0; i < getStackSize(); ++i) { - b.append(getStack(i).toString()); + sb.append(getStack(i).toString()); } - return b.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java --- a/src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java Mon May 12 07:17:17 2014 -0300 @@ -298,26 +298,26 @@ for (int j = 0; j < method.instructions.size(); ++j) { method.instructions.get(j).accept(mv); - StringBuffer s = new StringBuffer(); + StringBuilder sb = new StringBuilder(); Frame f = frames[j]; if (f == null) { - s.append('?'); + sb.append('?'); } else { for (int k = 0; k < f.getLocals(); ++k) { - s.append(getShortName(f.getLocal(k).toString())) + sb.append(getShortName(f.getLocal(k).toString())) .append(' '); } - s.append(" : "); + sb.append(" : "); for (int k = 0; k < f.getStackSize(); ++k) { - s.append(getShortName(f.getStack(k).toString())) + sb.append(getShortName(f.getStack(k).toString())) .append(' '); } } - while (s.length() < method.maxStack + method.maxLocals + 1) { - s.append(' '); + while (sb.length() < method.maxStack + method.maxLocals + 1) { + sb.append(' '); } pw.print(Integer.toString(j + 100000).substring(1)); - pw.print(" " + s + " : " + t.text.get(t.text.size() - 1)); + pw.print(" " + sb + " : " + t.text.get(t.text.size() - 1)); } for (int j = 0; j < method.tryCatchBlocks.size(); ++j) { method.tryCatchBlocks.get(j).accept(mv); diff -r 3e8e199e23b2 src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java --- a/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java Mon May 12 07:17:17 2014 -0300 @@ -118,7 +118,7 @@ } ExcC14NParameterSpec params = (ExcC14NParameterSpec)spec; - StringBuffer prefixListAttr = new StringBuffer(""); + StringBuilder prefixListAttr = new StringBuilder(""); @SuppressWarnings("unchecked") List prefixList = params.getPrefixList(); for (int i = 0, size = prefixList.size(); i < size; i++) { diff -r 3e8e199e23b2 src/share/classes/sun/applet/AppletViewer.java --- a/src/share/classes/sun/applet/AppletViewer.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/applet/AppletViewer.java Mon May 12 07:17:17 2014 -0300 @@ -1000,15 +1000,15 @@ * Scan identifier */ public static String scanIdentifier(Reader in) throws IOException { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); while (true) { if (((c >= 'a') && (c <= 'z')) || ((c >= 'A') && (c <= 'Z')) || ((c >= '0') && (c <= '9')) || (c == '_')) { - buf.append((char)c); + sb.append((char) c); c = in.read(); } else { - return buf.toString(); + return sb.toString(); } } } @@ -1031,19 +1031,19 @@ quote = c; c = in.read(); } - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); while ((c > 0) && (((quote < 0) && (c != ' ') && (c != '\t') && (c != '\n') && (c != '\r') && (c != '>')) || ((quote >= 0) && (c != quote)))) { - buf.append((char)c); + sb.append((char) c); c = in.read(); } if (c == quote) { c = in.read(); } skipSpace(in); - val = buf.toString(); + val = sb.toString(); } //statusMsgStream.println("PUT " + att + " = '" + val + "'"); if (! val.equals("")) { diff -r 3e8e199e23b2 src/share/classes/sun/font/Decoration.java --- a/src/share/classes/sun/font/Decoration.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/font/Decoration.java Mon May 12 07:17:17 2014 -0300 @@ -428,17 +428,17 @@ public String toString() { - StringBuffer buf = new StringBuffer(); - buf.append(super.toString()); - buf.append("["); - if (fgPaint != null) buf.append("fgPaint: " + fgPaint); - if (bgPaint != null) buf.append(" bgPaint: " + bgPaint); - if (swapColors) buf.append(" swapColors: true"); - if (strikethrough) buf.append(" strikethrough: true"); - if (stdUnderline != null) buf.append(" stdUnderline: " + stdUnderline); - if (imUnderline != null) buf.append(" imUnderline: " + imUnderline); - buf.append("]"); - return buf.toString(); + StringBuilder sb = new StringBuilder(); + sb.append(super.toString()); + sb.append("["); + if (fgPaint != null) sb.append("fgPaint: " + fgPaint); + if (bgPaint != null) sb.append(" bgPaint: " + bgPaint); + if (swapColors) sb.append(" swapColors: true"); + if (strikethrough) sb.append(" strikethrough: true"); + if (stdUnderline != null) sb.append(" stdUnderline: " + stdUnderline); + if (imUnderline != null) sb.append(" imUnderline: " + imUnderline); + sb.append("]"); + return sb.toString(); } } } diff -r 3e8e199e23b2 src/share/classes/sun/font/ExtendedTextSourceLabel.java --- a/src/share/classes/sun/font/ExtendedTextSourceLabel.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/font/ExtendedTextSourceLabel.java Mon May 12 07:17:17 2014 -0300 @@ -896,31 +896,31 @@ if (true) { return source.toString(TextSource.WITHOUT_CONTEXT); } - StringBuffer buf = new StringBuffer(); - buf.append(super.toString()); - buf.append("[source:"); - buf.append(source.toString(TextSource.WITHOUT_CONTEXT)); - buf.append(", lb:"); - buf.append(lb); - buf.append(", ab:"); - buf.append(ab); - buf.append(", vb:"); - buf.append(vb); - buf.append(", gv:"); - buf.append(gv); - buf.append(", ci: "); + StringBuilder sb = new StringBuilder(); + sb.append(super.toString()); + sb.append("[source:"); + sb.append(source.toString(TextSource.WITHOUT_CONTEXT)); + sb.append(", lb:"); + sb.append(lb); + sb.append(", ab:"); + sb.append(ab); + sb.append(", vb:"); + sb.append(vb); + sb.append(", gv:"); + sb.append(gv); + sb.append(", ci: "); if (charinfo == null) { - buf.append("null"); + sb.append("null"); } else { - buf.append(charinfo[0]); + sb.append(charinfo[0]); for (int i = 1; i < charinfo.length;) { - buf.append(i % numvals == 0 ? "; " : ", "); - buf.append(charinfo[i]); + sb.append(i % numvals == 0 ? "; " : ", "); + sb.append(charinfo[i]); } } - buf.append("]"); + sb.append("]"); - return buf.toString(); + return sb.toString(); } //public static ExtendedTextLabel create(TextSource source) { diff -r 3e8e199e23b2 src/share/classes/sun/font/StandardTextSource.java --- a/src/share/classes/sun/font/StandardTextSource.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/font/StandardTextSource.java Mon May 12 07:17:17 2014 -0300 @@ -210,16 +210,16 @@ } public String toString(boolean withContext) { - StringBuffer buf = new StringBuffer(super.toString()); - buf.append("[start:"); - buf.append(start); - buf.append(", len:" ); - buf.append(len); - buf.append(", cstart:"); - buf.append(cstart); - buf.append(", clen:" ); - buf.append(clen); - buf.append(", chars:\""); + StringBuilder sb = new StringBuilder(super.toString()); + sb.append("[start:"); + sb.append(start); + sb.append(", len:" ); + sb.append(len); + sb.append(", cstart:"); + sb.append(cstart); + sb.append(", clen:" ); + sb.append(clen); + sb.append(", chars:\""); int chStart, chLimit; if (withContext == WITH_CONTEXT) { chStart = cstart; @@ -231,23 +231,23 @@ } for (int i = chStart; i < chLimit; ++i) { if (i > chStart) { - buf.append(" "); + sb.append(" "); } - buf.append(Integer.toHexString(chars[i])); + sb.append(Integer.toHexString(chars[i])); } - buf.append("\""); - buf.append(", level:"); - buf.append(level); - buf.append(", flags:"); - buf.append(flags); - buf.append(", font:"); - buf.append(font); - buf.append(", frc:"); - buf.append(frc); - buf.append(", cm:"); - buf.append(cm); - buf.append("]"); + sb.append("\""); + sb.append(", level:"); + sb.append(level); + sb.append(", flags:"); + sb.append(flags); + sb.append(", font:"); + sb.append(font); + sb.append(", frc:"); + sb.append(frc); + sb.append(", cm:"); + sb.append(cm); + sb.append("]"); - return buf.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/font/Type1Font.java --- a/src/share/classes/sun/font/Type1Font.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/font/Type1Font.java Mon May 12 07:17:17 2014 -0300 @@ -529,7 +529,7 @@ } private String expandName(String s, boolean tryExpandAbbreviations) { - StringBuffer res = new StringBuffer(s.length() + 10); + StringBuilder res = new StringBuilder(s.length() + 10); int start=0, end; while(start < s.length()) { diff -r 3e8e199e23b2 src/share/classes/sun/java2d/opengl/OGLContext.java --- a/src/share/classes/sun/java2d/opengl/OGLContext.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/java2d/opengl/OGLContext.java Mon May 12 07:17:17 2014 -0300 @@ -201,29 +201,29 @@ @Override public String toString() { - StringBuffer buf = new StringBuffer(super.toString()); + StringBuilder sb = new StringBuilder(super.toString()); if ((caps & CAPS_EXT_FBOBJECT) != 0) { - buf.append("CAPS_EXT_FBOBJECT|"); + sb.append("CAPS_EXT_FBOBJECT|"); } if ((caps & CAPS_STORED_ALPHA) != 0) { - buf.append("CAPS_STORED_ALPHA|"); + sb.append("CAPS_STORED_ALPHA|"); } if ((caps & CAPS_DOUBLEBUFFERED) != 0) { - buf.append("CAPS_DOUBLEBUFFERED|"); + sb.append("CAPS_DOUBLEBUFFERED|"); } if ((caps & CAPS_EXT_LCD_SHADER) != 0) { - buf.append("CAPS_EXT_LCD_SHADER|"); + sb.append("CAPS_EXT_LCD_SHADER|"); } if ((caps & CAPS_EXT_BIOP_SHADER) != 0) { - buf.append("CAPS_BIOP_SHADER|"); + sb.append("CAPS_BIOP_SHADER|"); } if ((caps & CAPS_EXT_GRAD_SHADER) != 0) { - buf.append("CAPS_EXT_GRAD_SHADER|"); + sb.append("CAPS_EXT_GRAD_SHADER|"); } if ((caps & CAPS_EXT_TEXRECT) != 0) { - buf.append("CAPS_EXT_TEXRECT|"); + sb.append("CAPS_EXT_TEXRECT|"); } - return buf.toString(); + return sb.toString(); } } } diff -r 3e8e199e23b2 src/share/classes/sun/java2d/pipe/Region.java --- a/src/share/classes/sun/java2d/pipe/Region.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/java2d/pipe/Region.java Mon May 12 07:17:17 2014 -0300 @@ -1277,7 +1277,7 @@ } public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("Region[["); sb.append(lox); sb.append(", "); diff -r 3e8e199e23b2 src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java --- a/src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java Mon May 12 07:17:17 2014 -0300 @@ -93,37 +93,37 @@ @Override public String toString() { - StringBuffer buf = - new StringBuffer("ContextCapabilities: adapter=" + + StringBuilder sb = + new StringBuilder("ContextCapabilities: adapter=" + adapterId+", caps="); if (caps == CAPS_EMPTY) { - buf.append("CAPS_EMPTY"); + sb.append("CAPS_EMPTY"); } else { if ((caps & CAPS_RT_PLAIN_ALPHA) != 0) { - buf.append("CAPS_RT_PLAIN_ALPHA|"); + sb.append("CAPS_RT_PLAIN_ALPHA|"); } if ((caps & CAPS_RT_TEXTURE_ALPHA) != 0) { - buf.append("CAPS_RT_TEXTURE_ALPHA|"); + sb.append("CAPS_RT_TEXTURE_ALPHA|"); } if ((caps & CAPS_RT_TEXTURE_OPAQUE) != 0) { - buf.append("CAPS_RT_TEXTURE_OPAQUE|"); + sb.append("CAPS_RT_TEXTURE_OPAQUE|"); } if ((caps & CAPS_MULTITEXTURE) != 0) { - buf.append("CAPS_MULTITEXTURE|"); + sb.append("CAPS_MULTITEXTURE|"); } if ((caps & CAPS_TEXNONPOW2) != 0) { - buf.append("CAPS_TEXNONPOW2|"); + sb.append("CAPS_TEXNONPOW2|"); } if ((caps & CAPS_TEXNONSQUARE) != 0) { - buf.append("CAPS_TEXNONSQUARE|"); + sb.append("CAPS_TEXNONSQUARE|"); } if ((caps & CAPS_PS20) != 0) { - buf.append("CAPS_PS20|"); + sb.append("CAPS_PS20|"); } if ((caps & CAPS_PS30) != 0) { - buf.append("CAPS_PS30|"); + sb.append("CAPS_PS30|"); } } - return buf.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/jvmstat/monitor/HostIdentifier.java --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Mon May 12 07:17:17 2014 -0300 @@ -358,7 +358,7 @@ URI nuri = null; - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(scheme).append("://"); diff -r 3e8e199e23b2 src/share/classes/sun/jvmstat/monitor/MonitoredHost.java --- a/src/share/classes/sun/jvmstat/monitor/MonitoredHost.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/MonitoredHost.java Mon May 12 07:17:17 2014 -0300 @@ -257,7 +257,7 @@ throws MonitorException { String hostname = hostId.getHost(); String scheme = hostId.getScheme(); - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); assert hostname != null; diff -r 3e8e199e23b2 src/share/classes/sun/jvmstat/monitor/VmIdentifier.java --- a/src/share/classes/sun/jvmstat/monitor/VmIdentifier.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/VmIdentifier.java Mon May 12 07:17:17 2014 -0300 @@ -255,7 +255,7 @@ * a MonitorException in a future version. */ public HostIdentifier getHostIdentifier() throws URISyntaxException { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (getScheme() != null) { sb.append(getScheme()).append(":"); } diff -r 3e8e199e23b2 src/share/classes/sun/management/Agent.java --- a/src/share/classes/sun/management/Agent.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/management/Agent.java Mon May 12 07:17:17 2014 -0300 @@ -401,7 +401,7 @@ if (home == null) { throw new Error("Can't find java.home ??"); } - StringBuffer defaultFileName = new StringBuffer(home); + StringBuilder defaultFileName = new StringBuilder(home); defaultFileName.append(File.separator).append("lib"); defaultFileName.append(File.separator).append("management"); defaultFileName.append(File.separator).append("management.properties"); @@ -495,7 +495,7 @@ if (params == null || params.length == 0) { error(key); } else { - StringBuffer message = new StringBuffer(params[0]); + StringBuilder message = new StringBuilder(params[0]); for (int i = 1; i < params.length; i++) { message.append(" " + params[i]); } diff -r 3e8e199e23b2 src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java Mon May 12 07:17:17 2014 -0300 @@ -311,19 +311,19 @@ StackTraceElement[] stackTrace = info.getStackTrace(); //We append the stack trace in a buffer // XXX Revisit: should check isDebugOn() - StringBuffer b = new StringBuffer(); + StringBuilder sb = new StringBuilder(); final int stackSize = stackTrace.length; log.debug("getJvmThreadInstStackTrace", "Stack size : " + stackSize); for(int i = 0; i < stackSize; i++) { log.debug("getJvmThreadInstStackTrace", "Append " + stackTrace[i].toString()); - b.append(stackTrace[i].toString()); + sb.append(stackTrace[i].toString()); //Append \n at the end of each line except the last one if(i < stackSize) - b.append("\n"); + sb.append("\n"); } //The stack trace is truncated if its size exceeds 255. - return validPathElementTC(b.toString()); + return validPathElementTC(sb.toString()); } static final MibLogger log = new MibLogger(JvmThreadInstanceEntryImpl.class); diff -r 3e8e199e23b2 src/share/classes/sun/misc/MessageUtils.java --- a/src/share/classes/sun/misc/MessageUtils.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/misc/MessageUtils.java Mon May 12 07:17:17 2014 -0300 @@ -55,7 +55,7 @@ } public static String subst(String patt, String args[]) { - StringBuffer result = new StringBuffer(); + StringBuilder result = new StringBuilder(); int len = patt.length(); for (int i = 0; i >= 0 && i < len; i++) { char ch = patt.charAt(i); diff -r 3e8e199e23b2 src/share/classes/sun/misc/UUDecoder.java --- a/src/share/classes/sun/misc/UUDecoder.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/misc/UUDecoder.java Mon May 12 07:17:17 2014 -0300 @@ -123,7 +123,7 @@ throws IOException { int i, c1, c2, c3, c4; int a, b, c; - StringBuffer x = new StringBuffer(); + StringBuilder x = new StringBuilder(); for (i = 0; i < 4; i++) { c1 = inStream.read(); @@ -152,7 +152,7 @@ */ protected void decodeBufferPrefix(PushbackInputStream inStream, OutputStream outStream) throws IOException { int c; - StringBuffer q = new StringBuffer(32); + StringBuilder q = new StringBuilder(32); String r; boolean sawNewLine; diff -r 3e8e199e23b2 src/share/classes/sun/net/TransferProtocolClient.java --- a/src/share/classes/sun/net/TransferProtocolClient.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/net/TransferProtocolClient.java Mon May 12 07:17:17 2014 -0300 @@ -53,7 +53,7 @@ * number. Returns -1 on failure. */ public int readServerResponse() throws IOException { - StringBuffer replyBuf = new StringBuffer(32); + StringBuilder replyBuf = new StringBuilder(32); int c; int continuingCode = -1; int code; diff -r 3e8e199e23b2 src/share/classes/sun/net/ftp/impl/FtpClient.java --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Mon May 12 07:17:17 2014 -0300 @@ -409,7 +409,7 @@ * number. Returns -1 on failure. */ private int readServerResponse() throws IOException { - StringBuffer replyBuf = new StringBuffer(32); + StringBuilder replyBuf = new StringBuilder(32); int c; int continuingCode = -1; int code; @@ -1051,7 +1051,7 @@ // keep the welcome message around so we can // put it in the resulting HTML page. String l; - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < serverResponse.size(); i++) { l = serverResponse.elementAt(i); if (l != null) { @@ -1096,7 +1096,7 @@ // keep the welcome message around so we can // put it in the resulting HTML page. - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (serverResponse != null) { for (String l : serverResponse) { if (l != null) { @@ -1494,7 +1494,7 @@ * So we need to remove the 1st and last line */ Vector resp = getResponseStrings(); - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 1; i < resp.size() - 1; i++) { sb.append(resp.get(i)); } @@ -1992,7 +1992,7 @@ * by the server. */ public String getLastResponseString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (serverResponse != null) { for (String l : serverResponse) { if (l != null) { @@ -2195,7 +2195,7 @@ } // on multiple lines answers, like the ones above, remove 1st and last // line, concat the the others. - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 1; i < resp.size() - 1; i++) { sb.append(resp.get(i).substring(3)); } diff -r 3e8e199e23b2 src/share/classes/sun/net/www/MimeEntry.java --- a/src/share/classes/sun/net/www/MimeEntry.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/net/www/MimeEntry.java Mon May 12 07:17:17 2014 -0300 @@ -281,52 +281,52 @@ } public synchronized String toProperty() { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); String separator = "; "; boolean needSeparator = false; int action = getAction(); if (action != MimeEntry.UNKNOWN) { - buf.append("action=" + actionKeywords[action]); + sb.append("action=" + actionKeywords[action]); needSeparator = true; } String command = getLaunchString(); if (command != null && command.length() > 0) { if (needSeparator) { - buf.append(separator); + sb.append(separator); } - buf.append("application=" + command); + sb.append("application=" + command); needSeparator = true; } if (getImageFileName() != null) { if (needSeparator) { - buf.append(separator); + sb.append(separator); } - buf.append("icon=" + getImageFileName()); + sb.append("icon=" + getImageFileName()); needSeparator = true; } String extensions = getExtensionsAsList(); if (extensions.length() > 0) { if (needSeparator) { - buf.append(separator); + sb.append(separator); } - buf.append("file_extensions=" + extensions); + sb.append("file_extensions=" + extensions); needSeparator = true; } String description = getDescription(); if (description != null && !description.equals(getType())) { if (needSeparator) { - buf.append(separator); + sb.append(separator); } - buf.append("description=" + description); + sb.append("description=" + description); } - return buf.toString(); + return sb.toString(); } public String toString() { diff -r 3e8e199e23b2 src/share/classes/sun/net/www/http/HttpClient.java --- a/src/share/classes/sun/net/www/http/HttpClient.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/net/www/http/HttpClient.java Mon May 12 07:17:17 2014 -0300 @@ -558,7 +558,7 @@ // Do not use URLStreamHandler.toExternalForm as the fragment // should not be part of the RequestURI. It should be an // absolute URI which does not have a fragment part. - StringBuffer result = new StringBuffer(128); + StringBuilder result = new StringBuilder(128); result.append(url.getProtocol()); result.append(":"); if (url.getAuthority() != null && url.getAuthority().length() > 0) { diff -r 3e8e199e23b2 src/share/classes/sun/net/www/protocol/file/FileURLConnection.java --- a/src/share/classes/sun/net/www/protocol/file/FileURLConnection.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/net/www/protocol/file/FileURLConnection.java Mon May 12 07:17:17 2014 -0300 @@ -191,7 +191,7 @@ if (isDirectory) { FileNameMap map = java.net.URLConnection.getFileNameMap(); - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); if (files == null) { throw new FileNotFoundException(filename); @@ -201,11 +201,11 @@ for (int i = 0 ; i < files.size() ; i++) { String fileName = files.get(i); - buf.append(fileName); - buf.append("\n"); + sb.append(fileName); + sb.append("\n"); } // Put it into a (default) locale-specific byte-stream. - is = new ByteArrayInputStream(buf.toString().getBytes()); + is = new ByteArrayInputStream(sb.toString().getBytes()); } else { throw new FileNotFoundException(filename); } diff -r 3e8e199e23b2 src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java --- a/src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java Mon May 12 07:17:17 2014 -0300 @@ -502,7 +502,7 @@ } byte[] digest = md.digest(); - StringBuffer res = new StringBuffer(digest.length * 2); + StringBuilder res = new StringBuilder(digest.length * 2); for (int i = 0; i < digest.length; i++) { int hashchar = ((digest[i] >>> 4) & 0xf); res.append(charArray[hashchar]); diff -r 3e8e199e23b2 src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java --- a/src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java Mon May 12 07:17:17 2014 -0300 @@ -382,7 +382,7 @@ } public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(this.getClass().getName()); sb.append('['); if (!isOpen()) { diff -r 3e8e199e23b2 src/share/classes/sun/nio/ch/SocketChannelImpl.java --- a/src/share/classes/sun/nio/ch/SocketChannelImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/nio/ch/SocketChannelImpl.java Mon May 12 07:17:17 2014 -0300 @@ -983,7 +983,7 @@ @Override public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(this.getClass().getSuperclass().getName()); sb.append('['); if (!isOpen()) diff -r 3e8e199e23b2 src/share/classes/sun/print/PSPrinterJob.java --- a/src/share/classes/sun/print/PSPrinterJob.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/print/PSPrinterJob.java Mon May 12 07:17:17 2014 -0300 @@ -1269,7 +1269,7 @@ CharsetString cs = acs[i]; CharsetEncoder fontCS = cs.fontDescriptor.encoder; - StringBuffer nativeStr = new StringBuffer(); + StringBuilder nativeStr = new StringBuilder(); byte[] strSeg = new byte[cs.length * 2]; int len = 0; try { diff -r 3e8e199e23b2 src/share/classes/sun/reflect/MethodAccessorGenerator.java --- a/src/share/classes/sun/reflect/MethodAccessorGenerator.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/reflect/MethodAccessorGenerator.java Mon May 12 07:17:17 2014 -0300 @@ -751,14 +751,14 @@ } private String buildInternalSignature() { - StringBuffer buf = new StringBuffer(); - buf.append("("); + StringBuilder sb = new StringBuilder(); + sb.append("("); for (int i = 0; i < parameterTypes.length; i++) { - buf.append(getClassName(parameterTypes[i], true)); + sb.append(getClassName(parameterTypes[i], true)); } - buf.append(")"); - buf.append(getClassName(returnType, true)); - return buf.toString(); + sb.append(")"); + sb.append(getClassName(returnType, true)); + return sb.toString(); } private static synchronized String generateName(boolean isConstructor, diff -r 3e8e199e23b2 src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java --- a/src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java Mon May 12 07:17:17 2014 -0300 @@ -129,7 +129,7 @@ * Implementation of dynamicProxy.toString() */ private String toStringImpl() { - StringBuffer result = new StringBuffer(128); + StringBuilder result = new StringBuilder(128); result.append('@'); result.append(type.getName()); result.append('('); diff -r 3e8e199e23b2 src/share/classes/sun/rmi/server/Activation.java --- a/src/share/classes/sun/rmi/server/Activation.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/rmi/server/Activation.java Mon May 12 07:17:17 2014 -0300 @@ -1239,7 +1239,7 @@ checkArgs(desc, argv); if (debugExec) { - StringBuffer sb = new StringBuffer(argv[0]); + StringBuilder sb = new StringBuilder(argv[0]); int j; for (j = 1; j < argv.length; j++) { sb.append(' '); diff -r 3e8e199e23b2 src/share/classes/sun/rmi/server/LoaderHandler.java --- a/src/share/classes/sun/rmi/server/LoaderHandler.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Mon May 12 07:17:17 2014 -0300 @@ -793,7 +793,7 @@ } else if (urls.length == 1) { return urls[0].toExternalForm(); } else { - StringBuffer path = new StringBuffer(urls[0].toExternalForm()); + StringBuilder path = new StringBuilder(urls[0].toExternalForm()); for (int i = 1; i < urls.length; i++) { path.append(' '); path.append(urls[i].toExternalForm()); diff -r 3e8e199e23b2 src/share/classes/sun/rmi/server/Util.java --- a/src/share/classes/sun/rmi/server/Util.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/rmi/server/Util.java Mon May 12 07:17:17 2014 -0300 @@ -391,7 +391,7 @@ * the definition of a "method descriptor". */ private static String getMethodNameAndDescriptor(Method m) { - StringBuffer desc = new StringBuffer(m.getName()); + StringBuilder desc = new StringBuilder(m.getName()); desc.append('('); Class[] paramTypes = m.getParameterTypes(); for (int i = 0; i < paramTypes.length; i++) { diff -r 3e8e199e23b2 src/share/classes/sun/security/acl/AclImpl.java --- a/src/share/classes/sun/security/acl/AclImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/acl/AclImpl.java Mon May 12 07:17:17 2014 -0300 @@ -253,7 +253,7 @@ * ACL. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); Enumeration entries = entries(); while (entries.hasMoreElements()) { AclEntry entry = entries.nextElement(); diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/GSSCredentialImpl.java --- a/src/share/classes/sun/security/jgss/GSSCredentialImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/GSSCredentialImpl.java Mon May 12 07:17:17 2014 -0300 @@ -636,29 +636,29 @@ } GSSCredentialSpi element = null; - StringBuffer buffer = new StringBuffer("[GSSCredential: "); + StringBuilder sb = new StringBuilder("[GSSCredential: "); Object[] elements = hashtable.entrySet().toArray(); for (int i = 0; i < elements.length; i++) { try { - buffer.append('\n'); + sb.append('\n'); element = (GSSCredentialSpi) ((Map.Entry)elements[i]).getValue(); - buffer.append(element.getName()); - buffer.append(' '); - buffer.append(element.getMechanism()); - buffer.append(element.isInitiatorCredential() ? - " Initiate" : ""); - buffer.append(element.isAcceptorCredential() ? - " Accept" : ""); - buffer.append(" ["); - buffer.append(element.getClass()); - buffer.append(']'); + sb.append(element.getName()); + sb.append(' '); + sb.append(element.getMechanism()); + sb.append(element.isInitiatorCredential() ? + " Initiate" : ""); + sb.append(element.isAcceptorCredential() ? + " Accept" : ""); + sb.append(" ["); + sb.append(element.getClass()); + sb.append(']'); } catch (GSSException e) { // skip to next element } } - buffer.append(']'); - return buffer.toString(); + sb.append(']'); + return sb.toString(); } static class SearchKey { diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/GSSHeader.java --- a/src/share/classes/sun/security/jgss/GSSHeader.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/GSSHeader.java Mon May 12 07:17:17 2014 -0300 @@ -327,7 +327,7 @@ private String getHexBytes(byte[] bytes, int len) throws IOException { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < len; i++) { int b1 = (bytes[i]>>4) & 0x0f; diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/GSSToken.java --- a/src/share/classes/sun/security/jgss/GSSToken.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/GSSToken.java Mon May 12 07:17:17 2014 -0300 @@ -216,7 +216,7 @@ } public static final String getHexBytes(byte[] bytes, int pos, int len) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = pos; i < (pos+len); i++) { int b1 = (bytes[i]>>4) & 0x0f; int b2 = bytes[i] & 0x0f; diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/ProviderList.java --- a/src/share/classes/sun/security/jgss/ProviderList.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/ProviderList.java Mon May 12 07:17:17 2014 -0300 @@ -536,12 +536,12 @@ // For debugging public String toString() { - StringBuffer buf = new StringBuffer("<"); - buf.append(p.getName()); - buf.append(", "); - buf.append(oid); - buf.append(">"); - return buf.toString(); + StringBuilder sb = new StringBuilder("<"); + sb.append(p.getName()); + sb.append(", "); + sb.append(oid); + sb.append(">"); + return sb.toString(); } } } diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/TokenTracker.java --- a/src/share/classes/sun/security/jgss/TokenTracker.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/TokenTracker.java Mon May 12 07:17:17 2014 -0300 @@ -336,19 +336,19 @@ } public String toString() { - StringBuffer buf = new StringBuffer("TokenTracker: "); - buf.append(" initNumber=").append(initNumber); - buf.append(" windowStart=").append(windowStart); - buf.append(" expectedNumber=").append(expectedNumber); - buf.append(" windowStartIndex=").append(windowStartIndex); - buf.append("\n\tIntervals are: {"); + StringBuilder sb = new StringBuilder("TokenTracker: "); + sb.append(" initNumber=").append(initNumber); + sb.append(" windowStart=").append(windowStart); + sb.append(" expectedNumber=").append(expectedNumber); + sb.append(" windowStartIndex=").append(windowStartIndex); + sb.append("\n\tIntervals are: {"); for (int i = 0; i < list.size(); i++) { if (i != 0) - buf.append(", "); - buf.append(list.get(i).toString()); + sb.append(", "); + sb.append(list.get(i).toString()); } - buf.append('}'); - return buf.toString(); + sb.append('}'); + return sb.toString(); } /** diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/krb5/InitialToken.java --- a/src/share/classes/sun/security/jgss/krb5/InitialToken.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/krb5/InitialToken.java Mon May 12 07:17:17 2014 -0300 @@ -164,15 +164,15 @@ serviceTicket.getServer(); // Cannot use '\"' instead of "\"" in constructor because // it is interpreted as suggested length! - StringBuffer buf = new StringBuffer("\""); - buf.append(delegateTo.getName()).append('\"'); + StringBuilder sb = new StringBuilder("\""); + sb.append(delegateTo.getName()).append('\"'); String realm = delegateTo.getRealmAsString(); - buf.append(" \"krbtgt/").append(realm).append('@'); - buf.append(realm).append('\"'); + sb.append(" \"krbtgt/").append(realm).append('@'); + sb.append(realm).append('\"'); SecurityManager sm = System.getSecurityManager(); if (sm != null) { DelegationPermission perm = - new DelegationPermission(buf.toString()); + new DelegationPermission(sb.toString()); sm.checkPermission(perm); } diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/krb5/Krb5Context.java --- a/src/share/classes/sun/security/jgss/krb5/Krb5Context.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/krb5/Krb5Context.java Mon May 12 07:17:17 2014 -0300 @@ -1345,7 +1345,7 @@ private static String getHexBytes(byte[] bytes, int pos, int len) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < len; i++) { int b1 = (bytes[i]>>4) & 0x0f; diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/wrapper/Krb5Util.java --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Mon May 12 07:17:17 2014 -0300 @@ -41,9 +41,9 @@ String krbPrinc = name.getKrbName(); int atIndex = krbPrinc.indexOf("@"); String realm = krbPrinc.substring(atIndex + 1); - StringBuffer buf = new StringBuffer("krbtgt/"); - buf.append(realm).append('@').append(realm); - return buf.toString(); + StringBuilder sb = new StringBuilder("krbtgt/"); + sb.append(realm).append('@').append(realm); + return sb.toString(); } // Perform the Service Permission check using the specified diff -r 3e8e199e23b2 src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java --- a/src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java Mon May 12 07:17:17 2014 -0300 @@ -139,10 +139,10 @@ if (sm != null) { String targetStr = targetName.getKrbName(); String tgsStr = Krb5Util.getTGSName(targetName); - StringBuffer buf = new StringBuffer("\""); - buf.append(targetStr).append("\" \""); - buf.append(tgsStr).append('\"'); - String krbPrincPair = buf.toString(); + StringBuilder sb = new StringBuilder("\""); + sb.append(targetStr).append("\" \""); + sb.append(tgsStr).append('\"'); + String krbPrincPair = sb.toString(); SunNativeProvider.debug("Checking DelegationPermission (" + krbPrincPair + ")"); DelegationPermission perm = diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/Credentials.java --- a/src/share/classes/sun/security/krb5/Credentials.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/Credentials.java Mon May 12 07:17:17 2014 -0300 @@ -510,21 +510,21 @@ } public String toString() { - StringBuffer buffer = new StringBuffer("Credentials:"); - buffer.append( "\n client=").append(client); - buffer.append( "\n server=").append(server); + StringBuilder sb = new StringBuilder("Credentials:"); + sb.append("\n client=").append(client); + sb.append("\n server=").append(server); if (authTime != null) { - buffer.append("\n authTime=").append(authTime); + sb.append("\n authTime=").append(authTime); } if (startTime != null) { - buffer.append("\n startTime=").append(startTime); + sb.append("\n startTime=").append(startTime); } - buffer.append( "\n endTime=").append(endTime); - buffer.append( "\n renewTill=").append(renewTill); - buffer.append( "\n flags=").append(flags); - buffer.append( "\nEType (skey)=").append(key.getEType()); - buffer.append( "\n (tkt key)=").append(ticket.encPart.eType); - return buffer.toString(); + sb.append("\n endTime=").append(endTime); + sb.append("\n renewTill=").append(renewTill); + sb.append("\n flags=").append(flags); + sb.append("\nEType (skey)=").append(key.getEType()); + sb.append("\n (tkt key)=").append(ticket.encPart.eType); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/KrbException.java --- a/src/share/classes/sun/security/krb5/KrbException.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/KrbException.java Mon May 12 07:17:17 2014 -0300 @@ -96,7 +96,7 @@ public String krbErrorMessage() { - StringBuffer strbuf = new StringBuffer("krb_error " + returnCode); + StringBuilder strbuf = new StringBuilder("krb_error " + returnCode); String msg = getMessage(); if (msg != null) { strbuf.append(" "); @@ -112,7 +112,7 @@ * If the error code is 0 then the first half is skipped. */ public String getMessage() { - StringBuffer message = new StringBuffer(); + StringBuilder message = new StringBuilder(); int returnCode = returnCode(); if (returnCode != 0) { message.append(returnCodeMessage()); diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/PrincipalName.java --- a/src/share/classes/sun/security/krb5/PrincipalName.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/PrincipalName.java Mon May 12 07:17:17 2014 -0300 @@ -480,7 +480,7 @@ } public String getPrincipalNameAsString() { - StringBuffer temp = new StringBuffer(nameStrings[0]); + StringBuilder temp = new StringBuilder(nameStrings[0]); for (int i = 1; i < nameStrings.length; i++) temp.append(nameStrings[i]); return temp.toString(); @@ -521,7 +521,7 @@ public String getSalt() { if (salt == null) { - StringBuffer salt = new StringBuffer(); + StringBuilder salt = new StringBuilder(); salt.append(nameRealm.toString()); for (int i = 0; i < nameStrings.length; i++) { salt.append(nameStrings[i]); @@ -532,7 +532,7 @@ } public String toString() { - StringBuffer str = new StringBuffer(); + StringBuilder str = new StringBuilder(); for (int i = 0; i < nameStrings.length; i++) { if (i > 0) str.append("/"); @@ -544,7 +544,7 @@ } public String getNameString() { - StringBuffer str = new StringBuffer(); + StringBuilder str = new StringBuilder(); for (int i = 0; i < nameStrings.length; i++) { if (i > 0) str.append("/"); diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/internal/EncTicketPart.java --- a/src/share/classes/sun/security/krb5/internal/EncTicketPart.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/internal/EncTicketPart.java Mon May 12 07:17:17 2014 -0300 @@ -117,7 +117,7 @@ private static String getHexBytes(byte[] bytes, int len) throws IOException { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; i < len; i++) { int b1 = (bytes[i] >> 4) & 0x0f; diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/internal/TicketFlags.java --- a/src/share/classes/sun/security/krb5/internal/TicketFlags.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/internal/TicketFlags.java Mon May 12 07:17:17 2014 -0300 @@ -137,7 +137,7 @@ * Returns the string representative of ticket flags. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); boolean[] flags = toBooleanArray(); for (int i = 0; i < flags.length; i++) { if (flags[i] == true) { diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/internal/crypto/EType.java --- a/src/share/classes/sun/security/krb5/internal/crypto/EType.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/internal/crypto/EType.java Mon May 12 07:17:17 2014 -0300 @@ -269,7 +269,7 @@ } int len = list.size(); if (len <= 0) { - StringBuffer keystr = new StringBuffer(); + StringBuilder keystr = new StringBuilder(); for (int i = 0; i < keys.length; i++) { keystr.append(toString(keys[i].getEType())); keystr.append(" "); diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java --- a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java Mon May 12 07:17:17 2014 -0300 @@ -636,7 +636,7 @@ // Routines used for debugging static String bytesToString(byte[] digest) { // Get character representation of digest - StringBuffer digestString = new StringBuffer(); + StringBuilder digestString = new StringBuilder(); for (int i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { diff -r 3e8e199e23b2 src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java --- a/src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java Mon May 12 07:17:17 2014 -0300 @@ -73,7 +73,7 @@ } public String getKeyString() { - StringBuffer sb = new StringBuffer("0x"); + StringBuilder sb = new StringBuilder("0x"); for (int i = 0; i < keyblock.length; i++) { sb.append(String.format("%02x", keyblock[i]&0xff)); } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs/PKCS9Attribute.java --- a/src/share/classes/sun/security/pkcs/PKCS9Attribute.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs/PKCS9Attribute.java Mon May 12 07:17:17 2014 -0300 @@ -790,26 +790,26 @@ * Returns a string representation of this attribute. */ public String toString() { - StringBuffer buf = new StringBuffer(100); + StringBuilder sb = new StringBuilder(100); - buf.append("["); + sb.append("["); if (index == -1) { - buf.append(oid.toString()); + sb.append(oid.toString()); } else { - buf.append(OID_NAME_TABLE.get(PKCS9_OIDS[index])); + sb.append(OID_NAME_TABLE.get(PKCS9_OIDS[index])); } - buf.append(": "); + sb.append(": "); if (index == -1 || SINGLE_VALUED[index]) { if (value instanceof byte[]) { // special case for octet string HexDumpEncoder hexDump = new HexDumpEncoder(); - buf.append(hexDump.encodeBuffer((byte[]) value)); + sb.append(hexDump.encodeBuffer((byte[]) value)); } else { - buf.append(value.toString()); + sb.append(value.toString()); } - buf.append("]"); - return buf.toString(); + sb.append("]"); + return sb.toString(); } else { // multi-valued boolean first = true; Object[] values = (Object[]) value; @@ -818,11 +818,11 @@ if (first) first = false; else - buf.append(", "); + sb.append(", "); - buf.append(values[j].toString()); + sb.append(values[j].toString()); } - return buf.toString(); + return sb.toString(); } } @@ -857,7 +857,7 @@ private void throwTagException(Byte tag) throws IOException { Byte[] expectedTags = PKCS9_VALUE_TAGS[index]; - StringBuffer msg = new StringBuffer(100); + StringBuilder msg = new StringBuilder(100); msg.append("Value of attribute "); msg.append(oid.toString()); msg.append(" ("); diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs/PKCS9Attributes.java --- a/src/share/classes/sun/security/pkcs/PKCS9Attributes.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs/PKCS9Attributes.java Mon May 12 07:17:17 2014 -0300 @@ -323,8 +323,8 @@ * Returns the PKCS9 block in a printable string form. */ public String toString() { - StringBuffer buf = new StringBuffer(200); - buf.append("PKCS9 Attributes: [\n\t"); + StringBuilder sb = new StringBuilder(200); + sb.append("PKCS9 Attributes: [\n\t"); ObjectIdentifier oid; PKCS9Attribute value; @@ -339,14 +339,14 @@ if (first) first = false; else - buf.append(";\n\t"); + sb.append(";\n\t"); - buf.append(value.toString()); + sb.append(value.toString()); } - buf.append("\n\t] (end PKCS9 Attributes)"); + sb.append("\n\t] (end PKCS9 Attributes)"); - return buf.toString(); + return sb.toString(); } /** diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs/SigningCertificateInfo.java --- a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java Mon May 12 07:17:17 2014 -0300 @@ -92,15 +92,15 @@ } public String toString() { - StringBuffer buffer = new StringBuffer(); - buffer.append("[\n"); + StringBuilder sb = new StringBuilder(); + sb.append("[\n"); for (int i = 0; i < certId.length; i++) { - buffer.append(certId[i].toString()); + sb.append(certId[i].toString()); } // format policies as a string - buffer.append("\n]"); + sb.append("\n]"); - return buffer.toString(); + return sb.toString(); } public void parse(byte[] bytes) throws IOException { @@ -151,17 +151,17 @@ } public String toString() { - StringBuffer buffer = new StringBuffer(); - buffer.append("[\n\tCertificate hash (SHA-1):\n"); + StringBuilder sb = new StringBuilder(); + sb.append("[\n\tCertificate hash (SHA-1):\n"); if (hexDumper == null) { hexDumper = new HexDumpEncoder(); } - buffer.append(hexDumper.encode(certHash)); + sb.append(hexDumper.encode(certHash)); if (issuer != null && serialNumber != null) { - buffer.append("\n\tIssuer: " + issuer + "\n"); - buffer.append("\t" + serialNumber); + sb.append("\n\tIssuer: " + issuer + "\n"); + sb.append("\t" + serialNumber); } - buffer.append("\n]"); - return buffer.toString(); + sb.append("\n]"); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/P11Util.java --- a/src/share/classes/sun/security/pkcs11/P11Util.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/P11Util.java Mon May 12 07:17:17 2014 -0300 @@ -166,7 +166,7 @@ if (b == null) { return "(null)"; } - StringBuffer sb = new StringBuffer(b.length * 3); + StringBuilder sb = new StringBuilder(b.length * 3); for (int i = 0; i < b.length; i++) { int k = b[i] & 0xff; if (i != 0) { diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -50,17 +50,17 @@ } public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("ulCounterBits: "); - buffer.append(ulCounterBits); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulCounterBits: "); + sb.append(ulCounterBits); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("cb: "); - buffer.append(Functions.toHexString(cb)); + sb.append(Constants.INDENT); + sb.append("cb: "); + sb.append(Functions.toHexString(cb)); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_DATE.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_DATE.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_DATE.java Mon May 12 07:17:17 2014 -0300 @@ -122,16 +122,16 @@ * @return the string representation of CK_DATE */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(new String(day)); - buffer.append('.'); - buffer.append(new String(month)); - buffer.append('.'); - buffer.append(new String(year)); - buffer.append(" (DD.MM.YYYY)"); + sb.append(new String(day)); + sb.append('.'); + sb.append(new String(month)); + sb.append('.'); + sb.append(new String(year)); + sb.append(" (DD.MM.YYYY)"); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_ECDH1_DERIVE_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -105,34 +105,34 @@ * @return the string representation of CK_PKCS5_PBKD2_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("kdf: 0x"); - buffer.append(Functions.toFullHexString(kdf)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("kdf: 0x"); + sb.append(Functions.toFullHexString(kdf)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSharedDataLen: "); - buffer.append(pSharedData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSharedDataLen: "); + sb.append(pSharedData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSharedData: "); - buffer.append(Functions.toHexString(pSharedData)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSharedData: "); + sb.append(Functions.toHexString(pSharedData)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicDataLen: "); - buffer.append(pPublicData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicDataLen: "); + sb.append(pPublicData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicData: "); - buffer.append(Functions.toHexString(pPublicData)); + sb.append(Constants.INDENT); + sb.append("pPublicData: "); + sb.append(Functions.toHexString(pPublicData)); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_ECDH2_DERIVE_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_ECDH2_DERIVE_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_ECDH2_DERIVE_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -128,54 +128,54 @@ * @return the string representation of CK_PKCS5_PBKD2_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("kdf: 0x"); - buffer.append(Functions.toFullHexString(kdf)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("kdf: 0x"); + sb.append(Functions.toFullHexString(kdf)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSharedDataLen: "); - buffer.append(pSharedData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSharedDataLen: "); + sb.append(pSharedData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSharedData: "); - buffer.append(Functions.toHexString(pSharedData)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSharedData: "); + sb.append(Functions.toHexString(pSharedData)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicDataLen: "); - buffer.append(pPublicData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicDataLen: "); + sb.append(pPublicData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicData: "); - buffer.append(Functions.toHexString(pPublicData)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicData: "); + sb.append(Functions.toHexString(pPublicData)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulPrivateDataLen: "); - buffer.append(ulPrivateDataLen); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulPrivateDataLen: "); + sb.append(ulPrivateDataLen); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("hPrivateData: "); - buffer.append(hPrivateData); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("hPrivateData: "); + sb.append(hPrivateData); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicDataLen2: "); - buffer.append(pPublicData2.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicDataLen2: "); + sb.append(pPublicData2.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicData2: "); - buffer.append(Functions.toHexString(pPublicData2)); + sb.append(Constants.INDENT); + sb.append("pPublicData2: "); + sb.append(Functions.toHexString(pPublicData2)); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_INFO.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_INFO.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_INFO.java Mon May 12 07:17:17 2014 -0300 @@ -131,34 +131,34 @@ * @return the string representation of CK_INFO */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("cryptokiVersion: "); - buffer.append(cryptokiVersion.toString()); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("cryptokiVersion: "); + sb.append(cryptokiVersion.toString()); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("manufacturerID: "); - buffer.append(new String(manufacturerID)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("manufacturerID: "); + sb.append(new String(manufacturerID)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("flags: "); - buffer.append(Functions.toBinaryString(flags)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("flags: "); + sb.append(Functions.toBinaryString(flags)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("libraryDescription: "); - buffer.append(new String(libraryDescription)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("libraryDescription: "); + sb.append(new String(libraryDescription)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("libraryVersion: "); - buffer.append(libraryVersion.toString()); + sb.append(Constants.INDENT); + sb.append("libraryVersion: "); + sb.append(libraryVersion.toString()); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java Mon May 12 07:17:17 2014 -0300 @@ -143,24 +143,24 @@ * @return the string representation of CK_MECHANISM */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("mechanism: "); - buffer.append(mechanism); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("mechanism: "); + sb.append(mechanism); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pParameter: "); - buffer.append(pParameter.toString()); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pParameter: "); + sb.append(pParameter.toString()); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulParameterLen: ??"); + sb.append(Constants.INDENT); + sb.append("ulParameterLen: ??"); //buffer.append(pParameter.length); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java Mon May 12 07:17:17 2014 -0300 @@ -103,25 +103,25 @@ * @return the string representation of CK_MECHANISM_INFO */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("ulMinKeySize: "); - buffer.append(String.valueOf(ulMinKeySize)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulMinKeySize: "); + sb.append(String.valueOf(ulMinKeySize)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulMaxKeySize: "); - buffer.append(String.valueOf(ulMaxKeySize)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulMaxKeySize: "); + sb.append(String.valueOf(ulMaxKeySize)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("flags: "); - buffer.append(String.valueOf(flags)); - buffer.append(" = "); - buffer.append(Functions.mechanismInfoFlagsToString(flags)); + sb.append(Constants.INDENT); + sb.append("flags: "); + sb.append(String.valueOf(flags)); + sb.append(" = "); + sb.append(Functions.mechanismInfoFlagsToString(flags)); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_PBE_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -109,39 +109,39 @@ * @return the string representation of CK_PBE_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("pInitVector: "); - buffer.append(pInitVector); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pInitVector: "); + sb.append(pInitVector); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulPasswordLen: "); - buffer.append(pPassword.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulPasswordLen: "); + sb.append(pPassword.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPassword: "); - buffer.append(pPassword); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPassword: "); + sb.append(pPassword); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulSaltLen: "); - buffer.append(pSalt.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulSaltLen: "); + sb.append(pSalt.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSalt: "); - buffer.append(pSalt); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSalt: "); + sb.append(pSalt); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulIteration: "); - buffer.append(ulIteration); + sb.append(Constants.INDENT); + sb.append("ulIteration: "); + sb.append(ulIteration); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_PKCS5_PBKD2_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -118,44 +118,44 @@ * @return the string representation of CK_PKCS5_PBKD2_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("saltSource: "); - buffer.append(saltSource); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("saltSource: "); + sb.append(saltSource); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSaltSourceData: "); - buffer.append(Functions.toHexString(pSaltSourceData)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSaltSourceData: "); + sb.append(Functions.toHexString(pSaltSourceData)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulSaltSourceDataLen: "); - buffer.append(pSaltSourceData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulSaltSourceDataLen: "); + sb.append(pSaltSourceData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("iterations: "); - buffer.append(iterations); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("iterations: "); + sb.append(iterations); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("prf: "); - buffer.append(prf); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("prf: "); + sb.append(prf); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPrfData: "); - buffer.append(Functions.toHexString(pPrfData)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPrfData: "); + sb.append(Functions.toHexString(pPrfData)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulPrfDataLen: "); - buffer.append(pPrfData.length); + sb.append(Constants.INDENT); + sb.append("ulPrfDataLen: "); + sb.append(pPrfData.length); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_OAEP_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_OAEP_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_OAEP_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -110,34 +110,34 @@ * @return the string representation of CK_RSA_PKCS_OAEP_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("hashAlg: "); - buffer.append(hashAlg); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("hashAlg: "); + sb.append(hashAlg); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("mgf: "); - buffer.append(mgf); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("mgf: "); + sb.append(mgf); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("source: "); - buffer.append(source); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("source: "); + sb.append(source); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSourceData: "); - buffer.append(pSourceData.toString()); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pSourceData: "); + sb.append(pSourceData.toString()); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pSourceDataLen: "); - buffer.append(Functions.toHexString(pSourceData)); + sb.append(Constants.INDENT); + sb.append("pSourceDataLen: "); + sb.append(Functions.toHexString(pSourceData)); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -95,24 +95,24 @@ * @return the string representation of CK_PKCS5_PBKD2_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("hashAlg: 0x"); - buffer.append(Functions.toFullHexString(hashAlg)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("hashAlg: 0x"); + sb.append(Functions.toFullHexString(hashAlg)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("mgf: 0x"); - buffer.append(Functions.toFullHexString(mgf)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("mgf: 0x"); + sb.append(Functions.toFullHexString(mgf)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("sLen: "); - buffer.append(sLen); + sb.append(Constants.INDENT); + sb.append("sLen: "); + sb.append(sLen); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_SESSION_INFO.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_SESSION_INFO.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_SESSION_INFO.java Mon May 12 07:17:17 2014 -0300 @@ -114,29 +114,29 @@ * @return the string representation of CK_SESSION_INFO */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("slotID: "); - buffer.append(String.valueOf(slotID)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("slotID: "); + sb.append(String.valueOf(slotID)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("state: "); - buffer.append(Functions.sessionStateToString(state)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("state: "); + sb.append(Functions.sessionStateToString(state)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("flags: "); - buffer.append(Functions.sessionInfoFlagsToString(flags)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("flags: "); + sb.append(Functions.sessionInfoFlagsToString(flags)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulDeviceError: "); - buffer.append(Functions.toHexString(ulDeviceError)); + sb.append(Constants.INDENT); + sb.append("ulDeviceError: "); + sb.append(Functions.toHexString(ulDeviceError)); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_SLOT_INFO.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_SLOT_INFO.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_SLOT_INFO.java Mon May 12 07:17:17 2014 -0300 @@ -130,34 +130,34 @@ * @return the string representation of CK_SLOT_INFO */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("slotDescription: "); - buffer.append(new String(slotDescription)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("slotDescription: "); + sb.append(new String(slotDescription)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("manufacturerID: "); - buffer.append(new String(manufacturerID)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("manufacturerID: "); + sb.append(new String(manufacturerID)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("flags: "); - buffer.append(Functions.slotInfoFlagsToString(flags)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("flags: "); + sb.append(Functions.slotInfoFlagsToString(flags)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("hardwareVersion: "); - buffer.append(hardwareVersion.toString()); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("hardwareVersion: "); + sb.append(hardwareVersion.toString()); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("firmwareVersion: "); - buffer.append(firmwareVersion.toString()); + sb.append(Constants.INDENT); + sb.append("firmwareVersion: "); + sb.append(firmwareVersion.toString()); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_TOKEN_INFO.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_TOKEN_INFO.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_TOKEN_INFO.java Mon May 12 07:17:17 2014 -0300 @@ -271,119 +271,119 @@ * @return the string representation of CK_TOKEN_INFO */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("label: "); - buffer.append(new String(label)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("label: "); + sb.append(new String(label)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("manufacturerID: "); - buffer.append(new String(manufacturerID)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("manufacturerID: "); + sb.append(new String(manufacturerID)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("model: "); - buffer.append(new String(model)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("model: "); + sb.append(new String(model)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("serialNumber: "); - buffer.append(new String(serialNumber)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("serialNumber: "); + sb.append(new String(serialNumber)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("flags: "); - buffer.append(Functions.tokenInfoFlagsToString(flags)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("flags: "); + sb.append(Functions.tokenInfoFlagsToString(flags)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulMaxSessionCount: "); - buffer.append((ulMaxSessionCount == PKCS11Constants.CK_EFFECTIVELY_INFINITE) + sb.append(Constants.INDENT); + sb.append("ulMaxSessionCount: "); + sb.append((ulMaxSessionCount == PKCS11Constants.CK_EFFECTIVELY_INFINITE) ? "CK_EFFECTIVELY_INFINITE" : (ulMaxSessionCount == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulMaxSessionCount)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulSessionCount: "); - buffer.append((ulSessionCount == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) + sb.append(Constants.INDENT); + sb.append("ulSessionCount: "); + sb.append((ulSessionCount == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulSessionCount)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulMaxRwSessionCount: "); - buffer.append((ulMaxRwSessionCount == PKCS11Constants.CK_EFFECTIVELY_INFINITE) + sb.append(Constants.INDENT); + sb.append("ulMaxRwSessionCount: "); + sb.append((ulMaxRwSessionCount == PKCS11Constants.CK_EFFECTIVELY_INFINITE) ? "CK_EFFECTIVELY_INFINITE" : (ulMaxRwSessionCount == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulMaxRwSessionCount)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulRwSessionCount: "); - buffer.append((ulRwSessionCount == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) + sb.append(Constants.INDENT); + sb.append("ulRwSessionCount: "); + sb.append((ulRwSessionCount == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulRwSessionCount)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulMaxPinLen: "); - buffer.append(String.valueOf(ulMaxPinLen)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulMaxPinLen: "); + sb.append(String.valueOf(ulMaxPinLen)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulMinPinLen: "); - buffer.append(String.valueOf(ulMinPinLen)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulMinPinLen: "); + sb.append(String.valueOf(ulMinPinLen)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulTotalPublicMemory: "); - buffer.append((ulTotalPublicMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) + sb.append(Constants.INDENT); + sb.append("ulTotalPublicMemory: "); + sb.append((ulTotalPublicMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulTotalPublicMemory)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulFreePublicMemory: "); - buffer.append((ulFreePublicMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) + sb.append(Constants.INDENT); + sb.append("ulFreePublicMemory: "); + sb.append((ulFreePublicMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulFreePublicMemory)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulTotalPrivateMemory: "); - buffer.append((ulTotalPrivateMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) + sb.append(Constants.INDENT); + sb.append("ulTotalPrivateMemory: "); + sb.append((ulTotalPrivateMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulTotalPrivateMemory)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulFreePrivateMemory: "); - buffer.append((ulFreePrivateMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) + sb.append(Constants.INDENT); + sb.append("ulFreePrivateMemory: "); + sb.append((ulFreePrivateMemory == PKCS11Constants.CK_UNAVAILABLE_INFORMATION) ? "CK_UNAVAILABLE_INFORMATION" : String.valueOf(ulFreePrivateMemory)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("hardwareVersion: "); - buffer.append(hardwareVersion.toString()); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("hardwareVersion: "); + sb.append(hardwareVersion.toString()); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("firmwareVersion: "); - buffer.append(firmwareVersion.toString()); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("firmwareVersion: "); + sb.append(firmwareVersion.toString()); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("utcTime: "); - buffer.append(new String(utcTime)); + sb.append(Constants.INDENT); + sb.append("utcTime: "); + sb.append(new String(utcTime)); //buffer.append(Constants.NEWLINE); - return buffer.toString() ; + return sb.toString() ; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH1_DERIVE_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -99,34 +99,34 @@ * @return the string representation of CK_PKCS5_PBKD2_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("kdf: 0x"); - buffer.append(Functions.toFullHexString(kdf)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("kdf: 0x"); + sb.append(Functions.toFullHexString(kdf)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pOtherInfoLen: "); - buffer.append(pOtherInfo.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pOtherInfoLen: "); + sb.append(pOtherInfo.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pOtherInfo: "); - buffer.append(Functions.toHexString(pOtherInfo)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pOtherInfo: "); + sb.append(Functions.toHexString(pOtherInfo)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicDataLen: "); - buffer.append(pPublicData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicDataLen: "); + sb.append(pPublicData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicData: "); - buffer.append(Functions.toHexString(pPublicData)); + sb.append(Constants.INDENT); + sb.append("pPublicData: "); + sb.append(Functions.toHexString(pPublicData)); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH2_DERIVE_PARAMS.java --- a/src/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH2_DERIVE_PARAMS.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/CK_X9_42_DH2_DERIVE_PARAMS.java Mon May 12 07:17:17 2014 -0300 @@ -128,54 +128,54 @@ * @return the string representation of CK_PKCS5_PBKD2_PARAMS */ public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buffer.append(Constants.INDENT); - buffer.append("kdf: 0x"); - buffer.append(Functions.toFullHexString(kdf)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("kdf: 0x"); + sb.append(Functions.toFullHexString(kdf)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pOtherInfoLen: "); - buffer.append(pOtherInfo.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pOtherInfoLen: "); + sb.append(pOtherInfo.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pOtherInfo: "); - buffer.append(Functions.toHexString(pOtherInfo)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pOtherInfo: "); + sb.append(Functions.toHexString(pOtherInfo)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicDataLen: "); - buffer.append(pPublicData.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicDataLen: "); + sb.append(pPublicData.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicData: "); - buffer.append(Functions.toHexString(pPublicData)); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicData: "); + sb.append(Functions.toHexString(pPublicData)); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("ulPrivateDataLen: "); - buffer.append(ulPrivateDataLen); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("ulPrivateDataLen: "); + sb.append(ulPrivateDataLen); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("hPrivateData: "); - buffer.append(hPrivateData); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("hPrivateData: "); + sb.append(hPrivateData); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicDataLen2: "); - buffer.append(pPublicData2.length); - buffer.append(Constants.NEWLINE); + sb.append(Constants.INDENT); + sb.append("pPublicDataLen2: "); + sb.append(pPublicData2.length); + sb.append(Constants.NEWLINE); - buffer.append(Constants.INDENT); - buffer.append("pPublicData2: "); - buffer.append(Functions.toHexString(pPublicData2)); + sb.append(Constants.INDENT); + sb.append("pPublicData2: "); + sb.append(Functions.toHexString(pPublicData2)); //buffer.append(Constants.NEWLINE); - return buffer.toString(); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/security/pkcs11/wrapper/Functions.java --- a/src/share/classes/sun/security/pkcs11/wrapper/Functions.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/pkcs11/wrapper/Functions.java Mon May 12 07:17:17 2014 -0300 @@ -109,14 +109,14 @@ */ public static String toFullHexString(long value) { long currentValue = value; - StringBuffer stringBuffer = new StringBuffer(16); + StringBuilder sb = new StringBuilder(16); for(int j = 0; j < 16; j++) { int currentDigit = (int) currentValue & 0xf; - stringBuffer.append(HEX_DIGITS[currentDigit]); + sb.append(HEX_DIGITS[currentDigit]); currentValue >>>= 4; } - return stringBuffer.reverse().toString(); + return sb.reverse().toString(); } /** @@ -128,14 +128,14 @@ */ public static String toFullHexString(int value) { int currentValue = value; - StringBuffer stringBuffer = new StringBuffer(8); + StringBuilder sb = new StringBuilder(8); for(int i = 0; i < 8; i++) { int currentDigit = currentValue & 0xf; - stringBuffer.append(HEX_DIGITS[currentDigit]); + sb.append(HEX_DIGITS[currentDigit]); currentValue >>>= 4; } - return stringBuffer.reverse().toString(); + return sb.reverse().toString(); } /** @@ -161,20 +161,20 @@ return null; } - StringBuffer buffer = new StringBuffer(2 * value.length); + StringBuilder sb = new StringBuilder(2 * value.length); int single; for (int i = 0; i < value.length; i++) { single = value[i] & 0xFF; if (single < 0x10) { - buffer.append('0'); + sb.append('0'); } - buffer.append(Integer.toString(single, 16)); + sb.append(Integer.toString(single, 16)); } - return buffer.toString(); + return sb.toString(); } /** diff -r 3e8e199e23b2 src/share/classes/sun/security/provider/AuthPolicyFile.java --- a/src/share/classes/sun/security/provider/AuthPolicyFile.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/provider/AuthPolicyFile.java Mon May 12 07:17:17 2014 -0300 @@ -944,7 +944,7 @@ } File f = new File(path); path = f.getCanonicalPath(); - StringBuffer sb = new StringBuffer(path); + StringBuilder sb = new StringBuilder(path); // reappend '*' to canonicalized filename (note that // canonicalization may have removed trailing file // separator, so we have to check for that, too) @@ -1095,7 +1095,7 @@ @Override public String toString(){ - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(rb.getString("LPARAM")); sb.append(getCodeSource()); sb.append("\n"); diff -r 3e8e199e23b2 src/share/classes/sun/security/provider/X509Factory.java --- a/src/share/classes/sun/security/provider/X509Factory.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/provider/X509Factory.java Mon May 12 07:17:17 2014 -0300 @@ -519,7 +519,7 @@ // Step 2: Read the rest of header, determine the line end int end; - StringBuffer header = new StringBuffer("-----"); + StringBuilder header = new StringBuilder("-----"); while (true) { int next = is.read(); if (next == -1) { @@ -562,7 +562,7 @@ } // Step 4: Consume the footer - StringBuffer footer = new StringBuffer("-"); + StringBuilder footer = new StringBuilder("-"); while (true) { int next = is.read(); // Add next == '\n' for maximum safety, in case endline diff -r 3e8e199e23b2 src/share/classes/sun/security/smartcardio/PCSC.java --- a/src/share/classes/sun/security/smartcardio/PCSC.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/smartcardio/PCSC.java Mon May 12 07:17:17 2014 -0300 @@ -172,7 +172,7 @@ private final static char[] hexDigits = "0123456789abcdef".toCharArray(); public static String toString(byte[] b) { - StringBuffer sb = new StringBuffer(b.length * 3); + StringBuilder sb = new StringBuilder(b.length * 3); for (int i = 0; i < b.length; i++) { int k = b[i] & 0xff; if (i != 0) { diff -r 3e8e199e23b2 src/share/classes/sun/security/ssl/HandshakeMessage.java --- a/src/share/classes/sun/security/ssl/HandshakeMessage.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/ssl/HandshakeMessage.java Mon May 12 07:17:17 2014 -0300 @@ -1474,17 +1474,17 @@ s.println(); if (protocolVersion.v >= ProtocolVersion.TLS12.v) { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); boolean opened = false; for (SignatureAndHashAlgorithm signAlg : algorithms) { if (opened) { - buffer.append(", " + signAlg.getAlgorithmName()); + sb.append(", " + signAlg.getAlgorithmName()); } else { - buffer.append(signAlg.getAlgorithmName()); + sb.append(signAlg.getAlgorithmName()); opened = true; } } - s.println("Supported Signature Algorithms: " + buffer); + s.println("Supported Signature Algorithms: " + sb); } s.println("Cert Authorities:"); diff -r 3e8e199e23b2 src/share/classes/sun/security/ssl/SSLSocketImpl.java --- a/src/share/classes/sun/security/ssl/SSLSocketImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/ssl/SSLSocketImpl.java Mon May 12 07:17:17 2014 -0300 @@ -2594,7 +2594,7 @@ */ @Override public String toString() { - StringBuffer retval = new StringBuffer(80); + StringBuilder retval = new StringBuilder(80); retval.append(Integer.toHexString(hashCode())); retval.append("["); diff -r 3e8e199e23b2 src/share/classes/sun/security/ssl/ServerNameExtension.java --- a/src/share/classes/sun/security/ssl/ServerNameExtension.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/ssl/ServerNameExtension.java Mon May 12 07:17:17 2014 -0300 @@ -266,12 +266,12 @@ @Override public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (SNIServerName sniName : sniMap.values()) { - buffer.append("[" + sniName + "]"); + sb.append("[" + sniName + "]"); } - return "Extension " + type + ", server_name: " + buffer; + return "Extension " + type + ", server_name: " + sb; } private static class UnknownServerName extends SNIServerName { diff -r 3e8e199e23b2 src/share/classes/sun/security/ssl/SessionId.java --- a/src/share/classes/sun/security/ssl/SessionId.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/ssl/SessionId.java Mon May 12 07:17:17 2014 -0300 @@ -72,16 +72,16 @@ public String toString () { int len = sessionId.length; - StringBuffer s = new StringBuffer (10 + 2 * len); + StringBuilder sb = new StringBuilder (10 + 2 * len); - s.append ("{"); + sb.append("{"); for (int i = 0; i < len; i++) { - s.append (0x0ff & sessionId [i]); + sb.append(0x0ff & sessionId[i]); if (i != (len - 1)) - s.append (", "); + sb.append (", "); } - s.append ("}"); - return s.toString (); + sb.append("}"); + return sb.toString (); } diff -r 3e8e199e23b2 src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java --- a/src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java Mon May 12 07:17:17 2014 -0300 @@ -118,18 +118,18 @@ @Override public String toString() { - StringBuffer buffer = new StringBuffer(); + StringBuilder sb = new StringBuilder(); boolean opened = false; for (SignatureAndHashAlgorithm signAlg : algorithms) { if (opened) { - buffer.append(", " + signAlg.getAlgorithmName()); + sb.append(", " + signAlg.getAlgorithmName()); } else { - buffer.append(signAlg.getAlgorithmName()); + sb.append(signAlg.getAlgorithmName()); opened = true; } } - return "Extension " + type + ", signature_algorithms: " + buffer; + return "Extension " + type + ", signature_algorithms: " + sb; } } diff -r 3e8e199e23b2 src/share/classes/sun/security/tools/jarsigner/Main.java --- a/src/share/classes/sun/security/tools/jarsigner/Main.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/tools/jarsigner/Main.java Mon May 12 07:17:17 2014 -0300 @@ -687,7 +687,7 @@ output.put(label, new ArrayList()); } - StringBuffer fb = new StringBuffer(); + StringBuilder fb = new StringBuilder(); String s = Long.toString(je.getSize()); for (int i = 6 - s.length(); i > 0; --i) { fb.append(' '); @@ -1531,25 +1531,25 @@ if (cacheForSignerInfo.containsKey(signer)) { return cacheForSignerInfo.get(signer); } - StringBuffer s = new StringBuffer(); + StringBuilder sb = new StringBuilder(); List certs = signer.getSignerCertPath().getCertificates(); // display the signature timestamp, if present Date timestamp; Timestamp ts = signer.getTimestamp(); if (ts != null) { - s.append(printTimestamp(tab, ts)); - s.append('\n'); + sb.append(printTimestamp(tab, ts)); + sb.append('\n'); timestamp = ts.getTimestamp(); } else { timestamp = null; noTimestamp = true; } - // display the certificate(s). The first one is end-entity cert and + // display the certificate(sb). The first one is end-entity cert and // its KeyUsage should be checked. boolean first = true; for (Certificate c : certs) { - s.append(printCert(tab, c, true, timestamp, first)); - s.append('\n'); + sb.append(printCert(tab, c, true, timestamp, first)); + sb.append('\n'); first = false; } try { @@ -1565,11 +1565,11 @@ // No more warning, we alreay have hasExpiredCert or notYetValidCert } else { chainNotValidated = true; - s.append(tab + rb.getString(".CertPath.not.validated.") + + sb.append(tab + rb.getString(".CertPath.not.validated.") + e.getLocalizedMessage() + "]\n"); // TODO } } - String result = s.toString(); + String result = sb.toString(); cacheForSignerInfo.put(signer, result); return result; } diff -r 3e8e199e23b2 src/share/classes/sun/security/tools/keytool/Main.java --- a/src/share/classes/sun/security/tools/keytool/Main.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/tools/keytool/Main.java Mon May 12 07:17:17 2014 -0300 @@ -3618,7 +3618,7 @@ .startsWith(s.toLowerCase(Locale.ENGLISH))) { match[nmatch++] = i; } else { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); boolean first = true; for (char c: one.toCharArray()) { if (first) { @@ -3644,7 +3644,7 @@ if (match[1] > experiment) { return match[0]; } - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); MessageFormat form = new MessageFormat(rb.getString ("command.{0}.is.ambiguous.")); Object[] source = {s}; diff -r 3e8e199e23b2 src/share/classes/sun/security/tools/policytool/PolicyTool.java --- a/src/share/classes/sun/security/tools/policytool/PolicyTool.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/tools/policytool/PolicyTool.java Mon May 12 07:17:17 2014 -0300 @@ -975,16 +975,16 @@ String result = ""; if ((grantEntry.principals != null) && (!grantEntry.principals.isEmpty())) { - StringBuffer buffer = new StringBuffer(200); + StringBuilder sb = new StringBuilder(200); ListIterator list = grantEntry.principals.listIterator(); while (list.hasNext()) { PolicyParser.PrincipalEntry pppe = list.next(); - buffer.append(" Principal " + pppe.getDisplayClass() + " " + - pppe.getDisplayName(true)); - if (list.hasNext()) buffer.append(", "); + sb.append(" Principal " + pppe.getDisplayClass() + " " + + pppe.getDisplayName(true)); + if (list.hasNext()) sb.append(", "); } - result = buffer.toString(); + result = sb.toString(); } return result; } diff -r 3e8e199e23b2 src/share/classes/sun/security/util/Debug.java --- a/src/share/classes/sun/security/util/Debug.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/util/Debug.java Mon May 12 07:17:17 2014 -0300 @@ -188,13 +188,13 @@ */ public static String toHexString(BigInteger b) { String hexValue = b.toString(16); - StringBuffer buf = new StringBuffer(hexValue.length()*2); + StringBuilder sb = new StringBuilder(hexValue.length()*2); if (hexValue.startsWith("-")) { - buf.append(" -"); + sb.append(" -"); hexValue = hexValue.substring(1); } else { - buf.append(" "); // four spaces + sb.append(" "); // four spaces } if ((hexValue.length()%2) != 0) { // add back the leading 0 @@ -203,17 +203,17 @@ int i=0; while (i < hexValue.length()) { // one byte at a time - buf.append(hexValue.substring(i, i+2)); + sb.append(hexValue.substring(i, i + 2)); i+=2; if (i!= hexValue.length()) { if ((i%64) == 0) { - buf.append("\n "); // line after eight words + sb.append("\n "); // line after eight words } else if (i%8 == 0) { - buf.append(" "); // space between words + sb.append(" "); // space between words } } } - return buf.toString(); + return sb.toString(); } /** @@ -221,7 +221,7 @@ */ private static String marshal(String args) { if (args != null) { - StringBuffer target = new StringBuffer(); + StringBuilder target = new StringBuilder(); StringBuffer source = new StringBuffer(args); // obtain the "permission=" options diff -r 3e8e199e23b2 src/share/classes/sun/security/util/ManifestEntryVerifier.java --- a/src/share/classes/sun/security/util/ManifestEntryVerifier.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/util/ManifestEntryVerifier.java Mon May 12 07:17:17 2014 -0300 @@ -238,7 +238,7 @@ static String toHex(byte[] data) { - StringBuffer sb = new StringBuffer(data.length*2); + StringBuilder sb = new StringBuilder(data.length*2); for (int i=0; i>4) & 0x0f]); diff -r 3e8e199e23b2 src/share/classes/sun/security/util/ObjectIdentifier.java --- a/src/share/classes/sun/security/util/ObjectIdentifier.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/util/ObjectIdentifier.java Mon May 12 07:17:17 2014 -0300 @@ -418,7 +418,7 @@ String s = stringForm; if (s == null) { int length = encoding.length; - StringBuffer sb = new StringBuffer(length * 4); + StringBuilder sb = new StringBuilder(length * 4); int fromPos = 0; for (int i = 0; i < length; i++) { diff -r 3e8e199e23b2 src/share/classes/sun/security/util/PropertyExpander.java --- a/src/share/classes/sun/security/util/PropertyExpander.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/util/PropertyExpander.java Mon May 12 07:17:17 2014 -0300 @@ -67,7 +67,7 @@ // no special characters if (p == -1) return value; - StringBuffer sb = new StringBuffer(value.length()); + StringBuilder sb = new StringBuilder(value.length()); int max = value.length(); int i = 0; // index of last character we copied diff -r 3e8e199e23b2 src/share/classes/sun/security/util/SignatureFileVerifier.java --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java Mon May 12 07:17:17 2014 -0300 @@ -552,7 +552,7 @@ static String toHex(byte[] data) { - StringBuffer sb = new StringBuffer(data.length*2); + StringBuilder sb = new StringBuilder(data.length*2); for (int i=0; i>4) & 0x0f]); diff -r 3e8e199e23b2 src/share/classes/sun/security/x509/X509CRLImpl.java --- a/src/share/classes/sun/security/x509/X509CRLImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/security/x509/X509CRLImpl.java Mon May 12 07:17:17 2014 -0300 @@ -536,7 +536,7 @@ * @return value of this CRL in a printable form. */ public String toString() { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("X.509 CRL v" + (version+1) + "\n"); if (sigAlgId != null) sb.append("Signature Algorithm: " + sigAlgId.toString() + diff -r 3e8e199e23b2 src/share/classes/sun/swing/SwingUtilities2.java --- a/src/share/classes/sun/swing/SwingUtilities2.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/swing/SwingUtilities2.java Mon May 12 07:17:17 2014 -0300 @@ -1365,7 +1365,7 @@ } public static String displayPropertiesToCSS(Font font, Color fg) { - StringBuffer rule = new StringBuffer("body {"); + StringBuilder rule = new StringBuilder("body {"); if (font != null) { rule.append(" font-family: "); rule.append(font.getFamily()); diff -r 3e8e199e23b2 src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java --- a/src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java Mon May 12 07:17:17 2014 -0300 @@ -673,33 +673,33 @@ public String toString() { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buf.append(super.toString()).append(','); + sb.append(super.toString()).append(','); - buf.append("data=").append(data).append(','); + sb.append("data=").append(data).append(','); - buf.append("font=").append(font).append(','); + sb.append("font=").append(font).append(','); - buf.append("insets=").append(insets).append(','); + sb.append("insets=").append(insets).append(','); - buf.append("synthGraphics=").append(synthGraphics).append(','); + sb.append("synthGraphics=").append(synthGraphics).append(','); - buf.append("painter=").append(painter).append(','); + sb.append("painter=").append(painter).append(','); StateInfo[] states = getStateInfo(); if (states != null) { - buf.append("states["); + sb.append("states["); for (StateInfo state : states) { - buf.append(state.toString()).append(','); + sb.append(state.toString()).append(','); } - buf.append(']').append(','); + sb.append(']').append(','); } // remove last newline - buf.deleteCharAt(buf.length() - 1); + sb.deleteCharAt(sb.length() - 1); - return buf.toString(); + return sb.toString(); } @@ -909,19 +909,19 @@ } public String toString() { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); - buf.append(super.toString()).append(','); + sb.append(super.toString()).append(','); - buf.append("state=").append(Integer.toString(state)).append(','); + sb.append("state=").append(Integer.toString(state)).append(','); - buf.append("font=").append(font).append(','); + sb.append("font=").append(font).append(','); if (colors != null) { - buf.append("colors=").append(Arrays.asList(colors)). + sb.append("colors=").append(Arrays.asList(colors)). append(','); } - return buf.toString(); + return sb.toString(); } } } diff -r 3e8e199e23b2 src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java --- a/src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Mon May 12 07:17:17 2014 -0300 @@ -439,20 +439,20 @@ } private String fileNameString(File[] files) { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); for (int i = 0; files != null && i < files.length; i++) { if (i > 0) { - buf.append(" "); + sb.append(" "); } if (files.length > 1) { - buf.append("\""); + sb.append("\""); } - buf.append(fileNameString(files[i])); + sb.append(fileNameString(files[i])); if (files.length > 1) { - buf.append("\""); + sb.append("\""); } } - return buf.toString(); + return sb.toString(); } public void uninstallUI(JComponent c) { diff -r 3e8e199e23b2 src/share/classes/sun/text/normalizer/UTF16.java --- a/src/share/classes/sun/text/normalizer/UTF16.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/text/normalizer/UTF16.java Mon May 12 07:17:17 2014 -0300 @@ -530,7 +530,7 @@ return String.valueOf((char)ch); } - StringBuffer result = new StringBuffer(); + StringBuilder result = new StringBuilder(); result.append(getLeadSurrogate(ch)); result.append(getTrailSurrogate(ch)); return result.toString(); diff -r 3e8e199e23b2 src/share/classes/sun/tools/java/MemberDefinition.java --- a/src/share/classes/sun/tools/java/MemberDefinition.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/java/MemberDefinition.java Mon May 12 07:17:17 2014 -0300 @@ -919,18 +919,18 @@ if (isInitializer()) { return isStatic() ? "static {}" : "instance {}"; } else if (isConstructor()) { - StringBuffer buf = new StringBuffer(); - buf.append(name); - buf.append('('); + StringBuilder sb = new StringBuilder(); + sb.append(name); + sb.append('('); Type argTypes[] = getType().getArgumentTypes(); for (int i = 0 ; i < argTypes.length ; i++) { if (i > 0) { - buf.append(','); + sb.append(','); } - buf.append(argTypes[i].toString()); + sb.append(argTypes[i].toString()); } - buf.append(')'); - return buf.toString(); + sb.append(')'); + return sb.toString(); } else if (isInnerClass()) { return getInnerClass().toString(); } diff -r 3e8e199e23b2 src/share/classes/sun/tools/java/MethodSet.java --- a/src/share/classes/sun/tools/java/MethodSet.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/java/MethodSet.java Mon May 12 07:17:17 2014 -0300 @@ -261,18 +261,18 @@ */ public String toString() { int len = size(); - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); Iterator all = iterator(); - buf.append("{"); + sb.append("{"); while (all.hasNext()) { - buf.append(all.next().toString()); + sb.append(all.next().toString()); len--; if (len > 0) { - buf.append(", "); + sb.append(", "); } } - buf.append("}"); - return buf.toString(); + sb.append("}"); + return sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/tools/java/MethodType.java --- a/src/share/classes/sun/tools/java/MethodType.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/java/MethodType.java Mon May 12 07:17:17 2014 -0300 @@ -91,17 +91,17 @@ } public String typeString(String id, boolean abbrev, boolean ret) { - StringBuffer buf = new StringBuffer(); - buf.append(id); - buf.append('('); + StringBuilder sb = new StringBuilder(); + sb.append(id); + sb.append('('); for (int i = 0 ; i < argTypes.length ; i++) { if (i > 0) { - buf.append(", "); + sb.append(", "); } - buf.append(argTypes[i].typeString("", abbrev, ret)); + sb.append(argTypes[i].typeString("", abbrev, ret)); } - buf.append(')'); + sb.append(')'); - return ret ? getReturnType().typeString(buf.toString(), abbrev, ret) : buf.toString(); + return ret ? getReturnType().typeString(sb.toString(), abbrev, ret) : sb.toString(); } } diff -r 3e8e199e23b2 src/share/classes/sun/tools/java/Parser.java --- a/src/share/classes/sun/tools/java/Parser.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/java/Parser.java Mon May 12 07:17:17 2014 -0300 @@ -1395,24 +1395,24 @@ return res; } - StringBuffer buf = new StringBuffer(res.id.toString()); + StringBuilder sb = new StringBuilder(res.id.toString()); while (token == FIELD) { scan(); if ((token == MUL) && star) { scan(); - buf.append(".*"); + sb.append(".*"); break; } - buf.append('.'); + sb.append('.'); if (token == IDENT) { - buf.append(scanner.idValue); + sb.append(scanner.idValue); } expect(IDENT); } - res.id = Identifier.lookup(buf.toString()); + res.id = Identifier.lookup(sb.toString()); return res; } /** diff -r 3e8e199e23b2 src/share/classes/sun/tools/java/Type.java --- a/src/share/classes/sun/tools/java/Type.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/java/Type.java Mon May 12 07:17:17 2014 -0300 @@ -274,15 +274,15 @@ * Create a method type with arguments. */ public static synchronized Type tMethod(Type returnType, Type argTypes[]) { - StringBuffer buf = new StringBuffer(); - buf.append(SIG_METHOD); + StringBuilder sb = new StringBuilder(); + sb.append(SIG_METHOD); for (int i = 0 ; i < argTypes.length ; i++) { - buf.append(argTypes[i].getTypeSignature()); + sb.append(argTypes[i].getTypeSignature()); } - buf.append(SIG_ENDMETHOD); - buf.append(returnType.getTypeSignature()); + sb.append(SIG_ENDMETHOD); + sb.append(returnType.getTypeSignature()); - String sig = buf.toString(); + String sig = sb.toString(); Type t = (Type)typeHash.get(sig); if (t == null) { t = new MethodType(sig, returnType, argTypes); diff -r 3e8e199e23b2 src/share/classes/sun/tools/jconsole/Formatter.java --- a/src/share/classes/sun/tools/jconsole/Formatter.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/Formatter.java Mon May 12 07:17:17 2014 -0300 @@ -232,15 +232,15 @@ } static String justify(String str, int size) { - StringBuffer buf = new StringBuffer(); - buf.append(""); + StringBuilder sb = new StringBuilder(); + sb.append(""); int n = size - str.length(); for (int i = 0; i < n; i++) { - buf.append(" "); + sb.append(" "); } - buf.append(str); - buf.append(""); - return buf.toString(); + sb.append(str); + sb.append(""); + return sb.toString(); } static String newRow(String label, String value) { diff -r 3e8e199e23b2 src/share/classes/sun/tools/jstatd/RemoteHostImpl.java --- a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java Mon May 12 07:17:17 2014 -0300 @@ -64,7 +64,7 @@ throws RemoteException, MonitorException { Integer v = new Integer(lvmid); RemoteVm stub = null; - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append("local://").append(lvmid).append("@localhost"); if (mode != null) { diff -r 3e8e199e23b2 src/share/classes/sun/tools/native2ascii/N2AFilter.java --- a/src/share/classes/sun/tools/native2ascii/N2AFilter.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/native2ascii/N2AFilter.java Mon May 12 07:17:17 2014 -0300 @@ -58,7 +58,7 @@ out.write('u'); String hex = Integer.toHexString(buf[i]); - StringBuffer hex4 = new StringBuffer(hex); + StringBuilder hex4 = new StringBuilder(hex); hex4.reverse(); int length = 4 - hex4.length(); for (int j = 0; j < length; j++) { diff -r 3e8e199e23b2 src/share/classes/sun/tools/serialver/SerialVer.java --- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/serialver/SerialVer.java Mon May 12 07:17:17 2014 -0300 @@ -186,7 +186,7 @@ /* Class not found so far */ } if (!classFound) { - StringBuffer workBuffer = new StringBuffer(classname); + StringBuilder workBuffer = new StringBuilder(classname); String workName = workBuffer.toString(); int i; while ((i = workName.lastIndexOf('.')) != -1 && !classFound) { diff -r 3e8e199e23b2 src/share/classes/sun/tools/tree/FieldExpression.java --- a/src/share/classes/sun/tools/tree/FieldExpression.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/tree/FieldExpression.java Mon May 12 07:17:17 2014 -0300 @@ -79,21 +79,21 @@ * Convert an '.' expression to a qualified identifier */ static public Identifier toIdentifier(Expression e) { - StringBuffer buf = new StringBuffer(); + StringBuilder sb = new StringBuilder(); while (e.op == FIELD) { FieldExpression fe = (FieldExpression)e; if (fe.id == idThis || fe.id == idClass) { return null; } - buf.insert(0, fe.id); - buf.insert(0, '.'); + sb.insert(0, fe.id); + sb.insert(0, '.'); e = fe.right; } if (e.op != IDENT) { return null; } - buf.insert(0, ((IdentifierExpression)e).id); - return Identifier.lookup(buf.toString()); + sb.insert(0, ((IdentifierExpression) e).id); + return Identifier.lookup(sb.toString()); } /** diff -r 3e8e199e23b2 src/share/classes/sun/tools/tree/Vset.java --- a/src/share/classes/sun/tools/tree/Vset.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tools/tree/Vset.java Mon May 12 07:17:17 2014 -0300 @@ -495,7 +495,7 @@ public String toString() { if (this == DEAD_END) return "{DEAD_END}"; - StringBuffer sb = new StringBuffer("{"); + StringBuilder sb = new StringBuilder("{"); int maxVar = VBITS * (1 + (x.length+1)/2); for (int i = 0; i < maxVar; i++) { if (!testVarUnassigned(i)) { diff -r 3e8e199e23b2 src/share/classes/sun/tracing/PrintStreamProviderFactory.java --- a/src/share/classes/sun/tracing/PrintStreamProviderFactory.java Thu Apr 24 12:21:10 2014 -0700 +++ b/src/share/classes/sun/tracing/PrintStreamProviderFactory.java Mon May 12 07:17:17 2014 -0300 @@ -99,7 +99,7 @@ } public void uncheckedTrigger(Object[] args) { - StringBuffer sb = new StringBuffer(); + StringBuilder sb = new StringBuilder(); sb.append(provider.getName()); sb.append("."); sb.append(name); From ivan.gerasimov at oracle.com Mon May 12 10:37:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 May 2014 14:37:08 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A454.2080402@oracle.com> Wouldn't it be a little bit more efficient to replace a string concatenation with yet another StringBuilder operation? src/share/classes/com/sun/java/util/jar/pack/BandStructure.java 631 StringBuilder sb = new StringBuilder(); ... 636 Utils.log.fine(" meta-coding "+sb); => 631 StringBuilder sb = new StringBuilder(" meta-coding "); ... 636 Utils.log.fine(sb); and 759 StringBuilder sb = new StringBuilder(); ... 764 ps.print(" //header: "+sb); => 759 StringBuilder sb = new StringBuilder(" //header: "); ... 764 ps.print(sb); Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. > > This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > > From Alan.Bateman at oracle.com Mon May 12 10:42:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 May 2014 11:42:54 +0100 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A5AE.4080909@oracle.com> On 12/05/2014 11:03, Paul Sandoz wrote: > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. The groupings are a bit odd but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g. You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging. As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests. One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal. -Alan. From paul.sandoz at oracle.com Mon May 12 10:55:13 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 12:55:13 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A5AE.4080909@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> Message-ID: <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> On May 12, 2014, at 12:42 PM, Alan Bateman wrote: > On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. > The groupings are a bit odd Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Thanks! > Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g. > It might be worth fixing those if they are not too disruptive. > You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging. > Yes. > As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests. > Ok. > One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal. > I fixed that. Paul. From ivan.gerasimov at oracle.com Mon May 12 11:00:04 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 May 2014 15:00:04 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A9B4.80809@oracle.com> src/share/classes/sun/misc/UUDecoder.java 126 StringBuilder x = new StringBuilder(); Is only filled, but doesn't seem to be used anyhow. Maybe just delete it? Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing > under one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each > file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to > pull in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your > single ("uber") patch as textual attachment? (IIUC such attachments > should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > From xuelei.fan at oracle.com Mon May 12 11:17:43 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 May 2014 19:17:43 +0800 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370ADD7.4070208@oracle.com> > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ Looks fine to me. Thanks for making this update. Xuelei On 5/12/2014 6:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each file > and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull > in ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now > be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From mark.sheppard at oracle.com Mon May 12 11:33:05 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 12 May 2014 12:33:05 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> Message-ID: <5370B171.5070005@oracle.com> If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent seem to match the previous semantics of the if statement? computeIfAbsent: "If the value for the specified key is present and non-null, attempts to compute a new mapping given the key and its current mapped value." or "If the specified key is not already associated with a value (or is mapped to |null|), attempts to compute its value using the given mapping function and enters it into this map unless |null|. " my interpretation is this is relevant if value if there exist a value and you want to update? putIfAbsent: "If the specified key is not already associated with a value (or is mapped to |null|) associates it with the given value and returns |null|, else returns the current value." in this case we can have null value returned previous semantics were if the PM doesn't exist then instantiate and cache it in the hashtable. return the PM - no null value returned maybe I'm misinterpreting the docs regards Mark On 12/05/2014 08:52, Se?n Coffey wrote: > Good tip Alan/Chris. > > I'll make that change and push. > > Regards, > Sean. > > On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman wrote: >> On 11/05/2014 21:56, Se?n Coffey wrote: >>> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can >>> remove use of reflection in ORB code to access the applet context. >>> >>> bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ >> I agree with Chris that computeIfAbsent is best here, that was also the >> >> suggestion back in early April before the bootstrapping issue came up. >> In any case, it's good you are re-visiting this to clean it up. >> >> -Alan From chris.hegarty at oracle.com Mon May 12 12:45:59 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 May 2014 13:45:59 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <5370B171.5070005@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> Message-ID: <5370C287.8030800@oracle.com> On 12/05/14 12:33, Mark Sheppard wrote: > If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent > seem to match the > previous semantics of the if statement? > > computeIfAbsent: "If the value for the specified key is present and > non-null, attempts to compute a new mapping given the key and its > current mapped value." I think this is from computeIfPresent, rather than computeIfAbsent. > or > "If the specified key is not already associated with a value (or is > mapped to |null|), attempts to compute its value using the given mapping > function and enters it into this map unless |null|. " > my interpretation is this is relevant if value if there exist a value > and you want to update? Remapping is computeIfPresent. > putIfAbsent: "If the specified key is not already associated with a > value (or is mapped to |null|) associates it with the given value and > returns |null|, else returns the current value." > in this case we can have null value returned Yes, computeIfAbsent is not a swap in replacement here. > previous semantics were if the PM doesn't exist then instantiate and > cache it in the hashtable. return the PM - no null value returned The return value will be whatever, null of otherwise, is returned from setupPresentationManager, which is exactly what computeIfAbsent does. -Chris. > > maybe I'm misinterpreting the docs > > regards > Mark > On 12/05/2014 08:52, Se?n Coffey wrote: >> Good tip Alan/Chris. >> >> I'll make that change and push. >> >> Regards, >> Sean. >> >> On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman >> wrote: >>> On 11/05/2014 21:56, Se?n Coffey wrote: >>>> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can >>>> remove use of reflection in ORB code to access the applet context. >>>> >>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ >>> I agree with Chris that computeIfAbsent is best here, that was also the >>> >>> suggestion back in early April before the bootstrapping issue came up. >>> In any case, it's good you are re-visiting this to clean it up. >>> >>> -Alan > From daniel.fuchs at oracle.com Mon May 12 12:46:58 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 May 2014 14:46:58 +0200 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <5370B171.5070005@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> Message-ID: <5370C2C2.7040907@oracle.com> Hi Mark, AFAIKS computeIfAbsent does what we want: It seems that putIfAbsent would not though. This is indeed confusing. I wish putIfAbsent had been specified similarly to computeIfAbsent... best regards, -- daniel ConcurrentHashMap seems to have something more On 5/12/14 1:33 PM, Mark Sheppard wrote: > If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent > seem to match the > previous semantics of the if statement? > > computeIfAbsent: "If the value for the specified key is present and > non-null, attempts to compute a new mapping given the key and its > current mapped value." > or > "If the specified key is not already associated with a value (or is > mapped to |null|), attempts to compute its value using the given mapping > function and enters it into this map unless |null|. " > my interpretation is this is relevant if value if there exist a value > and you want to update? > > putIfAbsent: "If the specified key is not already associated with a > value (or is mapped to |null|) associates it with the given value and > returns |null|, else returns the current value." > in this case we can have null value returned > > previous semantics were if the PM doesn't exist then instantiate and > cache it in the hashtable. return the PM - no null value returned > > maybe I'm misinterpreting the docs > > regards > Mark > On 12/05/2014 08:52, Se?n Coffey wrote: >> Good tip Alan/Chris. >> >> I'll make that change and push. >> >> Regards, >> Sean. >> >> On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman >> wrote: >>> On 11/05/2014 21:56, Se?n Coffey wrote: >>>> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can >>>> remove use of reflection in ORB code to access the applet context. >>>> >>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ >>> I agree with Chris that computeIfAbsent is best here, that was also the >>> >>> suggestion back in early April before the bootstrapping issue came up. >>> In any case, it's good you are re-visiting this to clean it up. >>> >>> -Alan > From mark.sheppard at oracle.com Mon May 12 13:35:30 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 12 May 2014 14:35:30 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <5370C2C2.7040907@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> <5370C2C2.7040907@oracle.com> Message-ID: <5370CE22.1020707@oracle.com> OK thanks Chris and Daniel ... I see my misinterpretation now regards Mark On 12/05/2014 13:46, Daniel Fuchs wrote: > Hi Mark, > > AFAIKS computeIfAbsent does what we want: > > > > > It seems that putIfAbsent would not though. This is indeed confusing. > I wish putIfAbsent had been specified similarly to > computeIfAbsent... > > best regards, > > -- daniel > > ConcurrentHashMap seems to have something more > > On 5/12/14 1:33 PM, Mark Sheppard wrote: >> If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent >> seem to match the >> previous semantics of the if statement? >> >> computeIfAbsent: "If the value for the specified key is present and >> non-null, attempts to compute a new mapping given the key and its >> current mapped value." >> or >> "If the specified key is not already associated with a value (or is >> mapped to |null|), attempts to compute its value using the given mapping >> function and enters it into this map unless |null|. " >> my interpretation is this is relevant if value if there exist a value >> and you want to update? >> >> putIfAbsent: "If the specified key is not already associated with a >> value (or is mapped to |null|) associates it with the given value and >> returns |null|, else returns the current value." >> in this case we can have null value returned >> >> previous semantics were if the PM doesn't exist then instantiate and >> cache it in the hashtable. return the PM - no null value returned >> >> maybe I'm misinterpreting the docs >> >> regards >> Mark >> On 12/05/2014 08:52, Se?n Coffey wrote: >>> Good tip Alan/Chris. >>> >>> I'll make that change and push. >>> >>> Regards, >>> Sean. >>> >>> On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman >>> wrote: >>>> On 11/05/2014 21:56, Se?n Coffey wrote: >>>>> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can >>>>> remove use of reflection in ORB code to access the applet context. >>>>> >>>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ >>>> I agree with Chris that computeIfAbsent is best here, that was also >>>> the >>>> >>>> suggestion back in early April before the bootstrapping issue came up. >>>> In any case, it's good you are re-visiting this to clean it up. >>>> >>>> -Alan >> > From daniel.fuchs at oracle.com Mon May 12 14:07:57 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 May 2014 16:07:57 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370D5BD.4030503@oracle.com> Hi Paul, I looked at -management and the changes there look good. There is just some two spaces vs four space formatting in line 99. best regards, -- daniel On 5/12/14 12:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each file > and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull > in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now > be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From me at sandipan.net Mon May 12 15:43:02 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Mon, 12 May 2014 11:43:02 -0400 Subject: JDK-8037382 Sequence and SequenceSet interface In-Reply-To: References: Message-ID: Hi Remi - Thank you for the fast response, I have indeed signed the OCA. I shall work on the bug you suggested (JDK-8037343) over the week and submit a patch. Note that my work on OpenJDK is outside of work hours so will likely only get a chance this weekend. Cheers, SR Sandipan Razzaque | www.sandipan.net From: Remi Forax To: core-libs-dev at openjdk.java.net Subject: Re: JDK-8037382 Sequence and SequenceSet interface Message-ID: <53700000.8010801 at univ-mlv.fr> Content-Type: text/plain; charset=UTF-8; format=flowed On 05/12/2014 12:35 AM, Sandipan Razzaque wrote: > Hi all, > > I'm looking to get started making contributions :-) I figured I'd start > with something that was fairly prescriptive and mechanical just to get the > hang of the process. Two questions if I may, as per the contribution guide: > > * Is anyone already working on the above item? (I do not wish to duplicate > effort.) > * Are there any objections to the changes already laid out in the ticket? > > If all is well, I shall get started with a patch for review. > > Cheers, > SR > > https://bugs.openjdk.java.net/browse/JDK-8037382 > > Sandipan Razzaque | www.sandipan.net Hi Sandipan, I suppose that you have already sign the OCA. In my opinion, this bug is too big for a first contribution, any change to java.util collection require coordination between several people. I think you should start with something smaller, what do you think about this one: https://bugs.openjdk.java.net/browse/JDK-8037343 cheers, R?mi From peter.levart at gmail.com Mon May 12 15:51:31 2014 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 12 May 2014 17:51:31 +0200 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: References: <5332F00D.1020806@gmail.com> <533ABC14.50304@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> <5369E3DD.4020102@gmail.com> Message-ID: <5370EE03.1040003@gmail.com> On 05/07/2014 11:04 PM, Martin Buchholz wrote: > Hi Peter, > > Your last version version looks very good. Approved! I'm reduced to > asking you to fix ancient buglets of mine. > > *"I'd spell creat with an e.*" > > > 188 * Create a process. Depending on the mode flag, this is done by > *"I'd spell Create with an s.*" > > > Alan, Martin, Roger, thank you for your patience in reviewing this. Thanks also to Paul, David M., Rob and Volker for comments and testing. I have just pushed this changeset to jdk9-dev with a little javadoc tweak on a private native method suggested by Martin, fixing also the description of the 'mode' parameter to be in-sync with what it really means in native code. We can take this as a basis for consolidating some more code after some bake-in time... Regards, Peter > > > > On Wed, May 7, 2014 at 12:42 AM, Peter Levart > wrote: > > Hi Martin, > > I have restructured the processReaperExecutor construction. It now > incorporates system thread group search and thread pool > construction in one doPrivileged call. I also extracted the > creation of ThreadFactory into a local variable so it's more > explicit now. Here's the webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.09/ > > ...java/lang/ProcessBuilder tests still pass. > > Regards, Peter > > P.S. I don't belive Executors.newCachedTreadPool() could > strengthen security in future, since this would break existing > user code. The javadoc does not specify any SecurityExceptions. > But anyway - wrapping the whole logic of processReaperExecutor > construction in one doPrivileged call allowed me to use local > variables instead of private static final fields for > systemThreadGroup and threadFactory, so this looks nicer too. > > > > On 05/06/2014 07:41 PM, Martin Buchholz wrote: >> >> >> >> On Sun, May 4, 2014 at 3:26 AM, Peter Levart >> > wrote: >> >> >> Ah, I've forgotten to mention the most important change from >> webrev.07. >> >> Original code wraps the processReaperExecutor construction >> into the doPrivileged() call. I think this was not needed. >> >> The Executors.newCachedThreadPool() does not need any special >> privileges. And construction of nested class >> ProcessReaperThreadFactory also didn't need any special >> privileges - apart from static initialization which called >> the getRootThreadGroup() method. But that method did it's own >> doPrivileged() wrapping in order to be able to climb the >> ThreadGroup hierarchy (which requires privilege). In >> webrev.07 I followed original code and wrapped the >> construction of a processReaperExecutor into a doPrivileged() >> although in webrev.07 the rootThreadGroup search happens as >> part of UNIXProcess static initialization and is already >> wrapped in doPrivileged(). In webrev.08 I removed this >> superfluous doPrivileged(). I think this is correct. >> SecurityManagerClinit test passes. >> >> >> Although I think you're right with the current implementation, it >> seems too brittle to me to remove the doPrivileged, since you >> have no idea what future changes to newCachedThreadPool() might >> do (or what other JDK implementations might do); notably it might >> instantiate some kind of micro-manager thread or do some other >> privileged operation. >> >> If you want to have only one call to doPrivileged, you can cause >> both rootThreadGroup and processReaperExecutor to be initialized >> in one static block, although you will need to jump through some >> hoops to keep these fields final. >> >> --- >> >> As it stands, >> >> Executors.newCachedThreadPool(grimReaper -> { >> >> doesn't mention either the type ThreadFactory or Runnable. >> >> It might be clearer (more verbosity in the spirit of Java) if you >> used explicit ThreadFactory type >> >> ThreadFactory factory = grimReaper -> ... > > From rob.mckenna at oracle.com Mon May 12 16:06:24 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 12 May 2014 17:06:24 +0100 Subject: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix) In-Reply-To: <5370EE03.1040003@gmail.com> References: <5332F00D.1020806@gmail.com> <533AC3E9.3060406@oracle.com> <533ADEB3.2040306@gmail.com> <533AF19A.1060709@gmail.com> <533B17CA.6030203@oracle.com> <533BEB31.6050307@gmail.com> <533C0DFF.5020508@oracle.com> <533C3549.3030602@gmail.com> <533F06FC.40102@oracle.com> <534FF438.7000601@gmail.com> <53504C52.3020509@gmail.com> <535A3332.4070909@gmail.com> <535A6407.9040705@oracle.com> <535A8AF2.1050908@gmail.com> <535A91AD.4040405@oracle.com> <536113EE.3060100@oracle.com> <536612A4.6090406@gmail.com> <536615DA.2080808@gmail.com> <5369E3DD.4020102@gmail.com> <5370EE03.1040003@gmail.com> Message-ID: <5370F180.3010006@oracle.com> Great to see this getting in. Thanks Peter! -Rob On 12/05/14 16:51, Peter Levart wrote: > On 05/07/2014 11:04 PM, Martin Buchholz wrote: >> Hi Peter, >> >> Your last version version looks very good. Approved! I'm reduced to >> asking you to fix ancient buglets of mine. >> >> *"I'd spell creat with an e.*" >> >> >> 188 * Create a process. Depending on the mode flag, this is done by >> *"I'd spell Create with an s.*" >> >> >> > > Alan, Martin, Roger, thank you for your patience in reviewing this. > Thanks also to Paul, David M., Rob and Volker for comments and > testing. I have just pushed this changeset to jdk9-dev with a little > javadoc tweak on a private native method suggested by Martin, fixing > also the description of the 'mode' parameter to be in-sync with what > it really means in native code. > > We can take this as a basis for consolidating some more code after > some bake-in time... > > Regards, Peter > >> >> >> >> On Wed, May 7, 2014 at 12:42 AM, Peter Levart > > wrote: >> >> Hi Martin, >> >> I have restructured the processReaperExecutor construction. It >> now incorporates system thread group search and thread pool >> construction in one doPrivileged call. I also extracted the >> creation of ThreadFactory into a local variable so it's more >> explicit now. Here's the webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.09/ >> >> >> ...java/lang/ProcessBuilder tests still pass. >> >> Regards, Peter >> >> P.S. I don't belive Executors.newCachedTreadPool() could >> strengthen security in future, since this would break existing >> user code. The javadoc does not specify any SecurityExceptions. >> But anyway - wrapping the whole logic of processReaperExecutor >> construction in one doPrivileged call allowed me to use local >> variables instead of private static final fields for >> systemThreadGroup and threadFactory, so this looks nicer too. >> >> >> >> On 05/06/2014 07:41 PM, Martin Buchholz wrote: >>> >>> >>> >>> On Sun, May 4, 2014 at 3:26 AM, Peter Levart >>> > wrote: >>> >>> >>> Ah, I've forgotten to mention the most important change from >>> webrev.07. >>> >>> Original code wraps the processReaperExecutor construction >>> into the doPrivileged() call. I think this was not needed. >>> >>> The Executors.newCachedThreadPool() does not need any >>> special privileges. And construction of nested class >>> ProcessReaperThreadFactory also didn't need any special >>> privileges - apart from static initialization which called >>> the getRootThreadGroup() method. But that method did it's >>> own doPrivileged() wrapping in order to be able to climb the >>> ThreadGroup hierarchy (which requires privilege). In >>> webrev.07 I followed original code and wrapped the >>> construction of a processReaperExecutor into a >>> doPrivileged() although in webrev.07 the rootThreadGroup >>> search happens as part of UNIXProcess static initialization >>> and is already wrapped in doPrivileged(). In webrev.08 I >>> removed this superfluous doPrivileged(). I think this is >>> correct. SecurityManagerClinit test passes. >>> >>> >>> Although I think you're right with the current implementation, >>> it seems too brittle to me to remove the doPrivileged, since you >>> have no idea what future changes to newCachedThreadPool() might >>> do (or what other JDK implementations might do); notably it >>> might instantiate some kind of micro-manager thread or do some >>> other privileged operation. >>> >>> If you want to have only one call to doPrivileged, you can cause >>> both rootThreadGroup and processReaperExecutor to be initialized >>> in one static block, although you will need to jump through some >>> hoops to keep these fields final. >>> >>> --- >>> >>> As it stands, >>> >>> Executors.newCachedThreadPool(grimReaper -> { >>> >>> doesn't mention either the type ThreadFactory or Runnable. >>> >>> It might be clearer (more verbosity in the spirit of Java) if >>> you used explicit ThreadFactory type >>> >>> ThreadFactory factory = grimReaper -> ... >> >> > From alexfanando at yahoo.com Tue May 6 03:51:02 2014 From: alexfanando at yahoo.com (Alex Fanando) Date: Mon, 5 May 2014 20:51:02 -0700 (PDT) Subject: Infiniband-SDP in Java Message-ID: <1399348262.65273.YahooMailNeo@web125903.mail.ne1.yahoo.com> Hi All, As you all know, OFED's Socket Direct protocol is deprecated and OFED's 3.x releases do not come with SDP at all. Hence, Java's SDP also fails to work. I was wondering what is the proper method to program infiniband in Java? Is there any portable solution other than just writing JNI code? My requirement is achieve RDMA among collection of infiniband powered machines. Regards,Robo From forax at univ-mlv.fr Mon May 12 16:43:05 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 May 2014 18:43:05 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A5AE.4080909@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> Message-ID: <5370FA19.9090107@univ-mlv.fr> On 05/12/2014 12:42 PM, Alan Bateman wrote: > On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas >> to aid reviewing. When commenting please including core-libs. > The groupings are a bit odd but I looked through the -core, -io, > -management and -rmi patches and don't see any issues. Nothing jumped > out to suggest that the StringBuffer could be leaked to other threads. > There are a few cases where additional work could be done but I assume > you want to focus on s/StringBuffer/StringBuilder/g. > > You might want to hear from Remi or Kumar before including asm. I > mention it because there might be preference to get changes to ASM > done upstream to avoid the copy in OpenJDK from diverging. Hi all, I've applied the changes to the ASM trunk so Kumar can sync when he wants, the current revision of the trunk is 1745 cheers, R?mi From paul.sandoz at oracle.com Mon May 12 16:56:09 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 18:56:09 +0200 Subject: inefficient indexof when String has one length In-Reply-To: References: Message-ID: <8AEA68DB-8351-4EE1-8D3D-0EB9D475FA70@oracle.com> On Apr 26, 2014, at 12:56 PM, Ot?vio Gon?alves de Santana wrote: > When a String has length just one, could be replaced by equivalent > character literals, gaining some performance enhancement. > > I found 107 changes. > This looks good to me, just one small issue: --- a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java Sat Apr 26 07:31:04 2014 -0300 @@ -495,7 +495,7 @@ // perform new initialization from the permission name - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") == -1) { + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') == -1) { You no longer need to escape the double quote. Can someone else sponsor this? unfortunately i do not have the time at the moment. Paul. From Alan.Bateman at oracle.com Mon May 12 18:02:57 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 May 2014 19:02:57 +0100 Subject: 8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser Message-ID: <53710CD1.4050306@oracle.com> In JDK 8 we brought in a tiny XML parser to support the Properties loadFromXML/storeToXML methods. We needed this for the Compact Profiles work, specifically builds of compact1 as they do not have JAXP/XML APIs. At the time we were a bit nervous about switching the XML parser for anything other than compact1 builds. One reason for this was that the original javadoc didn't constrain the encodings that has to be supported, another reason was confidence in the tests as we didn't have too many tests for these methods in the jdk repository. I'd like to revisit one and switch over the implementation to always use the small parser. This allows for some clean-up, specifically it removes the need for the JDK-internal service type that was needed to use the JAXP code. On the original concerns then the spec was clarified in 8 to only require UTF-8 and UTF-16. In addition there were several tests added to better exercise these methods and the implementation. Also I think switching this early in JDK 9 means that we maximize the time to hear about any issues. The webrev with the proposed changes is here, mostly red=removal so easy to review: http://cr.openjdk.java.net/~alanb/8042889/webrev/ -Alan. From huizhe.wang at oracle.com Mon May 12 19:22:06 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 12 May 2014 12:22:06 -0700 Subject: 8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser In-Reply-To: <53710CD1.4050306@oracle.com> References: <53710CD1.4050306@oracle.com> Message-ID: <53711F5E.4080909@oracle.com> Hi Alan, The webrev looks good to me. On 5/12/2014 11:02 AM, Alan Bateman wrote: > > In JDK 8 we brought in a tiny XML parser to support the Properties > loadFromXML/storeToXML methods. We needed this for the Compact > Profiles work, specifically builds of compact1 as they do not have > JAXP/XML APIs. > > At the time we were a bit nervous about switching the XML parser for > anything other than compact1 builds. One reason for this was that the > original javadoc didn't constrain the encodings that has to be > supported, another reason was confidence in the tests as we didn't > have too many tests for these methods in the jdk repository. Yes, there may be a compatibility concern in case an application attempts to read a Properties file previously saved with a different encoding. > > I'd like to revisit one and switch over the implementation to always > use the small parser. This allows for some clean-up, specifically it > removes the need for the JDK-internal service type that was needed to > use the JAXP code. On the original concerns then the spec was > clarified in 8 to only require UTF-8 and UTF-16. In addition there > were several tests added to better exercise these methods and the > implementation. Also I think switching this early in JDK 9 means that > we maximize the time to hear about any issues. Would you think the wordings in the javadoc of Properties could be stronger in terms of encoding, e.g. instead of: The |loadFromXML(InputStream)| and |storeToXML(OutputStream, String, String)| methods load and store properties in a simple XML format. By default the UTF-8 character encoding is used, however a specific encoding may be specified if required. Implementations are required to support UTF-8 and UTF-16 and may support other encodings. change it to: The |loadFromXML(InputStream)| and |storeToXML(OutputStream, String, String)| methods load and store properties in a simple XML format. The default character encoding is UTF-8 which is the recommended encoding for all Properties files in XML format. Applications should use UTF-8 to avoid potential encoding errors. Implementations are required to support UTF-8 and UTF-16. XML specification requires processors to support both UTF-8 and 16. But UTF-8 is the dominant encoding for XML files. The above suggestion is "stronger" in terms of using UTF-8, but not as strong as for example, Google's Sitemap service that was straight forward in their requirement: "We require your Sitemap file to be UTF-8 encoded". -Joe > > The webrev with the proposed changes is here, mostly red=removal so > easy to review: > > http://cr.openjdk.java.net/~alanb/8042889/webrev/ > > -Alan. From roger.riggs at oracle.com Mon May 12 19:44:24 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 12 May 2014 15:44:24 -0400 Subject: RFR 9: 8003488 Add Process.getPid Message-ID: <53712498.20603@oracle.com> Please review and comment on this long requested addition to provide the native process id of a spawned Process. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 Thanks, Roger From chris.hegarty at oracle.com Mon May 12 20:35:52 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 May 2014 21:35:52 +0100 Subject: 8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser In-Reply-To: <53710CD1.4050306@oracle.com> References: <53710CD1.4050306@oracle.com> Message-ID: > On 12 May 2014, at 19:02, Alan Bateman wrote: > > > In JDK 8 we brought in a tiny XML parser to support the Properties loadFromXML/storeToXML methods. We needed this for the Compact Profiles work, specifically builds of compact1 as they do not have JAXP/XML APIs. > > At the time we were a bit nervous about switching the XML parser for anything other than compact1 builds. One reason for this was that the original javadoc didn't constrain the encodings that has to be supported, another reason was confidence in the tests as we didn't have too many tests for these methods in the jdk repository. > > I'd like to revisit one and switch over the implementation to always use the small parser. This allows for some clean-up, specifically it removes the need for the JDK-internal service type that was needed to use the JAXP code. On the original concerns then the spec was clarified in 8 to only require UTF-8 and UTF-16. In addition there were several tests added to better exercise these methods and the implementation. Also I think switching this early in JDK 9 means that we maximize the time to hear about any issues. > > The webrev with the proposed changes is here, mostly red=removal so easy to review: The code changes look good to me. I like red ;-) -Chris. > > http://cr.openjdk.java.net/~alanb/8042889/webrev/ > > -Alan. From martinrb at google.com Mon May 12 20:47:22 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 12 May 2014 13:47:22 -0700 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <53712498.20603@oracle.com> References: <53712498.20603@oracle.com> Message-ID: Thanks for taking on yet another task that has been on my TODO list for a decade. I decided many years ago that the "process identifier" should actually be a string (or at least not something as constrained as an int), in keeping with Java's OS-independent nature, even though all implementations may in fact use an integer. IIRC, Apollo computers used a hostname/int pair as a process identifier, and such a convention may become popular again in the future. Furthermore, returning a string is in practice at least as convenient, since the only thing you can typically do with a pid today is pass it as a string to a system command like "kill". On Mon, May 12, 2014 at 12:44 PM, roger riggs wrote: > Please review and comment on this long requested addition to provide the > native process id of a spawned Process. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > Thanks, Roger > > From roger.riggs at oracle.com Mon May 12 20:50:59 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 12 May 2014 16:50:59 -0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: References: <53712498.20603@oracle.com> Message-ID: <53713433.6060900@oracle.com> Hi Martin, Alan mentioned this case but it seemed more difficult to use than the primitive. For the other parts of JEP 102, I expect to represent a process with a type that can have additional methods. That type would provide stronger typing and a set of useful operations. It seems less desirable to use a String in those cases. Roger On 5/12/2014 4:47 PM, Martin Buchholz wrote: > Thanks for taking on yet another task that has been on my TODO list > for a decade. > > I decided many years ago that the "process identifier" should actually > be a string (or at least not something as constrained as an int), in > keeping with Java's OS-independent nature, even though all > implementations may in fact use an integer. IIRC, Apollo computers > used a hostname/int pair as a process identifier, and such a > convention may become popular again in the future. > > Furthermore, returning a string is in practice at least as convenient, > since the only thing you can typically do with a pid today is pass it > as a string to a system command like "kill". > > > On Mon, May 12, 2014 at 12:44 PM, roger riggs > wrote: > > Please review and comment on this long requested addition to > provide the > native process id of a spawned Process. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > Thanks, Roger > > From pbenedict at apache.org Mon May 12 20:52:08 2014 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 12 May 2014 15:52:08 -0500 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: References: <53712498.20603@oracle.com> Message-ID: I was thinking about this ticket today. Regarding Alan Bateman's comment that the pid may not be representable as an int/long, I was expecting some sort of Pid-like-object to be returned. I'd rather see an abstraction that *might* be able to convert into an int/long ... or even a String, as Martin B. just said. Cheers, Paul On Mon, May 12, 2014 at 3:47 PM, Martin Buchholz wrote: > Thanks for taking on yet another task that has been on my TODO list for a > decade. > > I decided many years ago that the "process identifier" should actually be a > string (or at least not something as constrained as an int), in keeping > with Java's OS-independent nature, even though all implementations may in > fact use an integer. IIRC, Apollo computers used a hostname/int pair as a > process identifier, and such a convention may become popular again in the > future. > > Furthermore, returning a string is in practice at least as convenient, > since the only thing you can typically do with a pid today is pass it as a > string to a system command like "kill". > > > On Mon, May 12, 2014 at 12:44 PM, roger riggs >wrote: > > > Please review and comment on this long requested addition to provide the > > native process id of a spawned Process. > > > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > > > Thanks, Roger > > > > > From martinrb at google.com Mon May 12 20:59:24 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 12 May 2014 13:59:24 -0700 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: References: <53712498.20603@oracle.com> Message-ID: Alan has by far the most experience with system-dependent java objects that have some kind of static structure, but enough flexibility to adapt dynamically to different systems. Perhaps Alan could apply some of that design expertise to e.g. java.lang.Process. On Mon, May 12, 2014 at 1:52 PM, Paul Benedict wrote: > I was thinking about this ticket today. Regarding Alan Bateman's comment > that the pid may not be representable as an int/long, I was expecting some > sort of Pid-like-object to be returned. I'd rather see an abstraction that > *might* be able to convert into an int/long ... or even a String, as Martin > B. just said. > > > Cheers, > Paul > > > On Mon, May 12, 2014 at 3:47 PM, Martin Buchholz wrote: > >> Thanks for taking on yet another task that has been on my TODO list for a >> decade. >> >> I decided many years ago that the "process identifier" should actually be >> a >> string (or at least not something as constrained as an int), in keeping >> with Java's OS-independent nature, even though all implementations may in >> fact use an integer. IIRC, Apollo computers used a hostname/int pair as a >> process identifier, and such a convention may become popular again in the >> future. >> >> Furthermore, returning a string is in practice at least as convenient, >> since the only thing you can typically do with a pid today is pass it as a >> string to a system command like "kill". >> >> >> On Mon, May 12, 2014 at 12:44 PM, roger riggs > >wrote: >> >> > Please review and comment on this long requested addition to provide the >> > native process id of a spawned Process. >> > >> > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ >> > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 >> > >> > Thanks, Roger >> > >> > >> > > From Alan.Bateman at oracle.com Mon May 12 21:01:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 May 2014 22:01:30 +0100 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <53712498.20603@oracle.com> References: <53712498.20603@oracle.com> Message-ID: <537136AA.8090807@oracle.com> On 12/05/2014 20:44, roger riggs wrote: > Please review and comment on this long requested addition to provide the > native process id of a spawned Process. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 I think the representation of the pid needs consideration - we need to be happy that using a long is the right thing to do and won't cause us problems in the future and won't conflict with other APIs that we might add in this area. In terms of spec then it might be helpful to say a bit more to define a "native process id", even in an abstract way. -Alan From brian.burkhalter at oracle.com Mon May 12 21:16:52 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 12 May 2014 14:16:52 -0700 Subject: JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY] In-Reply-To: <536C9672.7080902@redhat.com> References: <7E218912-0099-4B99-9611-BFD7EAAEC003@oracle.com> <5357CE13.8060905@gmail.com> <7B7A4981-680D-4755-B1DA-DE954CF587C4@oracle.com> <22209687-BD36-4C20-8459-8F643DE1F393@oracle.com> <53651F88.2080607@oracle.com> <5368A458.20704@redhat.com> <7635E575-0195-44DD-8D7E-4B9863C83480@oracle.com> <536C9672.7080902@redhat.com> Message-ID: <4485E990-F0A8-490B-ACF8-61D1CFEBBD70@oracle.com> On May 9, 2014, at 1:48 AM, Florian Weimer wrote: > On 05/06/2014 06:38 PM, Brian Burkhalter wrote: >> Paul / Florian, >> >> This is a combined response. I am making the corrections pointed out by >> Florian. Unless I hear otherwise, I am going to assume that Paul?s >> approval is still valid with these corrections included and will push >> the path on Wednesday. Please see the updated patch: >> >> http://cr.openjdk.java.net/~bpb/8026236/webrev.04/ > > Looks good to me now (but I'm not an official reviewer). The approval is informative and appreciated nonetheless. Thanks, Brian > -- > Florian Weimer / Red Hat Product Security Team From mandy.chung at oracle.com Mon May 12 22:02:26 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 May 2014 15:02:26 -0700 Subject: 8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser In-Reply-To: <53710CD1.4050306@oracle.com> References: <53710CD1.4050306@oracle.com> Message-ID: <537144F2.9030200@oracle.com> On 5/12/14 11:02 AM, Alan Bateman wrote: > > In JDK 8 we brought in a tiny XML parser to support the Properties > loadFromXML/storeToXML methods. We needed this for the Compact > Profiles work, specifically builds of compact1 as they do not have > JAXP/XML APIs. > > At the time we were a bit nervous about switching the XML parser for > anything other than compact1 builds. One reason for this was that the > original javadoc didn't constrain the encodings that has to be > supported, another reason was confidence in the tests as we didn't > have too many tests for these methods in the jdk repository. > > I'd like to revisit one and switch over the implementation to always > use the small parser. This allows for some clean-up, specifically it > removes the need for the JDK-internal service type that was needed to > use the JAXP code. On the original concerns then the spec was > clarified in 8 to only require UTF-8 and UTF-16. In addition there > were several tests added to better exercise these methods and the > implementation. Also I think switching this early in JDK 9 means that > we maximize the time to hear about any issues. > > The webrev with the proposed changes is here, mostly red=removal so > easy to review: > > http://cr.openjdk.java.net/~alanb/8042889/webrev/ > Looks good to me. Mandy From paul.sandoz at oracle.com Tue May 13 08:32:43 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 10:32:43 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A9B4.80809@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A9B4.80809@oracle.com> Message-ID: On May 12, 2014, at 1:00 PM, Ivan Gerasimov wrote: > src/share/classes/sun/misc/UUDecoder.java > 126 StringBuilder x = new StringBuilder(); > Is only filled, but doesn't seem to be used anyhow. > Maybe just delete it? > Thanks, i will take a look at this and your other change once s/StringBuffer/StringBuilder/g is out of the way. Paul. From paul.sandoz at oracle.com Tue May 13 08:35:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 10:35:18 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370D5BD.4030503@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370D5BD.4030503@oracle.com> Message-ID: On May 12, 2014, at 4:07 PM, Daniel Fuchs wrote: > Hi Paul, > > I looked at -management and the changes there look good. > > There is just some two spaces vs four space formatting in > > line 99. > Thanks, updated. Paul. From Alan.Bateman at oracle.com Tue May 13 08:45:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 May 2014 09:45:34 +0100 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> Message-ID: <5371DBAE.8010109@oracle.com> On 12/05/2014 11:55, Paul Sandoz wrote: > On May 12, 2014, at 12:42 PM, Alan Bateman wrote: > >> On 12/05/2014 11:03, Paul Sandoz wrote: >>> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. >> The groupings are a bit odd > Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > I looked through the -tools and don't see anything escaping so looks good to me. Minor alignment issues in ExpressionParser and TokenMgrError. I also didn't see any takers for -media so I looked through those changes too. A lot of toString methods and I don't see anything obviously leaking to other threads. The s/retBuffer/sb/ in TreeModelEvent.toString is another multi-line statement, no big deal of course. Minor alignment issue in DefaultTreeSelectionModel and StandardTextSource. -Alan. From Alan.Bateman at oracle.com Tue May 13 08:50:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 May 2014 09:50:33 +0100 Subject: 8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser In-Reply-To: <53711F5E.4080909@oracle.com> References: <53710CD1.4050306@oracle.com> <53711F5E.4080909@oracle.com> Message-ID: <5371DCD9.3050806@oracle.com> On 12/05/2014 20:22, huizhe wang wrote: > > Would you think the wordings in the javadoc of Properties could be > stronger in terms of encoding, e.g. instead of: > The |loadFromXML(InputStream)| > and > |storeToXML(OutputStream, String, String)| > methods > load and store properties in a simple XML format. By default the UTF-8 > character encoding is used, however a specific encoding may be > specified if required. Implementations are required to support UTF-8 > and UTF-16 and may support other encodings. > > change it to: > The |loadFromXML(InputStream)| > > and |storeToXML(OutputStream, String, String)| > > methods load and store properties in a simple XML format. The default > character encoding is UTF-8 which is the recommended encoding for all > Properties files in XML format. Applications should use UTF-8 to avoid > potential encoding errors. Implementations are required to support > UTF-8 and UTF-16. > > > XML specification requires processors to support both UTF-8 and 16. > But UTF-8 is the dominant encoding for XML files. The above suggestion > is "stronger" in terms of using UTF-8, but not as strong as for > example, Google's Sitemap service that was straight forward in their > requirement: "We require your Sitemap file to be UTF-8 encoded". A recommendation to use UTF-8 for maximum portability seems reasonable, do you mind if create a separate issue for that? -Alan From sean.coffey at oracle.com Tue May 13 09:34:49 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 13 May 2014 10:34:49 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <5370CE22.1020707@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> <5370C2C2.7040907@oracle.com> <5370CE22.1020707@oracle.com> Message-ID: <5371E739.3020607@oracle.com> thanks for the comments. I hit a build issue when introducing some lambda syntax to the corba repo : https://bugs.openjdk.java.net/browse/JDK-8042932 That's fixed now and I can continue with the corba push. I've cleaned up the ORB class to make better use of generics and the diamond operator. Removed some unused package imports also. Taken Daniel's suggestion to use ConcurrentHashMap on board (and removed the sync block) http://cr.openjdk.java.net/~coffeys/webrev.8042906.v2/webrev/ regards, Sean. On 12/05/2014 14:35, Mark Sheppard wrote: > OK thanks Chris and Daniel ... I see my misinterpretation now > > regards > Mark > > On 12/05/2014 13:46, Daniel Fuchs wrote: >> Hi Mark, >> >> AFAIKS computeIfAbsent does what we want: >> >> >> >> >> It seems that putIfAbsent would not though. This is indeed confusing. >> I wish putIfAbsent had been specified similarly to >> computeIfAbsent... >> >> best regards, >> >> -- daniel >> >> ConcurrentHashMap seems to have something more >> >> On 5/12/14 1:33 PM, Mark Sheppard wrote: >>> If I read the javdoc correctly neither computeIfAbsent nor putIfAbsent >>> seem to match the >>> previous semantics of the if statement? >>> >>> computeIfAbsent: "If the value for the specified key is present and >>> non-null, attempts to compute a new mapping given the key and its >>> current mapped value." >>> or >>> "If the specified key is not already associated with a value (or is >>> mapped to |null|), attempts to compute its value using the given >>> mapping >>> function and enters it into this map unless |null|. " >>> my interpretation is this is relevant if value if there exist a value >>> and you want to update? >>> >>> putIfAbsent: "If the specified key is not already associated with a >>> value (or is mapped to |null|) associates it with the given value and >>> returns |null|, else returns the current value." >>> in this case we can have null value returned >>> >>> previous semantics were if the PM doesn't exist then instantiate and >>> cache it in the hashtable. return the PM - no null value returned >>> >>> maybe I'm misinterpreting the docs >>> >>> regards >>> Mark >>> On 12/05/2014 08:52, Se?n Coffey wrote: >>>> Good tip Alan/Chris. >>>> >>>> I'll make that change and push. >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 12 May 2014 07:17:04 GMT+01:00, Alan Bateman >>>> wrote: >>>>> On 11/05/2014 21:56, Se?n Coffey wrote: >>>>>> Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can >>>>>> remove use of reflection in ORB code to access the applet context. >>>>>> >>>>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 >>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ >>>>> I agree with Chris that computeIfAbsent is best here, that was >>>>> also the >>>>> >>>>> suggestion back in early April before the bootstrapping issue came >>>>> up. >>>>> In any case, it's good you are re-visiting this to clean it up. >>>>> >>>>> -Alan >>> >> > From paul.sandoz at oracle.com Tue May 13 10:22:05 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 12:22:05 +0200 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <5371E739.3020607@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> <5370C2C2.7040907@oracle.com> <5370CE22.1020707@oracle.com> <5371E739.3020607@oracle.com> Message-ID: <0314CA26-D45A-4549-B6AE-5C463FA92B12@oracle.com> On May 13, 2014, at 11:34 AM, Se?n Coffey wrote: > thanks for the comments. I hit a build issue when introducing some lambda syntax to the corba repo : https://bugs.openjdk.java.net/browse/JDK-8042932 > > That's fixed now and I can continue with the corba push. I've cleaned up the ORB class to make better use of generics and the diamond operator. Removed some unused package imports also. Taken Daniel's suggestion to use ConcurrentHashMap on board (and removed the sync block) > > http://cr.openjdk.java.net/~coffeys/webrev.8042906.v2/webrev/ > There are also some compute-if-absent patterns that might be applicable: 503 public LogWrapperBase getLogWrapper(String logDomain, 504 String exceptionGroup, LogWrapperFactory factory) 505 { 506 StringPair key = new StringPair(logDomain, exceptionGroup); 507 508 LogWrapperBase logWrapper = wrapperMap.get(key); 509 if (logWrapper == null) { 510 logWrapper = factory.create(getLogger(logDomain)); 511 wrapperMap.put(key, logWrapper); 512 } 513 514 return logWrapper; 515 } 516 517 /** get the log wrapper class (its type is dependent on the exceptionGroup) for the 518 * given log domain and exception group in this ORB instance. 519 */ 520 public static LogWrapperBase staticGetLogWrapper(String logDomain, 521 String exceptionGroup, LogWrapperFactory factory) 522 { 523 StringPair key = new StringPair(logDomain, exceptionGroup); 524 525 LogWrapperBase logWrapper = staticWrapperMap.get(key); 526 if (logWrapper == null) { 527 logWrapper = factory.create( staticGetLogger(logDomain)); 528 staticWrapperMap.put(key, logWrapper); 529 } 530 531 return logWrapper; 532 } return wrapperMap.computeIfAbsent(new StringPair(...), x -> factory.create(....)); Paul. From aleksej.efimov at oracle.com Tue May 13 10:46:02 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 13 May 2014 14:46:02 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately Message-ID: <5371F7EA.1030300@oracle.com> Hi, Can I have a review for 8032901 bug [1] fix [2]. There is a possible case when 'WaitForMultipleObjects' function can return the WAIT_ABANDONED_0 [3] error value. In such case it's better to release the mutex and return error value. This will prevent other threads to be blocked on abandoned mutex. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8032901 [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ [3] http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx From forax at univ-mlv.fr Tue May 13 10:50:40 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 May 2014 12:50:40 +0200 Subject: JDK-8037382 Sequence and SequenceSet interface In-Reply-To: References: Message-ID: <5371F900.5070203@univ-mlv.fr> On 05/12/2014 05:43 PM, Sandipan Razzaque wrote: > Hi Remi - > > Thank you for the fast response, I have indeed signed the OCA. > > I shall work on the bug you suggested (JDK-8037343 > ) over the week and > submit a patch. Note that my work on OpenJDK is outside of work hours > so will likely only get a chance this weekend. > > Cheers, > SR > Ok, cool ! regards, R?mi > > Sandipan Razzaque | www.sandipan.net > > From: Remi Forax > > To: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8037382 Sequence and SequenceSet interface > Message-ID: <53700000.8010801 at univ-mlv.fr > > > Content-Type: text/plain; charset=UTF-8; format=flowed > > > On 05/12/2014 12:35 AM, Sandipan Razzaque wrote: > > Hi all, > > > > I'm looking to get started making contributions :-) I figured I'd start > > with something that was fairly prescriptive and mechanical just to > get the > > hang of the process. Two questions if I may, as per the contribution > guide: > > > > * Is anyone already working on the above item? (I do not wish to > duplicate > > effort.) > > * Are there any objections to the changes already laid out in the ticket? > > > > If all is well, I shall get started with a patch for review. > > > > Cheers, > > SR > > > >https://bugs.openjdk.java.net/browse/JDK-8037382 > > > > Sandipan Razzaque | www.sandipan.net > > Hi Sandipan, > I suppose that you have already sign the OCA. > > In my opinion, this bug is too big for a first contribution, > any change to java.util collection require coordination between > several people. > I think you should start with something smaller, > what do you think about this one: > https://bugs.openjdk.java.net/browse/JDK-8037343 > > cheers, > R?mi From Alan.Bateman at oracle.com Tue May 13 10:57:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 May 2014 11:57:39 +0100 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5371F7EA.1030300@oracle.com> References: <5371F7EA.1030300@oracle.com> Message-ID: <5371FAA3.3040006@oracle.com> This is debugger's shared memory transport so cc'ing serviceability-dev as that is there this code is maintained. Is there a test case or any outline of the conditions that cause this? I think that would be useful to understand the issue further. -Alan On 13/05/2014 11:46, Aleksej Efimov wrote: > Hi, > > Can I have a review for 8032901 bug [1] fix [2]. There is a possible > case when 'WaitForMultipleObjects' function can return the > WAIT_ABANDONED_0 [3] error value. > In such case it's better to release the mutex and return error value. > This will prevent other threads to be blocked on abandoned mutex. > > Thank you, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8032901 > [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ > [3] > http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx > From Sergey.Bylokhov at oracle.com Tue May 13 11:10:53 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 13 May 2014 15:10:53 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5371FDBD.9020002@oracle.com> Hi, Paul. adding 2d-dev@ media: sound/awt/swing part looks fine. Note that this part of the fix should be pushed to client forest. On 5/12/14 2:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing > under one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each > file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to > pull in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your > single ("uber") patch as textual attachment? (IIUC such attachments > should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > -- Best regards, Sergey. From aleksej.efimov at oracle.com Tue May 13 11:43:29 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 13 May 2014 15:43:29 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5371FAA3.3040006@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> Message-ID: <53720561.9080600@oracle.com> Alan, There is no test case for this issue and also the attempt to outline the conditions ended with no result. The report is based only on 'WaitForMultipleObjects' code analysis and this fix is an attempt to make the code looks a little more correct. -Aleksej On 05/13/2014 02:57 PM, Alan Bateman wrote: > > This is debugger's shared memory transport so cc'ing > serviceability-dev as that is there this code is maintained. > > Is there a test case or any outline of the conditions that cause this? > I think that would be useful to understand the issue further. > > -Alan > > On 13/05/2014 11:46, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >> case when 'WaitForMultipleObjects' function can return the >> WAIT_ABANDONED_0 [3] error value. >> In such case it's better to release the mutex and return error value. >> This will prevent other threads to be blocked on abandoned mutex. >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >> [3] >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >> > From david.holmes at oracle.com Tue May 13 12:00:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 May 2014 22:00:12 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5371FAA3.3040006@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> Message-ID: <5372094C.5070407@oracle.com> I don't understand this one at all. What is an "abandoned mutex"? For that matter why does the code wait on a mutex and an event? Do we already own the mutex? If so what does it mean to wait on it? If not then how can we release it? ??? Thanks, David On 13/05/2014 8:57 PM, Alan Bateman wrote: > > This is debugger's shared memory transport so cc'ing serviceability-dev > as that is there this code is maintained. > > Is there a test case or any outline of the conditions that cause this? I > think that would be useful to understand the issue further. > > -Alan > > On 13/05/2014 11:46, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >> case when 'WaitForMultipleObjects' function can return the >> WAIT_ABANDONED_0 [3] error value. >> In such case it's better to release the mutex and return error value. >> This will prevent other threads to be blocked on abandoned mutex. >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >> [3] >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >> > From aleksej.efimov at oracle.com Tue May 13 13:19:07 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 13 May 2014 17:19:07 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5372094C.5070407@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> Message-ID: <53721BCB.4060200@oracle.com> David, The Windows has a different terminology for mutex objects (much differs from the POSIX one). This one link gave me some understanding of it [1]. Here is the MSDN [1] description of what "abandoned mutex" is: " If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function will return*WAIT_ABANDONED*to indicate that the mutex object is abandoned. An abandoned mutex object indicates that an error has occurred and that any shared resource being protected by the mutex object is in an undefined state. If the thread proceeds as though the mutex object had not been abandoned, it is no longer considered abandoned after the thread releases its ownership. This restores normal behavior if a handle to the mutex object is subsequently specified in a wait function." What does it mean to wait on mutex and ownership of the mutex object: "Any thread with a handle to a mutex object can use one of thewait functions to request ownership of the mutex object. If the mutex object is owned by another thread, the wait function blocks the requesting thread until the owning thread releases the mutex object using the*ReleaseMutex* function." How we can release mutex and wait on already owned mutex: " After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call*ReleaseMutex* once for each time that the mutex satisfied the conditions of a wait function." [1] http://msdn.microsoft.com/en-gb/library/windows/desktop/ms684266(v=vs.85).aspx -Aleksej On 05/13/2014 04:00 PM, David Holmes wrote: > I don't understand this one at all. What is an "abandoned mutex"? For > that matter why does the code wait on a mutex and an event? Do we > already own the mutex? If so what does it mean to wait on it? If not > then how can we release it? > > ??? > > Thanks, > David > > > On 13/05/2014 8:57 PM, Alan Bateman wrote: >> >> This is debugger's shared memory transport so cc'ing serviceability-dev >> as that is there this code is maintained. >> >> Is there a test case or any outline of the conditions that cause this? I >> think that would be useful to understand the issue further. >> >> -Alan >> >> On 13/05/2014 11:46, Aleksej Efimov wrote: >>> Hi, >>> >>> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >>> case when 'WaitForMultipleObjects' function can return the >>> WAIT_ABANDONED_0 [3] error value. >>> In such case it's better to release the mutex and return error value. >>> This will prevent other threads to be blocked on abandoned mutex. >>> >>> Thank you, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >>> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >>> [3] >>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >>> >>> >> From paul.sandoz at oracle.com Tue May 13 13:51:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 15:51:21 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5371FDBD.9020002@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> Message-ID: <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> On May 13, 2014, at 1:10 PM, Sergey Bylokhov wrote: > Hi, Paul. > adding 2d-dev@ > > media: sound/awt/swing part looks fine. Thanks. > Note that this part of the fix should be pushed to client forest. > Which classes exactly from here: http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ ? I am not familiar with the client integration process but from my perspective it does seem a little odd to have to do that. Paul. From huizhe.wang at oracle.com Tue May 13 16:00:55 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 13 May 2014 09:00:55 -0700 Subject: 8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser In-Reply-To: <5371DCD9.3050806@oracle.com> References: <53710CD1.4050306@oracle.com> <53711F5E.4080909@oracle.com> <5371DCD9.3050806@oracle.com> Message-ID: <537241B7.8030207@oracle.com> On 5/13/2014 1:50 AM, Alan Bateman wrote: > On 12/05/2014 20:22, huizhe wang wrote: >> >> Would you think the wordings in the javadoc of Properties could be >> stronger in terms of encoding, e.g. instead of: >> The |loadFromXML(InputStream)| >> and >> |storeToXML(OutputStream, String, String)| >> methods >> load and store properties in a simple XML format. By default the >> UTF-8 character encoding is used, however a specific encoding may be >> specified if required. Implementations are required to support UTF-8 >> and UTF-16 and may support other encodings. >> >> change it to: >> The |loadFromXML(InputStream)| >> >> and |storeToXML(OutputStream, String, String)| >> >> methods load and store properties in a simple XML format. The default >> character encoding is UTF-8 which is the recommended encoding for all >> Properties files in XML format. Applications should use UTF-8 to >> avoid potential encoding errors. Implementations are required to >> support UTF-8 and UTF-16. >> >> >> XML specification requires processors to support both UTF-8 and 16. >> But UTF-8 is the dominant encoding for XML files. The above >> suggestion is "stronger" in terms of using UTF-8, but not as strong >> as for example, Google's Sitemap service that was straight forward in >> their requirement: "We require your Sitemap file to be UTF-8 encoded". > A recommendation to use UTF-8 for maximum portability seems > reasonable, do you mind if create a separate issue for that? That would be fine. Saw the JBS entry, thanks! Joe > > -Alan From sean.coffey at oracle.com Tue May 13 18:53:55 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 13 May 2014 19:53:55 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <0314CA26-D45A-4549-B6AE-5C463FA92B12@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> <5370C2C2.7040907@oracle.com> <5370CE22.1020707@oracle.com> <5371E739.3020607@oracle.com> <0314CA26-D45A-4549-B6AE-5C463FA92B12@oracle.com> Message-ID: <53726A43.7000607@oracle.com> That's some nice code reduction Paul. Thanks. http://cr.openjdk.java.net/~coffeys/webrev.8042906.v3/webrev/ I'll push these changes later unless I hear to the contrary. regards, Sean. On 13/05/2014 11:22, Paul Sandoz wrote: > On May 13, 2014, at 11:34 AM, Se?n Coffey wrote: > >> thanks for the comments. I hit a build issue when introducing some lambda syntax to the corba repo : https://bugs.openjdk.java.net/browse/JDK-8042932 >> >> That's fixed now and I can continue with the corba push. I've cleaned up the ORB class to make better use of generics and the diamond operator. Removed some unused package imports also. Taken Daniel's suggestion to use ConcurrentHashMap on board (and removed the sync block) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8042906.v2/webrev/ >> > There are also some compute-if-absent patterns that might be applicable: > > 503 public LogWrapperBase getLogWrapper(String logDomain, > 504 String exceptionGroup, LogWrapperFactory factory) > 505 { > 506 StringPair key = new StringPair(logDomain, exceptionGroup); > 507 > 508 LogWrapperBase logWrapper = wrapperMap.get(key); > 509 if (logWrapper == null) { > 510 logWrapper = factory.create(getLogger(logDomain)); > 511 wrapperMap.put(key, logWrapper); > 512 } > 513 > 514 return logWrapper; > 515 } > 516 > 517 /** get the log wrapper class (its type is dependent on the exceptionGroup) for the > 518 * given log domain and exception group in this ORB instance. > 519 */ > 520 public static LogWrapperBase staticGetLogWrapper(String logDomain, > 521 String exceptionGroup, LogWrapperFactory factory) > 522 { > 523 StringPair key = new StringPair(logDomain, exceptionGroup); > 524 > 525 LogWrapperBase logWrapper = staticWrapperMap.get(key); > 526 if (logWrapper == null) { > 527 logWrapper = factory.create( staticGetLogger(logDomain)); > 528 staticWrapperMap.put(key, logWrapper); > 529 } > 530 > 531 return logWrapper; > 532 } > > return wrapperMap.computeIfAbsent(new StringPair(...), > x -> factory.create(....)); > > Paul. From chris.hegarty at oracle.com Tue May 13 19:01:09 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 13 May 2014 20:01:09 +0100 Subject: RFR: 8042906: Remove use of reflection in ORB In-Reply-To: <53726A43.7000607@oracle.com> References: <536FE3E0.5080809@oracle.com> <53706760.5040101@oracle.com> <70480af2-c2fd-4b33-a8d9-d8231db9d8af@email.android.com> <5370B171.5070005@oracle.com> <5370C2C2.7040907@oracle.com> <5370CE22.1020707@oracle.com> <5371E739.3020607@oracle.com> <0314CA26-D45A-4549-B6AE-5C463FA92B12@oracle.com> <53726A43.7000607@oracle.com> Message-ID: On 13 May 2014, at 19:53, Se?n Coffey wrote: > That's some nice code reduction Paul. Thanks. > > http://cr.openjdk.java.net/~coffeys/webrev.8042906.v3/webrev/ > > I'll push these changes later unless I hear to the contrary. Push it quick! -Chris. > > regards, > Sean. > > On 13/05/2014 11:22, Paul Sandoz wrote: >> On May 13, 2014, at 11:34 AM, Se?n Coffey wrote: >> >>> thanks for the comments. I hit a build issue when introducing some lambda syntax to the corba repo : https://bugs.openjdk.java.net/browse/JDK-8042932 >>> >>> That's fixed now and I can continue with the corba push. I've cleaned up the ORB class to make better use of generics and the diamond operator. Removed some unused package imports also. Taken Daniel's suggestion to use ConcurrentHashMap on board (and removed the sync block) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8042906.v2/webrev/ >>> >> There are also some compute-if-absent patterns that might be applicable: >> >> 503 public LogWrapperBase getLogWrapper(String logDomain, >> 504 String exceptionGroup, LogWrapperFactory factory) >> 505 { >> 506 StringPair key = new StringPair(logDomain, exceptionGroup); >> 507 >> 508 LogWrapperBase logWrapper = wrapperMap.get(key); >> 509 if (logWrapper == null) { >> 510 logWrapper = factory.create(getLogger(logDomain)); >> 511 wrapperMap.put(key, logWrapper); >> 512 } >> 513 >> 514 return logWrapper; >> 515 } >> 516 >> 517 /** get the log wrapper class (its type is dependent on the exceptionGroup) for the >> 518 * given log domain and exception group in this ORB instance. >> 519 */ >> 520 public static LogWrapperBase staticGetLogWrapper(String logDomain, >> 521 String exceptionGroup, LogWrapperFactory factory) >> 522 { >> 523 StringPair key = new StringPair(logDomain, exceptionGroup); >> 524 >> 525 LogWrapperBase logWrapper = staticWrapperMap.get(key); >> 526 if (logWrapper == null) { >> 527 logWrapper = factory.create( staticGetLogger(logDomain)); >> 528 staticWrapperMap.put(key, logWrapper); >> 529 } >> 530 >> 531 return logWrapper; >> 532 } >> >> return wrapperMap.computeIfAbsent(new StringPair(...), >> x -> factory.create(....)); >> >> Paul. > From philip.race at oracle.com Tue May 13 21:15:47 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 May 2014 14:15:47 -0700 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> Message-ID: <53728B83.1060307@oracle.com> Paul, I don't see why you changed the variable names in some cases. See here where one change is only one line since you left it alone and the other is 6 lines since you changed it http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/javax/print/attribute/Size2DSyntax.java.sdiff.html As it is, its just inconsistent and makes it less obvious to the eye that nothing unexpected changed. And here what could have been a 2 line change is 25 .. http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html So I would say leave the variable names alone unless there's a compelling reason - and I don't see one. Also pushing the 2D, AWT and Swing changes to client is requested as although your changes are small its what is appropriate. I would not push hotspot changes to client either. Also lots of files are being updated in client and doing it this way will minimise merges ... -phil. On 5/13/2014 6:51 AM, Paul Sandoz wrote: > > On May 13, 2014, at 1:10 PM, Sergey Bylokhov > > wrote: > >> Hi, Paul. >> adding 2d-dev@ >> >> media: sound/awt/swing part looks fine. > > Thanks. > > >> Note that this part of the fix should be pushed to client forest. >> > > Which classes exactly from here: > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > ? > > I am not familiar with the client integration process but from my > perspective it does seem a little odd to have to do that. > > Paul. > From david.holmes at oracle.com Tue May 13 22:46:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 May 2014 08:46:19 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53721BCB.4060200@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> Message-ID: <5372A0BB.1040704@oracle.com> Hi Aleksej, Thanks for the doc references regarding abandonment. Let me rephrase my question. What is this logic trying to achieve by waiting on both a mutex and an event? Do we already own the mutex when this function is called? David On 13/05/2014 11:19 PM, Aleksej Efimov wrote: > David, > > The Windows has a different terminology for mutex objects (much differs > from the POSIX one). This one link gave me some understanding of it [1]. > > Here is the MSDN [1] description of what "abandoned mutex" is: > " If a thread terminates without releasing its ownership of a mutex > object, the mutex object is considered to be abandoned. A waiting thread > can acquire ownership of an abandoned mutex object, but the wait > function will return*WAIT_ABANDONED*to indicate that the mutex object is > abandoned. An abandoned mutex object indicates that an error has > occurred and that any shared resource being protected by the mutex > object is in an undefined state. If the thread proceeds as though the > mutex object had not been abandoned, it is no longer considered > abandoned after the thread releases its ownership. This restores normal > behavior if a handle to the mutex object is subsequently specified in a > wait function." > > > What does it mean to wait on mutex and ownership of the mutex object: > "Any thread with a handle to a mutex object can use one of thewait > functions > to > request ownership of the mutex object. If the mutex object is owned by > another thread, the wait function blocks the requesting thread until the > owning thread releases the mutex object using the*ReleaseMutex* > function." > > How we can release mutex and wait on already owned mutex: > " After a thread obtains ownership of a mutex, it can specify the same > mutex in repeated calls to the wait-functions > without > blocking its execution. This prevents a thread from deadlocking itself > while waiting for a mutex that it already owns. To release its ownership > under such circumstances, the thread must call*ReleaseMutex* > once > for each time that the mutex satisfied the conditions of a wait function." > > [1] > http://msdn.microsoft.com/en-gb/library/windows/desktop/ms684266(v=vs.85).aspx > > -Aleksej > > On 05/13/2014 04:00 PM, David Holmes wrote: >> I don't understand this one at all. What is an "abandoned mutex"? For >> that matter why does the code wait on a mutex and an event? Do we >> already own the mutex? If so what does it mean to wait on it? If not >> then how can we release it? >> >> ??? >> >> Thanks, >> David >> >> >> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>> >>> This is debugger's shared memory transport so cc'ing serviceability-dev >>> as that is there this code is maintained. >>> >>> Is there a test case or any outline of the conditions that cause this? I >>> think that would be useful to understand the issue further. >>> >>> -Alan >>> >>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>> Hi, >>>> >>>> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >>>> case when 'WaitForMultipleObjects' function can return the >>>> WAIT_ABANDONED_0 [3] error value. >>>> In such case it's better to release the mutex and return error value. >>>> This will prevent other threads to be blocked on abandoned mutex. >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >>>> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >>>> [3] >>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >>>> >>>> >>> > From vitalyd at gmail.com Wed May 14 01:06:25 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 13 May 2014 21:06:25 -0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5372A0BB.1040704@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> Message-ID: In windows, you acquire a mutex by waiting on it using one of the wait functions, one of them employed in the code in question. If WaitForMultipleObjects succeeds and returns the index of the mutex, current thread has ownership now. It's also common to use multi wait functions where the event is a "cancelation token", e.g. manual reset event; this allows someone to cancel waiting on mutex acquisition and return from the wait function. Presumably that's the case here, but I'll let Aleksej confirm; just wanted to throw this out there in the meantime :). Sent from my phone On May 13, 2014 6:46 PM, "David Holmes" wrote: > Hi Aleksej, > > Thanks for the doc references regarding abandonment. > > Let me rephrase my question. What is this logic trying to achieve by > waiting on both a mutex and an event? Do we already own the mutex when this > function is called? > > David > > On 13/05/2014 11:19 PM, Aleksej Efimov wrote: > >> David, >> >> The Windows has a different terminology for mutex objects (much differs >> from the POSIX one). This one link gave me some understanding of it [1]. >> >> Here is the MSDN [1] description of what "abandoned mutex" is: >> " If a thread terminates without releasing its ownership of a mutex >> object, the mutex object is considered to be abandoned. A waiting thread >> can acquire ownership of an abandoned mutex object, but the wait >> function will return*WAIT_ABANDONED*to indicate that the mutex object is >> abandoned. An abandoned mutex object indicates that an error has >> occurred and that any shared resource being protected by the mutex >> object is in an undefined state. If the thread proceeds as though the >> mutex object had not been abandoned, it is no longer considered >> abandoned after the thread releases its ownership. This restores normal >> behavior if a handle to the mutex object is subsequently specified in a >> wait function." >> >> >> What does it mean to wait on mutex and ownership of the mutex object: >> "Any thread with a handle to a mutex object can use one of thewait >> functions >> > ms687069%28v=vs.85%29.aspx>to >> request ownership of the mutex object. If the mutex object is owned by >> another thread, the wait function blocks the requesting thread until the >> owning thread releases the mutex object using the*ReleaseMutex* >> > ms685066%28v=vs.85%29.aspx>function." >> >> How we can release mutex and wait on already owned mutex: >> " After a thread obtains ownership of a mutex, it can specify the same >> mutex in repeated calls to the wait-functions >> > ms687069%28v=vs.85%29.aspx>without >> blocking its execution. This prevents a thread from deadlocking itself >> while waiting for a mutex that it already owns. To release its ownership >> under such circumstances, the thread must call*ReleaseMutex* >> > ms685066%28v=vs.85%29.aspx>once >> for each time that the mutex satisfied the conditions of a wait function." >> >> [1] >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ >> ms684266(v=vs.85).aspx >> >> -Aleksej >> >> On 05/13/2014 04:00 PM, David Holmes wrote: >> >>> I don't understand this one at all. What is an "abandoned mutex"? For >>> that matter why does the code wait on a mutex and an event? Do we >>> already own the mutex? If so what does it mean to wait on it? If not >>> then how can we release it? >>> >>> ??? >>> >>> Thanks, >>> David >>> >>> >>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>> >>>> >>>> This is debugger's shared memory transport so cc'ing serviceability-dev >>>> as that is there this code is maintained. >>>> >>>> Is there a test case or any outline of the conditions that cause this? I >>>> think that would be useful to understand the issue further. >>>> >>>> -Alan >>>> >>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>> >>>>> Hi, >>>>> >>>>> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >>>>> case when 'WaitForMultipleObjects' function can return the >>>>> WAIT_ABANDONED_0 [3] error value. >>>>> In such case it's better to release the mutex and return error value. >>>>> This will prevent other threads to be blocked on abandoned mutex. >>>>> >>>>> Thank you, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >>>>> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >>>>> [3] >>>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ >>>>> ms687025(v=vs.85).aspx >>>>> >>>>> >>>>> >>>> >> From paul.sandoz at oracle.com Wed May 14 08:15:55 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 May 2014 10:15:55 +0200 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <53728B83.1060307@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> Message-ID: <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> HI Phil, Thanks for looking at this. On May 13, 2014, at 11:15 PM, Phil Race wrote: > Paul, > > I don't see why you changed the variable names in some cases. Note it's not me :-) I am, mostly, the proxy. > See here where one change is only one line since you left it alone and the other is 6 lines since you changed it > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/javax/print/attribute/Size2DSyntax.java.sdiff.html > As it is, its just inconsistent and makes it less obvious to the eye that nothing unexpected changed. That's a fair point. > And here what could have been a 2 line change is 25 .. > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html > So I would say leave the variable names alone unless there's a compelling reason - and I don't see one. "buf" no longer corresponds to a buffer but to a builder, so i think it is reasonable in this case to use the canonical "sb" name. > Also pushing the 2D, AWT and Swing changes to client is requested as although your changes are > small its what is appropriate. I would not push hotspot changes to client either. Also lots of files > are being updated in client and doing it this way will minimise merges ... Although hotspot is a *separate* repository, there is a much clearer dividing line. This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere? Out of all the classes here: http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set? How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo? Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate. Paul. From david.holmes at oracle.com Wed May 14 09:05:11 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 May 2014 19:05:11 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> Message-ID: <537331C7.8030807@oracle.com> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: > In windows, you acquire a mutex by waiting on it using one of the wait > functions, one of them employed in the code in question. If > WaitForMultipleObjects succeeds and returns the index of the mutex, > current thread has ownership now. Yes I understand the basic mechanics :) > It's also common to use multi wait functions where the event is a > "cancelation token", e.g. manual reset event; this allows someone to > cancel waiting on mutex acquisition and return from the wait function. > Presumably that's the case here, but I'll let Aleksej confirm; just > wanted to throw this out there in the meantime :). Ah I see - yes cancellable lock acquisition would make sense. Thanks, David > Sent from my phone > > On May 13, 2014 6:46 PM, "David Holmes" > wrote: > > Hi Aleksej, > > Thanks for the doc references regarding abandonment. > > Let me rephrase my question. What is this logic trying to achieve by > waiting on both a mutex and an event? Do we already own the mutex > when this function is called? > > David > > On 13/05/2014 11:19 PM, Aleksej Efimov wrote: > > David, > > The Windows has a different terminology for mutex objects (much > differs > from the POSIX one). This one link gave me some understanding of > it [1]. > > Here is the MSDN [1] description of what "abandoned mutex" is: > " If a thread terminates without releasing its ownership of a mutex > object, the mutex object is considered to be abandoned. A > waiting thread > can acquire ownership of an abandoned mutex object, but the wait > function will return*WAIT_ABANDONED*to indicate that the mutex > object is > abandoned. An abandoned mutex object indicates that an error has > occurred and that any shared resource being protected by the mutex > object is in an undefined state. If the thread proceeds as > though the > mutex object had not been abandoned, it is no longer considered > abandoned after the thread releases its ownership. This restores > normal > behavior if a handle to the mutex object is subsequently > specified in a > wait function." > > > What does it mean to wait on mutex and ownership of the mutex > object: > "Any thread with a handle to a mutex object can use one of thewait > functions > >to > request ownership of the mutex object. If the mutex object is > owned by > another thread, the wait function blocks the requesting thread > until the > owning thread releases the mutex object using the*ReleaseMutex* > >__function." > > How we can release mutex and wait on already owned mutex: > " After a thread obtains ownership of a mutex, it can specify > the same > mutex in repeated calls to the wait-functions > >__without > blocking its execution. This prevents a thread from deadlocking > itself > while waiting for a mutex that it already owns. To release its > ownership > under such circumstances, the thread must call*ReleaseMutex* > >__once > for each time that the mutex satisfied the conditions of a wait > function." > > [1] > http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx > > > -Aleksej > > On 05/13/2014 04:00 PM, David Holmes wrote: > > I don't understand this one at all. What is an "abandoned > mutex"? For > that matter why does the code wait on a mutex and an event? > Do we > already own the mutex? If so what does it mean to wait on > it? If not > then how can we release it? > > ??? > > Thanks, > David > > > On 13/05/2014 8:57 PM, Alan Bateman wrote: > > > This is debugger's shared memory transport so cc'ing > serviceability-dev > as that is there this code is maintained. > > Is there a test case or any outline of the conditions > that cause this? I > think that would be useful to understand the issue further. > > -Alan > > On 13/05/2014 11:46, Aleksej Efimov wrote: > > Hi, > > Can I have a review for 8032901 bug [1] fix [2]. > There is a possible > case when 'WaitForMultipleObjects' function can > return the > WAIT_ABANDONED_0 [3] error value. > In such case it's better to release the mutex and > return error value. > This will prevent other threads to be blocked on > abandoned mutex. > > Thank you, > Aleksej > > [1] > https://bugs.openjdk.java.net/__browse/JDK-8032901 > > [2] > http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ > > [3] > http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx > > > > > From Alan.Bateman at oracle.com Wed May 14 09:05:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 May 2014 10:05:41 +0100 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> Message-ID: <537331E5.4070108@oracle.com> On 14/05/2014 09:15, Paul Sandoz wrote: > : >> And here what could have been a 2 line change is 25 .. >> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html >> So I would say leave the variable names alone unless there's a compelling reason - and I don't see one. > "buf" no longer corresponds to a buffer but to a builder, so i think it is reasonable in this case to use the canonical "sb" name. I agree, "buf" or "buffer" looks odd when the type is changed to StringBuilder. > : > > This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere? > > Out of all the classes here: > > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set? > > How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo? > > Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate. > I think Sergey and Phil are asking for the bean classes from -core patch and all of -media to be pushed to jdk9/client. From an approachability perspective then it's total baloney for library changes to take different routes. On the other hand there may be exceptions needed for areas or changes that involve manual or other special testing before integration. There was a lengthy thread on jdk9-dev about the integration forests and processes [1] where this was discussed. I don't recall seeing a boolean result to the questions that asked whether the client libraries require any manual testing before integration. As things stand then what we loosely call "client libraries" are pushed to jdk9/client, everything else is pushed to jdk9/dev. I really hope this can be re-visited soon. -Alan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html From forax at univ-mlv.fr Wed May 14 10:04:26 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 May 2014 12:04:26 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <53732FFB.7050407@oracle.com> References: <53732FFB.7050407@oracle.com> Message-ID: <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> your patch doesn't work ! the array is still allocated as an classical array in the constructor. cheers, Remi Envoy? avec AquaMail pour Android http://www.aqua-mail.com Le 14 mai 2014 11:04:41 Tobias Hartmann a ?crit : > Hi, > > please review the following patch for bug 8005873. > > *Problem* > Bug: https://bugs.openjdk.java.net/browse/JDK-8005873 > > The test creates multiple threads (~500) that repeatedly execute > invokeExact on a method handle referencing a static method. The call to > invokeExact is performed through an optimized inline cache > (CompiledStaticCall) that points to the LambdaForm generated for the method > handle. The IC is first set to interpreted code by > CompiledStaticCall::set_to_interpreted(...) but soon updated to refer to > the compiled version of the lambda form (-Xcomp). > > Because tiered compilation is enabled, the VM decides to compile the > LambdaForm at a different level and sets the old version to not-entrant. > The next call through the IC therefore triggers a re-resolving of the call > site finally performing a Java upcall to > java.lang.invoke.MethodHandleNatives::linkMethod(...) (see call sequence > [1]). A *new* LambdaForm is returned and > CompiledStaticCall::set_to_interpreted(...) is executed again to update the > IC. The assert is hit because the callee differs. > > The problem is that there are multiple LambdaForms created for the same > invokeExact instruction. Caching in the Java runtime code should guarantee > that only one LambdaForm is created and reused. Instrumenting > Invokers::invokeHandleForm(...) shows that almost all requests result in a > cache miss and return a new LambdaForm. > > This behaviour is caused by a race condition in > Invokers::invokeHandleForm(...). Threads may initially see a cache miss > when invoking MethodTypeForm::cachedLambdaForm(...), then create a new > LambdaForm and call MethodTypeForm::setCachedLambdaForm(...) to update the > cache without checking it again. In a high concurrency setting, this leads > to multiple LambdaForms being created for the same invokeExact instruction > because the cache entry is overwritten by multiple threads. > > *Solution* > Webrev: http://cr.openjdk.java.net/~anoll/8005873/webrev.00/ > > An AtomicReferenceArray is used to cache the LambdaForms and .get(...) and > .compareAndSet(...) are used to retrieve and update the cache entries. This > allows only one thread to set the LambdaForm that is then being used by all > instances of the invokeExact. > > *Testing* > - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) > - Nashorn + Octane > - JPRT > > Many thanks to Christian Thalinger and Vladimir Ivanov! > > Best, > Tobias > > [1] Call sequence of reresolving the IC target > SharedRuntime::handle_wrong_method(...) > -> SharedRuntime::reresolve_call_site(...) > -> SharedRuntime::find_callee_method(...) > -> SharedRuntime::find_callee_info_helper(...) > -> LinkResolver::resolve_invoke(...) > -> LinkResolver::resolve_invokehandle(...) > -> LinkResolver::resolve_invokehandle(...) > -> LinkResolver::lookup_polymorphic_method(...) > -> SystemDictionary::find_method_handle_invoker(...) > -> Java upcall to java.lang.invoke.MethodHandleNatives::linkMethod(...) > -> Invokers::methodHandleInvokeLinkerMethod(...) > -> Invokers::invokeHandleForm(...) > > > > > > > > > > Backport? From vladimir.x.ivanov at oracle.com Wed May 14 10:47:38 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 14 May 2014 14:47:38 +0400 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <53734692.6080409@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> Message-ID: <537349CA.1090904@oracle.com> Tobias, I agree with your evaluation. My only concern is that @Stable doesn't work for AtomicReferenceArray, so JIT doesn't see what is stored in the array. Maybe use a lock instead? Best regards, Vladimir Ivanov On 5/14/14 2:33 PM, Tobias Hartmann wrote: > Hi Remi, > > sorry, I accidentally reverted that part.. Here is the correct webrev: > > http://cr.openjdk.java.net/~anoll/8005873/webrev.01/ > > Thanks, > Tobias > > On 14.05.2014 12:04, Remi Forax wrote: >> your patch doesn't work ! >> >> the array is still allocated as an classical array in the constructor. >> >> cheers, >> Remi >> >> Envoy? avec AquaMail pour Android >> http://www.aqua-mail.com >> >> >> Le 14 mai 2014 11:04:41 Tobias Hartmann a >> ?crit : >> >>> Hi, >>> >>> please review the following patch for bug 8005873. >>> >>> *Problem* >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8005873 >>> >>> The test creates multiple threads (~500) that repeatedly execute >>> invokeExact on a method handle referencing a static method. The call >>> to invokeExact is performed through an optimized inline cache >>> (CompiledStaticCall) that points to the LambdaForm generated for the >>> method handle. The IC is first set to interpreted code by >>> CompiledStaticCall::set_to_interpreted(...) but soon updated to refer >>> to the compiled version of the lambda form (-Xcomp). >>> >>> Because tiered compilation is enabled, the VM decides to compile the >>> LambdaForm at a different level and sets the old version to >>> not-entrant. The next call through the IC therefore triggers a >>> re-resolving of the call site finally performing a Java upcall to >>> java.lang.invoke.MethodHandleNatives::linkMethod(...) (see call >>> sequence [1]). A *new* LambdaForm is returned and >>> CompiledStaticCall::set_to_interpreted(...) is executed again to >>> update the IC. The assert is hit because the callee differs. >>> >>> The problem is that there are multiple LambdaForms created for the >>> same invokeExact instruction. Caching in the Java runtime code should >>> guarantee that only one LambdaForm is created and reused. >>> Instrumenting Invokers::invokeHandleForm(...) shows that almost all >>> requests result in a cache miss and return a new LambdaForm. >>> >>> This behaviour is caused by a race condition in >>> Invokers::invokeHandleForm(...). Threads may initially see a cache >>> miss when invoking MethodTypeForm::cachedLambdaForm(...), then create >>> a new LambdaForm and call MethodTypeForm::setCachedLambdaForm(...) to >>> update the cache without checking it again. In a high concurrency >>> setting, this leads to multiple LambdaForms being created for the >>> same invokeExact instruction because the cache entry is overwritten >>> by multiple threads. >>> >>> *Solution* >>> Webrev: http://cr.openjdk.java.net/~anoll/8005873/webrev.00/ >>> >>> An AtomicReferenceArray is used to cache the LambdaForms and >>> .get(...) and .compareAndSet(...) are used to retrieve and update the >>> cache entries. This allows only one thread to set the LambdaForm that >>> is then being used by all instances of the invokeExact. >>> >>> *Testing* >>> - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) >>> - Nashorn + Octane >>> - JPRT >>> >>> Many thanks to Christian Thalinger and Vladimir Ivanov! >>> >>> Best, >>> Tobias >>> >>> [1] Call sequence of reresolving the IC target >>> SharedRuntime::handle_wrong_method(...) >>> -> SharedRuntime::reresolve_call_site(...) >>> -> SharedRuntime::find_callee_method(...) >>> -> SharedRuntime::find_callee_info_helper(...) >>> -> LinkResolver::resolve_invoke(...) >>> -> LinkResolver::resolve_invokehandle(...) >>> -> LinkResolver::resolve_invokehandle(...) >>> -> LinkResolver::lookup_polymorphic_method(...) >>> -> SystemDictionary::find_method_handle_invoker(...) >>> -> Java upcall to java.lang.invoke.MethodHandleNatives::linkMethod(...) >>> -> Invokers::methodHandleInvokeLinkerMethod(...) >>> -> Invokers::invokeHandleForm(...) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Backport? >> >> > From Alan.Bateman at oracle.com Wed May 14 11:03:09 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 May 2014 12:03:09 +0100 Subject: 8043119: (props) Properties.storeToXML closes output stream Message-ID: <53734D6D.4010807@oracle.com> This is a follow-up to the recent change to the modules motivated switch of the Properties XML methods to consistently use the UKit parser. An issue that has surfaced since is that the wrapper around UKit is incorrectly closing the output stream after writing the XML document, a basic assertion not covered by the tests in the jdk repository. Trivial fix: http://cr.openjdk.java.net/~alanb/8043119/webrev/ -Alan. From lance.andersen at oracle.com Wed May 14 11:08:38 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 14 May 2014 07:08:38 -0400 Subject: 8043119: (props) Properties.storeToXML closes output stream In-Reply-To: <53734D6D.4010807@oracle.com> References: <53734D6D.4010807@oracle.com> Message-ID: <821A4408-4533-4237-8652-D273E0B848B9@oracle.com> looks fine On May 14, 2014, at 7:03 AM, Alan Bateman wrote: > > This is a follow-up to the recent change to the modules motivated switch of the Properties XML methods to consistently use the UKit parser. An issue that has surfaced since is that the wrapper around UKit is incorrectly closing the output stream after writing the XML document, a basic assertion not covered by the tests in the jdk repository. Trivial fix: > > http://cr.openjdk.java.net/~alanb/8043119/webrev/ > > -Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Wed May 14 12:12:00 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 May 2014 14:12:00 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <537349CA.1090904@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> Message-ID: <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> On May 14, 2014, at 12:47 PM, Vladimir Ivanov wrote: > Tobias, I agree with your evaluation. > V. tricky one to track down! From @Stable: * It is (currently) undefined what happens if a field annotated as stable * is given a third value. In practice, if the JVM relies on this annotation * to promote a field reference to a constant, it may be that the Java memory * model would appear to be broken, if such a constant (the second value of the field) * is used as the value of the field even after the field value has changed. I dunno if that was a contributing factor in this case. > My only concern is that @Stable doesn't work for AtomicReferenceArray, so JIT doesn't see what is stored in the array. Yes, stability needs to be associated with the array elements. > Maybe use a lock instead? > Or perhaps use Unsafe.CAS directly within setCachedLambdaForm? Also, as a consequence of using AtomicReferenceArray the following change may result in a memory barrier on some architectures: public LambdaForm cachedLambdaForm(int which) { - return lambdaForms[which]; + return lambdaForms.get(which); } since lambdaForms.get will call Unsafe.getObjectVolatile. Separately, i think code that calls setCachedLambdaForm needs to be double checked to ensure that the return value is used. For example, in MethodHandleImpl.makeGuardWithCatchForm i see: basicType.form().setCachedLambdaForm(MethodTypeForm.LF_GWC, lform); return lform; which i think needs to be: return basicType.form().setCachedLambdaForm(MethodTypeForm.LF_GWC, lform); Paul. From vladimir.x.ivanov at oracle.com Wed May 14 13:15:39 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 14 May 2014 17:15:39 +0400 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> Message-ID: <53736C7B.2040303@oracle.com> On 5/14/14 4:12 PM, Paul Sandoz wrote: > > On May 14, 2014, at 12:47 PM, Vladimir Ivanov wrote: > >> Tobias, I agree with your evaluation. >> > > V. tricky one to track down! > > From @Stable: > > * It is (currently) undefined what happens if a field annotated as stable > * is given a third value. In practice, if the JVM relies on this annotation > * to promote a field reference to a constant, it may be that the Java memory > * model would appear to be broken, if such a constant (the second value of the field) > * is used as the value of the field even after the field value has changed. > > I dunno if that was a contributing factor in this case. No, @Stable doesn't contribute to the problem. > >> My only concern is that @Stable doesn't work for AtomicReferenceArray, so JIT doesn't see what is stored in the array. > > Yes, stability needs to be associated with the array elements. > > >> Maybe use a lock instead? >> > > Or perhaps use Unsafe.CAS directly within setCachedLambdaForm? Yes, Unsafe is another option here. But since cache updates should be rare, Unsafe is an overkill here IMO - locking should be fine. > > Also, as a consequence of using AtomicReferenceArray the following change may result in a memory barrier on some architectures: > > public LambdaForm cachedLambdaForm(int which) { > - return lambdaForms[which]; > > + return lambdaForms.get(which); > } > > since lambdaForms.get will call Unsafe.getObjectVolatile. MTF.cachedLambaForm isn't on a fast path, so it shouldn't be a problem. > Separately, i think code that calls setCachedLambdaForm needs to be double checked to ensure that the return value is used. For example, in MethodHandleImpl.makeGuardWithCatchForm i see: > > basicType.form().setCachedLambdaForm(MethodTypeForm.LF_GWC, lform); > return lform; > > which i think needs to be: > > return basicType.form().setCachedLambdaForm(MethodTypeForm.LF_GWC, lform); Good catch! MTF.setCachedLambdaForm usages should be fixed as well. Best regards, Vladimir Ivanov > > Paul. > > > > From aleksej.efimov at oracle.com Wed May 14 13:18:37 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 14 May 2014 17:18:37 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <537331C7.8030807@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> Message-ID: <53736D2D.7010805@oracle.com> David, Vitaly, I totally agree with Vitaly's explanation (Vitaly - thank you for that) and code in shmemBase.c (the usage of enterMutex() function for sending/receiving bytes through shared memory connection) illustrates on how the connection shutdown event is used as a "cancellation token". Thank you, -Aleksej On 05/14/2014 01:05 PM, David Holmes wrote: > On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >> In windows, you acquire a mutex by waiting on it using one of the wait >> functions, one of them employed in the code in question. If >> WaitForMultipleObjects succeeds and returns the index of the mutex, >> current thread has ownership now. > > Yes I understand the basic mechanics :) > >> It's also common to use multi wait functions where the event is a >> "cancelation token", e.g. manual reset event; this allows someone to >> cancel waiting on mutex acquisition and return from the wait function. >> Presumably that's the case here, but I'll let Aleksej confirm; just >> wanted to throw this out there in the meantime :). > > Ah I see - yes cancellable lock acquisition would make sense. > > Thanks, > David > >> Sent from my phone >> >> On May 13, 2014 6:46 PM, "David Holmes" > > wrote: >> >> Hi Aleksej, >> >> Thanks for the doc references regarding abandonment. >> >> Let me rephrase my question. What is this logic trying to achieve by >> waiting on both a mutex and an event? Do we already own the mutex >> when this function is called? >> >> David >> >> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >> >> David, >> >> The Windows has a different terminology for mutex objects (much >> differs >> from the POSIX one). This one link gave me some understanding of >> it [1]. >> >> Here is the MSDN [1] description of what "abandoned mutex" is: >> " If a thread terminates without releasing its ownership of a >> mutex >> object, the mutex object is considered to be abandoned. A >> waiting thread >> can acquire ownership of an abandoned mutex object, but the wait >> function will return*WAIT_ABANDONED*to indicate that the mutex >> object is >> abandoned. An abandoned mutex object indicates that an error has >> occurred and that any shared resource being protected by the >> mutex >> object is in an undefined state. If the thread proceeds as >> though the >> mutex object had not been abandoned, it is no longer considered >> abandoned after the thread releases its ownership. This restores >> normal >> behavior if a handle to the mutex object is subsequently >> specified in a >> wait function." >> >> >> What does it mean to wait on mutex and ownership of the mutex >> object: >> "Any thread with a handle to a mutex object can use one of >> thewait >> functions >> > >to >> request ownership of the mutex object. If the mutex object is >> owned by >> another thread, the wait function blocks the requesting thread >> until the >> owning thread releases the mutex object using the*ReleaseMutex* >> > >__function." >> >> How we can release mutex and wait on already owned mutex: >> " After a thread obtains ownership of a mutex, it can specify >> the same >> mutex in repeated calls to the wait-functions >> > >__without >> blocking its execution. This prevents a thread from deadlocking >> itself >> while waiting for a mutex that it already owns. To release its >> ownership >> under such circumstances, the thread must call*ReleaseMutex* >> > >__once >> for each time that the mutex satisfied the conditions of a wait >> function." >> >> [1] >> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >> >> >> -Aleksej >> >> On 05/13/2014 04:00 PM, David Holmes wrote: >> >> I don't understand this one at all. What is an "abandoned >> mutex"? For >> that matter why does the code wait on a mutex and an event? >> Do we >> already own the mutex? If so what does it mean to wait on >> it? If not >> then how can we release it? >> >> ??? >> >> Thanks, >> David >> >> >> On 13/05/2014 8:57 PM, Alan Bateman wrote: >> >> >> This is debugger's shared memory transport so cc'ing >> serviceability-dev >> as that is there this code is maintained. >> >> Is there a test case or any outline of the conditions >> that cause this? I >> think that would be useful to understand the issue >> further. >> >> -Alan >> >> On 13/05/2014 11:46, Aleksej Efimov wrote: >> >> Hi, >> >> Can I have a review for 8032901 bug [1] fix [2]. >> There is a possible >> case when 'WaitForMultipleObjects' function can >> return the >> WAIT_ABANDONED_0 [3] error value. >> In such case it's better to release the mutex and >> return error value. >> This will prevent other threads to be blocked on >> abandoned mutex. >> >> Thank you, >> Aleksej >> >> [1] >> https://bugs.openjdk.java.net/__browse/JDK-8032901 >> >> [2] >> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >> >> [3] >> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >> >> >> >> >> From pavel.rappo at oracle.com Wed May 14 15:29:41 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 14 May 2014 16:29:41 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize Message-ID: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> Hi everyone, could you please review my change for JDK-7153400? http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ http://ccc.us.oracle.com/7153400 It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 Thanks -Pavel From chris.hegarty at oracle.com Wed May 14 15:39:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 May 2014 16:39:46 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> Message-ID: <53738E42.8080006@oracle.com> Thanks for doing this Pavel. I can sponsor this for you. -Chris. On 14/05/14 16:29, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-7153400? > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > http://ccc.us.oracle.com/7153400 > > It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > Thanks > -Pavel > From pavel.rappo at oracle.com Wed May 14 15:29:41 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 14 May 2014 16:29:41 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize Message-ID: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> Hi everyone, could you please review my change for JDK-7153400? http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ http://ccc.us.oracle.com/7153400 It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 Thanks -Pavel From christian.thalinger at oracle.com Wed May 14 16:02:35 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 May 2014 09:02:35 -0700 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <537349CA.1090904@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> Message-ID: <195D7C4C-58E0-44ED-A57C-D51159E60BA6@oracle.com> On May 14, 2014, at 3:47 AM, Vladimir Ivanov wrote: > Tobias, I agree with your evaluation. > > My only concern is that @Stable doesn't work for AtomicReferenceArray, so JIT doesn't see what is stored in the array. Now that is really unfortunate. > Maybe use a lock instead? > > Best regards, > Vladimir Ivanov > > On 5/14/14 2:33 PM, Tobias Hartmann wrote: >> Hi Remi, >> >> sorry, I accidentally reverted that part.. Here is the correct webrev: >> >> http://cr.openjdk.java.net/~anoll/8005873/webrev.01/ >> >> Thanks, >> Tobias >> >> On 14.05.2014 12:04, Remi Forax wrote: >>> your patch doesn't work ! >>> >>> the array is still allocated as an classical array in the constructor. >>> >>> cheers, >>> Remi >>> >>> Envoy? avec AquaMail pour Android >>> http://www.aqua-mail.com >>> >>> >>> Le 14 mai 2014 11:04:41 Tobias Hartmann a >>> ?crit : >>> >>>> Hi, >>>> >>>> please review the following patch for bug 8005873. >>>> >>>> *Problem* >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8005873 >>>> >>>> The test creates multiple threads (~500) that repeatedly execute >>>> invokeExact on a method handle referencing a static method. The call >>>> to invokeExact is performed through an optimized inline cache >>>> (CompiledStaticCall) that points to the LambdaForm generated for the >>>> method handle. The IC is first set to interpreted code by >>>> CompiledStaticCall::set_to_interpreted(...) but soon updated to refer >>>> to the compiled version of the lambda form (-Xcomp). >>>> >>>> Because tiered compilation is enabled, the VM decides to compile the >>>> LambdaForm at a different level and sets the old version to >>>> not-entrant. The next call through the IC therefore triggers a >>>> re-resolving of the call site finally performing a Java upcall to >>>> java.lang.invoke.MethodHandleNatives::linkMethod(...) (see call >>>> sequence [1]). A *new* LambdaForm is returned and >>>> CompiledStaticCall::set_to_interpreted(...) is executed again to >>>> update the IC. The assert is hit because the callee differs. >>>> >>>> The problem is that there are multiple LambdaForms created for the >>>> same invokeExact instruction. Caching in the Java runtime code should >>>> guarantee that only one LambdaForm is created and reused. >>>> Instrumenting Invokers::invokeHandleForm(...) shows that almost all >>>> requests result in a cache miss and return a new LambdaForm. >>>> >>>> This behaviour is caused by a race condition in >>>> Invokers::invokeHandleForm(...). Threads may initially see a cache >>>> miss when invoking MethodTypeForm::cachedLambdaForm(...), then create >>>> a new LambdaForm and call MethodTypeForm::setCachedLambdaForm(...) to >>>> update the cache without checking it again. In a high concurrency >>>> setting, this leads to multiple LambdaForms being created for the >>>> same invokeExact instruction because the cache entry is overwritten >>>> by multiple threads. >>>> >>>> *Solution* >>>> Webrev: http://cr.openjdk.java.net/~anoll/8005873/webrev.00/ >>>> >>>> An AtomicReferenceArray is used to cache the LambdaForms and >>>> .get(...) and .compareAndSet(...) are used to retrieve and update the >>>> cache entries. This allows only one thread to set the LambdaForm that >>>> is then being used by all instances of the invokeExact. >>>> >>>> *Testing* >>>> - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) >>>> - Nashorn + Octane >>>> - JPRT >>>> >>>> Many thanks to Christian Thalinger and Vladimir Ivanov! >>>> >>>> Best, >>>> Tobias >>>> >>>> [1] Call sequence of reresolving the IC target >>>> SharedRuntime::handle_wrong_method(...) >>>> -> SharedRuntime::reresolve_call_site(...) >>>> -> SharedRuntime::find_callee_method(...) >>>> -> SharedRuntime::find_callee_info_helper(...) >>>> -> LinkResolver::resolve_invoke(...) >>>> -> LinkResolver::resolve_invokehandle(...) >>>> -> LinkResolver::resolve_invokehandle(...) >>>> -> LinkResolver::lookup_polymorphic_method(...) >>>> -> SystemDictionary::find_method_handle_invoker(...) >>>> -> Java upcall to java.lang.invoke.MethodHandleNatives::linkMethod(...) >>>> -> Invokers::methodHandleInvokeLinkerMethod(...) >>>> -> Invokers::invokeHandleForm(...) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Backport? >>> >>> >> From mandy.chung at oracle.com Wed May 14 16:22:40 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 May 2014 09:22:40 -0700 Subject: 8043119: (props) Properties.storeToXML closes output stream In-Reply-To: <53734D6D.4010807@oracle.com> References: <53734D6D.4010807@oracle.com> Message-ID: <53739850.5050203@oracle.com> On 5/14/14 4:03 AM, Alan Bateman wrote: > > This is a follow-up to the recent change to the modules motivated > switch of the Properties XML methods to consistently use the UKit > parser. An issue that has surfaced since is that the wrapper around > UKit is incorrectly closing the output stream after writing the XML > document, a basic assertion not covered by the tests in the jdk > repository. Trivial fix: > > http://cr.openjdk.java.net/~alanb/8043119/webrev/ Looks good. Mandy From mike.duigou at oracle.com Wed May 14 17:03:29 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 May 2014 10:03:29 -0700 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> Message-ID: <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> Hi Pavel; The change and test looks good. Will the test be upstreamed or will Doug be adding a similar test in his upstream? Mike On May 14 2014, at 08:29 , Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-7153400? > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > http://ccc.us.oracle.com/7153400 > > It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > Thanks > -Pavel From martinrb at google.com Wed May 14 17:21:39 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 May 2014 10:21:39 -0700 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> Message-ID: Pavel, Thanks for writing a test. We (jsr166 maintainers will add the jtreg test to jsr166 CVS when it has passed review. Instead of "succeed", I would just write main-line code. If you want per-api-call granularity, write a testng test. Instead of "fail", I suggest as in jsr166 CVS src/test/tck/JSR166TestCase.java : public void assertThrows(Class expectedExceptionClass, Runnable... throwingActions) { for (Runnable throwingAction : throwingActions) { boolean threw = false; try { throwingAction.run(); } catch (Throwable t) { threw = true; if (!expectedExceptionClass.isInstance(t)) { AssertionFailedError afe = new AssertionFailedError ("Expected " + expectedExceptionClass.getName() + ", got " + t.getClass().getName()); afe.initCause(t); threadUnexpectedException(afe); } } if (!threw) shouldThrow(expectedExceptionClass.getName()); } } I suggest checking the return from p.awaitTermination p.awaitTermination(1, TimeUnit.MINUTES); as in src/test/tck/JSR166TestCase.java: /** * Waits out termination of a thread pool or fails doing so. */ void joinPool(ExecutorService exec) { try { exec.shutdown(); assertTrue("ExecutorService did not terminate in a timely manner", exec.awaitTermination(2 * LONG_DELAY_MS, MILLISECONDS)); } catch (SecurityException ok) { // Allowed in case test doesn't have privs } catch (InterruptedException ie) { fail("Unexpected InterruptedException"); } } On Wed, May 14, 2014 at 10:03 AM, Mike Duigou wrote: > Hi Pavel; > > The change and test looks good. Will the test be upstreamed or will Doug > be adding a similar test in his upstream? > > Mike > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > > > Hi everyone, > > > > could you please review my change for JDK-7153400? > > > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > > http://ccc.us.oracle.com/7153400 > > > > It's a long expected fix for a minor issue in the ThreadPoolExecutor. > This has been agreed with Doug Lea. The exact same change (except for the > test) is already in jsr166 repo: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > > > Thanks > > -Pavel > > From joel.franck at oracle.com Wed May 14 18:01:21 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Wed, 14 May 2014 20:01:21 +0200 Subject: RFR (S) 9 and 8u: JDK-8038994: AnnotatedType.getType() of a TypeVariable boundary without annotations return null Message-ID: <20140514180121.GA31973@oracle.com> Hi, Here is a fix for: https://bugs.openjdk.java.net/browse/JDK-8038994 In short, getAnnotatedFoo.getType() is supposed to return the same Type as getGenericFoo(). This wasn't the case for a type variable bound without an annotation previously. Also cleaned up an allocation while in the neighborhood. Webrev here: http://cr.openjdk.java.net/~jfranck/8038994/webrev.00/ cheers /Joel From pavel.rappo at oracle.com Wed May 14 19:15:30 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 14 May 2014 20:15:30 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> Message-ID: <11CE21F5-FB0A-4FEF-95BD-9764A3B97AB8@oracle.com> Hi Mike, Unfortunately I don't know. I suppose it is better to rely on our own jdk tests. The only thing I did was sent Doug 2 patches for the tck tests. But as far as I can see he hasn't applied them yet. And I don't even know if he is going to. Here they are: --- src/test/tck/ThreadPoolExecutorSubclassTest.java (revision 1.32) +++ src/test/tck/ThreadPoolExecutorSubclassTest.java (revision ) @@ -1180,6 +1180,23 @@ } /** + * setCorePoolSize(int) throws IllegalArgumentException + * if given a value greater the maximum pool size + */ + public void testCorePoolSizeIllegalArgumentException2() { + ThreadPoolExecutor p = + new CustomTPE(1,2,LONG_DELAY_MS, MILLISECONDS,new ArrayBlockingQueue(10)); + try { + p.setCorePoolSize(3); + shouldThrow(); + } catch (IllegalArgumentException success) { + } finally { + try { p.shutdown(); } catch (SecurityException ok) { return; } + } + joinPool(p); + } + + /** * setMaximumPoolSize(int) throws IllegalArgumentException * if given a value less the core pool size */ --- src/test/tck/ThreadPoolExecutorTest.java (revision 1.49) +++ src/test/tck/ThreadPoolExecutorTest.java (revision ) @@ -1302,6 +1302,25 @@ } /** + * setCorePoolSize(int) throws IllegalArgumentException if + * given a value greater the maximum pool size + */ + public void testCorePoolSizeIllegalArgumentException2() { + ThreadPoolExecutor p = + new ThreadPoolExecutor(1, 2, + LONG_DELAY_MS, MILLISECONDS, + new ArrayBlockingQueue(10)); + try { + p.setCorePoolSize(3); + shouldThrow(); + } catch (IllegalArgumentException success) { + } finally { + try { p.shutdown(); } catch (SecurityException ok) { return; } + } + joinPool(p); + } + + /** * setMaximumPoolSize(int) throws IllegalArgumentException if * given a value less the core pool size */ -Pavel On 14 May 2014, at 18:03, Mike Duigou wrote: > Hi Pavel; > > The change and test looks good. Will the test be upstreamed or will Doug be adding a similar test in his upstream? > > Mike > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > >> Hi everyone, >> >> could you please review my change for JDK-7153400? >> >> http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ >> http://ccc.us.oracle.com/7153400 >> >> It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 >> >> Thanks >> -Pavel > From martinrb at google.com Wed May 14 19:23:50 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 May 2014 12:23:50 -0700 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <11CE21F5-FB0A-4FEF-95BD-9764A3B97AB8@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> <11CE21F5-FB0A-4FEF-95BD-9764A3B97AB8@oracle.com> Message-ID: Thanks, Pavel. These tests do belong in the tck tests, since they are testing spec, but only in the jdk9-specific versions. I'll see what I can do to integrate them. On Wed, May 14, 2014 at 12:15 PM, Pavel Rappo wrote: > Hi Mike, > > Unfortunately I don't know. I suppose it is better to rely on our own jdk > tests. The only thing I did was sent Doug 2 patches for the tck tests. But > as far as I can see he hasn't applied them yet. And I don't even know if he > is going to. Here they are: > > --- src/test/tck/ThreadPoolExecutorSubclassTest.java (revision 1.32) > +++ src/test/tck/ThreadPoolExecutorSubclassTest.java (revision ) > @@ -1180,6 +1180,23 @@ > } > > /** > + * setCorePoolSize(int) throws IllegalArgumentException > + * if given a value greater the maximum pool size > + */ > + public void testCorePoolSizeIllegalArgumentException2() { > + ThreadPoolExecutor p = > + new CustomTPE(1,2,LONG_DELAY_MS, MILLISECONDS,new > ArrayBlockingQueue(10)); > + try { > + p.setCorePoolSize(3); > + shouldThrow(); > + } catch (IllegalArgumentException success) { > + } finally { > + try { p.shutdown(); } catch (SecurityException ok) { return; } > + } > + joinPool(p); > + } > + > + /** > * setMaximumPoolSize(int) throws IllegalArgumentException > * if given a value less the core pool size > */ > > --- src/test/tck/ThreadPoolExecutorTest.java (revision 1.49) > +++ src/test/tck/ThreadPoolExecutorTest.java (revision ) > @@ -1302,6 +1302,25 @@ > } > > /** > + * setCorePoolSize(int) throws IllegalArgumentException if > + * given a value greater the maximum pool size > + */ > + public void testCorePoolSizeIllegalArgumentException2() { > + ThreadPoolExecutor p = > + new ThreadPoolExecutor(1, 2, > + LONG_DELAY_MS, MILLISECONDS, > + new ArrayBlockingQueue(10)); > + try { > + p.setCorePoolSize(3); > + shouldThrow(); > + } catch (IllegalArgumentException success) { > + } finally { > + try { p.shutdown(); } catch (SecurityException ok) { return; } > + } > + joinPool(p); > + } > + > + /** > * setMaximumPoolSize(int) throws IllegalArgumentException if > * given a value less the core pool size > */ > > > -Pavel > > On 14 May 2014, at 18:03, Mike Duigou wrote: > > > Hi Pavel; > > > > The change and test looks good. Will the test be upstreamed or will Doug > be adding a similar test in his upstream? > > > > Mike > > > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > > > >> Hi everyone, > >> > >> could you please review my change for JDK-7153400? > >> > >> http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > >> http://ccc.us.oracle.com/7153400 > >> > >> It's a long expected fix for a minor issue in the ThreadPoolExecutor. > This has been agreed with Doug Lea. The exact same change (except for the > test) is already in jsr166 repo: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > >> > >> Thanks > >> -Pavel > > > > From dl at cs.oswego.edu Wed May 14 19:56:11 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 14 May 2014 15:56:11 -0400 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <11CE21F5-FB0A-4FEF-95BD-9764A3B97AB8@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> <11CE21F5-FB0A-4FEF-95BD-9764A3B97AB8@oracle.com> Message-ID: <5373CA5B.5030402@cs.oswego.edu> On 05/14/2014 03:15 PM, Pavel Rappo wrote: > Hi Mike, > > Unfortunately I don't know. I suppose it is better to rely on our own jdk > tests. The only thing I did was sent Doug 2 patches for the tck tests. But as > far as I can see he hasn't applied them yet. And I don't even know if he is > going to. Here they are: > Sorry; I'm running behind (end of semester here). As Martin hinted at, the reason I hadn't gotten to this is that this is the first jdk9-only test revision, and we hadn't set up for this yet. But we'll definitely include jsr166 tck coverage by somehow adapting these. -Doug From roger.riggs at oracle.com Wed May 14 20:03:54 2014 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 14 May 2014 16:03:54 -0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537136AA.8090807@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> Message-ID: <5373CC2A.8060704@oracle.com> Hi, For system local process identifiers, all of the systems I'm aware are 32 bit integers, printed and parsed in decimal for ease of use. I would describe the native pid as: The native process id is the identifier commonly used in the operating system APIs and commands to show the status of and manage processes; typically a decimal number with 1 to 6 digits. The Apollo system used a string to be able to uniformly address processes across hosts and it was parseable to host and decimal pid. I anticipate a ProcessHandle type with methods to check if the process is alive, to destroy it, wait for it to terminate, etc. It would be a supertype of Process but not all ProcessHandles would be processes since they were not created by Process/ProcessBuilder and have different security concerns and checks. ProcessHandles would be returned from factory methods like current(long pid) or current(). If Java is ported to a system with non-numeric process identifiers it would be viable to add appropriate factory methods. Roger On 5/12/2014 5:01 PM, Alan Bateman wrote: > On 12/05/2014 20:44, roger riggs wrote: >> Please review and comment on this long requested addition to provide the >> native process id of a spawned Process. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > I think the representation of the pid needs consideration - we need to > be happy that using a long is the right thing to do and won't cause us > problems in the future and won't conflict with other APIs that we > might add in this area. > > In terms of spec then it might be helpful to say a bit more to define > a "native process id", even in an abstract way. > > -Alan > > From pavel.rappo at oracle.com Wed May 14 20:11:28 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 14 May 2014 21:11:28 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <5373CA5B.5030402@cs.oswego.edu> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> <11CE21F5-FB0A-4FEF-95BD-9764A3B97AB8@oracle.com> <5373CA5B.5030402@cs.oswego.edu> Message-ID: <3F092F79-B0C4-47FD-A614-C2F65CA3D335@oracle.com> Oh I see, thanks. -Pavel On 14 May 2014, at 20:56, Doug Lea
    wrote: > On 05/14/2014 03:15 PM, Pavel Rappo wrote: >> Hi Mike, >> >> Unfortunately I don't know. I suppose it is better to rely on our own jdk >> tests. The only thing I did was sent Doug 2 patches for the tck tests. But as >> far as I can see he hasn't applied them yet. And I don't even know if he is >> going to. Here they are: >> > > Sorry; I'm running behind (end of semester here). As Martin hinted at, > the reason I hadn't gotten to this is that this is the first jdk9-only > test revision, and we hadn't set up for this yet. But we'll definitely > include jsr166 tck coverage by somehow adapting these. > > -Doug > From pavel.rappo at oracle.com Wed May 14 21:02:47 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 14 May 2014 22:02:47 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> Message-ID: Hi Martin, Thanks for you comments. I forgot indeed that awaitTermination indicates its result by returning a boolean value rather than throwing TimeoutException. So this should be fine now: @@ -77,7 +77,10 @@ private static void dispose(ThreadPoolExecutor p) { p.shutdownNow(); try { - p.awaitTermination(1, TimeUnit.MINUTES); + boolean shutdown = p.awaitTermination(1, TimeUnit.MINUTES); + if (!shutdown) + throw new RuntimeException( + "Pool did not terminate in a timely manner"); } catch (InterruptedException e) { throw new RuntimeException("Should not happen", e); } As for the "fail" method, it's a little bit different from "assertThrows". I tried to keep my checks (test payload) to be one liners. So the whole lifecycle of a ThreadPoolExecutor is confined in a single line. In addition to check whether the IllegalArgumentException is thrown, "fail" also disposes the pool. It's not clean object oriented design, I agree, but it was done for the sake of clarity. This test is supposed to be simple. -Pavel On 14 May 2014, at 18:21, Martin Buchholz wrote: > Pavel, > > Thanks for writing a test. > > We (jsr166 maintainers will add the jtreg test to jsr166 CVS when it has passed review. > > Instead of "succeed", I would just write main-line code. If you want per-api-call granularity, write a testng test. > > Instead of "fail", I suggest as in jsr166 CVS src/test/tck/JSR166TestCase.java : > > public void assertThrows(Class expectedExceptionClass, > Runnable... throwingActions) { > for (Runnable throwingAction : throwingActions) { > boolean threw = false; > try { throwingAction.run(); } > catch (Throwable t) { > threw = true; > if (!expectedExceptionClass.isInstance(t)) { > AssertionFailedError afe = > new AssertionFailedError > ("Expected " + expectedExceptionClass.getName() + > ", got " + t.getClass().getName()); > afe.initCause(t); > threadUnexpectedException(afe); > } > } > if (!threw) > shouldThrow(expectedExceptionClass.getName()); > } > } > > I suggest checking the return from p.awaitTermination > p.awaitTermination(1, TimeUnit.MINUTES); > > as in src/test/tck/JSR166TestCase.java: > > > /** > * Waits out termination of a thread pool or fails doing so. > */ > void joinPool(ExecutorService exec) { > try { > exec.shutdown(); > assertTrue("ExecutorService did not terminate in a timely manner", > exec.awaitTermination(2 * LONG_DELAY_MS, MILLISECONDS)); > } catch (SecurityException ok) { > // Allowed in case test doesn't have privs > } catch (InterruptedException ie) { > fail("Unexpected InterruptedException"); > } > } > > > > > On Wed, May 14, 2014 at 10:03 AM, Mike Duigou wrote: > Hi Pavel; > > The change and test looks good. Will the test be upstreamed or will Doug be adding a similar test in his upstream? > > Mike > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > > > Hi everyone, > > > > could you please review my change for JDK-7153400? > > > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > > http://ccc.us.oracle.com/7153400 > > > > It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > > > Thanks > > -Pavel > > From martinrb at google.com Wed May 14 21:10:36 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 May 2014 14:10:36 -0700 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> Message-ID: We added the necessary support for jdk9+ tests and added the test below, which I think suffices. I don't think a separate jtreg test is necessary. (Just need to make sure openjdk testers also run Doug's jsr166 CVS tests!) /* * Written by Martin Buchholz and Doug Lea with assistance from * members of JCP JSR-166 Expert Group and released to the public * domain, as explained at * http://creativecommons.org/publicdomain/zero/1.0/ */ import junit.framework.*; import java.util.concurrent.*; import static java.util.concurrent.TimeUnit.MILLISECONDS; import static java.util.concurrent.TimeUnit.NANOSECONDS; import java.util.*; public class ThreadPoolExecutor9Test extends JSR166TestCase { public static void main(String[] args) { junit.textui.TestRunner.run(suite()); } public static Test suite() { return new TestSuite(ThreadPoolExecutor9Test.class); } /** * Configuration changes that allow core pool size greater than * max pool size result in IllegalArgumentException. */ public void testPoolSizeInvariants() { ThreadPoolExecutor p = new ThreadPoolExecutor(1, 1, LONG_DELAY_MS, MILLISECONDS, new ArrayBlockingQueue(10)); for (int s = 1; s < 5; s++) { p.setMaximumPoolSize(s); p.setCorePoolSize(s); try { p.setMaximumPoolSize(s - 1); shouldThrow(); } catch (IllegalArgumentException success) {} assertEquals(s, p.getCorePoolSize()); assertEquals(s, p.getMaximumPoolSize()); try { p.setCorePoolSize(s + 1); shouldThrow(); } catch (IllegalArgumentException success) {} assertEquals(s, p.getCorePoolSize()); assertEquals(s, p.getMaximumPoolSize()); } joinPool(p); } } On Wed, May 14, 2014 at 2:02 PM, Pavel Rappo wrote: > Hi Martin, > > Thanks for you comments. I forgot indeed that awaitTermination indicates > its result by returning a boolean value rather than throwing > TimeoutException. So this should be fine now: > > @@ -77,7 +77,10 @@ > private static void dispose(ThreadPoolExecutor p) { > p.shutdownNow(); > try { > - p.awaitTermination(1, TimeUnit.MINUTES); > + boolean shutdown = p.awaitTermination(1, TimeUnit.MINUTES); > + if (!shutdown) > + throw new RuntimeException( > + "Pool did not terminate in a timely manner"); > } catch (InterruptedException e) { > throw new RuntimeException("Should not happen", e); > } > > As for the "fail" method, it's a little bit different from "assertThrows". > I tried to keep my checks (test payload) to be one liners. So the whole > lifecycle of a ThreadPoolExecutor is confined in a single line. In addition > to check whether the IllegalArgumentException is thrown, "fail" also > disposes the pool. It's not clean object oriented design, I agree, but it > was done for the sake of clarity. This test is supposed to be simple. > > -Pavel > > On 14 May 2014, at 18:21, Martin Buchholz wrote: > > > Pavel, > > > > Thanks for writing a test. > > > > We (jsr166 maintainers will add the jtreg test to jsr166 CVS when it has > passed review. > > > > Instead of "succeed", I would just write main-line code. If you want > per-api-call granularity, write a testng test. > > > > Instead of "fail", I suggest as in jsr166 CVS > src/test/tck/JSR166TestCase.java : > > > > public void assertThrows(Class > expectedExceptionClass, > > Runnable... throwingActions) { > > for (Runnable throwingAction : throwingActions) { > > boolean threw = false; > > try { throwingAction.run(); } > > catch (Throwable t) { > > threw = true; > > if (!expectedExceptionClass.isInstance(t)) { > > AssertionFailedError afe = > > new AssertionFailedError > > ("Expected " + expectedExceptionClass.getName() + > > ", got " + t.getClass().getName()); > > afe.initCause(t); > > threadUnexpectedException(afe); > > } > > } > > if (!threw) > > shouldThrow(expectedExceptionClass.getName()); > > } > > } > > > > I suggest checking the return from p.awaitTermination > > p.awaitTermination(1, TimeUnit.MINUTES); > > > > as in src/test/tck/JSR166TestCase.java: > > > > > > /** > > * Waits out termination of a thread pool or fails doing so. > > */ > > void joinPool(ExecutorService exec) { > > try { > > exec.shutdown(); > > assertTrue("ExecutorService did not terminate in a timely > manner", > > exec.awaitTermination(2 * LONG_DELAY_MS, > MILLISECONDS)); > > } catch (SecurityException ok) { > > // Allowed in case test doesn't have privs > > } catch (InterruptedException ie) { > > fail("Unexpected InterruptedException"); > > } > > } > > > > > > > > > > On Wed, May 14, 2014 at 10:03 AM, Mike Duigou > wrote: > > Hi Pavel; > > > > The change and test looks good. Will the test be upstreamed or will Doug > be adding a similar test in his upstream? > > > > Mike > > > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > > > > > Hi everyone, > > > > > > could you please review my change for JDK-7153400? > > > > > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > > > http://ccc.us.oracle.com/7153400 > > > > > > It's a long expected fix for a minor issue in the ThreadPoolExecutor. > This has been agreed with Doug Lea. The exact same change (except for the > test) is already in jsr166 repo: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > > > > > Thanks > > > -Pavel > > > > > > From aleksej.efimov at oracle.com Wed May 14 22:59:17 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 15 May 2014 02:59:17 +0400 Subject: RFR: 8043012: (tz) Support tzdata2014c Message-ID: <5373F545.6090406@oracle.com> Hello, Can I have a review for the tzdata2014c integration to JDK9. This is a standard release of tzdata (except the hurry with Egypt rules - the main part in this release). The following set of tests was executed with no failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar Webrev: http://cr.openjdk.java.net/~aefimov/8043012/9/webrev.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8043012 Thank you, Aleksej From martinrb at google.com Wed May 14 23:14:12 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 May 2014 16:14:12 -0700 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <5373CC2A.8060704@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> Message-ID: I am OK with using longs despite my academic worries about the year 2100. On Wed, May 14, 2014 at 1:03 PM, roger riggs wrote: > Hi, > > For system local process identifiers, all of the systems I'm aware are > 32 bit integers, printed and parsed in decimal for ease of use. > I would describe the native pid as: > The native process id is the identifier commonly used in the > operating system APIs and commands to show the status of and > manage processes; typically a decimal number with 1 to 6 digits. > > The Apollo system used a string to be able to uniformly address > processes across hosts and it was parseable to host and decimal pid. > > I anticipate a ProcessHandle type with methods to check if the process is > alive, > to destroy it, wait for it to terminate, etc. > It would be a supertype of Process but not all ProcessHandles would be > processes > since they were not created by Process/ProcessBuilder and have different > security concerns and checks. > ProcessHandles would be returned from factory methods like current(long > pid) > or current(). If Java is ported to a system with non-numeric process > identifiers > it would be viable to add appropriate factory methods. > > Roger > > > On 5/12/2014 5:01 PM, Alan Bateman wrote: > >> On 12/05/2014 20:44, roger riggs wrote: >> >>> Please review and comment on this long requested addition to provide the >>> native process id of a spawned Process. >>> >>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 >>> >> I think the representation of the pid needs consideration - we need to be >> happy that using a long is the right thing to do and won't cause us >> problems in the future and won't conflict with other APIs that we might add >> in this area. >> >> In terms of spec then it might be helpful to say a bit more to define a >> "native process id", even in an abstract way. >> >> -Alan >> >> >> > From david.holmes at oracle.com Thu May 15 01:48:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 May 2014 11:48:25 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53736D2D.7010805@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> Message-ID: <53741CE9.1030807@oracle.com> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: > David, Vitaly, > > I totally agree with Vitaly's explanation (Vitaly - thank you for that) > and code in shmemBase.c (the usage of enterMutex() function for > sending/receiving bytes through shared memory connection) illustrates on > how the connection shutdown event is used as a "cancellation token". Thanks for clarifying that. So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: 204 /* If the mutex is abandoned we want to return an error 205 * and also release the mutex so that we don't cause 206 * other threads to be blocked. If a mutex was abandoned 207 * we are in scary state. Data may be corrupted or inconsistent 208 * but it is still better to let other threads run (and possibly 209 * crash) than having them blocked (on the premise that a crash 210 * is always easier to debug than a hang). Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. But I'll let the serviceability folk chime in here. Thanks, David > Thank you, > -Aleksej > > > On 05/14/2014 01:05 PM, David Holmes wrote: >> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>> In windows, you acquire a mutex by waiting on it using one of the wait >>> functions, one of them employed in the code in question. If >>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>> current thread has ownership now. >> >> Yes I understand the basic mechanics :) >> >>> It's also common to use multi wait functions where the event is a >>> "cancelation token", e.g. manual reset event; this allows someone to >>> cancel waiting on mutex acquisition and return from the wait function. >>> Presumably that's the case here, but I'll let Aleksej confirm; just >>> wanted to throw this out there in the meantime :). >> >> Ah I see - yes cancellable lock acquisition would make sense. >> >> Thanks, >> David >> >>> Sent from my phone >>> >>> On May 13, 2014 6:46 PM, "David Holmes" >> > wrote: >>> >>> Hi Aleksej, >>> >>> Thanks for the doc references regarding abandonment. >>> >>> Let me rephrase my question. What is this logic trying to achieve by >>> waiting on both a mutex and an event? Do we already own the mutex >>> when this function is called? >>> >>> David >>> >>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>> >>> David, >>> >>> The Windows has a different terminology for mutex objects (much >>> differs >>> from the POSIX one). This one link gave me some understanding of >>> it [1]. >>> >>> Here is the MSDN [1] description of what "abandoned mutex" is: >>> " If a thread terminates without releasing its ownership of a >>> mutex >>> object, the mutex object is considered to be abandoned. A >>> waiting thread >>> can acquire ownership of an abandoned mutex object, but the wait >>> function will return*WAIT_ABANDONED*to indicate that the mutex >>> object is >>> abandoned. An abandoned mutex object indicates that an error has >>> occurred and that any shared resource being protected by the >>> mutex >>> object is in an undefined state. If the thread proceeds as >>> though the >>> mutex object had not been abandoned, it is no longer considered >>> abandoned after the thread releases its ownership. This restores >>> normal >>> behavior if a handle to the mutex object is subsequently >>> specified in a >>> wait function." >>> >>> >>> What does it mean to wait on mutex and ownership of the mutex >>> object: >>> "Any thread with a handle to a mutex object can use one of >>> thewait >>> functions >>> >> >to >>> request ownership of the mutex object. If the mutex object is >>> owned by >>> another thread, the wait function blocks the requesting thread >>> until the >>> owning thread releases the mutex object using the*ReleaseMutex* >>> >> >__function." >>> >>> How we can release mutex and wait on already owned mutex: >>> " After a thread obtains ownership of a mutex, it can specify >>> the same >>> mutex in repeated calls to the wait-functions >>> >> >__without >>> blocking its execution. This prevents a thread from deadlocking >>> itself >>> while waiting for a mutex that it already owns. To release its >>> ownership >>> under such circumstances, the thread must call*ReleaseMutex* >>> >> >__once >>> for each time that the mutex satisfied the conditions of a wait >>> function." >>> >>> [1] >>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>> >>> >>> -Aleksej >>> >>> On 05/13/2014 04:00 PM, David Holmes wrote: >>> >>> I don't understand this one at all. What is an "abandoned >>> mutex"? For >>> that matter why does the code wait on a mutex and an event? >>> Do we >>> already own the mutex? If so what does it mean to wait on >>> it? If not >>> then how can we release it? >>> >>> ??? >>> >>> Thanks, >>> David >>> >>> >>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>> >>> >>> This is debugger's shared memory transport so cc'ing >>> serviceability-dev >>> as that is there this code is maintained. >>> >>> Is there a test case or any outline of the conditions >>> that cause this? I >>> think that would be useful to understand the issue >>> further. >>> >>> -Alan >>> >>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>> >>> Hi, >>> >>> Can I have a review for 8032901 bug [1] fix [2]. >>> There is a possible >>> case when 'WaitForMultipleObjects' function can >>> return the >>> WAIT_ABANDONED_0 [3] error value. >>> In such case it's better to release the mutex and >>> return error value. >>> This will prevent other threads to be blocked on >>> abandoned mutex. >>> >>> Thank you, >>> Aleksej >>> >>> [1] >>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>> >>> [2] >>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>> >>> [3] >>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>> >>> >>> >>> >>> > From yuka.kamiya at oracle.com Thu May 15 01:54:56 2014 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Thu, 15 May 2014 10:54:56 +0900 Subject: RFR: 8043012: (tz) Support tzdata2014c In-Reply-To: <5373F545.6090406@oracle.com> References: <5373F545.6090406@oracle.com> Message-ID: <53741E70.7070205@oracle.com> Hi, The fix looks good to me. Thanks, -- Yuka (5/15/14, 7:59), Aleksej Efimov wrote: > Hello, > > Can I have a review for the tzdata2014c integration to JDK9. This is a standard release of tzdata (except the hurry with Egypt rules - the main part in this release). > The following set of tests was executed with no failures: > test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone > test/java/time test/java/util/Formatter test/closed/java/util/Calendar > > Webrev: http://cr.openjdk.java.net/~aefimov/8043012/9/webrev.00 > Bug: https://bugs.openjdk.java.net/browse/JDK-8043012 > > Thank you, > Aleksej From me at sandipan.net Thu May 15 03:45:33 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Wed, 14 May 2014 23:45:33 -0400 Subject: 8037343 Ready for review Message-ID: Hi all, Please find below the webrev for bug 8037343. http://www.sandipan.net/public/webrevs/8037343/webrev.00 Thanks in advance - Cheers, SR Sandipan Razzaque | www.sandipan.net From Alan.Bateman at oracle.com Thu May 15 07:37:35 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 May 2014 08:37:35 +0100 Subject: 8037343 Ready for review In-Reply-To: References: Message-ID: <53746EBF.5090900@oracle.com> Forwarding to i18n-dev as that it usually the list where changes to the locale and resources are maintained. -Alan On 15/05/2014 04:45, Sandipan Razzaque wrote: > Hi all, > > Please find below the webrev for bug 8037343. > > http://www.sandipan.net/public/webrevs/8037343/webrev.00 > > Thanks in advance - > > Cheers, > SR > > Sandipan Razzaque | www.sandipan.net From masayoshi.okutsu at oracle.com Thu May 15 07:54:48 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 15 May 2014 16:54:48 +0900 Subject: RFR: 8043012: (tz) Support tzdata2014c In-Reply-To: <5373F545.6090406@oracle.com> References: <5373F545.6090406@oracle.com> Message-ID: <537472C8.3010803@oracle.com> Looks good to me. Masayoshi On 5/15/2014 7:59 AM, Aleksej Efimov wrote: > Hello, > > Can I have a review for the tzdata2014c integration to JDK9. This is a > standard release of tzdata (except the hurry with Egypt rules - the > main part in this release). > The following set of tests was executed with no failures: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone > test/java/time test/java/util/Formatter test/closed/java/util/Calendar > > Webrev: http://cr.openjdk.java.net/~aefimov/8043012/9/webrev.00 > Bug: https://bugs.openjdk.java.net/browse/JDK-8043012 > > Thank you, > Aleksej From staffan.larsen at oracle.com Thu May 15 09:11:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 15 May 2014 11:11:05 +0200 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53741CE9.1030807@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> Message-ID: <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> On 15 maj 2014, at 03:48, David Holmes wrote: > On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >> David, Vitaly, >> >> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >> and code in shmemBase.c (the usage of enterMutex() function for >> sending/receiving bytes through shared memory connection) illustrates on >> how the connection shutdown event is used as a "cancellation token". > > Thanks for clarifying that. > > So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. > > The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. > > Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: > > 204 /* If the mutex is abandoned we want to return an error > 205 * and also release the mutex so that we don't cause > 206 * other threads to be blocked. If a mutex was abandoned > 207 * we are in scary state. Data may be corrupted or inconsistent > 208 * but it is still better to let other threads run (and possibly > 209 * crash) than having them blocked (on the premise that a crash > 210 * is always easier to debug than a hang). > > Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. > > But I'll let the serviceability folk chime in here. I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. /Staffan > > Thanks, > David > > >> Thank you, >> -Aleksej >> >> >> On 05/14/2014 01:05 PM, David Holmes wrote: >>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>> functions, one of them employed in the code in question. If >>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>> current thread has ownership now. >>> >>> Yes I understand the basic mechanics :) >>> >>>> It's also common to use multi wait functions where the event is a >>>> "cancelation token", e.g. manual reset event; this allows someone to >>>> cancel waiting on mutex acquisition and return from the wait function. >>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>> wanted to throw this out there in the meantime :). >>> >>> Ah I see - yes cancellable lock acquisition would make sense. >>> >>> Thanks, >>> David >>> >>>> Sent from my phone >>>> >>>> On May 13, 2014 6:46 PM, "David Holmes" >>> > wrote: >>>> >>>> Hi Aleksej, >>>> >>>> Thanks for the doc references regarding abandonment. >>>> >>>> Let me rephrase my question. What is this logic trying to achieve by >>>> waiting on both a mutex and an event? Do we already own the mutex >>>> when this function is called? >>>> >>>> David >>>> >>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>> >>>> David, >>>> >>>> The Windows has a different terminology for mutex objects (much >>>> differs >>>> from the POSIX one). This one link gave me some understanding of >>>> it [1]. >>>> >>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>> " If a thread terminates without releasing its ownership of a >>>> mutex >>>> object, the mutex object is considered to be abandoned. A >>>> waiting thread >>>> can acquire ownership of an abandoned mutex object, but the wait >>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>> object is >>>> abandoned. An abandoned mutex object indicates that an error has >>>> occurred and that any shared resource being protected by the >>>> mutex >>>> object is in an undefined state. If the thread proceeds as >>>> though the >>>> mutex object had not been abandoned, it is no longer considered >>>> abandoned after the thread releases its ownership. This restores >>>> normal >>>> behavior if a handle to the mutex object is subsequently >>>> specified in a >>>> wait function." >>>> >>>> >>>> What does it mean to wait on mutex and ownership of the mutex >>>> object: >>>> "Any thread with a handle to a mutex object can use one of >>>> thewait >>>> functions >>>> >>> >to >>>> request ownership of the mutex object. If the mutex object is >>>> owned by >>>> another thread, the wait function blocks the requesting thread >>>> until the >>>> owning thread releases the mutex object using the*ReleaseMutex* >>>> >>> >__function." >>>> >>>> How we can release mutex and wait on already owned mutex: >>>> " After a thread obtains ownership of a mutex, it can specify >>>> the same >>>> mutex in repeated calls to the wait-functions >>>> >>> >__without >>>> blocking its execution. This prevents a thread from deadlocking >>>> itself >>>> while waiting for a mutex that it already owns. To release its >>>> ownership >>>> under such circumstances, the thread must call*ReleaseMutex* >>>> >>> >__once >>>> for each time that the mutex satisfied the conditions of a wait >>>> function." >>>> >>>> [1] >>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>> >>>> >>>> -Aleksej >>>> >>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>> >>>> I don't understand this one at all. What is an "abandoned >>>> mutex"? For >>>> that matter why does the code wait on a mutex and an event? >>>> Do we >>>> already own the mutex? If so what does it mean to wait on >>>> it? If not >>>> then how can we release it? >>>> >>>> ??? >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>> >>>> >>>> This is debugger's shared memory transport so cc'ing >>>> serviceability-dev >>>> as that is there this code is maintained. >>>> >>>> Is there a test case or any outline of the conditions >>>> that cause this? I >>>> think that would be useful to understand the issue >>>> further. >>>> >>>> -Alan >>>> >>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>> >>>> Hi, >>>> >>>> Can I have a review for 8032901 bug [1] fix [2]. >>>> There is a possible >>>> case when 'WaitForMultipleObjects' function can >>>> return the >>>> WAIT_ABANDONED_0 [3] error value. >>>> In such case it's better to release the mutex and >>>> return error value. >>>> This will prevent other threads to be blocked on >>>> abandoned mutex. >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] >>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>> >>>> [2] >>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>> >>>> [3] >>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>> >>>> >>>> >>>> >>>> >> From paul.sandoz at oracle.com Thu May 15 10:30:02 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 May 2014 12:30:02 +0200 Subject: RFR (S) 9 and 8u: JDK-8038994: AnnotatedType.getType() of a TypeVariable boundary without annotations return null In-Reply-To: <20140514180121.GA31973@oracle.com> References: <20140514180121.GA31973@oracle.com> Message-ID: <21A4AA8F-DE6F-45DA-A30E-C737C7496296@oracle.com> On May 14, 2014, at 8:01 PM, Joel Borggren-Franck wrote: > Hi, > > Here is a fix for: https://bugs.openjdk.java.net/browse/JDK-8038994 > > In short, getAnnotatedFoo.getType() is supposed to return the same Type > as getGenericFoo(). This wasn't the case for a type variable bound > without an annotation previously. > > Also cleaned up an allocation while in the neighborhood. > > Webrev here: http://cr.openjdk.java.net/~jfranck/8038994/webrev.00/ > The non test code looks good to me: Not totally sure about the test approach: 48 @Test(dataProvider = "data") 49 public void testClass(Class c, String method) throws Exception { 50 if (c.getTypeParameters().length == 0) 51 return; 60 @Test(dataProvider = "data") 61 public void testMethod(Classc, String method) throws Exception { 62 if ("".equals(method)) 63 return; That's gonna produce redundant results in test reports for stuff that is filtered out by the test method. Perhaps split the data provider into two, one for classes and one for methods, and replace the if statements with asserts? Paul. From pavel.rappo at oracle.com Thu May 15 12:53:45 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 15 May 2014 13:53:45 +0100 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> Message-ID: <382D099A-2354-41D3-84DD-F5BF8B7C5305@oracle.com> Martin, if I exclude the test can we push the change then? -Pavel On 14 May 2014, at 22:10, Martin Buchholz wrote: > We added the necessary support for jdk9+ tests and added the test below, which I think suffices. I don't think a separate jtreg test is necessary. (Just need to make sure openjdk testers also run Doug's jsr166 CVS tests!) > > /* > * Written by Martin Buchholz and Doug Lea with assistance from > * members of JCP JSR-166 Expert Group and released to the public > * domain, as explained at > * http://creativecommons.org/publicdomain/zero/1.0/ > */ > > import junit.framework.*; > import java.util.concurrent.*; > import static java.util.concurrent.TimeUnit.MILLISECONDS; > import static java.util.concurrent.TimeUnit.NANOSECONDS; > import java.util.*; > > public class ThreadPoolExecutor9Test extends JSR166TestCase { > public static void main(String[] args) { > junit.textui.TestRunner.run(suite()); > } > public static Test suite() { > return new TestSuite(ThreadPoolExecutor9Test.class); > } > > /** > * Configuration changes that allow core pool size greater than > * max pool size result in IllegalArgumentException. > */ > public void testPoolSizeInvariants() { > ThreadPoolExecutor p = > new ThreadPoolExecutor(1, 1, > LONG_DELAY_MS, MILLISECONDS, > new ArrayBlockingQueue(10)); > for (int s = 1; s < 5; s++) { > p.setMaximumPoolSize(s); > p.setCorePoolSize(s); > try { > p.setMaximumPoolSize(s - 1); > shouldThrow(); > } catch (IllegalArgumentException success) {} > assertEquals(s, p.getCorePoolSize()); > assertEquals(s, p.getMaximumPoolSize()); > try { > p.setCorePoolSize(s + 1); > shouldThrow(); > } catch (IllegalArgumentException success) {} > assertEquals(s, p.getCorePoolSize()); > assertEquals(s, p.getMaximumPoolSize()); > } > joinPool(p); > } > > } > > > > On Wed, May 14, 2014 at 2:02 PM, Pavel Rappo wrote: > Hi Martin, > > Thanks for you comments. I forgot indeed that awaitTermination indicates its result by returning a boolean value rather than throwing TimeoutException. So this should be fine now: > > @@ -77,7 +77,10 @@ > private static void dispose(ThreadPoolExecutor p) { > p.shutdownNow(); > try { > - p.awaitTermination(1, TimeUnit.MINUTES); > + boolean shutdown = p.awaitTermination(1, TimeUnit.MINUTES); > + if (!shutdown) > + throw new RuntimeException( > + "Pool did not terminate in a timely manner"); > } catch (InterruptedException e) { > throw new RuntimeException("Should not happen", e); > } > > As for the "fail" method, it's a little bit different from "assertThrows". I tried to keep my checks (test payload) to be one liners. So the whole lifecycle of a ThreadPoolExecutor is confined in a single line. In addition to check whether the IllegalArgumentException is thrown, "fail" also disposes the pool. It's not clean object oriented design, I agree, but it was done for the sake of clarity. This test is supposed to be simple. > > -Pavel > > On 14 May 2014, at 18:21, Martin Buchholz wrote: > > > Pavel, > > > > Thanks for writing a test. > > > > We (jsr166 maintainers will add the jtreg test to jsr166 CVS when it has passed review. > > > > Instead of "succeed", I would just write main-line code. If you want per-api-call granularity, write a testng test. > > > > Instead of "fail", I suggest as in jsr166 CVS src/test/tck/JSR166TestCase.java : > > > > public void assertThrows(Class expectedExceptionClass, > > Runnable... throwingActions) { > > for (Runnable throwingAction : throwingActions) { > > boolean threw = false; > > try { throwingAction.run(); } > > catch (Throwable t) { > > threw = true; > > if (!expectedExceptionClass.isInstance(t)) { > > AssertionFailedError afe = > > new AssertionFailedError > > ("Expected " + expectedExceptionClass.getName() + > > ", got " + t.getClass().getName()); > > afe.initCause(t); > > threadUnexpectedException(afe); > > } > > } > > if (!threw) > > shouldThrow(expectedExceptionClass.getName()); > > } > > } > > > > I suggest checking the return from p.awaitTermination > > p.awaitTermination(1, TimeUnit.MINUTES); > > > > as in src/test/tck/JSR166TestCase.java: > > > > > > /** > > * Waits out termination of a thread pool or fails doing so. > > */ > > void joinPool(ExecutorService exec) { > > try { > > exec.shutdown(); > > assertTrue("ExecutorService did not terminate in a timely manner", > > exec.awaitTermination(2 * LONG_DELAY_MS, MILLISECONDS)); > > } catch (SecurityException ok) { > > // Allowed in case test doesn't have privs > > } catch (InterruptedException ie) { > > fail("Unexpected InterruptedException"); > > } > > } > > > > > > > > > > On Wed, May 14, 2014 at 10:03 AM, Mike Duigou wrote: > > Hi Pavel; > > > > The change and test looks good. Will the test be upstreamed or will Doug be adding a similar test in his upstream? > > > > Mike > > > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > > > > > Hi everyone, > > > > > > could you please review my change for JDK-7153400? > > > > > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > > > http://ccc.us.oracle.com/7153400 > > > > > > It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > > > > > Thanks > > > -Pavel > > > > > > From roger.riggs at oracle.com Thu May 15 13:35:08 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 15 May 2014 09:35:08 -0400 Subject: Process API Updates (JEP 102) In-Reply-To: References: <52FD3897.7070903@oracle.com> <52FE7931.4020408@oracle.com> <53309F6A.1050002@oracle.com> Message-ID: <5374C28C.7010903@oracle.com> To gather developer input as Martin suggests, retweet from rriggs9000 or forward as appropriate. Seeking to improve Java 9, let us know how you use processes. https://www.surveymonkey.com/s/GHJL666 Thanks, Roger On 3/25/2014 4:54 AM, Martijn Verburg wrote: > Hi Roger, > > Is there a short survey we could send out to the wider dev community > on this one? I think just about every day to day Java developer has > had to use Process at some stage in their career. > > Cheers, > Martijn > From martinrb at google.com Thu May 15 14:35:51 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 May 2014 07:35:51 -0700 Subject: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize In-Reply-To: <382D099A-2354-41D3-84DD-F5BF8B7C5305@oracle.com> References: <4C09ACEA-BB35-4853-89A9-889EA9FC1E6E@oracle.com> <0F2E6D97-3FD6-4627-B626-033FCF61AD54@oracle.com> <382D099A-2354-41D3-84DD-F5BF8B7C5305@oracle.com> Message-ID: Yes, please do that! On Thu, May 15, 2014 at 5:53 AM, Pavel Rappo wrote: > Martin, if I exclude the test can we push the change then? > > -Pavel > > On 14 May 2014, at 22:10, Martin Buchholz wrote: > > > We added the necessary support for jdk9+ tests and added the test below, > which I think suffices. I don't think a separate jtreg test is necessary. > (Just need to make sure openjdk testers also run Doug's jsr166 CVS tests!) > > > > /* > > * Written by Martin Buchholz and Doug Lea with assistance from > > * members of JCP JSR-166 Expert Group and released to the public > > * domain, as explained at > > * http://creativecommons.org/publicdomain/zero/1.0/ > > */ > > > > import junit.framework.*; > > import java.util.concurrent.*; > > import static java.util.concurrent.TimeUnit.MILLISECONDS; > > import static java.util.concurrent.TimeUnit.NANOSECONDS; > > import java.util.*; > > > > public class ThreadPoolExecutor9Test extends JSR166TestCase { > > public static void main(String[] args) { > > junit.textui.TestRunner.run(suite()); > > } > > public static Test suite() { > > return new TestSuite(ThreadPoolExecutor9Test.class); > > } > > > > /** > > * Configuration changes that allow core pool size greater than > > * max pool size result in IllegalArgumentException. > > */ > > public void testPoolSizeInvariants() { > > ThreadPoolExecutor p = > > new ThreadPoolExecutor(1, 1, > > LONG_DELAY_MS, MILLISECONDS, > > new ArrayBlockingQueue(10)); > > for (int s = 1; s < 5; s++) { > > p.setMaximumPoolSize(s); > > p.setCorePoolSize(s); > > try { > > p.setMaximumPoolSize(s - 1); > > shouldThrow(); > > } catch (IllegalArgumentException success) {} > > assertEquals(s, p.getCorePoolSize()); > > assertEquals(s, p.getMaximumPoolSize()); > > try { > > p.setCorePoolSize(s + 1); > > shouldThrow(); > > } catch (IllegalArgumentException success) {} > > assertEquals(s, p.getCorePoolSize()); > > assertEquals(s, p.getMaximumPoolSize()); > > } > > joinPool(p); > > } > > > > } > > > > > > > > On Wed, May 14, 2014 at 2:02 PM, Pavel Rappo > wrote: > > Hi Martin, > > > > Thanks for you comments. I forgot indeed that awaitTermination indicates > its result by returning a boolean value rather than throwing > TimeoutException. So this should be fine now: > > > > @@ -77,7 +77,10 @@ > > private static void dispose(ThreadPoolExecutor p) { > > p.shutdownNow(); > > try { > > - p.awaitTermination(1, TimeUnit.MINUTES); > > + boolean shutdown = p.awaitTermination(1, TimeUnit.MINUTES); > > + if (!shutdown) > > + throw new RuntimeException( > > + "Pool did not terminate in a timely manner"); > > } catch (InterruptedException e) { > > throw new RuntimeException("Should not happen", e); > > } > > > > As for the "fail" method, it's a little bit different from > "assertThrows". I tried to keep my checks (test payload) to be one liners. > So the whole lifecycle of a ThreadPoolExecutor is confined in a single > line. In addition to check whether the IllegalArgumentException is thrown, > "fail" also disposes the pool. It's not clean object oriented design, I > agree, but it was done for the sake of clarity. This test is supposed to be > simple. > > > > -Pavel > > > > On 14 May 2014, at 18:21, Martin Buchholz wrote: > > > > > Pavel, > > > > > > Thanks for writing a test. > > > > > > We (jsr166 maintainers will add the jtreg test to jsr166 CVS when it > has passed review. > > > > > > Instead of "succeed", I would just write main-line code. If you want > per-api-call granularity, write a testng test. > > > > > > Instead of "fail", I suggest as in jsr166 CVS > src/test/tck/JSR166TestCase.java : > > > > > > public void assertThrows(Class > expectedExceptionClass, > > > Runnable... throwingActions) { > > > for (Runnable throwingAction : throwingActions) { > > > boolean threw = false; > > > try { throwingAction.run(); } > > > catch (Throwable t) { > > > threw = true; > > > if (!expectedExceptionClass.isInstance(t)) { > > > AssertionFailedError afe = > > > new AssertionFailedError > > > ("Expected " + > expectedExceptionClass.getName() + > > > ", got " + t.getClass().getName()); > > > afe.initCause(t); > > > threadUnexpectedException(afe); > > > } > > > } > > > if (!threw) > > > shouldThrow(expectedExceptionClass.getName()); > > > } > > > } > > > > > > I suggest checking the return from p.awaitTermination > > > p.awaitTermination(1, TimeUnit.MINUTES); > > > > > > as in src/test/tck/JSR166TestCase.java: > > > > > > > > > /** > > > * Waits out termination of a thread pool or fails doing so. > > > */ > > > void joinPool(ExecutorService exec) { > > > try { > > > exec.shutdown(); > > > assertTrue("ExecutorService did not terminate in a timely > manner", > > > exec.awaitTermination(2 * LONG_DELAY_MS, > MILLISECONDS)); > > > } catch (SecurityException ok) { > > > // Allowed in case test doesn't have privs > > > } catch (InterruptedException ie) { > > > fail("Unexpected InterruptedException"); > > > } > > > } > > > > > > > > > > > > > > > On Wed, May 14, 2014 at 10:03 AM, Mike Duigou > wrote: > > > Hi Pavel; > > > > > > The change and test looks good. Will the test be upstreamed or will > Doug be adding a similar test in his upstream? > > > > > > Mike > > > > > > On May 14 2014, at 08:29 , Pavel Rappo wrote: > > > > > > > Hi everyone, > > > > > > > > could you please review my change for JDK-7153400? > > > > > > > > http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ > > > > http://ccc.us.oracle.com/7153400 > > > > > > > > It's a long expected fix for a minor issue in the > ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same > change (except for the test) is already in jsr166 repo: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadPoolExecutor.java?r1=1.151&r2=1.152 > > > > > > > > Thanks > > > > -Pavel > > > > > > > > > > > > From christian.thalinger at oracle.com Thu May 15 17:48:51 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 May 2014 10:48:51 -0700 Subject: RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused Message-ID: https://bugs.openjdk.java.net/browse/JDK-8032606 http://cr.openjdk.java.net/~twisti/8032606/webrev.00 8032606: ClassValue.ClassValueMap.type is unused Reviewed-by: From john.r.rose at oracle.com Thu May 15 21:42:37 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 May 2014 14:42:37 -0700 Subject: RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused In-Reply-To: References: Message-ID: <3BB083E4-56C2-4F2F-A972-9612CDAB6FA5@oracle.com> Reviewed. ? John On May 15, 2014, at 10:48 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8032606 > http://cr.openjdk.java.net/~twisti/8032606/webrev.00 > > 8032606: ClassValue.ClassValueMap.type is unused > Reviewed-by: > From vladimir.x.ivanov at oracle.com Thu May 15 21:46:13 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 16 May 2014 01:46:13 +0400 Subject: RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused In-Reply-To: References: Message-ID: <537535A5.3020107@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/15/14 9:48 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8032606 > http://cr.openjdk.java.net/~twisti/8032606/webrev.00 > > 8032606: ClassValue.ClassValueMap.type is unused > Reviewed-by: > From christian.thalinger at oracle.com Thu May 15 22:11:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 May 2014 15:11:25 -0700 Subject: RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused In-Reply-To: <537535A5.3020107@oracle.com> References: <537535A5.3020107@oracle.com> Message-ID: <3C539961-8364-496B-8012-272C7B442A7B@oracle.com> Thanks, John and Vladimir. On May 15, 2014, at 2:46 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 5/15/14 9:48 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8032606 >> http://cr.openjdk.java.net/~twisti/8032606/webrev.00 >> >> 8032606: ClassValue.ClassValueMap.type is unused >> Reviewed-by: >> From lance.andersen at oracle.com Thu May 15 22:20:41 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 15 May 2014 18:20:41 -0400 Subject: RFR: 8043278: Add initial unit tests for javax.sql.rowset.serial Message-ID: <7DF26CDC-B4A8-4A5E-9D86-0E496EC07724@oracle.com> Hi all, Looking for a reviewer for initial pass at adding some tests for javax.sql.rowset.serial The webrev can be found at http://cr.openjdk.java.net/~lancea/8043278/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joel.franck at oracle.com Fri May 16 08:53:09 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 16 May 2014 10:53:09 +0200 Subject: RFR (S) 9 and 8u: JDK-8038994: AnnotatedType.getType() of a TypeVariable boundary without annotations return null In-Reply-To: <21A4AA8F-DE6F-45DA-A30E-C737C7496296@oracle.com> References: <20140514180121.GA31973@oracle.com> <21A4AA8F-DE6F-45DA-A30E-C737C7496296@oracle.com> Message-ID: <20140516085309.GC3472@oracle.com> On 2014-05-15, Paul Sandoz wrote: > > The non test code looks good to me: > > Not totally sure about the test approach: > > 48 @Test(dataProvider = "data") > 49 public void testClass(Class c, String method) throws Exception { > 50 if (c.getTypeParameters().length == 0) > 51 return; > > 60 @Test(dataProvider = "data") > 61 public void testMethod(Classc, String method) throws Exception { > 62 if ("".equals(method)) > 63 return; > > That's gonna produce redundant results in test reports for stuff that is filtered out by the test method. > > Perhaps split the data provider into two, one for classes and one for methods, and replace the if statements with asserts? > You are right, thanks for the suggestion. New webrev: http://cr.openjdk.java.net/~jfranck/8038994/webrev.01/ cheers /Joel From paul.sandoz at oracle.com Fri May 16 09:11:51 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 16 May 2014 11:11:51 +0200 Subject: RFR (S) 9 and 8u: JDK-8038994: AnnotatedType.getType() of a TypeVariable boundary without annotations return null In-Reply-To: <20140516085309.GC3472@oracle.com> References: <20140514180121.GA31973@oracle.com> <21A4AA8F-DE6F-45DA-A30E-C737C7496296@oracle.com> <20140516085309.GC3472@oracle.com> Message-ID: <4C32F856-D518-46CA-A5DF-53C191332F2E@oracle.com> On May 16, 2014, at 10:53 AM, Joel Borggren-Franck wrote: > On 2014-05-15, Paul Sandoz wrote: >> >> The non test code looks good to me: >> >> Not totally sure about the test approach: >> >> 48 @Test(dataProvider = "data") >> 49 public void testClass(Class c, String method) throws Exception { >> 50 if (c.getTypeParameters().length == 0) >> 51 return; >> >> 60 @Test(dataProvider = "data") >> 61 public void testMethod(Classc, String method) throws Exception { >> 62 if ("".equals(method)) >> 63 return; >> >> That's gonna produce redundant results in test reports for stuff that is filtered out by the test method. >> >> Perhaps split the data provider into two, one for classes and one for methods, and replace the if statements with asserts? >> > > You are right, thanks for the suggestion. New webrev: > > http://cr.openjdk.java.net/~jfranck/8038994/webrev.01/ > +1 Paul. From paul.sandoz at oracle.com Fri May 16 12:13:10 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 16 May 2014 14:13:10 +0200 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <537331E5.4070108@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> Message-ID: <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> On May 14, 2014, at 11:05 AM, Alan Bateman wrote: > >> : >> >> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere? >> >> Out of all the classes here: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ >> >> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set? >> >> How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo? >> >> Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate. >> > I think Sergey and Phil are asking for the bean classes from -core patch and all of -media to be pushed to jdk9/client. > Thanks. Sergey/Phil can you confirm? Is there a white-list of packages available to determine which classes should be pushed to the client jdk repo rather than the dev jdk repo? Paul. From joel.franck at oracle.com Fri May 16 14:32:47 2014 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 16 May 2014 16:32:47 +0200 Subject: RFR (S) 9 and 8u: JDK-8038994: AnnotatedType.getType() of a TypeVariable boundary without annotations return null In-Reply-To: <4C32F856-D518-46CA-A5DF-53C191332F2E@oracle.com> References: <20140514180121.GA31973@oracle.com> <21A4AA8F-DE6F-45DA-A30E-C737C7496296@oracle.com> <20140516085309.GC3472@oracle.com> <4C32F856-D518-46CA-A5DF-53C191332F2E@oracle.com> Message-ID: <20140516143247.GA3450@oracle.com> Thanks for the review Paul. Fix pushed cheers /Joel On 2014-05-16, Paul Sandoz wrote: > > On May 16, 2014, at 10:53 AM, Joel Borggren-Franck wrote: > > > On 2014-05-15, Paul Sandoz wrote: > >> > >> The non test code looks good to me: > >> > >> Not totally sure about the test approach: > >> > >> 48 @Test(dataProvider = "data") > >> 49 public void testClass(Class c, String method) throws Exception { > >> 50 if (c.getTypeParameters().length == 0) > >> 51 return; > >> > >> 60 @Test(dataProvider = "data") > >> 61 public void testMethod(Classc, String method) throws Exception { > >> 62 if ("".equals(method)) > >> 63 return; > >> > >> That's gonna produce redundant results in test reports for stuff that is filtered out by the test method. > >> > >> Perhaps split the data provider into two, one for classes and one for methods, and replace the if statements with asserts? > >> > > > > You are right, thanks for the suggestion. New webrev: > > > > http://cr.openjdk.java.net/~jfranck/8038994/webrev.01/ > > > > +1 > > Paul. > From forax at univ-mlv.fr Fri May 16 15:05:39 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 16 May 2014 17:05:39 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <5375FD00.90603@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> Message-ID: <53762943.1030301@univ-mlv.fr> On 05/16/2014 01:56 PM, Tobias Hartmann wrote: > Hi, > > thanks to everyone for the feedback. > > Is it sufficient then to use synchronized (lambdaForms) { ... } in > setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? > > Thanks, > Tobias no, it's not, The memory model doesn't guarantee that a normal read will see that another thread has changed the array item, the normal read may always see null. You need a synchronized block around the normal read. R?mi > >>>> >>>>>>>> I may be wrong but for me cachedLambdaForm() is used in a fast >>>>>>>> path. >>>>>>>> If it's not the case, I agree that a lock is enough. >>>>>>> I hold the opinion that we only need to synchronize writers and not >>>>>>> readers (MTF.setCachedLambdaForm() and not MTF.cachedLambdaForm()). >>>>>>> >>>>>>> Current usage pattern is the following: >>>>>>> MethodType type = ...; >>>>>>> LambdaForm lform = type.form().cachedLambdaForm(idx); >>>>>>> if (lform == NULL) { >>>>>>> // construct new LambaForm >>>>>>> lform = type.form().setCachedLambdaForm(idx, lform); >>>>>>> } >>>>>>> return lform; >>>>>>> >>>>>>> Cache is written only once, so it has only 2 states (null and >>>>>>> non-null >>>>>>> value) during it's lifecycle. >>>>>>> >>>>>>> The only stale value cachedLambdaForm() can see is null, but >>>>>>> then the >>>>>>> caller tries to initialize the cache and after acquiring the >>>>>>> lock in >>>>>>> setCachedLambdaForm() sees actual value. >>>>>>> >>>>>>> So, the worst thing can happen if readers aren't synchronized is >>>>>>> creation of unnecessary LF (which go dead right away) in rare >>>>>>> cases. >>>>>> Unless the cache is volatile this would be unsafe publication and >>>>>> the >>>>>> reader may see a non-null reference to the LF but the LF may not be >>>>>> properly initialized. >>>>> Good point. The cache is an array element. How does safe publication >>>>> of array element look like? Is accessing the element through volatile >>>>> reference to the array enough or additional synchronization actions >>>>> are needed? >>>>> >>>> I thought that since the only fields explicitly set when constructing >>>> a LambdaForm are final fields it should be safe to publish the form >>>> reference as an element in the array? >>>> >>>> Paul. >>>> >>> >>> that's my analysis too. >> >> Sorry didn't realize a LF only had final fields. >> >> David >> >>> R?mi >>> > From paul.sandoz at oracle.com Fri May 16 15:22:04 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 16 May 2014 17:22:04 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <53762943.1030301@univ-mlv.fr> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <53762943.1030301@univ-mlv.fr> Message-ID: On May 16, 2014, at 5:05 PM, Remi Forax wrote: > > On 05/16/2014 01:56 PM, Tobias Hartmann wrote: >> Hi, >> >> thanks to everyone for the feedback. >> >> Is it sufficient then to use synchronized (lambdaForms) { ... } in setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >> >> Thanks, >> Tobias > > no, it's not, > The memory model doesn't guarantee that a normal read will see that another thread has changed the array item, > the normal read may always see null. > > You need a synchronized block around the normal read. > I don't think that is required since the pattern is: form = cachedLambdaForm(which); if (form != null) return form ... form = /new form/ ... form = setCachedLambdaForm(which, form); return form; and the setCachedLambdaForm will, within it's the synchronized block, first perform a read to check if there is already a non-default value present. Paul. From forax at univ-mlv.fr Fri May 16 15:48:56 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 16 May 2014 17:48:56 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <53762943.1030301@univ-mlv.fr> Message-ID: <53763368.9090100@univ-mlv.fr> On 05/16/2014 05:22 PM, Paul Sandoz wrote: > On May 16, 2014, at 5:05 PM, Remi Forax wrote: > >> On 05/16/2014 01:56 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> thanks to everyone for the feedback. >>> >>> Is it sufficient then to use synchronized (lambdaForms) { ... } in setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >>> >>> Thanks, >>> Tobias >> no, it's not, >> The memory model doesn't guarantee that a normal read will see that another thread has changed the array item, >> the normal read may always see null. >> >> You need a synchronized block around the normal read. >> > I don't think that is required since the pattern is: > > form = cachedLambdaForm(which); > if (form != null) return form > ... > form = /new form/ > ... > form = setCachedLambdaForm(which, form); > return form; > > and the setCachedLambdaForm will, within it's the synchronized block, first perform a read to check if there is already a non-default value present. > > Paul. Ok, got it, it should work :) cheers, R?mi From rob.mckenna at oracle.com Fri May 16 16:00:04 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 16 May 2014 17:00:04 +0100 Subject: RFR - 8042857: 14 stuck threads waiting for notification on LDAPRequest Message-ID: <53763604.3030709@oracle.com> Hi folks, A simple fix to eliminate a possible infinite loop when an Ldap Connection cannot contact the server. http://cr.openjdk.java.net/~robm/8042857/webrev.01/ -Rob From lance.andersen at oracle.com Fri May 16 16:10:33 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 16 May 2014 12:10:33 -0400 Subject: RFR: 8043278: Add initial unit tests for javax.sql.rowset.serial In-Reply-To: <7DF26CDC-B4A8-4A5E-9D86-0E496EC07724@oracle.com> References: <7DF26CDC-B4A8-4A5E-9D86-0E496EC07724@oracle.com> Message-ID: I changed the test directory structure slightly so the revised webrev is at http://cr.openjdk.java.net/~lancea/8043278/webrev.01/ Best Lance On May 15, 2014, at 6:20 PM, Lance Andersen wrote: > Hi all, > > Looking for a reviewer for initial pass at adding some tests for javax.sql.rowset.serial > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8043278/webrev.00/ > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From roger.riggs at oracle.com Fri May 16 17:10:28 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 16 May 2014 13:10:28 -0400 Subject: RFR: 8043278: Add initial unit tests for javax.sql.rowset.serial In-Reply-To: References: <7DF26CDC-B4A8-4A5E-9D86-0E496EC07724@oracle.com> Message-ID: <53764684.1030609@oracle.com> Hi Lance, Looks fine. typo: SerialArrayTests.java: 62 * Validate a SQLException is thrown*if* the map is null Roger On 5/16/2014 12:10 PM, Lance Andersen wrote: > I changed the test directory structure slightly so the revised webrev is at > > http://cr.openjdk.java.net/~lancea/8043278/webrev.01/ > > Best > Lance > On May 15, 2014, at 6:20 PM, Lance Andersen wrote: > >> Hi all, >> >> Looking for a reviewer for initial pass at adding some tests for javax.sql.rowset.serial >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8043278/webrev.00/ >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Fri May 16 18:49:30 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 16 May 2014 14:49:30 -0400 Subject: RFR: 8043278: Add initial unit tests for javax.sql.rowset.serial In-Reply-To: <53764684.1030609@oracle.com> References: <7DF26CDC-B4A8-4A5E-9D86-0E496EC07724@oracle.com> <53764684.1030609@oracle.com> Message-ID: <98458557-3EA7-43FC-9845-3F8B350A22DC@oracle.com> Hi Roger, Thank you. I corrected the typo before the push. Best Lance On May 16, 2014, at 1:10 PM, roger riggs wrote: > Hi Lance, > > Looks fine. > > typo: > > SerialArrayTests.java: 62 * Validate a SQLException is thrown*if* the map is null > > Roger > > On 5/16/2014 12:10 PM, Lance Andersen wrote: >> I changed the test directory structure slightly so the revised webrev is at >> >> http://cr.openjdk.java.net/~lancea/8043278/webrev.01/ >> >> Best >> Lance >> On May 15, 2014, at 6:20 PM, Lance Andersen wrote: >> >>> Hi all, >>> >>> Looking for a reviewer for initial pass at adding some tests for javax.sql.rowset.serial >>> >>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8043278/webrev.00/ >>> >>> Best >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From philip.race at oracle.com Fri May 16 19:33:41 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 16 May 2014 12:33:41 -0700 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> Message-ID: <53766815.40600@oracle.com> On 5/16/2014 5:13 AM, Paul Sandoz wrote: > On May 14, 2014, at 11:05 AM, Alan Bateman wrote: >>> : >>> >>> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere? >>> >>> Out of all the classes here: >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ >>> >>> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set? All of the classes in that webrev are client (awt/swing/2d) so should go to client. BTW I am behind on email but w.r.t the variable changes, then if you at least make it consistent that will be fine by me. > -phil. Is there a white-list of packages available to determine which classes should be pushed to the client jdk repo rather than the dev jdk repo? Any public API with a package prefix that begins with java.applet, java.awt, java.beans, javax.imageio, javax.print, javax.sound, javax.swing and all implementation classes thereof .. -phil. From masayoshi.okutsu at oracle.com Sun May 18 23:10:16 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 19 May 2014 08:10:16 +0900 Subject: 8037343 Ready for review In-Reply-To: <53746EBF.5090900@oracle.com> References: <53746EBF.5090900@oracle.com> Message-ID: <53793DD8.4070202@oracle.com> Looks good to me. Thanks, Masayoshi On 5/15/2014 4:37 PM, Alan Bateman wrote: > > Forwarding to i18n-dev as that it usually the list where changes to > the locale and resources are maintained. > > -Alan > > On 15/05/2014 04:45, Sandipan Razzaque wrote: >> Hi all, >> >> Please find below the webrev for bug 8037343. >> >> http://www.sandipan.net/public/webrevs/8037343/webrev.00 >> >> Thanks in advance - >> >> Cheers, >> SR >> >> Sandipan Razzaque | www.sandipan.net > From paul.sandoz at oracle.com Mon May 19 06:53:52 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 May 2014 07:53:52 +0100 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <53766815.40600@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> <53766815.40600@oracle.com> Message-ID: <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com> On May 16, 2014, at 8:33 PM, Phil Race wrote: > On 5/16/2014 5:13 AM, Paul Sandoz wrote: >> On May 14, 2014, at 11:05 AM, Alan Bateman wrote: >>>> : >>>> >>>> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere? >>>> >>>> Out of all the classes here: >>>> >>>> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ >>>> >>>> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set? > All of the classes in that webrev are client (awt/swing/2d) so should go to client. > > > BTW I am behind on email but w.r.t the variable changes, then if you at least make it consistent that > will be fine by me. > I updated to avoid the unnecessary name change you pointed out, but i have left all others after reviewing. > > -phil. Is there a white-list of packages available to determine which classes should be pushed to the client jdk repo rather than the dev jdk repo? > > Any public API with a package prefix that begins with > java.applet, java.awt, java.beans, javax.imageio, javax.print, javax.sound, javax.swing > and all implementation classes thereof .. > Thanks. If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue. How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo? -- It's quite clear to me this process does not scale. The amount of work that has to be done to treat the above mentioned packages separately is rapidly accelerating away from the work required to make such changes to the point at which it is extremely tempting to not bother to make such changes, which is bad because code starts ossifying. What happens if i just commit to dev/jdk instead? :-) Paul. From Alan.Bateman at oracle.com Mon May 19 07:50:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 May 2014 08:50:52 +0100 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> <53766815.40600@oracle.com> <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com> Message-ID: <5379B7DC.2020206@oracle.com> On 19/05/2014 07:53, Paul Sandoz wrote: > If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue. If you do decide to split this then it will require creating a second issue JIRA to avoid running foul of jcheck when jdk/client eventually pushes to jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests there is currently about a month of changes backed up in jdk9/client but there may be issues to explain this). For this specific case then it doesn't seem worth it, it would be much less effort to just push the lot to jdk9/dev. Clearly if there were substantive changes then it would be important to push the changes to the forest where they are most likely to get tested but it hardly seems worth it here. From what I can tell then Phil or others sync up jdk9/client regularly and that might be the most efficient way to get these changes into jdk9/client. -Alan From miroslav.kos at oracle.com Mon May 19 13:33:26 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 19 May 2014 15:33:26 +0200 Subject: RFR: 8039210: Fix type error in DefaultResourceInjector Message-ID: <537A0826.1040402@oracle.com> Hi, this is review request for: 8039210: Fix type error in DefaultResourceInjector JBS: https://bugs.openjdk.java.net/browse/JDK-8039210 WEBREV: http://cr.openjdk.java.net/~mkos/8039210/jaxws.00/ It is simple one-line fix; it's blocker for another issue. Thanks Miran From miroslav.kos at oracle.com Mon May 19 13:36:16 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 19 May 2014 15:36:16 +0200 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail Message-ID: <537A08D0.9030404@oracle.com> Hi, this is review request for: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 WEBREV: http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) This solves conflict between JAF handlers for JAX-WS and javax.mail. The issue has been introduced in the latest CPU. Thanks Miran From chris.hegarty at oracle.com Mon May 19 17:09:25 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 May 2014 18:09:25 +0100 Subject: RFR: 8039210: Fix type error in DefaultResourceInjector In-Reply-To: <537A0826.1040402@oracle.com> References: <537A0826.1040402@oracle.com> Message-ID: <537A3AC5.5020706@oracle.com> This looks ok to me Miran. -Chris. On 19/05/14 14:33, Miroslav Kos wrote: > Hi, > this is review request for: > > 8039210: Fix type error in DefaultResourceInjector > > JBS: https://bugs.openjdk.java.net/browse/JDK-8039210 > WEBREV: http://cr.openjdk.java.net/~mkos/8039210/jaxws.00/ > > It is simple one-line fix; it's blocker for another issue. > > Thanks > Miran From philip.race at oracle.com Mon May 19 17:18:45 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 19 May 2014 10:18:45 -0700 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5379B7DC.2020206@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> <53766815.40600@oracle.com> <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com> <5379B7DC.2020206@oracle.com> Message-ID: <537A3CF5.5010401@oracle.com> On 5/19/2014 12:50 AM, Alan Bateman wrote: > On 19/05/2014 07:53, Paul Sandoz wrote: >> If i don't have permission to push to the client repo (which might be >> likely) i will need to hand over the patch to yourself or Sergey to >> commit. And i presume this will have to be a separate issue. > If you do decide to split this then it will require creating a second > issue JIRA to avoid running foul of jcheck when jdk/client eventually > pushes to jdk/dev. I don't know how often jdk9/client integrates into > jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests > there is currently about a month of changes backed up in jdk9/client > but there may be issues to explain this). > > For this specific case then it doesn't seem worth it, it would be much > less effort to just push the lot to jdk9/dev. Clearly if there were > substantive changes then it would be important to push the changes to > the forest where they are most likely to get tested but it hardly > seems worth it here. From what I can tell then Phil or others sync up > jdk9/client regularly and that might be the most efficient way to get > these changes into jdk9/client. > The changes should go through client for the reasons I already gave. No new permissions are needed but it will need a unique bug id. FWIW integrations are intended to be bi-weekly but holidays interfered this time. -phil. > -Alan From chris.hegarty at oracle.com Mon May 19 17:27:16 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 May 2014 18:27:16 +0100 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <537A08D0.9030404@oracle.com> References: <537A08D0.9030404@oracle.com> Message-ID: <537A3EF4.1040800@oracle.com> Miran, The source change looks ok to me. Have you commented out the line adding the handler because it may be reinstated, or as a reminder that it was deliberately omitted? The test, at the very minimum, will need a suitable copyright header. I also wonder if there is any other way of testing this issue without adding, what appears to be, a large jar file. -Chris. On 19/05/14 14:36, Miroslav Kos wrote: > Hi, > this is review request for: > > 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail > > JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 > WEBREV: > http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ > http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) > > This solves conflict between JAF handlers for JAX-WS and javax.mail. The > issue has been introduced in the latest CPU. > > Thanks > Miran From xueming.shen at oracle.com Mon May 19 18:12:16 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 19 May 2014 11:12:16 -0700 Subject: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb In-Reply-To: <53672CB4.3050708@oracle.com> References: <53672CB4.3050708@oracle.com> Message-ID: <537A4980.5050603@oracle.com> Hi, I've not got any feedback so far, so I assume it's good:-) Anyway, I'm going a little further to throw in a TarInputStream so now we just build the tzdb data directly on the tzdata201xy.tar.gz from iana site. I'm not sure if it is OK to check in the original .tar.gz file into the jdk repository though. There are also more improvements in this version, it is much faster now. It might not matter as it is only used during build time, though:-) http://cr.openjdk.java.net/~sherman/8042369/webrev -Sherman Btw, I'm still trying to sell the idea of checking in a second tzdb provider implementation into the jdk, which directly loads in the tzdb data by using the iana original source data, with the assumption that this might be useful at least in certain circumstance (such as one gov pushes a tz change, and some of your big jdk customers need their apps run with the new data in next 24 hrs...) in the future. http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev On 05/04/2014 11:16 PM, Xueming Shen wrote: > Hi > > Please help review the change for #8042369 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 > Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev > > In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data > for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these > classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so > most of these duplicated classes are no longer needed, with ZoneRules as the only exception. > The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the > serialization forms of those transitions and rules. The proposed change here is to remove > those unneeded duplicated classes. > > I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler > and and straightforward implementation, with the goal of migrating it into a second default > ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the > IANA directly. One of the benefits of such a provider is that the end user may just drop the latest > timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from > Oracle. > > Here is the webrev for the idea > http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ > > The only disadvantage appears to be the possible "slowdown" of startup time because of > the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for > j.u.TimeZone, if we go with this direction) > > Thanks! > -Sherman > > From john.r.rose at oracle.com Mon May 19 18:31:55 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 May 2014 11:31:55 -0700 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <5375FD00.90603@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> Message-ID: <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> On May 16, 2014, at 4:56 AM, Tobias Hartmann wrote: > Is it sufficient then to use synchronized (lambdaForms) { ... } in setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? Yes, that is how I see it. The fast path is a racy non-volatile read of a safely-published structure. (If safe publication via arrays were broken, java.lang.String would be broken. But the JMM is carefully designed to support safe publication of array elements, and through array elements.) ? John From bill.shannon at oracle.com Mon May 19 23:55:01 2014 From: bill.shannon at oracle.com (Bill Shannon) Date: Mon, 19 May 2014 16:55:01 -0700 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <537A3EF4.1040800@oracle.com> References: <537A08D0.9030404@oracle.com> <537A3EF4.1040800@oracle.com> Message-ID: <537A99D5.1050101@oracle.com> Chris Hegarty wrote on 05/19/14 10:27: > Miran, > > The source change looks ok to me. Have you commented out the line adding the > handler because it may be reinstated, or as a reminder that it was deliberately > omitted? Either way, the code could probably use a comment to explain why it's correct and necessary to comment out that line. From paul.sandoz at oracle.com Tue May 20 06:45:05 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 May 2014 07:45:05 +0100 Subject: [OpenJDK 2D-Dev] JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <537A3CF5.5010401@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5371FDBD.9020002@oracle.com> <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com> <53728B83.1060307@oracle.com> <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com> <537331E5.4070108@oracle.com> <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com> <53766815.40600@oracle.com> <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com> <5379B7DC.2020206@oracle.com> <537A3CF5.5010401@oracle.com> Message-ID: <68F1F3CD-502A-4CBC-ABD6-7B1A24F9D3D8@oracle.com> On May 19, 2014, at 6:18 PM, Phil Race wrote: > On 5/19/2014 12:50 AM, Alan Bateman wrote: >> On 19/05/2014 07:53, Paul Sandoz wrote: >>> If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue. >> If you do decide to split this then it will require creating a second issue JIRA to avoid running foul of jcheck when jdk/client eventually pushes to jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests there is currently about a month of changes backed up in jdk9/client but there may be issues to explain this). >> >> For this specific case then it doesn't seem worth it, it would be much less effort to just push the lot to jdk9/dev. Clearly if there were substantive changes then it would be important to push the changes to the forest where they are most likely to get tested but it hardly seems worth it here. From what I can tell then Phil or others sync up jdk9/client regularly and that might be the most efficient way to get these changes into jdk9/client. >> > The changes should go through client for the reasons I already gave. IIUC these were the reasons you gave in a previous email on this thread: "I would not push hotspot changes to client either. Also lots of files are being updated in client and doing it this way will minimise merges ..." I don't find either very convincing. > No new permissions are needed but it will need a unique bug id. > Ok. > FWIW integrations are intended to be bi-weekly but holidays interfered this time. > Why does it take so long? Paul. From miroslav.kos at oracle.com Tue May 20 10:07:16 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Tue, 20 May 2014 12:07:16 +0200 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <537A3EF4.1040800@oracle.com> References: <537A08D0.9030404@oracle.com> <537A3EF4.1040800@oracle.com> Message-ID: <537B2954.5070808@oracle.com> Hi Chris, thanks for pointing - I forgot to add copyright. Will fix. Regarding jar attachment - this is a slightly modified version of test as received from customer. If there is any mechanism allowing to use maven artifact (I am not aware of it) with jprt, it would be definitelly better solution, but I didn't find it. I could rewrite the test that it would test just not adding this handler, but it wouldn't explain much what the issue was about - I could write it to javadoc? Let me know, what you think. Thanks Miran On 19/05/14 19:27, Chris Hegarty wrote: > Miran, > > The source change looks ok to me. Have you commented out the line > adding the handler because it may be reinstated, or as a reminder that > it was deliberately omitted? > > The test, at the very minimum, will need a suitable copyright header. > I also wonder if there is any other way of testing this issue without > adding, what appears to be, a large jar file. > > -Chris. > > On 19/05/14 14:36, Miroslav Kos wrote: >> Hi, >> this is review request for: >> >> 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 >> WEBREV: >> http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ >> http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) >> >> This solves conflict between JAF handlers for JAX-WS and javax.mail. The >> issue has been introduced in the latest CPU. >> >> Thanks >> Miran From yekaterina.kantserova at oracle.com Tue May 20 12:24:33 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 20 May 2014 14:24:33 +0200 Subject: RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError Message-ID: <537B4981.9010806@oracle.com> Staffan, Alan, could you please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ I've missed somehow several tests in http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. Thanks, Katja From staffan.larsen at oracle.com Tue May 20 13:07:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 20 May 2014 15:07:14 +0200 Subject: RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <537B4981.9010806@oracle.com> References: <537B4981.9010806@oracle.com> Message-ID: <1BA665D6-A1B8-482B-99D2-893DB3DCABEF@oracle.com> test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java ?Dummy? is being built twice. Otherwise good! /Staffan On 20 maj 2014, at 14:24, Yekaterina Kantserova wrote: > Staffan, Alan, > > could you please review the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 > Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ > > I've missed somehow several tests in http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. > > Thanks, > Katja > From chris.hegarty at oracle.com Tue May 20 13:15:17 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 20 May 2014 14:15:17 +0100 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <537B2954.5070808@oracle.com> References: <537A08D0.9030404@oracle.com> <537A3EF4.1040800@oracle.com> <537B2954.5070808@oracle.com> Message-ID: <537B5565.8020201@oracle.com> On 05/20/2014 11:07 AM, Miroslav Kos wrote: > Hi Chris, > thanks for pointing - I forgot to add copyright. Will fix. Thanks. > Regarding jar attachment - this is a slightly modified version of test > as received from customer. If there is any mechanism allowing to use > maven artifact (I am not aware of it) with jprt, it would be definitelly > better solution, but I didn't find it. > > I could rewrite the test that it would test just not adding this > handler, but it wouldn't explain much what the issue was about - I could > write it to javadoc? > > Let me know, what you think. I see we have many other jar files under jdk/test, so maybe this is ok. -Chris. > > Thanks > Miran > > On 19/05/14 19:27, Chris Hegarty wrote: >> Miran, >> >> The source change looks ok to me. Have you commented out the line >> adding the handler because it may be reinstated, or as a reminder that >> it was deliberately omitted? >> >> The test, at the very minimum, will need a suitable copyright header. >> I also wonder if there is any other way of testing this issue without >> adding, what appears to be, a large jar file. >> >> -Chris. >> >> On 19/05/14 14:36, Miroslav Kos wrote: >>> Hi, >>> this is review request for: >>> >>> 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 >>> WEBREV: >>> http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ >>> http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) >>> >>> This solves conflict between JAF handlers for JAX-WS and javax.mail. The >>> issue has been introduced in the latest CPU. >>> >>> Thanks >>> Miran > From yekaterina.kantserova at oracle.com Tue May 20 13:48:23 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 20 May 2014 15:48:23 +0200 Subject: RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <1BA665D6-A1B8-482B-99D2-893DB3DCABEF@oracle.com> References: <537B4981.9010806@oracle.com> <1BA665D6-A1B8-482B-99D2-893DB3DCABEF@oracle.com> Message-ID: <537B5D27.7040707@oracle.com> Thanks Staffan! New webrev can be found here: http://cr.openjdk.java.net/~ykantser/8043520/webrev.01/ // Katja On 05/20/2014 03:07 PM, Staffan Larsen wrote: > test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java > ?Dummy? is being built twice. > > Otherwise good! > > /Staffan > > > On 20 maj 2014, at 14:24, Yekaterina Kantserova wrote: > >> Staffan, Alan, >> >> could you please review the following fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 >> Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ >> >> I've missed somehow several tests in http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. >> >> Thanks, >> Katja >> From staffan.larsen at oracle.com Tue May 20 13:55:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 20 May 2014 15:55:31 +0200 Subject: RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <537B5D27.7040707@oracle.com> References: <537B4981.9010806@oracle.com> <1BA665D6-A1B8-482B-99D2-893DB3DCABEF@oracle.com> <537B5D27.7040707@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 20 maj 2014, at 15:48, Yekaterina Kantserova wrote: > Thanks Staffan! > > New webrev can be found here: http://cr.openjdk.java.net/~ykantser/8043520/webrev.01/ > > // Katja > > > > On 05/20/2014 03:07 PM, Staffan Larsen wrote: >> test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java >> ?Dummy? is being built twice. >> >> Otherwise good! >> >> /Staffan >> >> >> On 20 maj 2014, at 14:24, Yekaterina Kantserova wrote: >> >>> Staffan, Alan, >>> >>> could you please review the following fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 >>> Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ >>> >>> I've missed somehow several tests in http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. >>> >>> Thanks, >>> Katja >>> > From roger.riggs at oracle.com Tue May 20 20:52:35 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 20 May 2014 16:52:35 -0400 Subject: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb In-Reply-To: <537A4980.5050603@oracle.com> References: <53672CB4.3050708@oracle.com> <537A4980.5050603@oracle.com> Message-ID: <537BC093.40102@oracle.com> Hi Sherman, Even though it has well defined content, checking in the tar.gz seems not quite right. Can the tests reconstruct the tar file from the contents or directly use the IANA data on demand from the IANA site? From a maintenance point of view, functions added to the JDK should be well used and maintained and be well supported. TzdbZoneRulesCompiler.java: +130 The error for srcFile == null still mentions "-srcdir". :+153; the commented out message should be removed Roger On 5/19/2014 2:12 PM, Xueming Shen wrote: > Hi, > > I've not got any feedback so far, so I assume it's good:-) > > Anyway, I'm going a little further to throw in a TarInputStream so now > we just build the > tzdb data directly on the tzdata201xy.tar.gz from iana site. I'm not > sure if it is OK to > check in the original .tar.gz file into the jdk repository though. > > There are also more improvements in this version, it is much faster > now. It might > not matter as it is only used during build time, though:-) > > http://cr.openjdk.java.net/~sherman/8042369/webrev > > -Sherman > > Btw, I'm still trying to sell the idea of checking in a second tzdb > provider implementation > into the jdk, which directly loads in the tzdb data by using the iana > original source data, > with the assumption that this might be useful at least in certain > circumstance (such as > one gov pushes a tz change, and some of your big jdk customers need > their apps run with > the new data in next 24 hrs...) in the future. > > http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev > > > On 05/04/2014 11:16 PM, Xueming Shen wrote: >> Hi >> >> Please help review the change for #8042369 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 >> Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev >> >> In jdk8 we had to duplicate dozen java.time classes in build.tools to >> build the timezone data >> for the new JSR310 timezone data compiler, which uses the new jdk8 >> java.time classes (these >> classes don't exit in the < 8 boot jdk). JDK9 has switched to use the >> jdk8 as the boot jdk, so >> most of these duplicated classes are no longer needed, with ZoneRules >> as the only exception. >> The ZoneRules is still needed to help the tzdb compiler to output the >> tzdb data in the >> serialization forms of those transitions and rules. The proposed >> change here is to remove >> those unneeded duplicated classes. >> >> I also took the opportunity to re-organize/re-wrote the "builder" >> classes to have a faster, simpler >> and and straightforward implementation, with the goal of migrating it >> into a second default >> ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the >> tzdb source data from the >> IANA directly. One of the benefits of such a provider is that the end >> user may just drop the latest >> timezone data file into the jdk/jre and go, without waiting for the >> latest timezone binary bits from >> Oracle. >> >> Here is the webrev for the idea >> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ >> >> The only disadvantage appears to be the possible "slowdown" of >> startup time because of >> the reading and compiling of the 200k tzdb source data...(we need >> another new "bridge" for >> j.u.TimeZone, if we go with this direction) >> >> Thanks! >> -Sherman >> >> > From xueming.shen at oracle.com Wed May 21 21:19:13 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 21 May 2014 14:19:13 -0700 Subject: RFR: Faster ZipFile.getEntry()/entries() In-Reply-To: <522910DB.6060004@oracle.com> References: <522910DB.6060004@oracle.com> Message-ID: <537D1851.3070408@oracle.com> Hi, This one didn't make into jdk8. Here is an updated webrev for the jdk9 repo http://cr.openjdk.java.net/~sherman/zipfile_j/webrev And a pure java version of j.u.ZipFile is also available at http://cr.openjdk.java.net/~sherman/zipfile_jj/webrev/ We do have incident reports and requests that suggest a pure Java version of j.u.ZipFile might be preferred, especially to eliminate the possibility of jvm crash at native level, mostly triggered by the mmap usage and/or use scenario that the target zip/jar file is being overwritten while reading. And java implementation also brings in the benefits of better memory usage (all memory allocated in java heap), no more expensive jni invocations... Opinion/comments are appreciated. Thanks! -Sherman On 09/05/2013 04:16 PM, Xueming Shen wrote: > Hi, > > The change proposed here is to bring the zip entry handing code from the native > level to the java level. This effectively solves the performance issues of ZipFile.getEntry > and entries() that is caused by multiple jni invocation steps to generate one single > ZipEntry (see ZipFile.getZipEntry()). A simple non-scientific benchmark test of simply > iterating the ZipFile via the Enumeration from entries() on rt.jar/charsets.jar suggests > a 50%+ speed boost. > > http://cr.openjdk.java.net/~sherman/zipfile_j/webrev > > Couple notes: > > (1) Ideally it might be desired to go further to bring all the native code of ZipFile to > java level (which should help completely remove that mmap crash issue, have better > file and memory management... ), but it is suggested that it might be better to limit > the scope of the change at this late release circle. > > (2) JavaFile.read0() is the version that uses "getPrimitiveArrayCritical" to read file bits > into the java array directly (instead of using a stack buffer and then copy into the > java array), which appears to be 5% faster. But I can't make up my mind of which one > would be better. Given (1) the trouble we had before in De/Infalter code (when the > getPrimitiveArrayCritical is being heavily used), (2) FileInputStream uses the same > "copy" approach, I'm staying with the "copy" appraoch, but option appreciated. > > (3) We will have to keep the native implementation (zip_util.c) for the vm directly > access. > > Thanks! > -Sherman > From ecki at zusammenkunft.net Wed May 21 21:31:15 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 21 May 2014 23:31:15 +0200 Subject: RFR: Faster ZipFile.getEntry()/entries() In-Reply-To: <537D1851.3070408@oracle.com> References: <522910DB.6060004@oracle.com> <537D1851.3070408@oracle.com> Message-ID: <20140521233115.00006c42.ecki@zusammenkunft.net> Am Wed, 21 May 2014 14:19:13 -0700 schrieb Xueming Shen : > And java implementation also brings in the benefits of better memory > usage (all memory allocated in java heap), no more expensive jni > invocations... > > Opinion/comments are appreciated. I had ZIP native code related crashes in the past. I suspected they all have been due to memory pressure (malloc returning null). But I expected that to be fixed meanwhile? I mean its not impossible to have robust C code, or? Anyway, having said that - is there a performance comparision? What was the reason for that native part in the first place? Greetings Bernd From xueming.shen at oracle.com Wed May 21 21:55:28 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 21 May 2014 14:55:28 -0700 Subject: RFR: Faster ZipFile.getEntry()/entries() In-Reply-To: <20140521233115.00006c42.ecki@zusammenkunft.net> References: <522910DB.6060004@oracle.com> <537D1851.3070408@oracle.com> <20140521233115.00006c42.ecki@zusammenkunft.net> Message-ID: <537D20D0.30304@oracle.com> On 05/21/2014 02:31 PM, Bernd Eckenfels wrote: > Am Wed, 21 May 2014 14:19:13 -0700 > schrieb Xueming Shen: > >> And java implementation also brings in the benefits of better memory >> usage (all memory allocated in java heap), no more expensive jni >> invocations... >> >> Opinion/comments are appreciated. > I had ZIP native code related crashes in the past. I suspected they all > have been due to memory pressure (malloc returning null). But I Most cases reported is due to the use scenario that a zip/jar file is being updated by someone else when it is still being used + mmap...for performance reason the implementation only does the reasonable sanity check at the beginning of reading in the central directory then it operations on "assumption" that these "data" are correct, so if the content is being changed later, the access may crash the vm, instead of having some exception throwing at somewhere at certain point. Currently we have a system property "sun.zip.disableMemoryMapping" to disable the mmap usage to workaround such scenario. The mmap was "useful" to share the jar/file content (among jvms) back to the old day that we actually mmap in the whole jar file, but we no longer do that, only the central directory is being mmap-ed now.... > expected that to be fixed meanwhile? I mean its not impossible to have > robust C code, or? > > Anyway, having said that - is there a performance comparision? What was > the reason for that native part in the first place? > We will still have to keep the native, even with a Java implementation. The jvm needs a native version to access the "jar" files to start with (all classes are stored in jar/zip format). So I believe the idea back then is to share that native implementation. I have a small micro-benchmark test case at http://cr.openjdk.java.net/~sherman/zipfile_jj/TestZipFile.java to do some measurement, it appears the Java version is slightly slower for the central directory initialization, but much faster to iterate the entries. -Sherman From vladimir.kozlov at oracle.com Wed May 21 23:34:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 May 2014 16:34:24 -0700 Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler Message-ID: <537D3800.8020603@oracle.com> http://cr.openjdk.java.net/~kvn/8035974/webrev https://bugs.openjdk.java.net/browse/JDK-8035974 Contributed by James Cheng and modified by me. To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified. On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected. About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check). Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968. Thanks, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8035968 From jeroen at sumatra.nl Thu May 22 07:07:28 2014 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Thu, 22 May 2014 07:07:28 +0000 Subject: RFR: Faster ZipFile.getEntry()/entries() In-Reply-To: <537D1851.3070408@oracle.com> References: <522910DB.6060004@oracle.com> <537D1851.3070408@oracle.com> Message-ID: <593c21126ac8487185cd24a3f30b0d5b@mane.sumatrasoftware.com> Hi Sherman, As a (minor) data point, IKVM.NET has been using a pure Java ZipFile implementation since day one (based on the GNU Classpath version) and other than a few compat bugs in the early days people have never complained about it. For obvious reasons, I'd certainly prefer the pure Java version (to minimize the amount of work I have to do ;-)), but I've also always thought that it was quite a hard sell that the native zip code was faster than pure Java code, given the overhead of JNI and the cost of native memory interop/pinning. Regards, Jeroen > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Xueming Shen > Sent: Wednesday, May 21, 2014 23:19 > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR: Faster ZipFile.getEntry()/entries() > > Hi, > > This one didn't make into jdk8. Here is an updated webrev for the jdk9 > repo > > http://cr.openjdk.java.net/~sherman/zipfile_j/webrev > > And a pure java version of j.u.ZipFile is also available at > > http://cr.openjdk.java.net/~sherman/zipfile_jj/webrev/ > > We do have incident reports and requests that suggest a pure Java > version of j.u.ZipFile might be preferred, especially to eliminate the > possibility of jvm crash at native level, mostly triggered by the mmap > usage and/or use scenario that the target zip/jar file is being > overwritten while reading. > > And java implementation also brings in the benefits of better memory > usage (all memory allocated in java heap), no more expensive jni > invocations... > > Opinion/comments are appreciated. > > Thanks! > -Sherman > > > On 09/05/2013 04:16 PM, Xueming Shen wrote: > > Hi, > > > > The change proposed here is to bring the zip entry handing code from > > the native level to the java level. This effectively solves the > > performance issues of ZipFile.getEntry and entries() that is caused by > > multiple jni invocation steps to generate one single ZipEntry (see > > ZipFile.getZipEntry()). A simple non-scientific benchmark test of > > simply iterating the ZipFile via the Enumeration from entries() on > rt.jar/charsets.jar suggests a 50%+ speed boost. > > > > http://cr.openjdk.java.net/~sherman/zipfile_j/webrev > > > > Couple notes: > > > > (1) Ideally it might be desired to go further to bring all the native > > code of ZipFile to java level (which should help completely remove > > that mmap crash issue, have better file and memory management... ), > > but it is suggested that it might be better to limit the scope of the > change at this late release circle. > > > > (2) JavaFile.read0() is the version that uses > > "getPrimitiveArrayCritical" to read file bits into the java array > > directly (instead of using a stack buffer and then copy into the java > > array), which appears to be 5% faster. But I can't make up my mind of > > which one would be better. Given (1) the trouble we had before in > > De/Infalter code (when the getPrimitiveArrayCritical is being heavily > used), (2) FileInputStream uses the same "copy" approach, I'm staying > with the "copy" appraoch, but option appreciated. > > > > (3) We will have to keep the native implementation (zip_util.c) for > > the vm directly access. > > > > Thanks! > > -Sherman > > From pavel.rappo at oracle.com Thu May 22 08:47:18 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 22 May 2014 09:47:18 +0100 Subject: RFR JDK-8042887: Remove serialver -show, this tool does not need a GUI Message-ID: Hi everyone, could you please review my change for JDK-8042887? http://cr.openjdk.java.net/~alanb/8042887/webrev/ I also created following issues for appropriate docs/localization updates: https://bugs.openjdk.java.net/browse/JDK-8043613 https://bugs.openjdk.java.net/browse/JDK-8043620 Thanks -Pavel From erik.gahlin at oracle.com Thu May 22 09:02:41 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 22 May 2014 11:02:41 +0200 Subject: RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <537B5D27.7040707@oracle.com> References: <537B4981.9010806@oracle.com> <1BA665D6-A1B8-482B-99D2-893DB3DCABEF@oracle.com> <537B5D27.7040707@oracle.com> Message-ID: <537DBD31.8040205@oracle.com> Looks good! Erik Yekaterina Kantserova skrev 2014-05-20 15:48: > Thanks Staffan! > > New webrev can be found here: > http://cr.openjdk.java.net/~ykantser/8043520/webrev.01/ > > // Katja > > > > On 05/20/2014 03:07 PM, Staffan Larsen wrote: >> test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java >> ?Dummy? is being built twice. >> >> Otherwise good! >> >> /Staffan >> >> >> On 20 maj 2014, at 14:24, Yekaterina Kantserova >> wrote: >> >>> Staffan, Alan, >>> >>> could you please review the following fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 >>> Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ >>> >>> I've missed somehow several tests in >>> http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which >>> existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. >>> >>> Thanks, >>> Katja >>> > From yekaterina.kantserova at oracle.com Thu May 22 09:08:49 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 22 May 2014 11:08:49 +0200 Subject: RFR(S): 8043520: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <537DBD31.8040205@oracle.com> References: <537B4981.9010806@oracle.com> <1BA665D6-A1B8-482B-99D2-893DB3DCABEF@oracle.com> <537B5D27.7040707@oracle.com> <537DBD31.8040205@oracle.com> Message-ID: <537DBEA1.9040906@oracle.com> Thanks Erik! Staffan, could you please be my sponsor and push the change? // Katja On 05/22/2014 11:02 AM, Erik Gahlin wrote: > Looks good! > > Erik > > Yekaterina Kantserova skrev 2014-05-20 15:48: >> Thanks Staffan! >> >> New webrev can be found here: >> http://cr.openjdk.java.net/~ykantser/8043520/webrev.01/ >> >> // Katja >> >> >> >> On 05/20/2014 03:07 PM, Staffan Larsen wrote: >>> test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.java >>> ?Dummy? is being built twice. >>> >>> Otherwise good! >>> >>> /Staffan >>> >>> >>> On 20 maj 2014, at 14:24, Yekaterina Kantserova >>> wrote: >>> >>>> Staffan, Alan, >>>> >>>> could you please review the following fix. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043520 >>>> Webrev: http://cr.openjdk.java.net/~ykantser/8043520/webrev.00/ >>>> >>>> I've missed somehow several tests in >>>> http://cr.openjdk.java.net/~ykantser/8034960/webrev.01/ which >>>> existed in http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/. >>>> >>>> Thanks, >>>> Katja >>>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8043520.2.patch Type: text/x-patch Size: 13311 bytes Desc: not available URL: From Alan.Bateman at oracle.com Thu May 22 11:50:37 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 May 2014 12:50:37 +0100 Subject: RFR JDK-8042887: Remove serialver -show, this tool does not need a GUI In-Reply-To: References: Message-ID: <537DE48D.4090509@oracle.com> On 22/05/2014 09:47, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8042887? > > http://cr.openjdk.java.net/~alanb/8042887/webrev Thanks Pavel, good to see this legacy option going away. The change looks good to me and I'm happy to sponsor it for you. -Alan. From chris.hegarty at oracle.com Thu May 22 13:32:53 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 May 2014 14:32:53 +0100 Subject: RFR JDK-8042887: Remove serialver -show, this tool does not need a GUI In-Reply-To: References: Message-ID: <8C30B1D1-D58B-4543-92E2-3CD98FB870EC@oracle.com> This looks good to me. Trivially, I think you could remove the 3 and 4 arg Res.getText methods, as I don?t see them being used. -Chris. On 22 May 2014, at 09:47, Pavel Rappo wrote: > Hi everyone, > > could you please review my change for JDK-8042887? > > http://cr.openjdk.java.net/~alanb/8042887/webrev/ > > I also created following issues for appropriate docs/localization updates: > > https://bugs.openjdk.java.net/browse/JDK-8043613 > https://bugs.openjdk.java.net/browse/JDK-8043620 > > Thanks > -Pavel From pavel.rappo at oracle.com Thu May 22 13:47:45 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 22 May 2014 14:47:45 +0100 Subject: RFR JDK-8042887: Remove serialver -show, this tool does not need a GUI In-Reply-To: <8C30B1D1-D58B-4543-92E2-3CD98FB870EC@oracle.com> References: <8C30B1D1-D58B-4543-92E2-3CD98FB870EC@oracle.com> Message-ID: <7AEA4CFF-C3BF-4B50-BDC1-F9A858112B49@oracle.com> Yeah, I've done that before. But finally decided to exclude this change and several more unrelated to the issue. I believe from the 'hg' history perspective it will look cleaner. I can file a separate bug for a tiny refactoring of this tool if you want, but being realistic I don't think anybody needs it. Here they are: @@ -169,11 +66,11 @@ */ static String serialSyntax(String classname) throws ClassNotFoundException { String ret = null; boolean classFound = false; - // If using old style of qualifyling inner classes with '$'s. + // If using old style of qualifying inner classes with '$'s. if (classname.indexOf('$') != -1) { ret = resolveClass(classname); } else { /* Try to resolve the fully qualified name and if that fails, start * replacing the '.'s with '$'s starting from the last '.', until @@ -276,25 +165,23 @@ } catch (IOException ioe) { System.err.println(Res.getText("error.parsing.classpath", envcp)); System.exit(3); } - if (!show) { /* - * Check if there are any class names specified, if it is not a - * invocation with the -show option. + * Check if there are any class names specified */ if (i == args.length) { usage(); System.exit(1); } /* * The rest of the parameters are classnames. */ boolean exitFlag = false; - for (i = i; i < args.length; i++ ) { + for (; i < args.length; i++) { try { String syntax = serialSyntax(args[i]); if (syntax != null) System.out.println(args[i] + ":" + syntax); else { @@ -184,17 +81,17 @@ classFound = true; } catch (ClassNotFoundException e) { /* Class not found so far */ } if (!classFound) { - StringBuffer workBuffer = new StringBuffer(classname); - String workName = workBuffer.toString(); + StringBuilder workBuilder = new StringBuilder(classname); + String workName = workBuilder.toString(); int i; while ((i = workName.lastIndexOf('.')) != -1 && !classFound) { - workBuffer.setCharAt(i, '$'); + workBuilder.setCharAt(i, '$'); try { - workName = workBuffer.toString(); + workName = workBuilder.toString(); ret = resolveClass(workName); classFound = true; } catch (ClassNotFoundException e) { /* Continue searching */ } @@ -423,49 +237,26 @@ * get and format message string from resource * * @param key selects message from resource */ static String getText(String key) { - return getText(key, (String)null); + return getText(key, null); } /** * get and format message string from resource * * @param key selects message from resource * @param a1 first argument */ static String getText(String key, String a1) { - return getText(key, a1, null); - } - - /** - * get and format message string from resource - * - * @param key selects message from resource - * @param a1 first argument - * @param a2 second argument - */ - static String getText(String key, String a1, String a2) { - return getText(key, a1, a2, null); - } - - /** - * get and format message string from resource - * - * @param key selects message from resource - * @param a1 first argument - * @param a2 second argument - * @param a3 third argument - */ - static String getText(String key, String a1, String a2, String a3) { if (messageRB == null) { initResource(); } try { String message = messageRB.getString(key); - return MessageFormat.format(message, a1, a2, a3); + return MessageFormat.format(message, a1); } catch (MissingResourceException e) { throw new Error("Fatal: Resource for serialver is broken. There is no " + key + " key in resource."); } } } -Pavel On 22 May 2014, at 14:32, Chris Hegarty wrote: > This looks good to me. > > Trivially, I think you could remove the 3 and 4 arg Res.getText methods, as I don?t see them being used. > > -Chris. > > On 22 May 2014, at 09:47, Pavel Rappo wrote: > >> Hi everyone, >> >> could you please review my change for JDK-8042887? >> >> http://cr.openjdk.java.net/~alanb/8042887/webrev/ >> >> I also created following issues for appropriate docs/localization updates: >> >> https://bugs.openjdk.java.net/browse/JDK-8043613 >> https://bugs.openjdk.java.net/browse/JDK-8043620 >> >> Thanks >> -Pavel > From chris.hegarty at oracle.com Thu May 22 13:48:44 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 May 2014 14:48:44 +0100 Subject: RFR JDK-8042887: Remove serialver -show, this tool does not need a GUI In-Reply-To: <7AEA4CFF-C3BF-4B50-BDC1-F9A858112B49@oracle.com> References: <8C30B1D1-D58B-4543-92E2-3CD98FB870EC@oracle.com> <7AEA4CFF-C3BF-4B50-BDC1-F9A858112B49@oracle.com> Message-ID: It is up to you. Consider it reviewed, from my perspective, either way. -Chris. On 22 May 2014, at 14:47, Pavel Rappo wrote: > Yeah, I've done that before. But finally decided to exclude this change and several more unrelated to the issue. I believe from the 'hg' history perspective it will look cleaner. I can file a separate bug for a tiny refactoring of this tool if you want, but being realistic I don't think anybody needs it. Here they are: > > @@ -169,11 +66,11 @@ > > */ > static String serialSyntax(String classname) throws ClassNotFoundException { > String ret = null; > boolean classFound = false; > > > - // If using old style of qualifyling inner classes with '$'s. > + // If using old style of qualifying inner classes with '$'s. > > if (classname.indexOf('$') != -1) { > ret = resolveClass(classname); > } else { > /* Try to resolve the fully qualified name and if that fails, start > * replacing the '.'s with '$'s starting from the last '.', until > > @@ -276,25 +165,23 @@ > > } catch (IOException ioe) { > System.err.println(Res.getText("error.parsing.classpath", envcp)); > System.exit(3); > } > > > - if (!show) { > > /* > > - * Check if there are any class names specified, if it is not a > - * invocation with the -show option. > + * Check if there are any class names specified > > */ > if (i == args.length) { > usage(); > System.exit(1); > } > > /* > * The rest of the parameters are classnames. > */ > boolean exitFlag = false; > > - for (i = i; i < args.length; i++ ) { > + for (; i < args.length; i++) { > > try { > String syntax = serialSyntax(args[i]); > if (syntax != null) > System.out.println(args[i] + ":" + syntax); > else { > > @@ -184,17 +81,17 @@ > > classFound = true; > } catch (ClassNotFoundException e) { > /* Class not found so far */ > } > if (!classFound) { > > - StringBuffer workBuffer = new StringBuffer(classname); > - String workName = workBuffer.toString(); > + StringBuilder workBuilder = new StringBuilder(classname); > + String workName = workBuilder.toString(); > > int i; > while ((i = workName.lastIndexOf('.')) != -1 && !classFound) { > > - workBuffer.setCharAt(i, '$'); > + workBuilder.setCharAt(i, '$'); > > try { > > - workName = workBuffer.toString(); > + workName = workBuilder.toString(); > > ret = resolveClass(workName); > classFound = true; > } catch (ClassNotFoundException e) { > /* Continue searching */ > } > @@ -423,49 +237,26 @@ > > * get and format message string from resource > * > * @param key selects message from resource > */ > static String getText(String key) { > > - return getText(key, (String)null); > + return getText(key, null); > > } > > /** > * get and format message string from resource > * > * @param key selects message from resource > * @param a1 first argument > */ > static String getText(String key, String a1) { > > - return getText(key, a1, null); > - } > - > - /** > - * get and format message string from resource > - * > - * @param key selects message from resource > - * @param a1 first argument > - * @param a2 second argument > - */ > - static String getText(String key, String a1, String a2) { > - return getText(key, a1, a2, null); > - } > - > - /** > - * get and format message string from resource > - * > - * @param key selects message from resource > - * @param a1 first argument > - * @param a2 second argument > - * @param a3 third argument > - */ > - static String getText(String key, String a1, String a2, String a3) { > > if (messageRB == null) { > initResource(); > } > try { > String message = messageRB.getString(key); > > - return MessageFormat.format(message, a1, a2, a3); > + return MessageFormat.format(message, a1); > > } catch (MissingResourceException e) { > throw new Error("Fatal: Resource for serialver is broken. There is no " + key + " key in resource."); > } > } > } > > > -Pavel > > On 22 May 2014, at 14:32, Chris Hegarty wrote: > >> This looks good to me. >> >> Trivially, I think you could remove the 3 and 4 arg Res.getText methods, as I don?t see them being used. >> >> -Chris. >> >> On 22 May 2014, at 09:47, Pavel Rappo wrote: >> >>> Hi everyone, >>> >>> could you please review my change for JDK-8042887? >>> >>> http://cr.openjdk.java.net/~alanb/8042887/webrev/ >>> >>> I also created following issues for appropriate docs/localization updates: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8043613 >>> https://bugs.openjdk.java.net/browse/JDK-8043620 >>> >>> Thanks >>> -Pavel >> > From roger.riggs at oracle.com Thu May 22 13:49:09 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 22 May 2014 09:49:09 -0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> Message-ID: <537E0055.2090302@oracle.com> Hi, The webrev has been updated to more completely describe the pid: "The native process id is an identification number that the operating system assigns to the process." Any other comments? Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 Thanks, Roger From pbenedict at apache.org Thu May 22 14:07:14 2014 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 22 May 2014 09:07:14 -0500 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E0055.2090302@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> Message-ID: Looks good. Don't forget @since 1.9 in the javadoc Cheers, Paul On Thu, May 22, 2014 at 8:49 AM, roger riggs wrote: > Hi, > > The webrev has been updated to more completely describe the pid: > "The native process id is an identification number that the operating > system assigns to the process." > > Any other comments? > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ < > http://cr.openjdk.java.net/%7Erriggs/webrev-getpid-8003488/> > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > Thanks, Roger > > From vincent.x.ryan at oracle.com Thu May 22 14:22:56 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 22 May 2014 15:22:56 +0100 Subject: RFR - 8042857: 14 stuck threads waiting for notification on LDAPRequest In-Reply-To: <53763604.3030709@oracle.com> References: <53763604.3030709@oracle.com> Message-ID: Fix looks fine Rob. Thanks. On 16 May 2014, at 17:00, Rob McKenna wrote: > Hi folks, > > A simple fix to eliminate a possible infinite loop when an Ldap Connection cannot contact the server. > > http://cr.openjdk.java.net/~robm/8042857/webrev.01/ > > -Rob > From ivan.gerasimov at oracle.com Thu May 22 14:44:13 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 22 May 2014 18:44:13 +0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E0055.2090302@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> Message-ID: <537E0D3D.8090505@oracle.com> Hi Roger! On 22.05.2014 17:49, roger riggs wrote: > Hi, > > The webrev has been updated to more completely describe the pid: > "The native process id is an identification number that the operating > system assigns to the process." > > Any other comments? > I assume it compiles fine, but in src/windows/native/java/lang/ProcessImpl_md.c: 258 DWORD pid = GetProcessId(handle); GetProcessId requires an argument of type HANDLE, which is defined as void*. Wouldn't it be better to explicitly cast jlong to HANDLE? Sincerely yours, Ivan > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > Thanks, Roger > > > From Alan.Bateman at oracle.com Thu May 22 15:01:21 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 May 2014 16:01:21 +0100 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E0055.2090302@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> Message-ID: <537E1141.2050100@oracle.com> On 22/05/2014 14:49, roger riggs wrote: > Hi, > > The webrev has been updated to more completely describe the pid: > "The native process id is an identification number that the operating > system assigns to the process." > > Any other comments? > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > Roger and I discussed this one last week so I'm happy with the signature and javadoc. I see Ivan has picked up on the HANDLE <--> jlong and jlong_to_ptr is normally the macro that we use for that. A minor consistency point is that the getPid is added before the constructor whereas the other overrides are below the constructor. For the test then it would be good to add the issue number to the @bug line. One question on the test as I'm not familiar with output of tasklist. If 2+ test were to run tasklist at the same time then could it confuse this test? I'm just wondering if there is anything closer to echo $$. Otherwise looks good to me. -Alan. From david.lloyd at redhat.com Thu May 22 15:34:08 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 22 May 2014 10:34:08 -0500 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E0055.2090302@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> Message-ID: <537E18F0.8060705@redhat.com> On 05/22/2014 08:49 AM, roger riggs wrote: > Hi, > > The webrev has been updated to more completely describe the pid: > "The native process id is an identification number that the operating > system assigns to the process." > > Any other comments? > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 I guess this is a little late, and minor, but the "jstack" tool uses the acronym "nid" for this purpose, which I believe is mapped to the same concept (on Linux it is anyway). I think either this terminology should be unified on the jstack side, or else the method should be called "getNativeId" or "getNid" or something. -- - DML From ivan.gerasimov at oracle.com Thu May 22 15:36:30 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 22 May 2014 19:36:30 +0400 Subject: RFR 8043772: Typos in Double/Int/LongSummaryStatistics.java Message-ID: <537E197E.1000200@oracle.com> Hello! Some functions were renamed with the fix for JDK-8015318. A few of them kept their old names in the comments. Would you please review this trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043772 WEBREV: http://cr.openjdk.java.net/~igerasim/8043772/0/webrev/ Sincerely yours, Ivan From Alan.Bateman at oracle.com Thu May 22 15:44:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 May 2014 16:44:48 +0100 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E18F0.8060705@redhat.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E18F0.8060705@redhat.com> Message-ID: <537E1B70.8080902@oracle.com> On 22/05/2014 16:34, David M. Lloyd wrote: > > I guess this is a little late, and minor, but the "jstack" tool uses > the acronym "nid" for this purpose, which I believe is mapped to the > same concept (on Linux it is anyway). > > I think either this terminology should be unified on the jstack side, > or else the method should be called "getNativeId" or "getNid" or > something. Are you thinking of "vmid" by any chance? If so then that term comes from jvmstat. It uses String for the identifier because it can support inspecting the counters of remote VMs (pid at host for example). If I recall correctly then jstack allows for a String too, mostly because it has its roots as a SA tool where it can connect to a remote VM when jsadebugd is running. -Alan. From roger.riggs at oracle.com Thu May 22 15:44:57 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 22 May 2014 11:44:57 -0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E18F0.8060705@redhat.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E18F0.8060705@redhat.com> Message-ID: <537E1B79.1090608@oracle.com> Hi, jstack -help uses "pid"; where are looking? Roger On 5/22/2014 11:34 AM, David M. Lloyd wrote: > On 05/22/2014 08:49 AM, roger riggs wrote: >> Hi, >> >> The webrev has been updated to more completely describe the pid: >> "The native process id is an identification number that the operating >> system assigns to the process." >> >> Any other comments? >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > I guess this is a little late, and minor, but the "jstack" tool uses > the acronym "nid" for this purpose, which I believe is mapped to the > same concept (on Linux it is anyway). > > I think either this terminology should be unified on the jstack side, > or else the method should be called "getNativeId" or "getNid" or > something. > > From david.lloyd at redhat.com Thu May 22 15:46:30 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 22 May 2014 10:46:30 -0500 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E18F0.8060705@redhat.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E18F0.8060705@redhat.com> Message-ID: <537E1BD6.4050607@redhat.com> On 05/22/2014 10:34 AM, David M. Lloyd wrote: > On 05/22/2014 08:49 AM, roger riggs wrote: >> Hi, >> >> The webrev has been updated to more completely describe the pid: >> "The native process id is an identification number that the operating >> system assigns to the process." >> >> Any other comments? >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 > > I guess this is a little late, and minor, but the "jstack" tool uses the > acronym "nid" for this purpose, which I believe is mapped to the same > concept (on Linux it is anyway). > > I think either this terminology should be unified on the jstack side, or > else the method should be called "getNativeId" or "getNid" or something. Refining that thought - on Linux, process IDs and thread IDs share a namespace, but maybe that isn't true on all platforms. Still calling it "getPid" seems very UNIX-specific. Process.getNativeId() seems "safer" or more future-proof to me, somehow. -- - DML From roger.riggs at oracle.com Thu May 22 15:51:15 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 22 May 2014 11:51:15 -0400 Subject: RFR 8043772: Typos in Double/Int/LongSummaryStatistics.java In-Reply-To: <537E197E.1000200@oracle.com> References: <537E197E.1000200@oracle.com> Message-ID: <537E1CF3.6050404@oracle.com> Hi Ivan, Looks fine, Roger On 5/22/2014 11:36 AM, Ivan Gerasimov wrote: > Hello! > > Some functions were renamed with the fix for JDK-8015318. > A few of them kept their old names in the comments. > Would you please review this trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043772 > WEBREV: http://cr.openjdk.java.net/~igerasim/8043772/0/webrev/ > > Sincerely yours, > Ivan From david.lloyd at redhat.com Thu May 22 15:55:16 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 22 May 2014 10:55:16 -0500 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E1B70.8080902@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E18F0.8060705@redhat.com> <537E1B70.8080902@oracle.com> Message-ID: <537E1DE4.3060205@redhat.com> On 05/22/2014 10:44 AM, Alan Bateman wrote: > On 22/05/2014 16:34, David M. Lloyd wrote: >> >> I guess this is a little late, and minor, but the "jstack" tool uses >> the acronym "nid" for this purpose, which I believe is mapped to the >> same concept (on Linux it is anyway). >> >> I think either this terminology should be unified on the jstack side, >> or else the method should be called "getNativeId" or "getNid" or >> something. > Are you thinking of "vmid" by any chance? If so then that term comes > from jvmstat. It uses String for the identifier because it can support > inspecting the counters of remote VMs (pid at host for example). If I > recall correctly then jstack allows for a String too, mostly because it > has its roots as a SA tool where it can connect to a remote VM when > jsadebugd is running. Nah I'm thinking of this: $ jstack 30044 2014-05-22 10:39:55 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode): [...] "RMI TCP Accept-0" daemon prio=10 tid=0x00007ff884143000 nid=0x756e The "nid" here is the hex-encoded process ID of the thread. But instead of saying "process ID" or whatever, it's "native ID". As stated earlier though, on Linux the thread and process IDs share a namespace so it's not always true that these are the *same* thing; however, it illustrates that in general, threads have a "native ID", reserving "thread ID" as an internal JVM concept. I would think the same would apply to processes, especially given that "process ID" is a first-order concept on some (but maybe not all) OSes, and even OSes without that first-order PID concept might still have some other meaningful numeric mapping for the native ID of a Process. -- - DML From roger.riggs at oracle.com Thu May 22 16:05:17 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 22 May 2014 12:05:17 -0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E1DE4.3060205@redhat.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E18F0.8060705@redhat.com> <537E1B70.8080902@oracle.com> <537E1DE4.3060205@redhat.com> Message-ID: <537E203D.3050903@oracle.com> Hi, Thanks for the rationale. Using the natural terminology familiar to developers seems most useful. Mac, Windows, and Linux refer to these values a process id or pid as the handle for a Process; it appears in the tools like ps and tasklist. The javadoc can explain anything more specific or system dependent. Roger On 5/22/2014 11:55 AM, David M. Lloyd wrote: > On 05/22/2014 10:44 AM, Alan Bateman wrote: >> On 22/05/2014 16:34, David M. Lloyd wrote: >>> >>> I guess this is a little late, and minor, but the "jstack" tool uses >>> the acronym "nid" for this purpose, which I believe is mapped to the >>> same concept (on Linux it is anyway). >>> >>> I think either this terminology should be unified on the jstack side, >>> or else the method should be called "getNativeId" or "getNid" or >>> something. >> Are you thinking of "vmid" by any chance? If so then that term comes >> from jvmstat. It uses String for the identifier because it can support >> inspecting the counters of remote VMs (pid at host for example). If I >> recall correctly then jstack allows for a String too, mostly because it >> has its roots as a SA tool where it can connect to a remote VM when >> jsadebugd is running. > > Nah I'm thinking of this: > > > $ jstack 30044 > 2014-05-22 10:39:55 > Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed > mode): > [...] > "RMI TCP Accept-0" daemon prio=10 tid=0x00007ff884143000 nid=0x756e > > The "nid" here is the hex-encoded process ID of the thread. But > instead of saying "process ID" or whatever, it's "native ID". As > stated earlier though, on Linux the thread and process IDs share a > namespace so it's not always true that these are the *same* thing; > however, it illustrates that in general, threads have a "native ID", > reserving "thread ID" as an internal JVM concept. I would think the > same would apply to processes, especially given that "process ID" is a > first-order concept on some (but maybe not all) OSes, and even OSes > without that first-order PID concept might still have some other > meaningful numeric mapping for the native ID of a Process. > From mike.duigou at oracle.com Thu May 22 16:22:03 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 22 May 2014 09:22:03 -0700 Subject: RFR 8043772: Typos in Double/Int/LongSummaryStatistics.java In-Reply-To: <537E197E.1000200@oracle.com> References: <537E197E.1000200@oracle.com> Message-ID: <404516BC-77C2-4DC1-A5D2-D413B2FF237A@oracle.com> Looks fine to me. Mike You are using an old version of webrev :-) wget http://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh On May 22 2014, at 08:36 , Ivan Gerasimov wrote: > Hello! > > Some functions were renamed with the fix for JDK-8015318. > A few of them kept their old names in the comments. > Would you please review this trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043772 > WEBREV: http://cr.openjdk.java.net/~igerasim/8043772/0/webrev/ > > Sincerely yours, > Ivan From huizhe.wang at oracle.com Thu May 22 16:30:01 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 22 May 2014 09:30:01 -0700 Subject: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE Message-ID: <537E2609.70104@oracle.com> Refer to 8042889, while verifying/testing 8042889, we noticed that the tiny XML parser failed on UTF-16BE or LE. The cause of the failure was that the parser was actually implemented to abide by the XML specification that required entities encoded in UTF-16 to begin with BOM. The test we used sent a byte array to the parser without BOM, thus failed. Since it's not uncommon for a XML to not have BOM, I borrowed the technique used in Xerces to add an additional check for UTF-16 encoding. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/ Thanks, Joe From lance.andersen at oracle.com Thu May 22 16:35:12 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 22 May 2014 12:35:12 -0400 Subject: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE In-Reply-To: <537E2609.70104@oracle.com> References: <537E2609.70104@oracle.com> Message-ID: <5E0C7F18-46BA-446A-8265-6E515BDB6E2A@oracle.com> Looks OK. I would suggest removing the commented out code from the test before you push to the workspace Best Lace On May 22, 2014, at 12:30 PM, huizhe wang wrote: > Refer to 8042889, while verifying/testing 8042889, we noticed that the tiny XML parser failed on UTF-16BE or LE. The cause of the failure was that the parser was actually implemented to abide by the XML specification that required entities encoded in UTF-16 to begin with BOM. The test we used sent a byte array to the parser without BOM, thus failed. > > Since it's not uncommon for a XML to not have BOM, I borrowed the technique used in Xerces to add an additional check for UTF-16 encoding. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From xueming.shen at oracle.com Thu May 22 17:25:17 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 22 May 2014 10:25:17 -0700 Subject: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE In-Reply-To: <537E2609.70104@oracle.com> References: <537E2609.70104@oracle.com> Message-ID: <537E32FD.7070102@oracle.com> Hi (1) Do we really need those shift at line ln#2989/90 and 2994/95? it appears to me those bytes have been decided to be ZERO already, we are talking about mChar[0] = '<' and mChar[1] = '?' here, right? (2) for test, maybe we should just do p.loadFromXML(in) ? that path should verify the fix as well (the real use scenario), right? (3) do we have tests for utf16 bom? if not, I would suggest to throw in UTF-16BE/LE-BOM into the charset[], just in case. thanks! -Sherman On 05/22/2014 09:30 AM, huizhe wang wrote: > Refer to 8042889, while verifying/testing 8042889, we noticed that the tiny XML parser failed on UTF-16BE or LE. The cause of the failure was that the parser was actually implemented to abide by the XML specification that required entities encoded in UTF-16 to begin with BOM. The test we used sent a byte array to the parser without BOM, thus failed. > > Since it's not uncommon for a XML to not have BOM, I borrowed the technique used in Xerces to add an additional check for UTF-16 encoding. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/ > > Thanks, > Joe From xueming.shen at oracle.com Thu May 22 18:40:00 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 22 May 2014 11:40:00 -0700 Subject: RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb In-Reply-To: <537BC093.40102@oracle.com> References: <53672CB4.3050708@oracle.com> <537A4980.5050603@oracle.com> <537BC093.40102@oracle.com> Message-ID: <537E4480.7030504@oracle.com> Masayoshi, Roger, OK, let's forget the fancy TarInputStream for now:-) Here is the webrev that just updates the code to use existing java.time classes for tzdb data building. http://cr.openjdk.java.net/~sherman/8042369/webrev The difference compared to the last version [1] is that it reads in individual files from the file system, as the existing tool does. Thanks! -Sherman [1] http://cr.openjdk.java.net/~sherman/8042369/webrev.01/ On 05/20/2014 01:52 PM, roger riggs wrote: > Hi Sherman, > > Even though it has well defined content, checking in the tar.gz seems not quite right. > Can the tests reconstruct the tar file from the contents or directly use > the IANA data on demand from the IANA site? > > From a maintenance point of view, functions added to the JDK should be > well used and maintained and be well supported. > > TzdbZoneRulesCompiler.java: +130 The error for srcFile == null still mentions "-srcdir". > > :+153; the commented out message should be removed > > > Roger > > > On 5/19/2014 2:12 PM, Xueming Shen wrote: >> Hi, >> >> I've not got any feedback so far, so I assume it's good:-) >> >> Anyway, I'm going a little further to throw in a TarInputStream so now we just build the >> tzdb data directly on the tzdata201xy.tar.gz from iana site. I'm not sure if it is OK to >> check in the original .tar.gz file into the jdk repository though. >> >> There are also more improvements in this version, it is much faster now. It might >> not matter as it is only used during build time, though:-) >> >> http://cr.openjdk.java.net/~sherman/8042369/webrev >> >> -Sherman >> >> Btw, I'm still trying to sell the idea of checking in a second tzdb provider implementation >> into the jdk, which directly loads in the tzdb data by using the iana original source data, >> with the assumption that this might be useful at least in certain circumstance (such as >> one gov pushes a tz change, and some of your big jdk customers need their apps run with >> the new data in next 24 hrs...) in the future. >> >> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev >> >> >> On 05/04/2014 11:16 PM, Xueming Shen wrote: >>> Hi >>> >>> Please help review the change for #8042369 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8042369 >>> Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev >>> >>> In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data >>> for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these >>> classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so >>> most of these duplicated classes are no longer needed, with ZoneRules as the only exception. >>> The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the >>> serialization forms of those transitions and rules. The proposed change here is to remove >>> those unneeded duplicated classes. >>> >>> I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler >>> and and straightforward implementation, with the goal of migrating it into a second default >>> ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the >>> IANA directly. One of the benefits of such a provider is that the end user may just drop the latest >>> timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from >>> Oracle. >>> >>> Here is the webrev for the idea >>> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/ >>> >>> The only disadvantage appears to be the possible "slowdown" of startup time because of >>> the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for >>> j.u.TimeZone, if we go with this direction) >>> >>> Thanks! >>> -Sherman >>> >>> >> > From roger.riggs at oracle.com Thu May 22 19:47:56 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 22 May 2014 15:47:56 -0400 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E1141.2050100@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E1141.2050100@oracle.com> Message-ID: <537E546C.80307@oracle.com> Thanks for the feedback and recommendations; the webrev has been updated. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Alan, on the use of tasklist, I think a cleaner test can be written when the Java API to inspect other processes is available. I did not find a straightforward eqivalent for $$; there is a possible hack using tasklist but it would be a throwaway. Roger On 5/22/2014 11:01 AM, Alan Bateman wrote: > On 22/05/2014 14:49, roger riggs wrote: >> Hi, >> >> The webrev has been updated to more completely describe the pid: >> "The native process id is an identification number that the operating >> system assigns to the process." >> >> Any other comments? >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > Roger and I discussed this one last week so I'm happy with the > signature and javadoc. > > I see Ivan has picked up on the HANDLE <--> jlong and jlong_to_ptr is > normally the macro that we use for that. > > A minor consistency point is that the getPid is added before the > constructor whereas the other overrides are below the constructor. > > For the test then it would be good to add the issue number to the @bug > line. > > One question on the test as I'm not familiar with output of tasklist. > If 2+ test were to run tasklist at the same time then could it confuse > this test? I'm just wondering if there is anything closer to echo $$. > > Otherwise looks good to me. > > -Alan. > > > > > From bradford.wetmore at oracle.com Thu May 22 20:36:11 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 22 May 2014 13:36:11 -0700 Subject: Webrev for 8043342: StringBuffer/StringBuilder crypto changes. Message-ID: <537E5FBB.1060504@oracle.com> No additional code review necessary, this is just an FYI. For internal reasons (i.e. we have to sign our JCE jar files), we have separated the JCE portion for: 8041679: Replace uses of StringBuffer with StringBuilder within the JDK into: 8043342: Replace uses of StringBuffer with StringBuilder within crypto code It's the exact same code, but only the four JCE files are included here. http://cr.openjdk.java.net/~wetmore/8043342/webrev.00/ I am sponsoring this for Jamil, from an original fix [1] sponsored by Paul Sandoz from: Ot?vio Gon?alves de Santana Thanks, Brad [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/026820.html From huizhe.wang at oracle.com Fri May 23 05:15:02 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 22 May 2014 22:15:02 -0700 Subject: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE In-Reply-To: <537E32FD.7070102@oracle.com> References: <537E2609.70104@oracle.com> <537E32FD.7070102@oracle.com> Message-ID: <537ED956.3040200@oracle.com> Hi Sherman, Lance, Thanks for reviews. It appears resetting InputStream is not reliable since not every InputStream will support reset. I've modified the code. For other changes, pls see inline comments. On 5/22/2014 10:25 AM, Xueming Shen wrote: > Hi > > (1) Do we really need those shift at line ln#2989/90 and 2994/95? it > appears to me > those bytes have been decided to be ZERO already, we are talking > about > mChar[0] = '<' and mChar[1] = '?' here, right? Fixed. No need indeed. > > (2) for test, maybe we should just do p.loadFromXML(in) ? that path > should verify the > fix as well (the real use scenario), right? I've removed the test and updated LoadAndStoreXM instead, as Alan suggested, to cover UTF-16BE/LE. > > (3) do we have tests for utf16 bom? if not, I would suggest to throw > in UTF-16BE/LE-BOM > into the charset[], just in case. java.nio.charset states that it writes BOM when encoding in UTF-16, but not for BE or LE. That is why the tests behaved differently, that is, detecting BOM in the case of UTF-16, but not for UTF-16BE/LE. I added tests to manually append BOM in the case of UTF-16BE/LE to verify that the code is capable of handling these cases (although normally they won't come with BOM). http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/ Thanks, Joe > > thanks! > -Sherman > > On 05/22/2014 09:30 AM, huizhe wang wrote: >> Refer to 8042889, while verifying/testing 8042889, we noticed that >> the tiny XML parser failed on UTF-16BE or LE. The cause of the >> failure was that the parser was actually implemented to abide by the >> XML specification that required entities encoded in UTF-16 to begin >> with BOM. The test we used sent a byte array to the parser without >> BOM, thus failed. >> >> Since it's not uncommon for a XML to not have BOM, I borrowed the >> technique used in Xerces to add an additional check for UTF-16 >> encoding. Please review. >> >> http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/ >> >> Thanks, >> Joe > From paul.sandoz at oracle.com Fri May 23 09:06:19 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 23 May 2014 11:06:19 +0200 Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler In-Reply-To: <537D3800.8020603@oracle.com> References: <537D3800.8020603@oracle.com> Message-ID: On May 22, 2014, at 1:34 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8035974/webrev > https://bugs.openjdk.java.net/browse/JDK-8035974 > > Contributed by James Cheng and modified by me. > Looks good to me. Paul. > To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified. > > On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected. > > About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check). > > Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968. > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8035968 From forax at univ-mlv.fr Fri May 23 10:17:49 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 23 May 2014 12:17:49 +0200 Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler In-Reply-To: References: <537D3800.8020603@oracle.com> Message-ID: <537F204D.1000109@univ-mlv.fr> On 05/23/2014 11:06 AM, Paul Sandoz wrote: > On May 22, 2014, at 1:34 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8035974/webrev >> https://bugs.openjdk.java.net/browse/JDK-8035974 >> >> Contributed by James Cheng and modified by me. >> > Looks good to me. > > Paul. implCompressMultiBlock should be private thus don't need to be final. R?mi > >> To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified. >> >> On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected. >> >> About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check). >> >> Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968. >> >> Thanks, >> Vladimir >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8035968 From anthony.scarpino at oracle.com Fri May 23 14:25:50 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 23 May 2014 07:25:50 -0700 Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler In-Reply-To: <537D3800.8020603@oracle.com> References: <537D3800.8020603@oracle.com> Message-ID: <357BA371-4662-48CC-89C7-50F1918C86EB@oracle.com> This looks fine to me Tony > On May 21, 2014, at 4:34 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8035974/webrev > https://bugs.openjdk.java.net/browse/JDK-8035974 > > Contributed by James Cheng and modified by me. > > To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method implCompressMultiBlock() which contains only the loop and can be intrinsified. > > On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance regression with the pure Java SUN provider is expected. > > About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check). > > Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968. > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8035968 From huizhe.wang at oracle.com Fri May 23 15:23:05 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 23 May 2014 08:23:05 -0700 Subject: RFR: 8043666: Remove unused files from jaxp repository Message-ID: <537F67D9.8090405@oracle.com> Removing unused files in jaxp repository. Most of them are META-INF/services files used by Apache build process. The COPYING files at the bottom came with SAX, but they are included in the THIRD_PARTY_README file already. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8043666/webrev/ Thanks, Joe From Alan.Bateman at oracle.com Fri May 23 15:36:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 May 2014 16:36:34 +0100 Subject: RFR: 8043666: Remove unused files from jaxp repository In-Reply-To: <537F67D9.8090405@oracle.com> References: <537F67D9.8090405@oracle.com> Message-ID: <537F6B02.9090508@oracle.com> On 23/05/2014 16:23, huizhe wang wrote: > Removing unused files in jaxp repository. Most of them are > META-INF/services files used by Apache build process. The COPYING > files at the bottom came with SAX, but they are included in the > THIRD_PARTY_README file already. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8043666/webrev/ Thanks Joe, good to have these removed. Now we just need to do the same in the other repositories. -Alan From rob.mckenna at oracle.com Fri May 23 17:08:02 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 23 May 2014 18:08:02 +0100 Subject: RFR - 8041451: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request Message-ID: <537F8072.4090206@oracle.com> Hi folks, Very simple fix to ensure that a slow server isn't left waiting around for a request we have already given up on. http://cr.openjdk.java.net/~robm/8041451/webrev.01/ -Rob From vincent.x.ryan at oracle.com Fri May 23 17:09:06 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 23 May 2014 18:09:06 +0100 Subject: RFR - 8041451: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request In-Reply-To: <537F8072.4090206@oracle.com> References: <537F8072.4090206@oracle.com> Message-ID: That fix looks fine. Thanks. On 23 May 2014, at 18:08, Rob McKenna wrote: > Hi folks, > > Very simple fix to ensure that a slow server isn't left waiting around for a request we have already given up on. > > http://cr.openjdk.java.net/~robm/8041451/webrev.01/ > > -Rob > From james.cheng at oracle.com Fri May 23 17:27:32 2014 From: james.cheng at oracle.com (james cheng) Date: Fri, 23 May 2014 10:27:32 -0700 Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler In-Reply-To: <537F204D.1000109@univ-mlv.fr> References: <537D3800.8020603@oracle.com> <537F204D.1000109@univ-mlv.fr> Message-ID: <537F8504.1070104@oracle.com> On 5/23/2014 3:17 AM, Remi Forax wrote: > > On 05/23/2014 11:06 AM, Paul Sandoz wrote: >> On May 22, 2014, at 1:34 AM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/8035974/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8035974 >>> >>> Contributed by James Cheng and modified by me. >>> >> Looks good to me. >> >> Paul. > > implCompressMultiBlock should be private thus don't need to be final. > > R?mi I pulled it out of engineUpdate() so kept it "protected final" as before. I just tried it with "private" and it still could be intrinsified. So either way is okay in terms of intrinsification. Thanks, -James > >> >>> To use intrinsics to accelerate SHA operations on multiple blocks [1], it is needed to pull a loop out of DigestBase.engineUpdate() and make a new method >>> implCompressMultiBlock() which contains only the loop and can be intrinsified. >>> >>> On platforms which does not use intrinsic implCompressMultiBlock() method will be inlined by JIT and the same code will be generated as before. So no performance >>> regression with the pure Java SUN provider is expected. >>> >>> About arithmetic change. limit = ofs + len will not overflow integer because ofs <= b.length - len (there is check). >>> >>> Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 8035968. >>> >>> Thanks, >>> Vladimir >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8035968 > From vladimir.kozlov at oracle.com Fri May 23 18:18:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 May 2014 11:18:31 -0700 Subject: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler In-Reply-To: <537F8504.1070104@oracle.com> References: <537D3800.8020603@oracle.com> <537F204D.1000109@univ-mlv.fr> <537F8504.1070104@oracle.com> Message-ID: <537F90F7.2020408@oracle.com> Thank you, Paul, Remi, Anthony, for reviews. I changed "protected final" to "private" as suggested: http://cr.openjdk.java.net/~kvn/8035974/webrev.01 Note, JIT inlines final and private methods without generation a method's class check. So inlined code is the same. Thanks, Vladimir On 5/23/14 10:27 AM, james cheng wrote: > On 5/23/2014 3:17 AM, Remi Forax wrote: >> >> On 05/23/2014 11:06 AM, Paul Sandoz wrote: >>> On May 22, 2014, at 1:34 AM, Vladimir Kozlov >>> wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/8035974/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8035974 >>>> >>>> Contributed by James Cheng and modified by me. >>>> >>> Looks good to me. >>> >>> Paul. >> >> implCompressMultiBlock should be private thus don't need to be final. >> >> R?mi > > I pulled it out of engineUpdate() so kept it "protected final" as > before. I > just tried it with "private" and it still could be intrinsified. So > either way > is okay in terms of intrinsification. > > Thanks, > -James > >> >>> >>>> To use intrinsics to accelerate SHA operations on multiple blocks >>>> [1], it is needed to pull a loop out of DigestBase.engineUpdate() >>>> and make a new method >>>> implCompressMultiBlock() which contains only the loop and can be >>>> intrinsified. >>>> >>>> On platforms which does not use intrinsic implCompressMultiBlock() >>>> method will be inlined by JIT and the same code will be generated as >>>> before. So no performance >>>> regression with the pure Java SUN provider is expected. >>>> >>>> About arithmetic change. limit = ofs + len will not overflow integer >>>> because ofs <= b.length - len (there is check). >>>> >>>> Tested with jdk jtreg tests and new hotspot jtreg test James wrote >>>> for 8035968. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8035968 >> From joe.darcy at oracle.com Fri May 23 19:01:34 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 23 May 2014 12:01:34 -0700 Subject: JDK 9 RFR of 8043916: Fix fallthrough lint warnings in java/lang/UNIXProcess.java Message-ID: <537F9B0E.6050208@oracle.com> Hello, Please review the patch below to address 8043916: Fix fallthrough lint warnings in java/lang/UNIXProcess.java diff -r f142c0938978 src/solaris/classes/java/lang/UNIXProcess.java --- a/src/solaris/classes/java/lang/UNIXProcess.java Fri May 23 09:05:24 2014 -0700 +++ b/src/solaris/classes/java/lang/UNIXProcess.java Fri May 23 11:59:34 2014 -0700 @@ -97,6 +97,7 @@ EnumSet.copyOf(Arrays.asList(launchMechanisms)); } + @SuppressWarnings("fallthrough") private String helperPath(String javahome, String osArch) { switch (this) { case SOLARIS: The code of the switch in question is case SOLARIS: if (osArch.equals("x86")) { osArch = "i386"; } else if (osArch.equals("x86_64")) { osArch = "amd64"; } // fall through... case LINUX: case AIX: return javahome + "/lib/" + osArch + "/jspawnhelper"; Thanks, -Joe From lance.andersen at oracle.com Fri May 23 19:02:55 2014 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 23 May 2014 15:02:55 -0400 Subject: JDK 9 RFR of 8043916: Fix fallthrough lint warnings in java/lang/UNIXProcess.java In-Reply-To: <537F9B0E.6050208@oracle.com> References: <537F9B0E.6050208@oracle.com> Message-ID: <2AD07D59-D6B3-47F2-A5E9-23E9EF315B4F@oracle.com> +1 On May 23, 2014, at 3:01 PM, Joe Darcy wrote: > Hello, > > Please review the patch below to address > > 8043916: Fix fallthrough lint warnings in java/lang/UNIXProcess.java > > diff -r f142c0938978 src/solaris/classes/java/lang/UNIXProcess.java > --- a/src/solaris/classes/java/lang/UNIXProcess.java Fri May 23 09:05:24 2014 -0700 > +++ b/src/solaris/classes/java/lang/UNIXProcess.java Fri May 23 11:59:34 2014 -0700 > @@ -97,6 +97,7 @@ > EnumSet.copyOf(Arrays.asList(launchMechanisms)); > } > > + @SuppressWarnings("fallthrough") > private String helperPath(String javahome, String osArch) { > switch (this) { > case SOLARIS: > > The code of the switch in question is > > case SOLARIS: > if (osArch.equals("x86")) { osArch = "i386"; } > else if (osArch.equals("x86_64")) { osArch = "amd64"; } > // fall through... > case LINUX: > case AIX: > return javahome + "/lib/" + osArch + "/jspawnhelper"; > > Thanks, > > -Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Fri May 23 19:21:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 May 2014 20:21:48 +0100 Subject: JDK 9 RFR of 8043916: Fix fallthrough lint warnings in java/lang/UNIXProcess.java In-Reply-To: <537F9B0E.6050208@oracle.com> References: <537F9B0E.6050208@oracle.com> Message-ID: <537F9FCC.1060300@oracle.com> On 23/05/2014 20:01, Joe Darcy wrote: > Hello, > > Please review the patch below to address > > 8043916: Fix fallthrough lint warnings in java/lang/UNIXProcess.java > Looks okay. -Alan From otaviojava at java.net Sat May 24 14:34:55 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sat, 24 May 2014 11:34:55 -0300 Subject: Boolean valueOf instead of new Boolean In-Reply-To: References: Message-ID: The Boolean class has cache for true and false and using it, will save memory and will faster than using create new instance of boolean. Using JMH[1] with a code test[2] the result was: Benchmark Mode Samples Mean Mean error Units m.BooleanBenchmark.newInstanceBoolean thrpt 20 49801.326 369.897 ops/s m.BooleanBenchmark.newInstanceString thrpt 20 365.080 27.537 ops/s m.BooleanBenchmark.valueOfBoolean thrpt 20 764906233.316 9623009.653 ops/s m.BooleanBenchmark.valueOfString thrpt 20 371.174 28.216 ops/s The diff is on attachment or can is downloading the webdrev here: https://dl.dropboxusercontent.com/u/16109193/open_jdk/boolean_instance_of.zip [1] http://openjdk.java.net/projects/code-tools/jmh/ [2] @State(Scope.Thread) @OutputTimeUnit(TimeUnit.SECONDS) public class BooleanBenchmark { private static final int SIZE = 1_000_000; private List booleanString; private boolean[] booleans; { booleans = new boolean[SIZE]; booleanString = new ArrayList<>(SIZE); for (int index = 0; index < SIZE; index++) { if (index % 2 == 0) { booleans[index] = true; booleanString.add(Boolean.TRUE.toString()); } else { booleans[index] = false; booleanString.add(Boolean.FALSE.toString()); } } } @GenerateMicroBenchmark public void valueOfBoolean() { for(boolean b: booleans) { Boolean result = b; } } @GenerateMicroBenchmark public void valueOfString() { for(String b: booleanString) { Boolean result = Boolean.valueOf(b); } } @GenerateMicroBenchmark public void newInstanceBoolean() { for(boolean b: booleans) { Boolean result = new Boolean(b); } } @GenerateMicroBenchmark public void newInstanceString() { for(String b: booleanString) { Boolean result = new Boolean(b); } } } -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 -------------- next part -------------- diff -r 28d1de89ff27 src/share/classes/java/net/Socket.java --- a/src/share/classes/java/net/Socket.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/java/net/Socket.java Sat May 24 10:55:43 2014 -0300 @@ -1017,7 +1017,7 @@ if (isClosed()) throw new SocketException("Socket is closed"); if (!on) { - getImpl().setOption(SocketOptions.SO_LINGER, new Boolean(on)); + getImpl().setOption(SocketOptions.SO_LINGER, on); } else { if (linger < 0) { throw new IllegalArgumentException("invalid value for SO_LINGER"); diff -r 28d1de89ff27 src/share/classes/sun/font/SunFontManager.java --- a/src/share/classes/sun/font/SunFontManager.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/font/SunFontManager.java Sat May 24 10:55:43 2014 -0300 @@ -2871,8 +2871,7 @@ new java.security.PrivilegedAction() { public Object run() { SecurityManager sm = System.getSecurityManager(); - return new Boolean - (sm instanceof sun.applet.AppletSecurity); + return sm instanceof sun.applet.AppletSecurity; } }); return appletSM.booleanValue(); diff -r 28d1de89ff27 src/share/classes/sun/management/StackTraceElementCompositeData.java --- a/src/share/classes/sun/management/StackTraceElementCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/StackTraceElementCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -68,7 +68,7 @@ ste.getMethodName(), ste.getFileName(), new Integer(ste.getLineNumber()), - new Boolean(ste.isNativeMethod()), + ste.isNativeMethod(), }; try { return new CompositeDataSupport(stackTraceElementCompositeType, diff -r 28d1de89ff27 src/share/classes/sun/management/ThreadInfoCompositeData.java --- a/src/share/classes/sun/management/ThreadInfoCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/ThreadInfoCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -120,8 +120,8 @@ new Long(threadInfo.getLockOwnerId()), threadInfo.getLockOwnerName(), stackTraceData, - new Boolean(threadInfo.isSuspended()), - new Boolean(threadInfo.isInNative()), + threadInfo.isSuspended(), + threadInfo.isInNative(), lockedMonitorsData, lockedSyncsData, }; diff -r 28d1de89ff27 src/share/classes/sun/management/VMOptionCompositeData.java --- a/src/share/classes/sun/management/VMOptionCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/VMOptionCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -59,7 +59,7 @@ final Object[] vmOptionItemValues = { option.getName(), option.getValue(), - new Boolean(option.isWriteable()), + option.isWriteable(), option.getOrigin().toString(), }; diff -r 28d1de89ff27 src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java Sat May 24 10:55:43 2014 -0300 @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return getBoolean(obj); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff -r 28d1de89ff27 src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java Sat May 24 10:55:43 2014 -0300 @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return getBoolean(obj); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff -r 28d1de89ff27 src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java Sat May 24 10:55:43 2014 -0300 @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return getBoolean(obj); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff -r 28d1de89ff27 src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java Sat May 24 10:55:43 2014 -0300 @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return getBoolean(obj); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff -r 28d1de89ff27 src/share/classes/sun/security/jgss/GSSManagerImpl.java --- a/src/share/classes/sun/security/jgss/GSSManagerImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/security/jgss/GSSManagerImpl.java Sat May 24 10:55:43 2014 -0300 @@ -50,8 +50,8 @@ if (osname.startsWith("SunOS") || osname.contains("OS X") || osname.startsWith("Linux")) { - return new Boolean(System.getProperty - (USE_NATIVE_PROP)); + return Boolean.valueOf(System.getProperty + (USE_NATIVE_PROP)); } return Boolean.FALSE; } diff -r 28d1de89ff27 src/share/classes/sun/security/provider/PolicyFile.java --- a/src/share/classes/sun/security/provider/PolicyFile.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat May 24 10:55:43 2014 -0300 @@ -1271,7 +1271,7 @@ Boolean imp = AccessController.doPrivileged (new PrivilegedAction() { public Boolean run() { - return new Boolean(entry.getCodeSource().implies(cs)); + return entry.getCodeSource().implies(cs); } }); if (!imp.booleanValue()) { From aleksey.shipilev at oracle.com Sat May 24 15:19:41 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 24 May 2014 19:19:41 +0400 Subject: Boolean valueOf instead of new Boolean In-Reply-To: References: Message-ID: <5380B88D.60009@oracle.com> On 05/24/2014 06:34 PM, Ot?vio Gon?alves de Santana wrote: > The Boolean class has cache for true and false and using it, will save > memory and will faster than using create new instance of boolean. > Using JMH[1] with a code test[2] the result was: I agree Boolean.valueOf (whether explicit or implicit) should be used if identity is not required. Do you really need explicit Boolean.valueOf in, say, GSSManagerImpl, instead of relying on autoboxing? That said, your benchmark is not correct. At very least, you have to use explicit BlackHoles to avoid DCE [1][2]. This is how you do it: @State(Scope.Thread) @OutputTimeUnit(TimeUnit.SECONDS) public class BooleanBenchmark { @Param("1000000") private int size; private List booleanString; private boolean[] booleans; @Setup public void s() { booleans = new boolean[size]; booleanString = new ArrayList(size); for (int index = 0; index < size; index++) { if (index % 2 == 0) { booleans[index] = true; booleanString.add(Boolean.TRUE.toString()); } else { booleans[index] = false; booleanString.add(Boolean.FALSE.toString()); } } } @GenerateMicroBenchmark public void valueOfBoolean(BlackHole bh) { for (boolean b : booleans) { Boolean result = b; bh.consume(result); } } @GenerateMicroBenchmark public void valueOfString(BlackHole bh) { for (String b : booleanString) { Boolean result = Boolean.valueOf(b); bh.consume(result); } } @GenerateMicroBenchmark public void newInstanceBoolean(BlackHole bh) { for (boolean b : booleans) { Boolean result = new Boolean(b); bh.consume(result); } } @GenerateMicroBenchmark public void newInstanceString(BlackHole bh) { for (String b : booleanString) { Boolean result = new Boolean(b); bh.consume(result); } } } Thanks, -Aleksey. [1] http://hg.openjdk.java.net/code-tools/jmh/file/75f8b23444f6/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java [2] http://hg.openjdk.java.net/code-tools/jmh/file/75f8b23444f6/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_09_Blackholes.java From otaviojava at java.net Sat May 24 18:52:58 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sat, 24 May 2014 15:52:58 -0300 Subject: Boolean valueOf instead of new Boolean In-Reply-To: <5380B88D.60009@oracle.com> References: <5380B88D.60009@oracle.com> Message-ID: Hi Alexis. Thank you for fixes the benchMarck. About the class GSSManagerImpl, yes it is necessary because the System.getProperty(USE_NATIVE_PROP) returns a String. On Sat, May 24, 2014 at 12:19 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 05/24/2014 06:34 PM, Ot?vio Gon?alves de Santana wrote: > > The Boolean class has cache for true and false and using it, will save > > memory and will faster than using create new instance of boolean. > > Using JMH[1] with a code test[2] the result was: > > I agree Boolean.valueOf (whether explicit or implicit) should be used if > identity is not required. Do you really need explicit Boolean.valueOf > in, say, GSSManagerImpl, instead of relying on autoboxing? > > That said, your benchmark is not correct. At very least, you have to use > explicit BlackHoles to avoid DCE [1][2]. This is how you do it: > > @State(Scope.Thread) > @OutputTimeUnit(TimeUnit.SECONDS) > public class BooleanBenchmark { > > @Param("1000000") > private int size; > > private List booleanString; > private boolean[] booleans; > > @Setup > public void s() { > booleans = new boolean[size]; > booleanString = new ArrayList(size); > > for (int index = 0; index < size; index++) { > if (index % 2 == 0) { > booleans[index] = true; > booleanString.add(Boolean.TRUE.toString()); > } else { > booleans[index] = false; > booleanString.add(Boolean.FALSE.toString()); > } > } > } > > @GenerateMicroBenchmark > public void valueOfBoolean(BlackHole bh) { > for (boolean b : booleans) { > Boolean result = b; > bh.consume(result); > } > } > > @GenerateMicroBenchmark > public void valueOfString(BlackHole bh) { > for (String b : booleanString) { > Boolean result = Boolean.valueOf(b); > bh.consume(result); > } > } > > @GenerateMicroBenchmark > public void newInstanceBoolean(BlackHole bh) { > for (boolean b : booleans) { > Boolean result = new Boolean(b); > bh.consume(result); > } > } > > @GenerateMicroBenchmark > public void newInstanceString(BlackHole bh) { > for (String b : booleanString) { > Boolean result = new Boolean(b); > bh.consume(result); > } > } > } > > Thanks, > -Aleksey. > > > [1] > > http://hg.openjdk.java.net/code-tools/jmh/file/75f8b23444f6/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_08_DeadCode.java > [2] > > http://hg.openjdk.java.net/code-tools/jmh/file/75f8b23444f6/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_09_Blackholes.java > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From andrej.golovnin at gmail.com Sat May 24 20:10:57 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Sat, 24 May 2014 22:10:57 +0200 Subject: Boolean valueOf instead of new Boolean In-Reply-To: References: Message-ID: <608EFFC1-9319-415D-977E-9A05DD7278FD@gmail.com> Hi Ot?vio, it would be nice, if you would not modify the classes sun.reflect.UnsafeXXXFieldAccessorImpl. This classes should be changed as a part of the fix for the issue JDK-5043030. The patch for this issue is already in work. Best regards, Andrej Golovnin On 24.05.2014, at 16:34, Ot?vio Gon?alves de Santana wrote: > The Boolean class has cache for true and false and using it, will save > memory and will faster than using create new instance of boolean. > Using JMH[1] with a code test[2] the result was: > Benchmark Mode Samples > Mean Mean error Units > m.BooleanBenchmark.newInstanceBoolean thrpt 20 49801.326 > 369.897 ops/s > m.BooleanBenchmark.newInstanceString thrpt 20 > 365.080 27.537 ops/s > m.BooleanBenchmark.valueOfBoolean thrpt 20 764906233.316 > 9623009.653 ops/s > m.BooleanBenchmark.valueOfString thrpt 20 > 371.174 28.216 ops/s > > > > The diff is on attachment or can is downloading the webdrev here: > https://dl.dropboxusercontent.com/u/16109193/open_jdk/boolean_instance_of.zip > > [1] http://openjdk.java.net/projects/code-tools/jmh/ > > [2] > > @State(Scope.Thread) > > @OutputTimeUnit(TimeUnit.SECONDS) > > public class BooleanBenchmark { > > private static final int SIZE = 1_000_000; > > private List booleanString; > > private boolean[] booleans; > > { > > booleans = new boolean[SIZE]; > > booleanString = new ArrayList<>(SIZE); > > for (int index = 0; index < SIZE; index++) { > > if (index % 2 == 0) { > > booleans[index] = true; > > booleanString.add(Boolean.TRUE.toString()); > > } else { > > booleans[index] = false; > > booleanString.add(Boolean.FALSE.toString()); > > } > > } > > } > > @GenerateMicroBenchmark > > public void valueOfBoolean() { > > > for(boolean b: booleans) { > > Boolean result = b; > > } > > } > > @GenerateMicroBenchmark > > public void valueOfString() { > > for(String b: booleanString) { > > Boolean result = Boolean.valueOf(b); > > } > > } > > @GenerateMicroBenchmark > > public void newInstanceBoolean() { > > > for(boolean b: booleans) { > > Boolean result = new Boolean(b); > > } > > } > > @GenerateMicroBenchmark > > public void newInstanceString() { > > for(String b: booleanString) { > > Boolean result = new Boolean(b); > > } > > } > > } > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > From otaviojava at java.net Sun May 25 05:08:36 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Sun, 25 May 2014 02:08:36 -0300 Subject: Boolean valueOf instead of new Boolean In-Reply-To: <608EFFC1-9319-415D-977E-9A05DD7278FD@gmail.com> References: <608EFFC1-9319-415D-977E-9A05DD7278FD@gmail.com> Message-ID: Really Happy to hear that. Done. On Sat, May 24, 2014 at 5:10 PM, Andrej Golovnin wrote: > Hi Ot?vio, > > it would be nice, if you would not modify the classes > sun.reflect.UnsafeXXXFieldAccessorImpl. > This classes should be changed as a part of the fix for the issue > JDK-5043030. > The patch for this issue is already in work. > > Best regards, > Andrej Golovnin > > On 24.05.2014, at 16:34, Ot?vio Gon?alves de Santana > wrote: > > > The Boolean class has cache for true and false and using it, will save > > memory and will faster than using create new instance of boolean. > > Using JMH[1] with a code test[2] the result was: > > Benchmark Mode > Samples > > Mean Mean error Units > > m.BooleanBenchmark.newInstanceBoolean thrpt 20 > 49801.326 > > 369.897 ops/s > > m.BooleanBenchmark.newInstanceString thrpt 20 > > 365.080 27.537 ops/s > > m.BooleanBenchmark.valueOfBoolean thrpt 20 > 764906233.316 > > 9623009.653 ops/s > > m.BooleanBenchmark.valueOfString thrpt 20 > > 371.174 28.216 ops/s > > > > > > > > The diff is on attachment or can is downloading the webdrev here: > > > https://dl.dropboxusercontent.com/u/16109193/open_jdk/boolean_instance_of.zip > > > > [1] http://openjdk.java.net/projects/code-tools/jmh/ > > > > [2] > > > > @State(Scope.Thread) > > > > @OutputTimeUnit(TimeUnit.SECONDS) > > > > public class BooleanBenchmark { > > > > private static final int SIZE = 1_000_000; > > > > private List booleanString; > > > > private boolean[] booleans; > > > > { > > > > booleans = new boolean[SIZE]; > > > > booleanString = new ArrayList<>(SIZE); > > > > for (int index = 0; index < SIZE; index++) { > > > > if (index % 2 == 0) { > > > > booleans[index] = true; > > > > booleanString.add(Boolean.TRUE.toString()); > > > > } else { > > > > booleans[index] = false; > > > > booleanString.add(Boolean.FALSE.toString()); > > > > } > > > > } > > > > } > > > > @GenerateMicroBenchmark > > > > public void valueOfBoolean() { > > > > > > for(boolean b: booleans) { > > > > Boolean result = b; > > > > } > > > > } > > > > @GenerateMicroBenchmark > > > > public void valueOfString() { > > > > for(String b: booleanString) { > > > > Boolean result = Boolean.valueOf(b); > > > > } > > > > } > > > > @GenerateMicroBenchmark > > > > public void newInstanceBoolean() { > > > > > > for(boolean b: booleans) { > > > > Boolean result = new Boolean(b); > > > > } > > > > } > > > > @GenerateMicroBenchmark > > > > public void newInstanceString() { > > > > for(String b: booleanString) { > > > > Boolean result = new Boolean(b); > > > > } > > > > } > > > > } > > > > -- > > Atenciosamente. > > > > Ot?vio Gon?alves de Santana > > > > blog: http://otaviosantana.blogspot.com.br/ > > twitter: http://twitter.com/otaviojava > > site: http://www.otaviojava.com.br > > (11) 98255-3513 > > > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 -------------- next part -------------- diff -r 28d1de89ff27 src/share/classes/java/net/Socket.java --- a/src/share/classes/java/net/Socket.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/java/net/Socket.java Sat May 24 10:55:43 2014 -0300 @@ -1017,7 +1017,7 @@ if (isClosed()) throw new SocketException("Socket is closed"); if (!on) { - getImpl().setOption(SocketOptions.SO_LINGER, new Boolean(on)); + getImpl().setOption(SocketOptions.SO_LINGER, on); } else { if (linger < 0) { throw new IllegalArgumentException("invalid value for SO_LINGER"); diff -r 28d1de89ff27 src/share/classes/sun/font/SunFontManager.java --- a/src/share/classes/sun/font/SunFontManager.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/font/SunFontManager.java Sat May 24 10:55:43 2014 -0300 @@ -2871,8 +2871,7 @@ new java.security.PrivilegedAction() { public Object run() { SecurityManager sm = System.getSecurityManager(); - return new Boolean - (sm instanceof sun.applet.AppletSecurity); + return sm instanceof sun.applet.AppletSecurity; } }); return appletSM.booleanValue(); diff -r 28d1de89ff27 src/share/classes/sun/management/StackTraceElementCompositeData.java --- a/src/share/classes/sun/management/StackTraceElementCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/StackTraceElementCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -68,7 +68,7 @@ ste.getMethodName(), ste.getFileName(), new Integer(ste.getLineNumber()), - new Boolean(ste.isNativeMethod()), + ste.isNativeMethod(), }; try { return new CompositeDataSupport(stackTraceElementCompositeType, diff -r 28d1de89ff27 src/share/classes/sun/management/ThreadInfoCompositeData.java --- a/src/share/classes/sun/management/ThreadInfoCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/ThreadInfoCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -120,8 +120,8 @@ new Long(threadInfo.getLockOwnerId()), threadInfo.getLockOwnerName(), stackTraceData, - new Boolean(threadInfo.isSuspended()), - new Boolean(threadInfo.isInNative()), + threadInfo.isSuspended(), + threadInfo.isInNative(), lockedMonitorsData, lockedSyncsData, }; diff -r 28d1de89ff27 src/share/classes/sun/management/VMOptionCompositeData.java --- a/src/share/classes/sun/management/VMOptionCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/VMOptionCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -59,7 +59,7 @@ final Object[] vmOptionItemValues = { option.getName(), option.getValue(), - new Boolean(option.isWriteable()), + option.isWriteable(), option.getOrigin().toString(), }; diff -r 28d1de89ff27 src/share/classes/sun/security/jgss/GSSManagerImpl.java --- a/src/share/classes/sun/security/jgss/GSSManagerImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/security/jgss/GSSManagerImpl.java Sat May 24 10:55:43 2014 -0300 @@ -50,8 +50,8 @@ if (osname.startsWith("SunOS") || osname.contains("OS X") || osname.startsWith("Linux")) { - return new Boolean(System.getProperty - (USE_NATIVE_PROP)); + return Boolean.valueOf(System.getProperty + (USE_NATIVE_PROP)); } return Boolean.FALSE; } diff -r 28d1de89ff27 src/share/classes/sun/security/provider/PolicyFile.java --- a/src/share/classes/sun/security/provider/PolicyFile.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat May 24 10:55:43 2014 -0300 @@ -1271,7 +1271,7 @@ Boolean imp = AccessController.doPrivileged (new PrivilegedAction() { public Boolean run() { - return new Boolean(entry.getCodeSource().implies(cs)); + return entry.getCodeSource().implies(cs); } }); if (!imp.booleanValue()) { From ivan.gerasimov at oracle.com Sun May 25 06:43:02 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 25 May 2014 10:43:02 +0400 Subject: RFR [8043476] java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space Message-ID: <538190F6.5090801@oracle.com> Hello! There was a bug in BitSet.toString() fixed with JDK-8040806. Unfortunately, the test that had come with this change started to fail with OOM. This is because it needs to create a BitSet with the bit Integer.MAX_VALUE set, so this BitSet occupies 256M. In particular, the test fails on 32-bit platforms. The proposed fix for this is: First, run in othervm mode, so we're sure that no other tests consume the heap space. And second, explicitly check that VM is able to allocate enough memory. Experiments showed that 380M seem to be the needed minimum, so I set the boundary to 512M. I've checked the updated test with JPRT on all available platforms, no failures. Would you please review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043476 WEBREV: http://cr.openjdk.java.net/~igerasim/8043476/0/webrev/ Sincerely yours, Ivan From luchsh at linux.vnet.ibm.com Mon May 26 09:04:38 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 26 May 2014 17:04:38 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX Message-ID: Hello, May I have following patch reviewed ? http://cr.openjdk.java.net/~luchsh/JDK-8043495/ The patch will add native FileChannelImpl.transferTo0() implementation for AIX by using the 'send_file' API, http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/send_file.htm?lang=en Thanks Jonathan From Alan.Bateman at oracle.com Mon May 26 10:09:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2014 11:09:53 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: Message-ID: <538312F1.10503@oracle.com> On 26/05/2014 10:04, Jonathan Lu wrote: > Hello, > > May I have following patch reviewed ? > > http://cr.openjdk.java.net/~luchsh/JDK-8043495/ > > > The patch will add native FileChannelImpl.transferTo0() implementation > for AIX > by using the 'send_file' API, > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/send_file.htm?lang=en Is the getsockopt needed to test the destination? I don't have access to a system with AIX and the man page you cite seems to detect this and give you the ENOTSOCK. Otherwise I don't see any issues with this, a minor consistent issue at L245 where it could be "< 0". Just looking at the OSX implementation just before this in the function and there is redundant ifdef __APPLE__. We could fix it with this patch or use another bug, I don't of course want to expand the scope of your change. -Alan From erik.joelsson at oracle.com Mon May 26 10:19:11 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 May 2014 12:19:11 +0200 Subject: RFR: 8043666: Remove unused files from jaxp repository In-Reply-To: <537F67D9.8090405@oracle.com> References: <537F67D9.8090405@oracle.com> Message-ID: <5383151F.5000109@oracle.com> Looks good to me, Joe. /Erik On 2014-05-23 17:23, huizhe wang wrote: > Removing unused files in jaxp repository. Most of them are > META-INF/services files used by Apache build process. The COPYING > files at the bottom came with SAX, but they are included in the > THIRD_PARTY_README file already. Please review. > > http://cr.openjdk.java.net/~joehw/jdk9/8043666/webrev/ > > Thanks, > Joe From Alan.Bateman at oracle.com Mon May 26 11:11:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2014 12:11:15 +0100 Subject: 8043958: Remove unused com.sun.pept classes from jdk repository Message-ID: <53832153.2080608@oracle.com> As part of modularity motivated clean-up, I'd like to remove the PEPt [1] classes from the jdk repository. The classes are excluded by the build so removing them should not have any impact. The removal not impact the copy of these classes in the corba repository (in a different package), these will continue to be compiled in with the CORBA code. The red webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8043958/webrev/ -Alan. [1] http://haroldcarr.net/computerScience/pept/indexPept.html From miroslav.kos at oracle.com Mon May 26 11:57:56 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 26 May 2014 13:57:56 +0200 Subject: RFR: 8043762: Remove unused files from jaxws repository Message-ID: <53832C44.6070400@oracle.com> Hi everybody, here is the request for review for 8043762: Remove unused files from jaxws repository JBS: https://bugs.openjdk.java.net/browse/JDK-8043762 webrev: http://cr.openjdk.java.net/~mkos/8043762/jaxws.01/ Simple fix removing unused files in jaxws repo, no tests necessary. Thanks Miran From Lance.Andersen at oracle.com Mon May 26 12:10:52 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 26 May 2014 08:10:52 -0400 Subject: RFR: 8043762: Remove unused files from jaxws repository In-Reply-To: <53832C44.6070400@oracle.com> References: <53832C44.6070400@oracle.com> Message-ID: +1 -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPhone On May 26, 2014, at 7:57 AM, Miroslav Kos wrote: > Hi everybody, > > here is the request for review for > > 8043762: Remove unused files from jaxws repository > JBS: https://bugs.openjdk.java.net/browse/JDK-8043762 > webrev: http://cr.openjdk.java.net/~mkos/8043762/jaxws.01/ > > Simple fix removing unused files in jaxws repo, no tests necessary. > > Thanks > Miran From Alan.Bateman at oracle.com Mon May 26 12:15:59 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2014 13:15:59 +0100 Subject: RFR: 8043762: Remove unused files from jaxws repository In-Reply-To: <53832C44.6070400@oracle.com> References: <53832C44.6070400@oracle.com> Message-ID: <5383307F.6070700@oracle.com> On 26/05/2014 12:57, Miroslav Kos wrote: > Hi everybody, > > here is the request for review for > > 8043762: Remove unused files from jaxws repository > JBS: https://bugs.openjdk.java.net/browse/JDK-8043762 > webrev: http://cr.openjdk.java.net/~mkos/8043762/jaxws.01/ > > Simple fix removing unused files in jaxws repo, no tests necessary. Thanks for doing this, the change looks good to me. -Alan. From Alan.Bateman at oracle.com Mon May 26 12:31:23 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2014 13:31:23 +0100 Subject: RFR [8043476] java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space In-Reply-To: <538190F6.5090801@oracle.com> References: <538190F6.5090801@oracle.com> Message-ID: <5383341B.7030604@oracle.com> On 25/05/2014 07:43, Ivan Gerasimov wrote: > Hello! > > There was a bug in BitSet.toString() fixed with JDK-8040806. > Unfortunately, the test that had come with this change started to fail > with OOM. > This is because it needs to create a BitSet with the bit > Integer.MAX_VALUE set, so this BitSet occupies 256M. > In particular, the test fails on 32-bit platforms. > > The proposed fix for this is: First, run in othervm mode, so we're > sure that no other tests consume the heap space. > And second, explicitly check that VM is able to allocate enough memory. > Experiments showed that 380M seem to be the needed minimum, so I set > the boundary to 512M. > > I've checked the updated test with JPRT on all available platforms, no > failures. > > Would you please review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043476 > WEBREV: http://cr.openjdk.java.net/~igerasim/8043476/0/webrev/ Skipping the this toString test when there isn't enough heap seems okay. Using 0x20_000_000 looks a bit odd though, might be clearer to define MB as 1024*1024 and then check 512*MB, no big deal of course. I assume the System.out was just for debugging, it looks misaligned and misleading to print "Ok" before the checks. -Alan From lance.andersen at oracle.com Mon May 26 13:02:10 2014 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Mon, 26 May 2014 09:02:10 -0400 Subject: 8043958: Remove unused com.sun.pept classes from jdk repository In-Reply-To: <53832153.2080608@oracle.com> References: <53832153.2080608@oracle.com> Message-ID: +1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad On May 26, 2014, at 7:11 AM, Alan Bateman wrote: > > As part of modularity motivated clean-up, I'd like to remove the PEPt [1] classes from the jdk repository. The classes are excluded by the build so removing them should not have any impact. The removal not impact the copy of these classes in the corba repository (in a different package), these will continue to be compiled in with the CORBA code. > > The red webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8043958/webrev/ > > -Alan. > > [1] http://haroldcarr.net/computerScience/pept/indexPept.html From ivan.gerasimov at oracle.com Mon May 26 13:31:22 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 26 May 2014 17:31:22 +0400 Subject: RFR [8043476] java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space In-Reply-To: <5383341B.7030604@oracle.com> References: <538190F6.5090801@oracle.com> <5383341B.7030604@oracle.com> Message-ID: <5383422A.8070007@oracle.com> Thank you Alan! On 26.05.2014 16:31, Alan Bateman wrote: > On 25/05/2014 07:43, Ivan Gerasimov wrote: >> Hello! >> >> There was a bug in BitSet.toString() fixed with JDK-8040806. >> Unfortunately, the test that had come with this change started to >> fail with OOM. >> This is because it needs to create a BitSet with the bit >> Integer.MAX_VALUE set, so this BitSet occupies 256M. >> In particular, the test fails on 32-bit platforms. >> >> The proposed fix for this is: First, run in othervm mode, so we're >> sure that no other tests consume the heap space. >> And second, explicitly check that VM is able to allocate enough memory. >> Experiments showed that 380M seem to be the needed minimum, so I set >> the boundary to 512M. >> >> I've checked the updated test with JPRT on all available platforms, >> no failures. >> >> Would you please review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8043476 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8043476/0/webrev/ > Skipping the this toString test when there isn't enough heap seems okay. > Using 0x20_000_000 looks a bit odd though, might be clearer to define > MB as 1024*1024 and then check 512*MB, no big deal of course. I'll change it as you suggest. > I assume the System.out was just for debugging, it looks misaligned > and misleading to print "Ok" before the checks. > Sure, it was for debugging only, I'll remove it. Sincerely yours, Ivan > -Alan > > From info at kliemeck.de Mon May 26 16:50:12 2014 From: info at kliemeck.de (info at kliemeck.de) Date: Mon, 26 May 2014 18:50:12 +0200 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <537A08D0.9030404@oracle.com> References: <537A08D0.9030404@oracle.com> Message-ID: <20140526185012.Horde.pqzOumYEioNbp1Op6FWtNw7@webmail.your-server.de> Hey Miroslav, is this correct that the issue will be fixed on jdk9 only (as stated on https://bugs.openjdk.java.net/browse/JDK-8043129). Since this is a major loss of functionality which we encountered too, this should be fixed with the next jdk 7 release. Regards Hajo Quoting miroslav.kos at oracle.com: > Hi, > this is review request for: > > 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail > > JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 > WEBREV: > http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ > http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) > > This solves conflict between JAF handlers for JAX-WS and javax.mail. The > issue has been introduced in the latest CPU. > > Thanks > Miran From luchsh at linux.vnet.ibm.com Tue May 27 06:31:49 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 27 May 2014 14:31:49 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <538312F1.10503@oracle.com> References: <538312F1.10503@oracle.com> Message-ID: Hi Alan, Thank you for the comments, here's the updated webrev, http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ On Mon, May 26, 2014 at 6:09 PM, Alan Bateman wrote: > On 26/05/2014 10:04, Jonathan Lu wrote: > >> Hello, >> >> May I have following patch reviewed ? >> >> http://cr.openjdk.java.net/~luchsh/JDK-8043495/ < >> http://cr.openjdk.java.net/%7Eluchsh/JDK-8043495/> >> >> >> The patch will add native FileChannelImpl.transferTo0() implementation >> for AIX >> by using the 'send_file' API, >> http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/ >> com.ibm.aix.commtrf2/send_file.htm?lang=en >> > Is the getsockopt needed to test the destination? I don't have access to a > system with AIX and the man page you cite seems to detect this and give you > the ENOTSOCK. > Agree, the updated patch has removed getsockopt and will check ENOTSOCK if send_file() reports error (-1). > > Otherwise I don't see any issues with this, a minor consistent issue at > L245 where it could be "< 0". > Fixed in the updated patch. > > Just looking at the OSX implementation just before this in the function > and there is redundant ifdef __APPLE__. We could fix it with this patch or > use another bug, I don't of course want to expand the scope of your change. > I'm OK with this minor removal and have done that in the second patch, please review. > > -Alan > > > Thanks Jonathan From Alan.Bateman at oracle.com Tue May 27 06:49:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 07:49:27 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: <538312F1.10503@oracle.com> Message-ID: <53843577.8050709@oracle.com> On 27/05/2014 07:31, Jonathan Lu wrote: > Hi Alan, > > Thank you for the comments, here's the updated webrev, > http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ > Thanks for the updates and for including the the ifdef __APPLE__ change. With the getsockopt removed then maybe socket.h is not needed now? Otherwise looks good to me. -Alan. From volker.simonis at gmail.com Tue May 27 08:49:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 May 2014 10:49:46 +0200 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <53843577.8050709@oracle.com> References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> Message-ID: On Tue, May 27, 2014 at 8:49 AM, Alan Bateman wrote: > On 27/05/2014 07:31, Jonathan Lu wrote: >> >> Hi Alan, >> >> Thank you for the comments, here's the updated webrev, >> http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ >> > > Thanks for the updates and for including the the ifdef __APPLE__ change. > With the getsockopt removed then maybe socket.h is not needed now? Otherwise > looks good to me. 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. The change looks good to me as well. Thanks for contributing it! Is there any test which exercises this code? Regards, Volker > > -Alan. From Alan.Bateman at oracle.com Tue May 27 09:00:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 10:00:08 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> Message-ID: <53845418.606@oracle.com> On 27/05/2014 09:49, Volker Simonis wrote: > : > 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. Thanks, just checking. > : > > > Is there any test which exercises this code? > The tests in java/nio/channels/FileChannel are the tests to run, they will give the transfer methods a good work out. -Alan. From chuanshenglu at gmail.com Tue May 27 09:43:37 2014 From: chuanshenglu at gmail.com (Jonathan Lu) Date: Tue, 27 May 2014 17:43:37 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <53845418.606@oracle.com> References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> <53845418.606@oracle.com> Message-ID: Thanks, Alan and Volker! I will push this change. Regards, Jonathan On Tue, May 27, 2014 at 5:00 PM, Alan Bateman wrote: > On 27/05/2014 09:49, Volker Simonis wrote: > >> : >> 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. >> > Thanks, just checking. > > > : >> >> >> Is there any test which exercises this code? >> >> The tests in java/nio/channels/FileChannel are the tests to run, they > will give the transfer methods a good work out. > > -Alan. > From vladimir.x.ivanov at oracle.com Tue May 27 13:19:30 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 27 May 2014 17:19:30 +0400 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error Message-ID: <538490E2.2090102@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8035186 http://cr.openjdk.java.net/~vlivanov/8035186/webrev.00/ LogGeneratedClassesTest.testDumpDirNotWritable is not applicable when it is run by super user on Linux/Solaris. The test checks that it's forbidden to create files in read-only directory, but super user is allowed to do so. The fix is to skip the test in such configuration. Testing: ran the test by super user on Solaris/Linux. Best regards, Vladimir Ivanov From Alan.Bateman at oracle.com Tue May 27 13:30:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 14:30:54 +0100 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <537E546C.80307@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E1141.2050100@oracle.com> <537E546C.80307@oracle.com> Message-ID: <5384938E.5030906@oracle.com> On 22/05/2014 20:47, roger riggs wrote: > Thanks for the feedback and recommendations; the webrev has been updated. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ > > Alan, on the use of tasklist, I think a cleaner test can be written > when the > Java API to inspect other processes is available. I did not find a > straightforward > eqivalent for $$; there is a possible hack using tasklist but it would > be a throwaway. > > Roger > The updated webrev looks good to me. On tasklist then what you have is fine for now, it can always be re-visited if it gives trouble or there is an API available. -Alan. From paul.sandoz at oracle.com Tue May 27 13:35:14 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 27 May 2014 15:35:14 +0200 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error In-Reply-To: <538490E2.2090102@oracle.com> References: <538490E2.2090102@oracle.com> Message-ID: <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> Hi, I am wondering if it may be more reliable to attempt creation of a new file in the read only directory rather than checking for the "root" user name? Paul. On May 27, 2014, at 3:19 PM, Vladimir Ivanov wrote: > https://bugs.openjdk.java.net/browse/JDK-8035186 > http://cr.openjdk.java.net/~vlivanov/8035186/webrev.00/ > > LogGeneratedClassesTest.testDumpDirNotWritable is not applicable when it is run by super user on Linux/Solaris. The test checks that it's forbidden to create files in read-only directory, but super user is allowed to do so. > > The fix is to skip the test in such configuration. > > Testing: ran the test by super user on Solaris/Linux. > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue May 27 13:53:05 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 27 May 2014 17:53:05 +0400 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error In-Reply-To: <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> References: <538490E2.2090102@oracle.com> <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> Message-ID: <538498C1.5080909@oracle.com> Paul, What you suggest is much cleaner. Thanks! Updated version: http://cr.openjdk.java.net/~vlivanov/8035186/webrev.01/ Best regards, Vladimir Ivanov On 5/27/14 5:35 PM, Paul Sandoz wrote: > Hi, > > I am wondering if it may be more reliable to attempt creation of a new file in the read only directory rather than checking for the "root" user name? > > Paul. > > On May 27, 2014, at 3:19 PM, Vladimir Ivanov wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8035186 >> http://cr.openjdk.java.net/~vlivanov/8035186/webrev.00/ >> >> LogGeneratedClassesTest.testDumpDirNotWritable is not applicable when it is run by super user on Linux/Solaris. The test checks that it's forbidden to create files in read-only directory, but super user is allowed to do so. >> >> The fix is to skip the test in such configuration. >> >> Testing: ran the test by super user on Solaris/Linux. >> >> Best regards, >> Vladimir Ivanov > From paul.sandoz at oracle.com Tue May 27 15:07:32 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 27 May 2014 17:07:32 +0200 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error In-Reply-To: <538498C1.5080909@oracle.com> References: <538490E2.2090102@oracle.com> <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> <538498C1.5080909@oracle.com> Message-ID: <1F4BB8AF-F2A4-472F-9489-A49368399FCC@oracle.com> On May 27, 2014, at 3:53 PM, Vladimir Ivanov wrote: > Paul, > > What you suggest is much cleaner. Thanks! > > Updated version: > http://cr.openjdk.java.net/~vlivanov/8035186/webrev.01/ > Don't you need to trap the exception? e.g.: try { Path test = Paths.get("readOnly/test"); Files.createFile(test); // Running with privileged permissions; cannot test; clean up and return } catch (AccessDeniedException ade) { // Continue with the test } Paul. From vladimir.x.ivanov at oracle.com Tue May 27 16:16:37 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 27 May 2014 20:16:37 +0400 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error In-Reply-To: <1F4BB8AF-F2A4-472F-9489-A49368399FCC@oracle.com> References: <538490E2.2090102@oracle.com> <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> <538498C1.5080909@oracle.com> <1F4BB8AF-F2A4-472F-9489-A49368399FCC@oracle.com> Message-ID: <5384BA65.6020206@oracle.com> Good catch! One more iteration: http://cr.openjdk.java.net/~vlivanov/8035186/webrev.02/ Best regards, Vladimir Ivanov On 5/27/14 7:07 PM, Paul Sandoz wrote: > > On May 27, 2014, at 3:53 PM, Vladimir Ivanov wrote: > >> Paul, >> >> What you suggest is much cleaner. Thanks! >> >> Updated version: >> http://cr.openjdk.java.net/~vlivanov/8035186/webrev.01/ >> > > Don't you need to trap the exception? e.g.: > > try { > Path test = Paths.get("readOnly/test"); > Files.createFile(test); > // Running with privileged permissions; cannot test; clean up and return > } catch (AccessDeniedException ade) { > // Continue with the test > } > > Paul. > From martinrb at google.com Tue May 27 16:57:10 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 27 May 2014 09:57:10 -0700 Subject: RFR 9: 8003488 Add Process.getPid In-Reply-To: <5384938E.5030906@oracle.com> References: <53712498.20603@oracle.com> <537136AA.8090807@oracle.com> <5373CC2A.8060704@oracle.com> <537E0055.2090302@oracle.com> <537E1141.2050100@oracle.com> <537E546C.80307@oracle.com> <5384938E.5030906@oracle.com> Message-ID: Looks good to me too (but I'm sure Alan did a more careful review than I). On Tue, May 27, 2014 at 6:30 AM, Alan Bateman wrote: > On 22/05/2014 20:47, roger riggs wrote: > >> Thanks for the feedback and recommendations; the webrev has been updated. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ >> >> Alan, on the use of tasklist, I think a cleaner test can be written when >> the >> Java API to inspect other processes is available. I did not find a >> straightforward >> eqivalent for $$; there is a possible hack using tasklist but it would be >> a throwaway. >> >> Roger >> >> The updated webrev looks good to me. On tasklist then what you have is > fine for now, it can always be re-visited if it gives trouble or there is > an API available. > > -Alan. > > From otaviopolianasantana at gmail.com Tue May 27 17:16:33 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 27 May 2014 14:16:33 -0300 Subject: Boolean valueOf instead of new Boolean In-Reply-To: References: <608EFFC1-9319-415D-977E-9A05DD7278FD@gmail.com> Message-ID: Can anyone help me as sponsor? On May 25, 2014 2:08 AM, "Ot?vio Gon?alves de Santana" wrote: > Really Happy to hear that. > Done. > > > On Sat, May 24, 2014 at 5:10 PM, Andrej Golovnin < > andrej.golovnin at gmail.com> wrote: > >> Hi Ot?vio, >> >> it would be nice, if you would not modify the classes >> sun.reflect.UnsafeXXXFieldAccessorImpl. >> This classes should be changed as a part of the fix for the issue >> JDK-5043030. >> The patch for this issue is already in work. >> >> Best regards, >> Andrej Golovnin >> >> On 24.05.2014, at 16:34, Ot?vio Gon?alves de Santana >> wrote: >> >> > The Boolean class has cache for true and false and using it, will save >> > memory and will faster than using create new instance of boolean. >> > Using JMH[1] with a code test[2] the result was: >> > Benchmark Mode >> Samples >> > Mean Mean error Units >> > m.BooleanBenchmark.newInstanceBoolean thrpt 20 >> 49801.326 >> > 369.897 ops/s >> > m.BooleanBenchmark.newInstanceString thrpt 20 >> > 365.080 27.537 ops/s >> > m.BooleanBenchmark.valueOfBoolean thrpt 20 >> 764906233.316 >> > 9623009.653 ops/s >> > m.BooleanBenchmark.valueOfString thrpt 20 >> > 371.174 28.216 ops/s >> > >> > >> > >> > The diff is on attachment or can is downloading the webdrev here: >> > >> https://dl.dropboxusercontent.com/u/16109193/open_jdk/boolean_instance_of.zip >> > >> > [1] http://openjdk.java.net/projects/code-tools/jmh/ >> > >> > [2] >> > >> > @State(Scope.Thread) >> > >> > @OutputTimeUnit(TimeUnit.SECONDS) >> > >> > public class BooleanBenchmark { >> > >> > private static final int SIZE = 1_000_000; >> > >> > private List booleanString; >> > >> > private boolean[] booleans; >> > >> > { >> > >> > booleans = new boolean[SIZE]; >> > >> > booleanString = new ArrayList<>(SIZE); >> > >> > for (int index = 0; index < SIZE; index++) { >> > >> > if (index % 2 == 0) { >> > >> > booleans[index] = true; >> > >> > booleanString.add(Boolean.TRUE.toString()); >> > >> > } else { >> > >> > booleans[index] = false; >> > >> > booleanString.add(Boolean.FALSE.toString()); >> > >> > } >> > >> > } >> > >> > } >> > >> > @GenerateMicroBenchmark >> > >> > public void valueOfBoolean() { >> > >> > >> > for(boolean b: booleans) { >> > >> > Boolean result = b; >> > >> > } >> > >> > } >> > >> > @GenerateMicroBenchmark >> > >> > public void valueOfString() { >> > >> > for(String b: booleanString) { >> > >> > Boolean result = Boolean.valueOf(b); >> > >> > } >> > >> > } >> > >> > @GenerateMicroBenchmark >> > >> > public void newInstanceBoolean() { >> > >> > >> > for(boolean b: booleans) { >> > >> > Boolean result = new Boolean(b); >> > >> > } >> > >> > } >> > >> > @GenerateMicroBenchmark >> > >> > public void newInstanceString() { >> > >> > for(String b: booleanString) { >> > >> > Boolean result = new Boolean(b); >> > >> > } >> > >> > } >> > >> > } >> > >> > -- >> > Atenciosamente. >> > >> > Ot?vio Gon?alves de Santana >> > >> > blog: http://otaviosantana.blogspot.com.br/ >> > twitter: http://twitter.com/otaviojava >> > site: http://www.otaviojava.com.br >> > (11) 98255-3513 >> > >> >> > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > > From otaviopolianasantana at gmail.com Tue May 27 17:17:01 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Tue, 27 May 2014 14:17:01 -0300 Subject: inefficient indexof when String has one length In-Reply-To: <8AEA68DB-8351-4EE1-8D3D-0EB9D475FA70@oracle.com> References: <8AEA68DB-8351-4EE1-8D3D-0EB9D475FA70@oracle.com> Message-ID: Can anyone help me as sponsor? On May 12, 2014 1:57 PM, "Paul Sandoz" wrote: > On Apr 26, 2014, at 12:56 PM, Ot?vio Gon?alves de Santana < > otaviojava at java.net> wrote: > > When a String has length just one, could be replaced by equivalent > > character literals, gaining some performance enhancement. > > > > I found 107 changes. > > > > This looks good to me, just one small issue: > > --- > a/src/share/classes/javax/security/auth/PrivateCredentialPermission.java > Wed Apr 23 11:35:40 2014 -0700 > +++ > b/src/share/classes/javax/security/auth/PrivateCredentialPermission.java > Sat Apr 26 07:31:04 2014 -0300 > @@ -495,7 +495,7 @@ > > // perform new initialization from the permission name > > - if (getName().indexOf(" ") == -1 && getName().indexOf("\"") == > -1) { > + if (getName().indexOf(' ') == -1 && getName().indexOf('\"') == > -1) { > > You no longer need to escape the double quote. > > Can someone else sponsor this? unfortunately i do not have the time at the > moment. > > Paul. > From roger.riggs at oracle.com Tue May 27 18:02:34 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 27 May 2014 14:02:34 -0400 Subject: Boolean valueOf instead of new Boolean In-Reply-To: References: <608EFFC1-9319-415D-977E-9A05DD7278FD@gmail.com> Message-ID: <5384D33A.9050202@oracle.com> Hi Ot?vio, I can sponsor these two (Boolean and single char strings) for you. Because they cross over different repositories and require different reviews it would be more convenient to process each of them in two batches (client vs core) Please can you break out the 'client' changes into a separate webrev? The client packages are: (java and javax...) java2d, awt, swing, font, print, beans, media, imageio, applet, sound and accessibility. The client webrevs should be posted to awt-dev and the other two to core-libs, net-dev and servicability-dev. Thanks, Roger On 5/27/2014 1:16 PM, Ot?vio Gon?alves de Santana wrote: > Can anyone help me as sponsor? > On May 25, 2014 2:08 AM, "Ot?vio Gon?alves de Santana" > wrote: > > From jeremymanson at google.com Tue May 27 20:09:15 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 27 May 2014 13:09:15 -0700 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation Message-ID: Just like the title says - every time you generate a new private key, you leak a little memory. Webrev here: http://cr.openjdk.java.net/~jmanson/8044059/webrev/ This is probably the wrong mailing list for this bug, but I expect someone on this list will point me in the right direction. Jeremy From vincent.x.ryan at oracle.com Tue May 27 20:55:59 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 27 May 2014 21:55:59 +0100 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: References: Message-ID: Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your fix if you wish. On 27 May 2014, at 21:09, Jeremy Manson wrote: > Just like the title says - every time you generate a new private key, you > leak a little memory. Webrev here: > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ > > This is probably the wrong mailing list for this bug, but I expect someone > on this list will point me in the right direction. > > Jeremy From jeremymanson at google.com Tue May 27 21:18:35 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 27 May 2014 14:18:35 -0700 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: References: Message-ID: Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in? Jeremy On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan wrote: > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your > fix if you wish. > > On 27 May 2014, at 21:09, Jeremy Manson wrote: > > > Just like the title says - every time you generate a new private key, you > > leak a little memory. Webrev here: > > > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ > > > > This is probably the wrong mailing list for this bug, but I expect > someone > > on this list will point me in the right direction. > > > > Jeremy > > From huizhe.wang at oracle.com Tue May 27 22:36:06 2014 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 27 May 2014 15:36:06 -0700 Subject: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE In-Reply-To: <5384F9B2.6020207@oracle.com> References: <537ED956.3040200@oracle.com> <5384CF6D.7090601@oracle.com> <5384ED8E.4070102@oracle.com> <5384F9B2.6020207@oracle.com> Message-ID: <53851356.1070201@oracle.com> Thanks Sherman! On 5/27/2014 1:46 PM, Xueming Shen wrote: > One more nit, > > ln#2876-2879 > > Do we really need to create a new ReaderUTF8, if the encoding is > indeed is utf8? > which I would assume should be true for most use scenarios. Maybe the > following > would be better? > > // Encoding is defined by the xml text decl. > reader = enc("UTF-8", is.getByteStream()); > expenc = xml(reader); > if (!expenc.equals("UTF-8")) { > if (expenc.startsWith("UTF-16")) { > panic(FAULT); // UTF-16 must have BOM [#4.3.3] > } > reader = enc(expenc, is.getByteStream()); > } Updated to reflect the above suggestion: http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/. For the performance improvement, I'll create a new bug to track it. Reading is buffered in the regular jaxp parser than the UKit one. It would be nice if the benchmark had a separate measurement in parsing performance. We currently have indirect measurement through validation and transform. Buffer size will affect performance, UKit sets the default to 512 (but actually read byte by byte from the underlying stream as you noted), while jaxp parser default to 8k. For a small parser such as UKit, it may make sense to use a smaller buffer. -Joe > > -Sherman > > On 05/27/2014 12:54 PM, Xueming Shen wrote: >> On 05/27/2014 10:46 AM, huizhe wang wrote: >>> Hi, >>> >>> Are you okay with the updated patch? >>> >>> Thanks, >>> Joe >>> >> >> looks fine for me. >> >> Btw, if I took a quick look at the UTF8 reader, my observation >> suggests read byte by byte >> from the underlying stream probably is the bottleneck of the overall >> "parsing". Attached >> is a buffered the version, my simple test (just the parsing, use the >> default handler do noting) >> indicates it might double the parsing speed. Sure the overall >> performance will depends on >> the individual handler, but it might worth considering, any second >> counts :-) The code is >> not fully tested though, just for your reference. >> >> -Sherman >> >> package jdk.internal.util.xml.impl; >> >> import java.io.Reader; >> import java.io.InputStream; >> import java.io.IOException; >> import java.io.UnsupportedEncodingException; >> >> /** >> * UTF-8 transformed UCS-2 character stream reader. >> * >> * This reader converts UTF-8 transformed UCS-2 characters to Java >> characters. >> * The UCS-2 subset of UTF-8 transformation is described in RFC-2279 #2 >> * "UTF-8 definition": >> * 0000 0000-0000 007F 0xxxxxxx >> * 0000 0080-0000 07FF 110xxxxx 10xxxxxx >> * 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx >> * >> * This reader will return incorrect last character on broken UTF-8 >> stream. >> */ >> public class ReaderUTF8 extends Reader { >> >> private InputStream is; >> >> private static int DEFAULT_BUFFER_SIZE = 8192; >> private byte buf[]; >> private int pos, limit; >> >> /** >> * Constructor. >> * >> * @param is A byte input stream. >> */ >> public ReaderUTF8(InputStream is) { >> this.is = is; >> this.buf = new byte[DEFAULT_BUFFER_SIZE]; >> this.pos = limit = 0; >> } >> >> private void fill() throws IOException { >> if (pos >= buf.length) { // no room left in buffer >> pos = limit = 0; >> } >> int n = is.read(buf, pos, buf.length - pos); >> if (n > 0) { >> limit = n + pos; >> } >> } >> >> /** >> * Reads characters into a portion of an array. >> * >> * @param cbuf Destination buffer. >> * @param off Offset at which to start storing characters. >> * @param len Maximum number of characters to read. >> * @exception IOException If any IO errors occur. >> * @exception UnsupportedEncodingException If UCS-4 character >> occur in the stream. >> */ >> public int read(char[] cbuf, int off, int len) throws IOException { >> int off0 = off; >> int end = off + len; >> while (off < len) { >> if (pos >= limit) { >> fill(); >> if (pos >= limit) { >> return (off != off0) ? off - off0 : -1; >> } >> } >> int val = buf[pos] & 0xff; >> if (val >= 0x80) { >> break; >> } >> cbuf[off++] = (char) val; >> pos++; >> } >> while (off < end) { >> if (pos >= limit) { >> fill(); >> if (pos >= limit) { >> return (off != off0) ? off - off0 : -1; >> } >> } >> int val = buf[pos++] & 0xff; >> switch (val & 0xf0) { >> case 0xc0: >> case 0xd0: >> if (pos >= limit) { >> fill(); >> } >> if (pos >= limit) { >> cbuf[off++] = (char) (((val & 0x1f) << 6) | >> (is.read() & 0x3f)); >> } else { >> cbuf[off++] = (char) (((val & 0x1f) << 6) | >> (buf[pos++] & 0x3f)); >> } >> break; >> case 0xe0: >> if (pos >= limit) { >> fill(); >> } >> val = (val & 0x0f) << 12; >> if (pos >= limit) { >> val |= ((is.read() & 0x3f) << 6); >> } else { >> val |= ((buf[pos++] & 0x3f) << 6); >> } >> if (pos >= limit) { >> val |= (buf[pos++] & 0x3f); >> } else { >> val |= (is.read() & 0x3f); >> } >> cbuf[off++] = (char) val; >> break; >> case 0xf0: // UCS-4 character >> throw new UnsupportedEncodingException("UTF-32 >> (or UCS-4) encoding not supported."); >> default: >> cbuf[off++] = (char) val; >> break; >> } >> } >> return off - off0; >> >> } >> >> /** >> * Reads a single character. >> * >> * @return The character read, as an integer in the range 0 to 65535 >> * (0x00-0xffff), or -1 if the end of the stream has been reached. >> * @exception IOException If any IO errors occur. >> * @exception UnsupportedEncodingException If UCS-4 character >> occur in the stream. >> */ >> public int read() throws IOException { >> int val; >> if (pos >= limit) { >> val = is.read(); >> } else { >> val = buf[pos++] & 0xff; >> } >> switch (val & 0xf0) { >> case 0xc0: >> case 0xd0: >> if (pos >= limit) { >> val = ((val & 0x1f) << 6) | (is.read() & 0x3f); >> } else { >> val = ((val & 0x1f) << 6) | (buf[pos++] & 0x3f); >> } >> break; >> case 0xe0: >> val = (val & 0x0f) << 12; >> if (pos >= limit) { >> val |= ((is.read() & 0x3f) << 6); >> } else { >> val |= ((buf[pos++] & 0x3f) << 6); >> } >> if (pos >= limit) { >> val |= (is.read() & 0x3f); >> } else { >> val |= (buf[pos++] & 0x3f); >> } >> break; >> case 0xf0: // UCS-4 character >> throw new UnsupportedEncodingException(); >> default: >> break; >> } >> return val; >> } >> >> /** >> * Closes the stream. >> * >> * @exception IOException If any IO errors occur. >> */ >> public void close() throws IOException { >> is.close(); >> } >> } >> > From kumar.x.srinivasan at oracle.com Tue May 27 23:20:52 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 27 May 2014 16:20:52 -0700 Subject: Please review: 8044046: [asm] refresh internal ASM version to v5.0.3 Message-ID: <53851DD4.30806@oracle.com> Hello, Please review the following webrev which updates internal ASM to v5.0.3, the individual bug fixes are listed in the JBS issue for reference, https://bugs.openjdk.java.net/browse/JDK-8044046#comment-13501358 All core regression tests have been run, additionally nashorn regressions, test262parallel, octane, and all applicable JFR related tests have also been run. https://bugs.openjdk.java.net/browse/JDK-8044046 http://cr.openjdk.java.net/~ksrini/8044046/jdk9/webrev.00/ Thanks Kumar From xueming.shen at oracle.com Tue May 27 23:42:07 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 27 May 2014 16:42:07 -0700 Subject: RFR: 8043592: The basic XML parser based on UKit fails to read XML files encoded in UTF-16BE or LE In-Reply-To: <53851356.1070201@oracle.com> References: <537ED956.3040200@oracle.com> <5384CF6D.7090601@oracle.com> <5384ED8E.4070102@oracle.com> <5384F9B2.6020207@oracle.com> <53851356.1070201@oracle.com> Message-ID: <538522CF.4060702@oracle.com> looks good. -Sherman On 5/27/14 3:36 PM, huizhe wang wrote: > Thanks Sherman! > > On 5/27/2014 1:46 PM, Xueming Shen wrote: >> One more nit, >> >> ln#2876-2879 >> >> Do we really need to create a new ReaderUTF8, if the encoding is >> indeed is utf8? >> which I would assume should be true for most use scenarios. Maybe the >> following >> would be better? >> >> // Encoding is defined by the xml text decl. >> reader = enc("UTF-8", is.getByteStream()); >> expenc = xml(reader); >> if (!expenc.equals("UTF-8")) { >> if (expenc.startsWith("UTF-16")) { >> panic(FAULT); // UTF-16 must have BOM [#4.3.3] >> } >> reader = enc(expenc, is.getByteStream()); >> } > > Updated to reflect the above suggestion: > http://cr.openjdk.java.net/~joehw/jdk9/8043592/webrev/. > > > For the performance improvement, I'll create a new bug to track it. > Reading is buffered in the regular jaxp parser than the UKit one. It > would be nice if the benchmark had a separate measurement in parsing > performance. We currently have indirect measurement through validation > and transform. > > Buffer size will affect performance, UKit sets the default to 512 (but > actually read byte by byte from the underlying stream as you noted), > while jaxp parser default to 8k. For a small parser such as UKit, it > may make sense to use a smaller buffer. > > -Joe > >> >> -Sherman >> >> On 05/27/2014 12:54 PM, Xueming Shen wrote: >>> On 05/27/2014 10:46 AM, huizhe wang wrote: >>>> Hi, >>>> >>>> Are you okay with the updated patch? >>>> >>>> Thanks, >>>> Joe >>>> >>> >>> looks fine for me. >>> >>> Btw, if I took a quick look at the UTF8 reader, my observation >>> suggests read byte by byte >>> from the underlying stream probably is the bottleneck of the overall >>> "parsing". Attached >>> is a buffered the version, my simple test (just the parsing, use the >>> default handler do noting) >>> indicates it might double the parsing speed. Sure the overall >>> performance will depends on >>> the individual handler, but it might worth considering, any second >>> counts :-) The code is >>> not fully tested though, just for your reference. >>> >>> -Sherman >>> >>> package jdk.internal.util.xml.impl; >>> >>> import java.io.Reader; >>> import java.io.InputStream; >>> import java.io.IOException; >>> import java.io.UnsupportedEncodingException; >>> >>> /** >>> * UTF-8 transformed UCS-2 character stream reader. >>> * >>> * This reader converts UTF-8 transformed UCS-2 characters to Java >>> characters. >>> * The UCS-2 subset of UTF-8 transformation is described in RFC-2279 #2 >>> * "UTF-8 definition": >>> * 0000 0000-0000 007F 0xxxxxxx >>> * 0000 0080-0000 07FF 110xxxxx 10xxxxxx >>> * 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx >>> * >>> * This reader will return incorrect last character on broken UTF-8 >>> stream. >>> */ >>> public class ReaderUTF8 extends Reader { >>> >>> private InputStream is; >>> >>> private static int DEFAULT_BUFFER_SIZE = 8192; >>> private byte buf[]; >>> private int pos, limit; >>> >>> /** >>> * Constructor. >>> * >>> * @param is A byte input stream. >>> */ >>> public ReaderUTF8(InputStream is) { >>> this.is = is; >>> this.buf = new byte[DEFAULT_BUFFER_SIZE]; >>> this.pos = limit = 0; >>> } >>> >>> private void fill() throws IOException { >>> if (pos >= buf.length) { // no room left in buffer >>> pos = limit = 0; >>> } >>> int n = is.read(buf, pos, buf.length - pos); >>> if (n > 0) { >>> limit = n + pos; >>> } >>> } >>> >>> /** >>> * Reads characters into a portion of an array. >>> * >>> * @param cbuf Destination buffer. >>> * @param off Offset at which to start storing characters. >>> * @param len Maximum number of characters to read. >>> * @exception IOException If any IO errors occur. >>> * @exception UnsupportedEncodingException If UCS-4 character >>> occur in the stream. >>> */ >>> public int read(char[] cbuf, int off, int len) throws IOException { >>> int off0 = off; >>> int end = off + len; >>> while (off < len) { >>> if (pos >= limit) { >>> fill(); >>> if (pos >= limit) { >>> return (off != off0) ? off - off0 : -1; >>> } >>> } >>> int val = buf[pos] & 0xff; >>> if (val >= 0x80) { >>> break; >>> } >>> cbuf[off++] = (char) val; >>> pos++; >>> } >>> while (off < end) { >>> if (pos >= limit) { >>> fill(); >>> if (pos >= limit) { >>> return (off != off0) ? off - off0 : -1; >>> } >>> } >>> int val = buf[pos++] & 0xff; >>> switch (val & 0xf0) { >>> case 0xc0: >>> case 0xd0: >>> if (pos >= limit) { >>> fill(); >>> } >>> if (pos >= limit) { >>> cbuf[off++] = (char) (((val & 0x1f) << 6) | >>> (is.read() & 0x3f)); >>> } else { >>> cbuf[off++] = (char) (((val & 0x1f) << 6) | >>> (buf[pos++] & 0x3f)); >>> } >>> break; >>> case 0xe0: >>> if (pos >= limit) { >>> fill(); >>> } >>> val = (val & 0x0f) << 12; >>> if (pos >= limit) { >>> val |= ((is.read() & 0x3f) << 6); >>> } else { >>> val |= ((buf[pos++] & 0x3f) << 6); >>> } >>> if (pos >= limit) { >>> val |= (buf[pos++] & 0x3f); >>> } else { >>> val |= (is.read() & 0x3f); >>> } >>> cbuf[off++] = (char) val; >>> break; >>> case 0xf0: // UCS-4 character >>> throw new UnsupportedEncodingException("UTF-32 >>> (or UCS-4) encoding not supported."); >>> default: >>> cbuf[off++] = (char) val; >>> break; >>> } >>> } >>> return off - off0; >>> >>> } >>> >>> /** >>> * Reads a single character. >>> * >>> * @return The character read, as an integer in the range 0 to 65535 >>> * (0x00-0xffff), or -1 if the end of the stream has been reached. >>> * @exception IOException If any IO errors occur. >>> * @exception UnsupportedEncodingException If UCS-4 character >>> occur in the stream. >>> */ >>> public int read() throws IOException { >>> int val; >>> if (pos >= limit) { >>> val = is.read(); >>> } else { >>> val = buf[pos++] & 0xff; >>> } >>> switch (val & 0xf0) { >>> case 0xc0: >>> case 0xd0: >>> if (pos >= limit) { >>> val = ((val & 0x1f) << 6) | (is.read() & 0x3f); >>> } else { >>> val = ((val & 0x1f) << 6) | (buf[pos++] & 0x3f); >>> } >>> break; >>> case 0xe0: >>> val = (val & 0x0f) << 12; >>> if (pos >= limit) { >>> val |= ((is.read() & 0x3f) << 6); >>> } else { >>> val |= ((buf[pos++] & 0x3f) << 6); >>> } >>> if (pos >= limit) { >>> val |= (is.read() & 0x3f); >>> } else { >>> val |= (buf[pos++] & 0x3f); >>> } >>> break; >>> case 0xf0: // UCS-4 character >>> throw new UnsupportedEncodingException(); >>> default: >>> break; >>> } >>> return val; >>> } >>> >>> /** >>> * Closes the stream. >>> * >>> * @exception IOException If any IO errors occur. >>> */ >>> public void close() throws IOException { >>> is.close(); >>> } >>> } >>> >> > From iris.clark at oracle.com Wed May 28 05:00:30 2014 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 27 May 2014 22:00:30 -0700 (PDT) Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: References: Message-ID: <13a1868f-854e-4bcb-8666-8678b25acb04@default> Hi, Jeremy. As an "Author", you can create a changeset but you can't push to the repo until you're a "Committer". Additional details about the differences between Author and Committer may be found here [1,2]. The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the "hg commit -u jmanson ..." to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of "hg export -g" which would preserve information in the changeset header including the author, commit comment, etc. Thanks, iris [1]: http://openjdk.java.net/projects/#project-author [2]: http://openjdk.java.net/projects/#project-committer -----Original Message----- From: Jeremy Manson [mailto:jeremymanson at google.com] Sent: Tuesday, May 27, 2014 2:19 PM To: Vincent Ryan Cc: OpenJDK; core-libs-dev Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in? Jeremy On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan wrote: > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor > your fix if you wish. > > On 27 May 2014, at 21:09, Jeremy Manson wrote: > > > Just like the title says - every time you generate a new private > > key, you leak a little memory. Webrev here: > > > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ > > > > This is probably the wrong mailing list for this bug, but I expect > someone > > on this list will point me in the right direction. > > > > Jeremy > > From tobias.hartmann at oracle.com Wed May 28 09:49:45 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 28 May 2014 11:49:45 +0200 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> Message-ID: <5385B139.80808@oracle.com> Hi, thanks everyone for the feedback! @Remi: I agree with Paul. This is not a problem because if the normal read sees an outdated null value, a new LambdaForm is created and setCachedLambdaForm(...) is executed. This will guarantee that the non-null value is seen and used. The unnecessary creation of a new LamdaForm is not a problem either. @John: I added the code that you suggested to simulate CAS. Please find the new webrev at: http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ Sorry for the delay, I was on vacation. Thanks, Tobias On 19.05.2014 20:31, John Rose wrote: > On May 16, 2014, at 4:56 AM, Tobias Hartmann wrote: > >> Is it sufficient then to use synchronized (lambdaForms) { ... } in setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? > Yes, that is how I see it. The fast path is a racy non-volatile read of a safely-published structure. > > (If safe publication via arrays were broken, java.lang.String would be broken. But the JMM is carefully designed to support safe publication of array elements, and through array elements.) > > ? John From paul.sandoz at oracle.com Wed May 28 10:04:38 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 28 May 2014 12:04:38 +0200 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error In-Reply-To: <5384BA65.6020206@oracle.com> References: <538490E2.2090102@oracle.com> <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> <538498C1.5080909@oracle.com> <1F4BB8AF-F2A4-472F-9489-A49368399FCC@oracle.com> <5384BA65.6020206@oracle.com> Message-ID: <2D9354AF-DEB8-4F0B-832B-F4D47944793B@oracle.com> On May 27, 2014, at 6:16 PM, Vladimir Ivanov wrote: > Good catch! > One more iteration: > http://cr.openjdk.java.net/~vlivanov/8035186/webrev.02/ > Looks good. Some minor points, no need for another review round either way: - don't need the nested try blocks in isWriteableDirectory, just tack the finally block on the end of the last catch block. - could add a println when there is no POSIX environment to indicate the test is not run and remove it when/if jtreg supports skipping. Paul. From vladimir.x.ivanov at oracle.com Wed May 28 10:36:25 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 May 2014 14:36:25 +0400 Subject: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error In-Reply-To: <2D9354AF-DEB8-4F0B-832B-F4D47944793B@oracle.com> References: <538490E2.2090102@oracle.com> <2D157047-9E76-48C9-A19E-B0C24E27B50F@oracle.com> <538498C1.5080909@oracle.com> <1F4BB8AF-F2A4-472F-9489-A49368399FCC@oracle.com> <5384BA65.6020206@oracle.com> <2D9354AF-DEB8-4F0B-832B-F4D47944793B@oracle.com> Message-ID: <5385BC29.9090707@oracle.com> Thanks, Paul. I agree your comments and will address them before the push. Best regards, Vladimir Ivanov On 5/28/14 2:04 PM, Paul Sandoz wrote: > > On May 27, 2014, at 6:16 PM, Vladimir Ivanov wrote: > >> Good catch! >> One more iteration: >> http://cr.openjdk.java.net/~vlivanov/8035186/webrev.02/ >> > > Looks good. > > Some minor points, no need for another review round either way: > > - don't need the nested try blocks in isWriteableDirectory, just tack the finally block on the end of the last catch block. > > - could add a println when there is no POSIX environment to indicate the test is not run and remove it when/if jtreg supports skipping. > > Paul. > > From vladimir.x.ivanov at oracle.com Wed May 28 10:48:38 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 28 May 2014 14:48:38 +0400 Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <5385B139.80808@oracle.com> References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com> <5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com> <5385B139.80808@oracle.com> Message-ID: <5385BF06.5090808@oracle.com> Looks good. It should be safe to sync on MTF instance since it's not accessible outside (MTF and MT.form() are package-private). Best regards, Vladimir Ivanov On 5/28/14 1:49 PM, Tobias Hartmann wrote: > Hi, > > thanks everyone for the feedback! > > @Remi: I agree with Paul. This is not a problem because if the normal > read sees an outdated null value, a new LambdaForm is created and > setCachedLambdaForm(...) is executed. This will guarantee that the > non-null value is seen and used. The unnecessary creation of a new > LamdaForm is not a problem either. > > @John: I added the code that you suggested to simulate CAS. Please find > the new webrev at: > > http://cr.openjdk.java.net/~anoll/8005873/webrev.02/ > > Sorry for the delay, I was on vacation. > > Thanks, > Tobias > > On 19.05.2014 20:31, John Rose wrote: >> On May 16, 2014, at 4:56 AM, Tobias Hartmann >> wrote: >> >>> Is it sufficient then to use synchronized (lambdaForms) { ... } in >>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)? >> Yes, that is how I see it. The fast path is a racy non-volatile read >> of a safely-published structure. >> >> (If safe publication via arrays were broken, java.lang.String would be >> broken. But the JMM is carefully designed to support safe publication >> of array elements, and through array elements.) >> >> ? John > From me at sandipan.net Wed May 28 12:33:58 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Wed, 28 May 2014 08:33:58 -0400 Subject: Intent to work on 8043740 Message-ID: Hi all, Ready to contribute another patch - I intend to try and fix the following: https://bugs.openjdk.java.net/browse/JDK-8043740 Any thoughts/objections and/or is anyone already working on it? Cheers, SR Sandipan Razzaque | www.sandipan.net From brian.burkhalter at oracle.com Wed May 28 14:36:45 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 May 2014 07:36:45 -0700 Subject: Intent to work on 8043740 In-Reply-To: References: Message-ID: On May 28, 2014, at 5:33 AM, Sandipan Razzaque wrote: > Hi all, > > Ready to contribute another patch - I intend to try and fix the following: > > https://bugs.openjdk.java.net/browse/JDK-8043740 > > Any thoughts/objections and/or is anyone already working on it? It is unassigned so I have to presume no one is working on it yet. I don?t know your OpenJDK status but you will need to have submitted an OCA to submit a patch: http://openjdk.java.net/contribute/ Thanks, Brian > > Cheers, > SR > > Sandipan Razzaque | www.sandipan.net From mark.reinhold at oracle.com Wed May 28 15:03:31 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 May 2014 08:03:31 -0700 Subject: Intent to work on 8043740 In-Reply-To: References: Message-ID: <20140528080331.409029@eggemoggin.niobe.net> It'd help immensely if you'd include the title of the bug in question in the subject line of messages such as this. That way people can more easily decide whether and how to respond to your query. - Mark From jeremymanson at google.com Wed May 28 15:28:04 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 28 May 2014 08:28:04 -0700 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: <13a1868f-854e-4bcb-8666-8678b25acb04@default> References: <13a1868f-854e-4bcb-8666-8678b25acb04@default> Message-ID: Ah, okay. Thanks, Iris. I should already know known that - Martin has explained it to me before. Vincent - let me know how you want to proceed. Jeremy On Tue, May 27, 2014 at 10:00 PM, Iris Clark wrote: > Hi, Jeremy. > > As an "Author", you can create a changeset but you can't push to the repo > until you're a "Committer". Additional details about the differences > between Author and Committer may be found here [1,2]. > > The diffs to create a changeset are (of course) in your webrev. Your > Sponsor can use that along with the "hg commit -u jmanson ..." to list you > as the changeset Author. Alternatively, your Sponsor may want you to just > send the output of "hg export -g" which would preserve information in the > changeset header including the author, commit comment, etc. > > Thanks, > iris > > [1]: http://openjdk.java.net/projects/#project-author > [2]: http://openjdk.java.net/projects/#project-committer > > -----Original Message----- > From: Jeremy Manson [mailto:jeremymanson at google.com] > Sent: Tuesday, May 27, 2014 2:19 PM > To: Vincent Ryan > Cc: OpenJDK; core-libs-dev > Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key > Generation > > Thanks, Vincent. This would be the first change I've made as an author, > so I'm not sure what the process is. I think I just need someone to do the > review, and then I can check it in? > > Jeremy > > > On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan > wrote: > > > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor > > your fix if you wish. > > > > On 27 May 2014, at 21:09, Jeremy Manson wrote: > > > > > Just like the title says - every time you generate a new private > > > key, you leak a little memory. Webrev here: > > > > > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ > > > > > > This is probably the wrong mailing list for this bug, but I expect > > someone > > > on this list will point me in the right direction. > > > > > > Jeremy > > > > > From fuyou001 at gmail.com Wed May 28 15:40:37 2014 From: fuyou001 at gmail.com (fuyou) Date: Wed, 28 May 2014 23:40:37 +0800 Subject: JVM crash when I use google gperftools Non Heap profiler Message-ID: crash log A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x00002b626db6c304, pid=15640, tid=1167100224 JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13) Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 > > compressed oops) Problematic frame: C [libunwind.so.7+0xb304] _ULx86_64_get_save_loc+0x568 Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again An error report file with more information is saved as: If you would like to submit a bug report, please visit: http://bugreport.sun.com/bugreport/crash.jsp java version java version "1.7.0_55" Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) google gperftools version gperftools-2.1 OS version Red Hat Enterprise Linux Server release 5.7 (Tikanga) Kernel \r on an \m reproduction step ------------------------------ 1 yum install libunwind 2 download gperftools from https://code.google.com/p/gperftools/downloads/list and configue;sudo make install 3 export LD_PRELOAD=/usr/local/lib/libtcmalloc_and_profiler.so; export HEAPPROFILE=/tmp/memory/temp how to solve it? -- ============================================= fuyou001 Best Regards From vincent.x.ryan at oracle.com Wed May 28 15:52:04 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 28 May 2014 16:52:04 +0100 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: References: <13a1868f-854e-4bcb-8666-8678b25acb04@default> Message-ID: <8A7D584B-9C81-49B9-80E2-616484EB836D@oracle.com> I?ll begin reviewing your changeset and get back to you. Thanks. On 28 May 2014, at 16:28, Jeremy Manson wrote: > Ah, okay. Thanks, Iris. I should already know known that - Martin has explained it to me before. > > Vincent - let me know how you want to proceed. > > Jeremy > > > On Tue, May 27, 2014 at 10:00 PM, Iris Clark wrote: > Hi, Jeremy. > > As an "Author", you can create a changeset but you can't push to the repo until you're a "Committer". Additional details about the differences between Author and Committer may be found here [1,2]. > > The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the "hg commit -u jmanson ..." to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of "hg export -g" which would preserve information in the changeset header including the author, commit comment, etc. > > Thanks, > iris > > [1]: http://openjdk.java.net/projects/#project-author > [2]: http://openjdk.java.net/projects/#project-committer > > -----Original Message----- > From: Jeremy Manson [mailto:jeremymanson at google.com] > Sent: Tuesday, May 27, 2014 2:19 PM > To: Vincent Ryan > Cc: OpenJDK; core-libs-dev > Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation > > Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in? > > Jeremy > > > On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan > wrote: > > > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor > > your fix if you wish. > > > > On 27 May 2014, at 21:09, Jeremy Manson wrote: > > > > > Just like the title says - every time you generate a new private > > > key, you leak a little memory. Webrev here: > > > > > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ > > > > > > This is probably the wrong mailing list for this bug, but I expect > > someone > > > on this list will point me in the right direction. > > > > > > Jeremy > > > > > From jeremymanson at google.com Wed May 28 16:21:21 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 28 May 2014 09:21:21 -0700 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: <8A7D584B-9C81-49B9-80E2-616484EB836D@oracle.com> References: <13a1868f-854e-4bcb-8666-8678b25acb04@default> <8A7D584B-9C81-49B9-80E2-616484EB836D@oracle.com> Message-ID: You can defer the change if you need to. I'm going on vacation from the 6th to the 16th, so there are timing issues around that. At Google, we plug in a different version of malloc that checks to make sure that you've freed everything you've allocated. It's a bit painful to write this from scratch, but I might be able to hack something together for you (that only runs on Linux), if you want. Jeremy On Wed, May 28, 2014 at 8:52 AM, Vincent Ryan wrote: > I?ll begin reviewing your changeset and get back to you. > Thanks. > > On 28 May 2014, at 16:28, Jeremy Manson wrote: > > Ah, okay. Thanks, Iris. I should already know known that - Martin has > explained it to me before. > > Vincent - let me know how you want to proceed. > > Jeremy > > > On Tue, May 27, 2014 at 10:00 PM, Iris Clark > wrote: > >> Hi, Jeremy. >> >> As an "Author", you can create a changeset but you can't push to the repo >> until you're a "Committer". Additional details about the differences >> between Author and Committer may be found here [1,2]. >> >> The diffs to create a changeset are (of course) in your webrev. Your >> Sponsor can use that along with the "hg commit -u jmanson ..." to list you >> as the changeset Author. Alternatively, your Sponsor may want you to just >> send the output of "hg export -g" which would preserve information in the >> changeset header including the author, commit comment, etc. >> >> Thanks, >> iris >> >> [1]: http://openjdk.java.net/projects/#project-author >> [2]: http://openjdk.java.net/projects/#project-committer >> >> -----Original Message----- >> From: Jeremy Manson [mailto:jeremymanson at google.com] >> Sent: Tuesday, May 27, 2014 2:19 PM >> To: Vincent Ryan >> Cc: OpenJDK; core-libs-dev >> Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key >> Generation >> >> Thanks, Vincent. This would be the first change I've made as an author, >> so I'm not sure what the process is. I think I just need someone to do the >> review, and then I can check it in? >> >> Jeremy >> >> >> On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan >> wrote: >> >> > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor >> > your fix if you wish. >> > >> > On 27 May 2014, at 21:09, Jeremy Manson >> wrote: >> > >> > > Just like the title says - every time you generate a new private >> > > key, you leak a little memory. Webrev here: >> > > >> > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ >> > > >> > > This is probably the wrong mailing list for this bug, but I expect >> > someone >> > > on this list will point me in the right direction. >> > > >> > > Jeremy >> > >> > >> > > > From vincent.x.ryan at oracle.com Wed May 28 16:23:49 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 28 May 2014 17:23:49 +0100 Subject: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation In-Reply-To: References: <13a1868f-854e-4bcb-8666-8678b25acb04@default> <8A7D584B-9C81-49B9-80E2-616484EB836D@oracle.com> Message-ID: It?s difficult to develop a useful test that is cross-platform so let?s skip the testcase for this fix. On 28 May 2014, at 17:21, Jeremy Manson wrote: > You can defer the change if you need to. I'm going on vacation from the 6th to the 16th, so there are timing issues around that. > > At Google, we plug in a different version of malloc that checks to make sure that you've freed everything you've allocated. It's a bit painful to write this from scratch, but I might be able to hack something together for you (that only runs on Linux), if you want. > > Jeremy > > > On Wed, May 28, 2014 at 8:52 AM, Vincent Ryan wrote: > I?ll begin reviewing your changeset and get back to you. > Thanks. > > On 28 May 2014, at 16:28, Jeremy Manson wrote: > >> Ah, okay. Thanks, Iris. I should already know known that - Martin has explained it to me before. >> >> Vincent - let me know how you want to proceed. >> >> Jeremy >> >> >> On Tue, May 27, 2014 at 10:00 PM, Iris Clark wrote: >> Hi, Jeremy. >> >> As an "Author", you can create a changeset but you can't push to the repo until you're a "Committer". Additional details about the differences between Author and Committer may be found here [1,2]. >> >> The diffs to create a changeset are (of course) in your webrev. Your Sponsor can use that along with the "hg commit -u jmanson ..." to list you as the changeset Author. Alternatively, your Sponsor may want you to just send the output of "hg export -g" which would preserve information in the changeset header including the author, commit comment, etc. >> >> Thanks, >> iris >> >> [1]: http://openjdk.java.net/projects/#project-author >> [2]: http://openjdk.java.net/projects/#project-committer >> >> -----Original Message----- >> From: Jeremy Manson [mailto:jeremymanson at google.com] >> Sent: Tuesday, May 27, 2014 2:19 PM >> To: Vincent Ryan >> Cc: OpenJDK; core-libs-dev >> Subject: Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation >> >> Thanks, Vincent. This would be the first change I've made as an author, so I'm not sure what the process is. I think I just need someone to do the review, and then I can check it in? >> >> Jeremy >> >> >> On Tue, May 27, 2014 at 1:55 PM, Vincent Ryan >> wrote: >> >> > Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor >> > your fix if you wish. >> > >> > On 27 May 2014, at 21:09, Jeremy Manson wrote: >> > >> > > Just like the title says - every time you generate a new private >> > > key, you leak a little memory. Webrev here: >> > > >> > > http://cr.openjdk.java.net/~jmanson/8044059/webrev/ >> > > >> > > This is probably the wrong mailing list for this bug, but I expect >> > someone >> > > on this list will point me in the right direction. >> > > >> > > Jeremy >> > >> > >> > > From me at sandipan.net Wed May 28 16:56:53 2014 From: me at sandipan.net (Sandipan Razzaque) Date: Wed, 28 May 2014 12:56:53 -0400 Subject: Intent to work on 8043740 In-Reply-To: References: Message-ID: Thanks Brian - My concern is that, despite the unassigned status, someone just like me could be working on it. Since I don't have a Jira login I cannot update the status to communicate this to others. Cheers, SR Sandipan Razzaque | www.sandipan.net On Wed, May 28, 2014 at 10:36 AM, Brian Burkhalter wrote: > > On May 28, 2014, at 5:33 AM, Sandipan Razzaque wrote: > >> Hi all, >> >> Ready to contribute another patch - I intend to try and fix the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8043740 >> >> Any thoughts/objections and/or is anyone already working on it? > > It is unassigned so I have to presume no one is working on it yet. > > I don?t know your OpenJDK status but you will need to have submitted an OCA to submit a patch: > > http://openjdk.java.net/contribute/ > > Thanks, > > Brian > >> >> Cheers, >> SR >> >> Sandipan Razzaque | www.sandipan.net > From brian.burkhalter at oracle.com Wed May 28 17:25:19 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 May 2014 10:25:19 -0700 Subject: Doubles with large exponents overflow to Infinity incorrectly (Re: Intent to work on 8043740) In-Reply-To: References: Message-ID: Continuing this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/027030.html under a new subject line ? Hi Sandipan, Per the contribution page information I sent earlier, I can sponsor the patch and assign the issue to myself and mark it as ?in progress? while you are working on it. Information on obtaining a JDK Bug System (JBS) account is at https://wiki.openjdk.java.net/display/general/JBS+Overview so you can review that yourself. As I now see that you have an OCA on file already, my prior comment on that topic is irrelevant. Thanks, Brian On May 28, 2014, at 9:56 AM, Sandipan Razzaque wrote: > Thanks Brian - > > My concern is that, despite the unassigned status, someone just like > me could be working on it. Since I don't have a Jira login I cannot > update the status to communicate this to others. > > Cheers, > SR > Sandipan Razzaque | www.sandipan.net > > > On Wed, May 28, 2014 at 10:36 AM, Brian Burkhalter > wrote: >> >> On May 28, 2014, at 5:33 AM, Sandipan Razzaque wrote: >> >>> Hi all, >>> >>> Ready to contribute another patch - I intend to try and fix the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8043740 >>> >>> Any thoughts/objections and/or is anyone already working on it? >> >> It is unassigned so I have to presume no one is working on it yet. >> >> I don?t know your OpenJDK status but you will need to have submitted an OCA to submit a patch: >> >> http://openjdk.java.net/contribute/ >> >> Thanks, >> >> Brian >> >>> >>> Cheers, >>> SR >>> >>> Sandipan Razzaque | www.sandipan.net >> From ecki at zusammenkunft.net Wed May 28 19:09:07 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 28 May 2014 21:09:07 +0200 Subject: JVM crash when I use google gperftools Non Heap profiler In-Reply-To: References: Message-ID: <20140528210907.00006ffb.ecki@zusammenkunft.net> Hello, ask there: https://groups.google.com/forum/#!forum/google-perftools It is (does not look) related to openjdk core libraries at all. Gruss Bernd schrieb fuyou : > crash log > > A fatal error has been detected by the Java Runtime Environment: > SIGSEGV (0xb) at pc=0x00002b626db6c304, pid=15640, tid=1167100224 > JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build > 1.7.0_55-b13) > Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode > linux-amd64 > > compressed oops) > Problematic frame: > C [libunwind.so.7+0xb304] _ULx86_64_get_save_loc+0x568 > > Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > > An error report file with more information is saved as: > > If you would like to submit a bug report, please visit: > http://bugreport.sun.com/bugreport/crash.jsp > > java version > > java version "1.7.0_55" > Java(TM) SE Runtime Environment (build 1.7.0_55-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) > google gperftools version > > gperftools-2.1 > OS version > > Red Hat Enterprise Linux Server release 5.7 (Tikanga) > Kernel \r on an \m > reproduction step > ------------------------------ > 1 > > yum install libunwind > > 2 > > download gperftools from > https://code.google.com/p/gperftools/downloads/list and configue;sudo > make install > > 3 > > export LD_PRELOAD=/usr/local/lib/libtcmalloc_and_profiler.so; > export HEAPPROFILE=/tmp/memory/temp > > > > how to solve it? From andrej.golovnin at gmail.com Wed May 28 21:44:34 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 28 May 2014 23:44:34 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection Message-ID: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Hi Joe, I have prepared a patch for the issue JDK-5043030. The patch consists of two parts: one for jdk and one for hotspot. You can find the webrevs here: JDK-patch: https://db.tt/7DYph0OH Hotspot-patch: https://db.tt/hHsN0yn4 The JDK-patch has two tests to verify the changes. Please review it and I hope you can sponsor it. Best regards, Andrej Golovnin From jeremymanson at google.com Thu May 29 00:15:08 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 28 May 2014 17:15:08 -0700 Subject: JVM crash when I use google gperftools Non Heap profiler In-Reply-To: <20140528210907.00006ffb.ecki@zusammenkunft.net> References: <20140528210907.00006ffb.ecki@zusammenkunft.net> Message-ID: FWIW, I haven't looked at our OSS perftools in a while, but I wouldn't be shocked if either a) that code can't handle code compiled without frame pointers (the libunwind crash suggests that), or b) it barfed when it hit a Java stack frame. The internal versions have had problems of that nature. If you want something similar for profiling *just* Java code (no native code or JNI), my lightweight Java profiler uses a similar approach: https://code.google.com/p/lightweight-java-profiler/ Jeremy On Wed, May 28, 2014 at 12:09 PM, Bernd Eckenfels wrote: > Hello, > > ask there: https://groups.google.com/forum/#!forum/google-perftools > > It is (does not look) related to openjdk core libraries at all. > > Gruss > Bernd > > schrieb fuyou : > > > crash log > > > > A fatal error has been detected by the Java Runtime Environment: > > SIGSEGV (0xb) at pc=0x00002b626db6c304, pid=15640, tid=1167100224 > > JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build > > 1.7.0_55-b13) > > Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode > > linux-amd64 > > compressed oops) > > Problematic frame: > > C [libunwind.so.7+0xb304] _ULx86_64_get_save_loc+0x568 > > > > Failed to write core dump. Core dumps have been disabled. To enable > > core dumping, try "ulimit -c unlimited" before starting Java again > > > > An error report file with more information is saved as: > > > > If you would like to submit a bug report, please visit: > > http://bugreport.sun.com/bugreport/crash.jsp > > > > java version > > > > java version "1.7.0_55" > > Java(TM) SE Runtime Environment (build 1.7.0_55-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) > > google gperftools version > > > > gperftools-2.1 > > OS version > > > > Red Hat Enterprise Linux Server release 5.7 (Tikanga) > > Kernel \r on an \m > > reproduction step > > ------------------------------ > > 1 > > > > yum install libunwind > > > > 2 > > > > download gperftools from > > https://code.google.com/p/gperftools/downloads/list and configue;sudo > > make install > > > > 3 > > > > export LD_PRELOAD=/usr/local/lib/libtcmalloc_and_profiler.so; > > export HEAPPROFILE=/tmp/memory/temp > > > > > > > > how to solve it? > > From otaviojava at java.net Thu May 29 01:50:55 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Wed, 28 May 2014 22:50:55 -0300 Subject: Fwd: Boolean valueOf instead of new Boolean In-Reply-To: <5384D33A.9050202@oracle.com> References: <608EFFC1-9319-415D-977E-9A05DD7278FD@gmail.com> <5384D33A.9050202@oracle.com> Message-ID: ---------- Forwarded message ---------- From: roger riggs Date: Tue, May 27, 2014 at 3:02 PM Subject: Re: Boolean valueOf instead of new Boolean To: core-libs-dev at openjdk.java.net Hi Ot?vio, I can sponsor these two (Boolean and single char strings) for you. Because they cross over different repositories and require different reviews it would be more convenient to process each of them in two batches (client vs core) Please can you break out the 'client' changes into a separate webrev? The client packages are: (java and javax...) java2d, awt, swing, font, print, beans, media, imageio, applet, sound and accessibility. The client webrevs should be posted to awt-dev and the other two to core-libs, net-dev and servicability-dev. Thanks, Roger On 5/27/2014 1:16 PM, Ot?vio Gon?alves de Santana wrote: > Can anyone help me as sponsor? > On May 25, 2014 2:08 AM, "Ot?vio Gon?alves de Santana" < > otaviojava at java.net> > wrote: > > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 -------------- next part -------------- diff -r e323c74edabd src/share/classes/sun/applet/AppletClassLoader.java --- a/src/share/classes/sun/applet/AppletClassLoader.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/applet/AppletClassLoader.java Tue May 27 21:47:24 2014 -0300 @@ -168,7 +168,7 @@ */ protected Class findClass(String name) throws ClassNotFoundException { - int index = name.indexOf(";"); + int index = name.indexOf(';'); String cookie = ""; if(index != -1) { cookie = name.substring(index, name.length()); @@ -608,7 +608,7 @@ // deal with URL rewriting String cookie = null; - int index = name.indexOf(";"); + int index = name.indexOf(';'); if(index != -1) { cookie = name.substring(index, name.length()); name = name.substring(0, index); diff -r e323c74edabd src/share/classes/sun/awt/FontConfiguration.java --- a/src/share/classes/sun/awt/FontConfiguration.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/awt/FontConfiguration.java Tue May 27 21:47:24 2014 -0300 @@ -272,9 +272,9 @@ if (configFile != null) { return configFile; } - int decimalPointIndex = osVersion.indexOf("."); + int decimalPointIndex = osVersion.indexOf('.'); if (decimalPointIndex != -1) { - osMajorVersion = osVersion.substring(0, osVersion.indexOf(".")); + osMajorVersion = osVersion.substring(0, osVersion.indexOf('.')); configFile = findImpl(baseName + "." + osName + "." + osMajorVersion); if (configFile != null) { return configFile; diff -r e323c74edabd src/share/classes/sun/font/Type1Font.java --- a/src/share/classes/sun/font/Type1Font.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/font/Type1Font.java Tue May 27 21:47:24 2014 -0300 @@ -492,7 +492,7 @@ //Conversion: Expand abbreviations in style portion (everything after '-'), // replace '-' with space and insert missing spaces - pos = name.indexOf("-"); + pos = name.indexOf('-'); if (pos >= 0) { res = expandName(name.substring(0, pos), false); res += " " + expandName(name.substring(pos+1), true); @@ -513,8 +513,8 @@ //Conversion: Truncate style portion (everything after '-') // and insert missing spaces - if (tmp.indexOf("-") > 0) { - tmp = tmp.substring(0, tmp.indexOf("-")); + if (tmp.indexOf('-') > 0) { + tmp = tmp.substring(0, tmp.indexOf('-')); } return expandName(tmp, false); diff -r e323c74edabd src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java --- a/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java Tue May 27 21:47:24 2014 -0300 @@ -84,7 +84,7 @@ * {@inheritDoc} */ public String getBaseName() { - int baseIndex = name.lastIndexOf(".")+1; + int baseIndex = name.lastIndexOf('.') + 1; return name.substring(baseIndex); } diff -r e323c74edabd src/share/classes/sun/jvmstat/monitor/HostIdentifier.java --- a/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/jvmstat/monitor/HostIdentifier.java Tue May 27 21:47:24 2014 -0300 @@ -138,8 +138,8 @@ String frag = u.getFragment(); URI u2 = null; - int c1index = uriString.indexOf(":"); - int c2index = uriString.lastIndexOf(":"); + int c1index = uriString.indexOf(':'); + int c2index = uriString.lastIndexOf(':'); if (c2index != c1index) { /* * this is the scheme:hostname:port case. Attempt to diff -r e323c74edabd src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java --- a/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/management/snmp/jvminstr/NotificationTargetImpl.java Tue May 27 21:47:24 2014 -0300 @@ -70,8 +70,8 @@ String addrStr; if (target.startsWith("[")) { - final int index = target.indexOf("]"); - final int index2 = target.lastIndexOf(":"); + final int index = target.indexOf(']'); + final int index2 = target.lastIndexOf(':'); if(index == -1) throw new IllegalArgumentException("Host starts with [ but " + "does not end with ]"); @@ -85,8 +85,8 @@ if (addrStr.startsWith("[")) throw new IllegalArgumentException("More than one [[...]]"); } else { - final int index = target.indexOf(":"); - final int index2 = target.lastIndexOf(":"); + final int index = target.indexOf(':'); + final int index2 = target.lastIndexOf(':'); if(index == -1) throw new IllegalArgumentException("Missing port separator \":\""); addrStr = target.substring(0, index); @@ -98,7 +98,7 @@ address = InetAddress.getByName(addrStr); //THE CHECK SHOULD BE STRONGER!!! - final int index = target.lastIndexOf(":"); + final int index = target.lastIndexOf(':'); community = target.substring(index + 1, target.length()); diff -r e323c74edabd src/share/classes/sun/misc/ExtensionInfo.java --- a/src/share/classes/sun/misc/ExtensionInfo.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/ExtensionInfo.java Tue May 27 21:47:24 2014 -0300 @@ -273,8 +273,8 @@ else { // Look for index of "." in the string - int sIdx = source.indexOf("."); - int tIdx = target.indexOf("."); + int sIdx = source.indexOf('.'); + int tIdx = target.indexOf('.'); if (sIdx == -1) sIdx = source.length() - 1; @@ -304,10 +304,10 @@ String versionError = mf.format(args); // Look for "-" for pre-release - int prIndex = token.indexOf("-"); + int prIndex = token.indexOf('-'); // Look for "_" for patch release - int patchIndex = token.indexOf("_"); + int patchIndex = token.indexOf('_'); if (prIndex == -1 && patchIndex == -1) { diff -r e323c74edabd src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/JarIndex.java Tue May 27 21:47:24 2014 -0300 @@ -172,7 +172,7 @@ if ((jarFiles = indexMap.get(fileName)) == null) { /* try the package name again */ int pos; - if((pos = fileName.lastIndexOf("/")) != -1) { + if((pos = fileName.lastIndexOf('/')) != -1) { jarFiles = indexMap.get(fileName.substring(0, pos)); } } @@ -195,7 +195,7 @@ public void add(String fileName, String jarName) { String packageName; int pos; - if((pos = fileName.lastIndexOf("/")) != -1) { + if((pos = fileName.lastIndexOf('/')) != -1) { packageName = fileName.substring(0, pos); } else { packageName = fileName; diff -r e323c74edabd src/share/classes/sun/misc/URLClassPath.java --- a/src/share/classes/sun/misc/URLClassPath.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/misc/URLClassPath.java Tue May 27 21:47:24 2014 -0300 @@ -793,7 +793,7 @@ boolean validIndex(final String name) { String packageName = name; int pos; - if((pos = name.lastIndexOf("/")) != -1) { + if((pos = name.lastIndexOf('/')) != -1) { packageName = name.substring(0, pos); } @@ -803,7 +803,7 @@ while (enum_.hasMoreElements()) { entry = enum_.nextElement(); entryName = entry.getName(); - if((pos = entryName.lastIndexOf("/")) != -1) + if((pos = entryName.lastIndexOf('/')) != -1) entryName = entryName.substring(0, pos); if (entryName.equals(packageName)) { return true; @@ -900,7 +900,7 @@ */ JarIndex newIndex = newLoader.getIndex(); if(newIndex != null) { - int pos = jarName.lastIndexOf("/"); + int pos = jarName.lastIndexOf('/'); newIndex.merge(this.index, (pos == -1 ? null : jarName.substring(0, pos + 1))); } diff -r e323c74edabd src/share/classes/sun/net/ftp/impl/FtpClient.java --- a/src/share/classes/sun/net/ftp/impl/FtpClient.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/ftp/impl/FtpClient.java Tue May 27 21:47:24 2014 -0300 @@ -259,7 +259,7 @@ d = null; } if (d != null && time != null) { - int c = time.indexOf(":"); + int c = time.indexOf(':'); now.setTime(d); now.set(Calendar.HOUR, Integer.parseInt(time.substring(0, c))); now.set(Calendar.MINUTE, Integer.parseInt(time.substring(c + 1))); @@ -295,7 +295,7 @@ public FtpDirEntry parseLine(String line) { String name = null; - int i = line.lastIndexOf(";"); + int i = line.lastIndexOf(';'); if (i > 0) { name = line.substring(i + 1).trim(); line = line.substring(0, i); @@ -306,7 +306,7 @@ FtpDirEntry file = new FtpDirEntry(name); while (!line.isEmpty()) { String s; - i = line.indexOf(";"); + i = line.indexOf(';'); if (i > 0) { s = line.substring(0, i); line = line.substring(i + 1); @@ -314,7 +314,7 @@ s = line; line = ""; } - i = s.indexOf("="); + i = s.indexOf('='); if (i > 0) { String fact = s.substring(0, i); String value = s.substring(i + 1); diff -r e323c74edabd src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java --- a/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java Tue May 27 21:47:24 2014 -0300 @@ -325,7 +325,7 @@ while (i.hasNext()) { String parentDomain = i.next(); int start = 0; - while ((start = parentDomain.indexOf(".")) != -1 + while ((start = parentDomain.indexOf('.')) != -1 && start < parentDomain.length() -1) { try { results = resolve(ctx, host+"."+parentDomain, ids, 0); diff -r e323c74edabd src/share/classes/sun/net/util/IPAddressUtil.java --- a/src/share/classes/sun/net/util/IPAddressUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/util/IPAddressUtil.java Tue May 27 21:47:24 2014 -0300 @@ -149,7 +149,7 @@ byte[] dst = new byte[INADDR16SZ]; int srcb_length = srcb.length; - int pc = src.indexOf ("%"); + int pc = src.indexOf ('%'); if (pc == srcb_length -1) { return null; } diff -r e323c74edabd src/share/classes/sun/net/www/ParseUtil.java --- a/src/share/classes/sun/net/www/ParseUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/net/www/ParseUtil.java Tue May 27 21:47:24 2014 -0300 @@ -356,8 +356,8 @@ * because we must not quote a literal IPv6 address */ if (opaquePart.startsWith("//[")) { - int end = opaquePart.indexOf("]"); - if (end != -1 && opaquePart.indexOf(":")!=-1) { + int end = opaquePart.indexOf(']'); + if (end != -1 && opaquePart.indexOf(':')!=-1) { String doquote, dontquote; if (end == opaquePart.length()) { dontquote = opaquePart; @@ -408,8 +408,8 @@ } else if (authority != null) { sb.append("//"); if (authority.startsWith("[")) { - int end = authority.indexOf("]"); - if (end != -1 && authority.indexOf(":")!=-1) { + int end = authority.indexOf(']'); + if (end != -1 && authority.indexOf(':')!=-1) { String doquote, dontquote; if (end == authority.length()) { dontquote = authority; diff -r e323c74edabd src/share/classes/sun/reflect/misc/ReflectUtil.java --- a/src/share/classes/sun/reflect/misc/ReflectUtil.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/reflect/misc/ReflectUtil.java Tue May 27 21:47:24 2014 -0300 @@ -341,6 +341,6 @@ * (not to be confused with a Java Language anonymous inner class). */ public static boolean isVMAnonymousClass(Class cls) { - return cls.getName().indexOf("/") > -1; + return cls.getName().indexOf('/') > -1; } } diff -r e323c74edabd src/share/classes/sun/rmi/runtime/Log.java --- a/src/share/classes/sun/rmi/runtime/Log.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/rmi/runtime/Log.java Tue May 27 21:47:24 2014 -0300 @@ -434,7 +434,7 @@ * Mimic old log messages that only contain unqualified names. */ private static String unqualifiedName(String name) { - int lastDot = name.lastIndexOf("."); + int lastDot = name.lastIndexOf('.'); if (lastDot >= 0) { name = name.substring(lastDot + 1); } diff -r e323c74edabd src/share/classes/sun/rmi/transport/proxy/CGIHandler.java --- a/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/rmi/transport/proxy/CGIHandler.java Tue May 27 21:47:24 2014 -0300 @@ -141,7 +141,7 @@ { try { String command, param; - int delim = QueryString.indexOf("="); + int delim = QueryString.indexOf('='); if (delim == -1) { command = QueryString; param = ""; diff -r e323c74edabd src/share/classes/sun/security/jgss/wrapper/Krb5Util.java --- a/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/jgss/wrapper/Krb5Util.java Tue May 27 21:47:24 2014 -0300 @@ -39,7 +39,7 @@ static String getTGSName(GSSNameElement name) throws GSSException { String krbPrinc = name.getKrbName(); - int atIndex = krbPrinc.indexOf("@"); + int atIndex = krbPrinc.indexOf('@'); String realm = krbPrinc.substring(atIndex + 1); StringBuffer buf = new StringBuffer("krbtgt/"); buf.append(realm).append('@').append(realm); diff -r e323c74edabd src/share/classes/sun/security/provider/PolicyFile.java --- a/src/share/classes/sun/security/provider/PolicyFile.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/provider/PolicyFile.java Tue May 27 21:47:24 2014 -0300 @@ -1856,7 +1856,7 @@ int colonIndex; String prefix = value; String suffix; - if ((colonIndex = value.indexOf(":")) != -1) { + if ((colonIndex = value.indexOf(':')) != -1) { prefix = value.substring(0, colonIndex); } diff -r e323c74edabd src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java --- a/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java Tue May 27 21:47:24 2014 -0300 @@ -338,7 +338,7 @@ } String sigType; if (keyType.contains("_")) { - int k = keyType.indexOf("_"); + int k = keyType.indexOf('_'); sigType = keyType.substring(k + 1); keyType = keyType.substring(0, k); } else { diff -r e323c74edabd src/share/classes/sun/security/ssl/X509KeyManagerImpl.java --- a/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java Tue May 27 21:47:24 2014 -0300 @@ -302,7 +302,7 @@ final String sigKeyAlgorithm; KeyType(String algorithm) { - int k = algorithm.indexOf("_"); + int k = algorithm.indexOf('_'); if (k == -1) { keyAlgorithm = algorithm; sigKeyAlgorithm = null; diff -r e323c74edabd src/share/classes/sun/security/util/HostnameChecker.java --- a/src/share/classes/sun/security/util/HostnameChecker.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/util/HostnameChecker.java Tue May 27 21:47:24 2014 -0300 @@ -300,8 +300,8 @@ template = template.toLowerCase(Locale.ENGLISH); // Retreive leftmost component - int templateIdx = template.indexOf("."); - int nameIdx = name.indexOf("."); + int templateIdx = template.indexOf('.'); + int nameIdx = name.indexOf('.'); if (templateIdx == -1) templateIdx = template.length(); @@ -326,7 +326,7 @@ */ private static boolean matchWildCards(String name, String template) { - int wildcardIdx = template.indexOf("*"); + int wildcardIdx = template.indexOf('*'); if (wildcardIdx == -1) return name.equals(template); @@ -349,7 +349,7 @@ // update the match scope name = name.substring(beforeStartIdx + beforeWildcard.length()); - wildcardIdx = afterWildcard.indexOf("*"); + wildcardIdx = afterWildcard.indexOf('*'); } return name.endsWith(afterWildcard); } diff -r e323c74edabd src/share/classes/sun/security/util/SignatureFileVerifier.java --- a/src/share/classes/sun/security/util/SignatureFileVerifier.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/util/SignatureFileVerifier.java Tue May 27 21:47:24 2014 -0300 @@ -98,7 +98,7 @@ } finally { Providers.stopJarVerification(obj); } - this.name = name.substring(0, name.lastIndexOf(".")) + this.name = name.substring(0, name.lastIndexOf('.')) .toUpperCase(Locale.ENGLISH); this.md = md; this.signerCache = signerCache; diff -r e323c74edabd src/share/classes/sun/security/x509/CRLExtensions.java --- a/src/share/classes/sun/security/x509/CRLExtensions.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/security/x509/CRLExtensions.java Tue May 27 21:47:24 2014 -0300 @@ -185,7 +185,7 @@ String name; String id = attr.getPrefix(); if (id.equalsIgnoreCase(X509CertImpl.NAME)) { // fully qualified - int index = alias.lastIndexOf("."); + int index = alias.lastIndexOf('.'); name = alias.substring(index + 1); } else name = alias; diff -r e323c74edabd src/share/classes/sun/tools/jconsole/ConnectDialog.java --- a/src/share/classes/sun/tools/jconsole/ConnectDialog.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/ConnectDialog.java Tue May 27 21:47:24 2014 -0300 @@ -325,7 +325,7 @@ } else { String host = remoteTF.getText().trim(); String port = "0"; - int index = host.lastIndexOf(":"); + int index = host.lastIndexOf(':'); if (index >= 0) { port = host.substring(index + 1); host = host.substring(0, index); diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/Utils.java --- a/src/share/classes/sun/tools/jconsole/inspector/Utils.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/Utils.java Tue May 27 21:47:24 2014 -0300 @@ -210,7 +210,7 @@ public static String getArrayClassName(String name) { String className = null; if (name.startsWith("[")) { - int index = name.lastIndexOf("["); + int index = name.lastIndexOf('['); className = name.substring(index, name.length()); if (className.startsWith("[L")) { className = className.substring(2, className.length() - 1); @@ -241,7 +241,7 @@ if (className == null) { return name; } - int index = name.lastIndexOf("["); + int index = name.lastIndexOf('['); StringBuilder brackets = new StringBuilder(className); for (int i = 0; i <= index; i++) { brackets.append("[]"); diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/XOperations.java --- a/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XOperations.java Tue May 27 21:47:24 2014 -0300 @@ -112,7 +112,7 @@ if (methodLabel.getText().length() > 20) { methodLabel.setText(methodLabel.getText(). substring(methodLabel.getText(). - lastIndexOf(".") + 1, + lastIndexOf('.') + 1, methodLabel.getText().length())); } diff -r e323c74edabd src/share/classes/sun/tools/jconsole/inspector/XTree.java --- a/src/share/classes/sun/tools/jconsole/inspector/XTree.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/sun/tools/jconsole/inspector/XTree.java Tue May 27 21:47:24 2014 -0300 @@ -475,7 +475,7 @@ private static Map extractKeyValuePairs( String props, ObjectName mbean) { Map map = new LinkedHashMap(); - int eq = props.indexOf("="); + int eq = props.indexOf('='); while (eq != -1) { String key = props.substring(0, eq); String value = mbean.getKeyProperty(key); @@ -484,7 +484,7 @@ if (props.startsWith(",")) { props = props.substring(1); } - eq = props.indexOf("="); + eq = props.indexOf('='); } return map; } @@ -821,7 +821,7 @@ } private void buildKeyValue() { - int index = tokenValue.indexOf("="); + int index = tokenValue.indexOf('='); if (index < 0) { key = tokenValue; value = tokenValue; -------------- next part -------------- diff -r e323c74edabd src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java --- a/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Tue May 27 21:46:45 2014 -0300 @@ -547,7 +547,7 @@ i = strLowerCase.indexOf("", i); if (i > 0) { i += "".length(); - int i2 = str.indexOf("<", i); + int i2 = str.indexOf('<', i); return str.substring(i, i2); } } diff -r e323c74edabd src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java --- a/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java Tue May 27 21:46:45 2014 -0300 @@ -512,7 +512,7 @@ } static String qualifiedStringValue(String s1, String s234) { // Qualification by dot must decompose uniquely. Second string might already be qualified. - assert(s1.indexOf(".") < 0); + assert(s1.indexOf('.') < 0); return s1+"."+s234; } diff -r e323c74edabd src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java --- a/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/cosnaming/CorbanameUrl.java Tue May 27 21:46:45 2014 -0300 @@ -102,7 +102,7 @@ } location = url.substring(addrStart, addrEnd); - int keyStart = location.indexOf("/"); + int keyStart = location.indexOf('/'); if (keyStart >= 0) { // Has key string if (keyStart == (location.length() -1)) { diff -r e323c74edabd src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java --- a/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Tue May 27 21:46:45 2014 -0300 @@ -336,7 +336,7 @@ String url = "rmi://"; // Enclose IPv6 literal address in '[' and ']' - url = (host.indexOf(":") > -1) ? url + "[" + host + "]" : + url = (host.indexOf(':') > -1) ? url + "[" + host + "]" : url + host; if (port > 0) { url += ":" + Integer.toString(port); diff -r e323c74edabd src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java --- a/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java Tue May 27 21:46:45 2014 -0300 @@ -149,7 +149,7 @@ * foo:rest/of/name foo: */ protected String getURLPrefix(String url) throws NamingException { - int start = url.indexOf(":"); + int start = url.indexOf(':'); if (start < 0) { throw new OperationNotSupportedException("Invalid URL: " + url); @@ -160,7 +160,7 @@ start += 2; // skip double slash // find last slash - int posn = url.indexOf("/", start); + int posn = url.indexOf('/', start); if (posn >= 0) { start = posn; } else { diff -r e323c74edabd src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java --- a/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java Tue May 27 21:46:45 2014 -0300 @@ -303,7 +303,7 @@ offset = pname.length() - 1; - while ((last = pname.lastIndexOf(".", offset)) != -1) { + while ((last = pname.lastIndexOf('.', offset)) != -1) { pname = pname.substring(0, last+1) + "*"; x = permissions.get(pname); @@ -318,7 +318,7 @@ pname = p.getName(); offset = pname.length() - 1; - while ((last = pname.lastIndexOf("=", offset)) != -1) { + while ((last = pname.lastIndexOf('=', offset)) != -1) { pname = pname.substring(0, last+1) + "*"; x = permissions.get(pname); diff -r e323c74edabd src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Tue May 27 21:46:45 2014 -0300 @@ -6831,7 +6831,7 @@ // table name else isolate table name. indexFrom = command.toLowerCase().indexOf("from"); - indexComma = command.indexOf(",", indexFrom); + indexComma = command.indexOf(',', indexFrom); if(indexComma == -1) { // implies only one table diff -r e323c74edabd src/share/classes/com/sun/rowset/JoinRowSetImpl.java --- a/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/JoinRowSetImpl.java Tue May 27 21:46:45 2014 -0300 @@ -910,7 +910,7 @@ // now remove the last "," strWhereClause = strWhereClause.substring - (0, strWhereClause.lastIndexOf(",")); + (0, strWhereClause.lastIndexOf(',')); // Add from clause strWhereClause = strWhereClause.concat(" from "); @@ -920,7 +920,7 @@ //Remove the last "," strWhereClause = strWhereClause.substring - (0, strWhereClause.lastIndexOf(",")); + (0, strWhereClause.lastIndexOf(',')); // Add the where clause strWhereClause = strWhereClause.concat(" where "); diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java --- a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Tue May 27 21:46:45 2014 -0300 @@ -240,7 +240,7 @@ // Remove the string after "@xxxx" // before writing it to the xml file. String strProviderInstance = (caller.getSyncProvider()).toString(); - String strProvider = strProviderInstance.substring(0, (caller.getSyncProvider()).toString().indexOf("@")); + String strProvider = strProviderInstance.substring(0, (caller.getSyncProvider()).toString().indexOf('@')); propString("sync-provider-name", strProvider); propString("sync-provider-vendor", "Oracle Corporation"); diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Tue May 27 21:46:45 2014 -0300 @@ -1147,7 +1147,7 @@ if (nullValue) { rs.setSyncProvider(null); } else { - String str = s.substring(0,s.indexOf("@")+1); + String str = s.substring(0,s.indexOf('@')+1); rs.setSyncProvider(str); } break; diff -r e323c74edabd src/share/classes/com/sun/rowset/internal/XmlResolver.java --- a/src/share/classes/com/sun/rowset/internal/XmlResolver.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/rowset/internal/XmlResolver.java Tue May 27 21:46:45 2014 -0300 @@ -39,7 +39,7 @@ public class XmlResolver implements EntityResolver { public InputSource resolveEntity(String publicId, String systemId) { - String schemaName = systemId.substring(systemId.lastIndexOf("/")); + String schemaName = systemId.substring(systemId.lastIndexOf('/')); if(systemId.startsWith("http://java.sun.com/xml/ns/jdbc")) { return new InputSource(this.getClass().getResourceAsStream(schemaName)); diff -r e323c74edabd src/share/classes/com/sun/security/auth/module/JndiLoginModule.java --- a/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/module/JndiLoginModule.java Tue May 27 21:46:45 2014 -0300 @@ -694,7 +694,7 @@ throw new LoginException("Error: no CallbackHandler available " + "to garner authentication information from the user"); - String protocol = userProvider.substring(0, userProvider.indexOf(":")); + String protocol = userProvider.substring(0, userProvider.indexOf(':')); Callback[] callbacks = new Callback[2]; callbacks[0] = new NameCallback(protocol + " " diff -r e323c74edabd src/share/classes/com/sun/security/auth/module/LdapLoginModule.java --- a/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/security/auth/module/LdapLoginModule.java Tue May 27 21:46:45 2014 -0300 @@ -400,7 +400,7 @@ // Add any JNDI properties to the environment for (String key : options.keySet()) { - if (key.indexOf(".") > -1) { + if (key.indexOf('.') > -1) { ldapEnvironment.put(key, options.get(key)); } } diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java --- a/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java Tue May 27 21:46:45 2014 -0300 @@ -857,7 +857,7 @@ bpSpec = runtime.createClassLineBreakpoint(classId, lineNumber); } else { // Try stripping method from class.method token. - int idot = token.lastIndexOf("."); + int idot = token.lastIndexOf('.'); if ( (idot <= 0) || /* No dot or dot in first char */ (idot >= token.length() - 1) ) { /* dot in last char */ return null; diff -r e323c74edabd src/share/classes/com/sun/tools/example/debug/tty/Commands.java --- a/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/example/debug/tty/Commands.java Tue May 27 21:46:45 2014 -0300 @@ -1079,7 +1079,7 @@ } } else { // Try stripping method from class.method token. - int idot = token.lastIndexOf("."); + int idot = token.lastIndexOf('.'); if ( (idot <= 0) || /* No dot or dot in first char */ (idot >= token.length() - 1) ) { /* dot in last char */ printBreakpointCommandUsage(atForm, inForm); diff -r e323c74edabd src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java --- a/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Wed Apr 23 11:35:40 2014 -0700 +++ b/src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java Tue May 27 21:46:45 2014 -0300 @@ -67,7 +67,7 @@ continue; } String name = clazz.getName(); - int pos = name.lastIndexOf("."); + int pos = name.lastIndexOf('.'); String pkg; if (name.startsWith("[")) { // Only in ancient heap dumps pkg = ""; -------------- next part -------------- iff -r 28d1de89ff27 src/share/classes/sun/font/SunFontManager.java --- a/src/share/classes/sun/font/SunFontManager.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/font/SunFontManager.java Sat May 24 10:55:43 2014 -0300 @@ -2871,8 +2871,7 @@ new java.security.PrivilegedAction() { public Object run() { SecurityManager sm = System.getSecurityManager(); - return new Boolean - (sm instanceof sun.applet.AppletSecurity); + return sm instanceof sun.applet.AppletSecurity; } }); return appletSM.booleanValue(); diff -r 28d1de89ff27 src/share/classes/sun/management/StackTraceElementCompositeData.java --- a/src/share/classes/sun/management/StackTraceElementCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/StackTraceElementCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -68,7 +68,7 @@ ste.getMethodName(), ste.getFileName(), new Integer(ste.getLineNumber()), - new Boolean(ste.isNativeMethod()), + ste.isNativeMethod(), }; try { return new CompositeDataSupport(stackTraceElementCompositeType, diff -r 28d1de89ff27 src/share/classes/sun/management/ThreadInfoCompositeData.java --- a/src/share/classes/sun/management/ThreadInfoCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/ThreadInfoCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -120,8 +120,8 @@ new Long(threadInfo.getLockOwnerId()), threadInfo.getLockOwnerName(), stackTraceData, - new Boolean(threadInfo.isSuspended()), - new Boolean(threadInfo.isInNative()), + threadInfo.isSuspended(), + threadInfo.isInNative(), lockedMonitorsData, lockedSyncsData, }; diff -r 28d1de89ff27 src/share/classes/sun/management/VMOptionCompositeData.java --- a/src/share/classes/sun/management/VMOptionCompositeData.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/management/VMOptionCompositeData.java Sat May 24 10:55:43 2014 -0300 @@ -59,7 +59,7 @@ final Object[] vmOptionItemValues = { option.getName(), option.getValue(), - new Boolean(option.isWriteable()), + option.isWriteable(), option.getOrigin().toString(), }; diff -r 28d1de89ff27 src/share/classes/sun/security/jgss/GSSManagerImpl.java --- a/src/share/classes/sun/security/jgss/GSSManagerImpl.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/security/jgss/GSSManagerImpl.java Sat May 24 10:55:43 2014 -0300 @@ -50,8 +50,8 @@ if (osname.startsWith("SunOS") || osname.contains("OS X") || osname.startsWith("Linux")) { - return new Boolean(System.getProperty - (USE_NATIVE_PROP)); + return Boolean.valueOf(System.getProperty + (USE_NATIVE_PROP)); } return Boolean.FALSE; } diff -r 28d1de89ff27 src/share/classes/sun/security/provider/PolicyFile.java --- a/src/share/classes/sun/security/provider/PolicyFile.java Thu May 22 12:54:02 2014 -0700 +++ b/src/share/classes/sun/security/provider/PolicyFile.java Sat May 24 10:55:43 2014 -0300 @@ -1271,7 +1271,7 @@ Boolean imp = AccessController.doPrivileged (new PrivilegedAction() { public Boolean run() { - return new Boolean(entry.getCodeSource().implies(cs)); + return entry.getCodeSource().implies(cs); } }); if (!imp.booleanValue()) { From joel.franck at oracle.com Thu May 29 07:35:13 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 29 May 2014 09:35:13 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Message-ID: Hi, We need you send in the patches via the mailing list. Please reply to your mail with the diffs attached directly (not zipped for example). I?ll might have time to look at this next week, but it surprises me you need to patch hotspot. Allocations before we have inflated shouldn?t be a problem. Also do you have any data showing that this actually makes a difference? cheers /Joel On 28 maj 2014, at 23:44, Andrej Golovnin wrote: > Hi Joe, > > I have prepared a patch for the issue JDK-5043030. > The patch consists of two parts: one for jdk and one for hotspot. > You can find the webrevs here: > > JDK-patch: https://db.tt/7DYph0OH > Hotspot-patch: https://db.tt/hHsN0yn4 > > The JDK-patch has two tests to verify the changes. > > Please review it and I hope you can sponsor it. > > Best regards, > Andrej Golovnin > From andrej.golovnin at gmail.com Thu May 29 08:23:33 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 29 May 2014 10:23:33 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Message-ID: Hi Joel, > We need you send in the patches via the mailing list. Please reply to your mail with the diffs attached directly (not zipped for example). OK, will do that. But I always thought a webrev is the preferred and the best way to submit a patch. > I?ll might have time to look at this next week, but it surprises me you need to patch hotspot. Allocations before we have inflated shouldn?t be a problem. > Also do you have any data showing that this actually makes a difference? When you have for example following method: public int method() { return 0; } And you invoke this method over the reflection API, then the first N invocations are done via the native code. The returned value must be wrapped. Currently this is done by the following call java_lang_boxing_object::create(type, value, CHECK_NULL); in reflection.cpp. This method allocates a new object. As I wrote in my previous mail, the JDK patch contains two regression tests for jtreg to verify my changes. If you run this tests using current JDK9, than the tests will fail. After applying my patches the tests executed without any problem. Best regards, Andrej Golovnin > > cheers > /Joel > > On 28 maj 2014, at 23:44, Andrej Golovnin wrote: > >> Hi Joe, >> >> I have prepared a patch for the issue JDK-5043030. >> The patch consists of two parts: one for jdk and one for hotspot. >> You can find the webrevs here: >> >> JDK-patch: https://db.tt/7DYph0OH >> Hotspot-patch: https://db.tt/hHsN0yn4 >> >> The JDK-patch has two tests to verify the changes. >> >> Please review it and I hope you can sponsor it. >> >> Best regards, >> Andrej Golovnin >> > From andrej.golovnin at gmail.com Thu May 29 08:23:39 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 29 May 2014 10:23:39 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Message-ID: <80784503-54AA-4C1C-8F4C-3ADB5099DE08@gmail.com> Hi all, as requested here are the patches as diffs. Best regards, Andrej Golovnin -------------- next part -------------- On 28.05.2014, at 23:44, Andrej Golovnin wrote: > Hi Joe, > > I have prepared a patch for the issue JDK-5043030. > The patch consists of two parts: one for jdk and one for hotspot. > You can find the webrevs here: > > JDK-patch: https://db.tt/7DYph0OH > Hotspot-patch: https://db.tt/hHsN0yn4 > > The JDK-patch has two tests to verify the changes. > > Please review it and I hope you can sponsor it. > > Best regards, > Andrej Golovnin > From miroslav.kos at oracle.com Thu May 29 08:46:43 2014 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Thu, 29 May 2014 10:46:43 +0200 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <20140526185012.Horde.pqzOumYEioNbp1Op6FWtNw7@webmail.your-server.de> References: <537A08D0.9030404@oracle.com> <20140526185012.Horde.pqzOumYEioNbp1Op6FWtNw7@webmail.your-server.de> Message-ID: <5386F3F3.5040402@oracle.com> Hi Hajo, I agree with you, this issue means major loss of functionality. I already started processing backport to jdk8 and after that will continue with jdk7. Thanks Miran On 26/05/14 18:50, info at kliemeck.de wrote: > Hey Miroslav, > > is this correct that the issue will be fixed on jdk9 only (as stated > on https://bugs.openjdk.java.net/browse/JDK-8043129). Since this is a > major loss of functionality which we encountered too, this should be > fixed with the next jdk 7 release. > > Regards > Hajo > > Quoting miroslav.kos at oracle.com: > >> Hi, >> this is review request for: >> >> 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 >> WEBREV: >> http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ >> http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) >> >> This solves conflict between JAF handlers for JAX-WS and javax.mail. The >> issue has been introduced in the latest CPU. >> >> Thanks >> Miran > > > From joel.franck at oracle.com Thu May 29 09:12:06 2014 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 29 May 2014 11:12:06 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Message-ID: <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> Hello, On 29 maj 2014, at 10:23, Andrej Golovnin wrote: > Hi Joel, > >> We need you send in the patches via the mailing list. Please reply to your mail with the diffs attached directly (not zipped for example). > > OK, will do that. But I always thought a webrev is > the preferred and the best way to submit a patch. You are right that webrevs are preferred for reviewing, but we also need the contribution submitted through openjdk infrastructure. BTW it looks like your attachments were stripped. >> I?ll might have time to look at this next week, but it surprises me you need to patch hotspot. Allocations before we have inflated shouldn?t be a problem. >> Also do you have any data showing that this actually makes a difference? > > When you have for example following method: > > public int method() { > return 0; > } > > And you invoke this method over the reflection API, > then the first N invocations are done via the native code. Yes, this is before inflation. Inflation happens after 15 calls IIRC, which is why I don?t think it matters from a performance standpoint. > The returned value must be wrapped. Currently this is > done by the following call > > java_lang_boxing_object::create(type, value, CHECK_NULL); > > in reflection.cpp. This method allocates a new object. > > As I wrote in my previous mail, the JDK patch contains > two regression tests for jtreg to verify my changes. > If you run this tests using current JDK9, than the tests will fail. > After applying my patches the tests executed without any problem. Your tests show that the valueOf caches are used which is good. However the byte code spinning is a core piece of reflection that is currently in production in countless places. A change in this area should not only be obviously correct and thouroghly tested, you must show "real world? benefit. Ideally you should be able to show significant reduction in allocation in some application. cheers /Joel From andrej.golovnin at gmail.com Thu May 29 10:12:06 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 29 May 2014 12:12:06 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> Message-ID: Hi all, as requested here are the diffs again as they were stripped last time. Best regards, Andrej Golovnin On Wed, May 28, 2014 at 11:44 PM, Andrej Golovnin wrote: > Hi Joe, > > I have prepared a patch for the issue JDK-5043030. > The patch consists of two parts: one for jdk and one for hotspot. > You can find the webrevs here: > > JDK-patch: https://db.tt/7DYph0OH > Hotspot-patch: https://db.tt/hHsN0yn4 > > The JDK-patch has two tests to verify the changes. > > Please review it and I hope you can sponsor it. > > Best regards, > Andrej Golovnin > > -------------- next part -------------- diff --git a/src/share/vm/prims/jvm.cpp b/src/share/vm/prims/jvm.cpp --- a/src/share/vm/prims/jvm.cpp +++ b/src/share/vm/prims/jvm.cpp @@ -3995,15 +3995,6 @@ objArrayHandle args(THREAD, objArrayOop(JNIHandles::resolve(args0))); oop result = Reflection::invoke_method(method_handle(), receiver, args, CHECK_NULL); jobject res = JNIHandles::make_local(env, result); - if (JvmtiExport::should_post_vm_object_alloc()) { - oop ret_type = java_lang_reflect_Method::return_type(method_handle()); - assert(ret_type != NULL, "sanity check: ret_type oop must not be NULL!"); - if (java_lang_Class::is_primitive(ret_type)) { - // Only for primitive type vm allocates memory for java object. - // See box() method. - JvmtiExport::post_vm_object_alloc(JavaThread::current(), result); - } - } return res; } else { THROW_0(vmSymbols::java_lang_StackOverflowError()); diff --git a/src/share/vm/runtime/reflection.cpp b/src/share/vm/runtime/reflection.cpp --- a/src/share/vm/runtime/reflection.cpp +++ b/src/share/vm/runtime/reflection.cpp @@ -89,7 +89,63 @@ // regular objects are not boxed return (oop) value->l; } - oop result = java_lang_boxing_object::create(type, value, CHECK_NULL); + JavaCallArguments args; + Klass* wrapper_klass; + Symbol* valueOf_signature; + switch (type) { + case T_BOOLEAN: + args.push_int(value->z); + wrapper_klass = SystemDictionary::Boolean_klass(); + valueOf_signature = vmSymbols::Boolean_valueOf_signature(); + break; + case T_CHAR: + args.push_int(value->c); + wrapper_klass = SystemDictionary::Character_klass(); + valueOf_signature = vmSymbols::Character_valueOf_signature(); + break; + case T_BYTE: + args.push_int(value->b); + wrapper_klass = SystemDictionary::Byte_klass(); + valueOf_signature = vmSymbols::Byte_valueOf_signature(); + break; + case T_SHORT: + args.push_int(value->s); + wrapper_klass = SystemDictionary::Short_klass(); + valueOf_signature = vmSymbols::Short_valueOf_signature(); + break; + case T_INT: + args.push_int(value->i); + wrapper_klass = SystemDictionary::Integer_klass(); + valueOf_signature = vmSymbols::Integer_valueOf_signature(); + break; + case T_LONG: + args.push_long(value->j); + wrapper_klass = SystemDictionary::Long_klass(); + valueOf_signature = vmSymbols::Long_valueOf_signature(); + break; + case T_FLOAT: + args.push_float(value->f); + wrapper_klass = SystemDictionary::Float_klass(); + valueOf_signature = vmSymbols::Float_valueOf_signature(); + break; + case T_DOUBLE: + args.push_double(value->d); + wrapper_klass = SystemDictionary::Double_klass(); + valueOf_signature = vmSymbols::Double_valueOf_signature(); + break; + default: + THROW_MSG_0(vmSymbols::java_lang_IllegalArgumentException(), "argument type mismatch"); + } + instanceKlassHandle klass_handle(THREAD, wrapper_klass); + JavaValue boxed_value(T_OBJECT); + JavaCalls::call_static(&boxed_value, + klass_handle, + vmSymbols::valueOf_name(), + valueOf_signature, + &args, + THREAD); + + oop result = (oop) boxed_value.get_jobject(); if (result == NULL) { THROW_(vmSymbols::java_lang_IllegalArgumentException(), result); } -------------- next part -------------- diff --git a/src/share/classes/sun/reflect/AccessorGenerator.java b/src/share/classes/sun/reflect/AccessorGenerator.java --- a/src/share/classes/sun/reflect/AccessorGenerator.java +++ b/src/share/classes/sun/reflect/AccessorGenerator.java @@ -69,33 +69,34 @@ protected short codeIdx; protected short exceptionsIdx; // Boxing + protected short valueOfIdx; protected short booleanIdx; - protected short booleanCtorIdx; + protected short booleanBoxIdx; protected short booleanUnboxIdx; protected short byteIdx; - protected short byteCtorIdx; + protected short byteBoxIdx; protected short byteUnboxIdx; protected short characterIdx; - protected short characterCtorIdx; + protected short characterBoxIdx; protected short characterUnboxIdx; protected short doubleIdx; - protected short doubleCtorIdx; + protected short doubleBoxIdx; protected short doubleUnboxIdx; protected short floatIdx; - protected short floatCtorIdx; + protected short floatBoxIdx; protected short floatUnboxIdx; protected short integerIdx; - protected short integerCtorIdx; + protected short integerBoxIdx; protected short integerUnboxIdx; protected short longIdx; - protected short longCtorIdx; + protected short longBoxIdx; protected short longUnboxIdx; protected short shortIdx; - protected short shortCtorIdx; + protected short shortBoxIdx; protected short shortUnboxIdx; protected final short NUM_COMMON_CPOOL_ENTRIES = (short) 30; - protected final short NUM_BOXING_CPOOL_ENTRIES = (short) 72; + protected final short NUM_BOXING_CPOOL_ENTRIES = (short) 73; // Requires that superClass has been set up protected void emitCommonConstantPoolEntries() { @@ -181,9 +182,10 @@ /** Constant pool entries required to be able to box/unbox primitive types. Note that we don't emit these if we don't need them. */ protected void emitBoxingContantPoolEntries() { + // * [UTF-8] "valueOf" // * [UTF-8] "java/lang/Boolean" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(Z)V" + // * [UTF-8] "(Z)Ljava/lang/Boolean;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "booleanValue" @@ -192,7 +194,7 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Byte" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(B)V" + // * [UTF-8] "(B)Ljava/lang/Byte;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "byteValue" @@ -201,7 +203,7 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Character" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(C)V" + // * [UTF-8] "(C)Ljava/lang/Character;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "charValue" @@ -210,7 +212,7 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Double" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(D)V" + // * [UTF-8] "(D)Ljava/lang/Double;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "doubleValue" @@ -219,7 +221,7 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Float" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(F)V" + // * [UTF-8] "(F)Ljava/lang/Float;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "floatValue" @@ -228,7 +230,7 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Integer" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(I)V" + // * [UTF-8] "(I)Ljava/lang/Integer;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "intValue" @@ -237,7 +239,7 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Long" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(J)V" + // * [UTF-8] "(J)Ljava/lang/Long;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "longValue" @@ -246,21 +248,26 @@ // * [CONSTANT_Methodref_info] for above // * [UTF-8] "java/lang/Short" // * [CONSTANT_Class_info] for above - // * [UTF-8] "(S)V" + // * [UTF-8] "(S)Ljava/lang/Short;" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above // * [UTF-8] "shortValue" // * [UTF-8] "()S" // * [CONSTANT_NameAndType_info] for above // * [CONSTANT_Methodref_info] for above + + // valueOf-method name + asm.emitConstantPoolUTF8("valueOf"); + valueOfIdx = asm.cpi(); + // Boolean asm.emitConstantPoolUTF8("java/lang/Boolean"); asm.emitConstantPoolClass(asm.cpi()); booleanIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(Z)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(Z)Ljava/lang/Boolean;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - booleanCtorIdx = asm.cpi(); + booleanBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("booleanValue"); asm.emitConstantPoolUTF8("()Z"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -271,10 +278,10 @@ asm.emitConstantPoolUTF8("java/lang/Byte"); asm.emitConstantPoolClass(asm.cpi()); byteIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(B)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(B)Ljava/lang/Byte;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - byteCtorIdx = asm.cpi(); + byteBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("byteValue"); asm.emitConstantPoolUTF8("()B"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -285,10 +292,10 @@ asm.emitConstantPoolUTF8("java/lang/Character"); asm.emitConstantPoolClass(asm.cpi()); characterIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(C)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(C)Ljava/lang/Character;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - characterCtorIdx = asm.cpi(); + characterBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("charValue"); asm.emitConstantPoolUTF8("()C"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -299,10 +306,10 @@ asm.emitConstantPoolUTF8("java/lang/Double"); asm.emitConstantPoolClass(asm.cpi()); doubleIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(D)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(D)Ljava/lang/Double;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - doubleCtorIdx = asm.cpi(); + doubleBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("doubleValue"); asm.emitConstantPoolUTF8("()D"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -313,10 +320,10 @@ asm.emitConstantPoolUTF8("java/lang/Float"); asm.emitConstantPoolClass(asm.cpi()); floatIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(F)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(F)Ljava/lang/Float;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - floatCtorIdx = asm.cpi(); + floatBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("floatValue"); asm.emitConstantPoolUTF8("()F"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -327,10 +334,10 @@ asm.emitConstantPoolUTF8("java/lang/Integer"); asm.emitConstantPoolClass(asm.cpi()); integerIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(I)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(I)Ljava/lang/Integer;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - integerCtorIdx = asm.cpi(); + integerBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("intValue"); asm.emitConstantPoolUTF8("()I"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -341,10 +348,10 @@ asm.emitConstantPoolUTF8("java/lang/Long"); asm.emitConstantPoolClass(asm.cpi()); longIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(J)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(J)Ljava/lang/Long;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - longCtorIdx = asm.cpi(); + longBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("longValue"); asm.emitConstantPoolUTF8("()J"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -355,10 +362,10 @@ asm.emitConstantPoolUTF8("java/lang/Short"); asm.emitConstantPoolClass(asm.cpi()); shortIdx = asm.cpi(); - asm.emitConstantPoolUTF8("(S)V"); - asm.emitConstantPoolNameAndType(initIdx, asm.cpi()); + asm.emitConstantPoolUTF8("(S)Ljava/lang/Short;"); + asm.emitConstantPoolNameAndType(valueOfIdx, asm.cpi()); asm.emitConstantPoolMethodref(sub(asm.cpi(), S2), asm.cpi()); - shortCtorIdx = asm.cpi(); + shortBoxIdx = asm.cpi(); asm.emitConstantPoolUTF8("shortValue"); asm.emitConstantPoolUTF8("()S"); asm.emitConstantPoolNameAndType(sub(asm.cpi(), S1), asm.cpi()); @@ -515,23 +522,23 @@ throw new InternalError("Should have found primitive type"); } - protected short ctorIndexForPrimitiveType(Class type) { + protected short boxingMethodForPrimitiveType(Class type) { if (type == Boolean.TYPE) { - return booleanCtorIdx; + return booleanBoxIdx; } else if (type == Byte.TYPE) { - return byteCtorIdx; + return byteBoxIdx; } else if (type == Character.TYPE) { - return characterCtorIdx; + return characterBoxIdx; } else if (type == Double.TYPE) { - return doubleCtorIdx; + return doubleBoxIdx; } else if (type == Float.TYPE) { - return floatCtorIdx; + return floatBoxIdx; } else if (type == Integer.TYPE) { - return integerCtorIdx; + return integerBoxIdx; } else if (type == Long.TYPE) { - return longCtorIdx; + return longBoxIdx; } else if (type == Short.TYPE) { - return shortCtorIdx; + return shortBoxIdx; } throw new InternalError("Should have found primitive type"); } diff --git a/src/share/classes/sun/reflect/MethodAccessorGenerator.java b/src/share/classes/sun/reflect/MethodAccessorGenerator.java --- a/src/share/classes/sun/reflect/MethodAccessorGenerator.java +++ b/src/share/classes/sun/reflect/MethodAccessorGenerator.java @@ -660,9 +660,9 @@ if (!isConstructor) { // Box return value if necessary if (isPrimitive(returnType)) { - cb.opc_invokespecial(ctorIndexForPrimitiveType(returnType), - typeSizeInStackSlots(returnType), - 0); + cb.opc_invokestatic(boxingMethodForPrimitiveType(returnType), + typeSizeInStackSlots(returnType), + 0); } else if (returnType == Void.TYPE) { cb.opc_aconst_null(); } diff --git a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Double(getDouble(obj)); + return Double.valueOf(getDouble(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Float(getFloat(obj)); + return Float.valueOf(getFloat(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Double(getDouble(obj)); + return Double.valueOf(getDouble(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Float(getFloat(obj)); + return Float.valueOf(getFloat(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Double(getDouble(obj)); + return Double.valueOf(getDouble(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Float(getFloat(obj)); + return Float.valueOf(getFloat(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java @@ -35,7 +35,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Boolean(getBoolean(obj)); + return Boolean.valueOf(getBoolean(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Byte(getByte(obj)); + return Byte.valueOf(getByte(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Character(getChar(obj)); + return Character.valueOf(getChar(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Double(getDouble(obj)); + return Double.valueOf(getDouble(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Float(getFloat(obj)); + return Float.valueOf(getFloat(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Integer(getInt(obj)); + return Integer.valueOf(getInt(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Long(getLong(obj)); + return Long.valueOf(getLong(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java b/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java --- a/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java +++ b/src/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java @@ -33,7 +33,7 @@ } public Object get(Object obj) throws IllegalArgumentException { - return new Short(getShort(obj)); + return Short.valueOf(getShort(obj)); } public boolean getBoolean(Object obj) throws IllegalArgumentException { diff --git a/test/java/lang/reflect/Field/TestFieldReflectValueOf.java b/test/java/lang/reflect/Field/TestFieldReflectValueOf.java new file mode 100644 --- /dev/null +++ b/test/java/lang/reflect/Field/TestFieldReflectValueOf.java @@ -0,0 +1,172 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 5043030 + * @summary The language requires caching wrapper instances for well defined + * ranges, e.g. Integers in the range -128 to 127. + * @author Andrej Golovnin + */ + +import java.lang.reflect.Field; + +public class TestFieldReflectValueOf { + + @SuppressWarnings("unused") + private static boolean booleanStaticField; + @SuppressWarnings("unused") + private static byte byteStaticField; + @SuppressWarnings("unused") + private static char charStaticField; + @SuppressWarnings("unused") + private static int intStaticField; + @SuppressWarnings("unused") + private static long longStaticField; + @SuppressWarnings("unused") + private static short shortStaticField; + + @SuppressWarnings("unused") + private static volatile boolean booleanStaticVolatileField; + @SuppressWarnings("unused") + private static volatile byte byteStaticVolatileField; + @SuppressWarnings("unused") + private static volatile char charStaticVolatileField; + @SuppressWarnings("unused") + private static volatile int intStaticVolatileField; + @SuppressWarnings("unused") + private static volatile long longStaticVolatileField; + @SuppressWarnings("unused") + private static volatile short shortStaticVolatileField; + + @SuppressWarnings("unused") + private boolean booleanField; + @SuppressWarnings("unused") + private byte byteField; + @SuppressWarnings("unused") + private char charField; + @SuppressWarnings("unused") + private int intField; + @SuppressWarnings("unused") + private long longField; + @SuppressWarnings("unused") + private short shortField; + + @SuppressWarnings("unused") + private volatile boolean booleanVolatileField; + @SuppressWarnings("unused") + private volatile byte byteVolatileField; + @SuppressWarnings("unused") + private volatile char charVolatileField; + @SuppressWarnings("unused") + private volatile int intVolatileField; + @SuppressWarnings("unused") + private volatile long longVolatileField; + @SuppressWarnings("unused") + private volatile short shortVolatileField; + + public static void main(String[] args) { + testUnsafeStaticFieldAccessors(); + testUnsafeQualifiedStaticFieldAccessors(); + testUnsafeFieldAccessors(); + testUnsafeQualifiedFieldAccessors(); + } + + private static void testUnsafeStaticFieldAccessors() { + testFieldAccessors(true, false); + } + + private static void testUnsafeQualifiedStaticFieldAccessors() { + testFieldAccessors(true, true); + } + + private static void testUnsafeFieldAccessors() { + testFieldAccessors(false, false); + } + + private static void testUnsafeQualifiedFieldAccessors() { + testFieldAccessors(false, true); + } + + private static void testFieldAccessors(boolean checkStatic, + boolean checkVolatile) + { + // Boolean#valueOf test + testField(Boolean.TYPE, Boolean.FALSE, checkStatic, checkVolatile); + testField(Boolean.TYPE, Boolean.TRUE, checkStatic, checkVolatile); + + // Byte#valueOf test + for (int b = Byte.MIN_VALUE; b < (Byte.MAX_VALUE + 1); b++) { + testField(Byte.TYPE, Byte.valueOf((byte) b), checkStatic, checkVolatile); + } + + // Character#valueOf test + for (char c = '\u0000'; c <= '\u007F'; c++) { + testField(Character.TYPE, Character.valueOf(c), checkStatic, checkVolatile); + } + + // Integer#valueOf test + for (int i = -128; i <= 127; i++) { + testField(Integer.TYPE, Integer.valueOf(i), checkStatic, checkVolatile); + } + + // Long#valueOf test + for (long l = -128L; l <= 127L; l++) { + testField(Long.TYPE, Long.valueOf(l), checkStatic, checkVolatile); + } + + // Short#valueOf test + for (short s = -128; s <= 127; s++) { + testField(Short.TYPE, Short.valueOf(s), checkStatic, checkVolatile); + } + } + + private static void testField(Class primType, Object wrappedValue, + boolean checkStatic, boolean checkVolatile) + { + String fieldName = primType.getName(); + if (checkStatic) { + fieldName += "Static"; + } + if (checkVolatile) { + fieldName += "Volatile"; + } + fieldName += "Field"; + try { + Field field = TestFieldReflectValueOf.class.getDeclaredField(fieldName); + field.setAccessible(true); + TestFieldReflectValueOf obj = new TestFieldReflectValueOf(); + field.set(obj, wrappedValue); + Object result = field.get(obj); + if (result != wrappedValue) { + throw new RuntimeException("Value " + wrappedValue + + " is not cached for type " + primType); + } + } catch ( NoSuchFieldException | SecurityException + | IllegalAccessException | IllegalArgumentException e) + { + throw new RuntimeException(e); + } + } + +} diff --git a/test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java b/test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java new file mode 100644 --- /dev/null +++ b/test/java/lang/reflect/Method/invoke/TestMethodReflectValueOf.java @@ -0,0 +1,112 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 5043030 + * @summary The language requires caching wrapper instances for well defined + * ranges, e.g. Integers in the range -128 to 127. + * @author Andrej Golovnin + * @run main/othervm -Dsun.reflect.noInflation=true TestMethodReflectValueOf + * @run main/othervm -Dsun.reflect.noInflation=false -Dsun.reflect.inflationThreshold=500 TestMethodReflectValueOf + */ + +import java.lang.reflect.InvocationTargetException; +import java.lang.reflect.Method; + + +public class TestMethodReflectValueOf { + + public static void main(String[] args) { + // Boolean#valueOf test + testMethod(Boolean.TYPE, Boolean.FALSE); + testMethod(Boolean.TYPE, Boolean.TRUE); + + // Byte#valueOf test + for (int b = Byte.MIN_VALUE; b < (Byte.MAX_VALUE + 1); b++) { + testMethod(Byte.TYPE, Byte.valueOf((byte) b)); + } + + // Character#valueOf test + for (char c = '\u0000'; c <= '\u007F'; c++) { + testMethod(Character.TYPE, Character.valueOf(c)); + } + + // Integer#valueOf test + for (int i = -128; i <= 127; i++) { + testMethod(Integer.TYPE, Integer.valueOf(i)); + } + + // Long#valueOf test + for (long l = -128L; l <= 127L; l++) { + testMethod(Long.TYPE, Long.valueOf(l)); + } + + // Short#valueOf test + for (short s = -128; s <= 127; s++) { + testMethod(Short.TYPE, Short.valueOf(s)); + } + } + + public static void testMethod(Class primType, Object wrappedValue) { + String methodName = primType.getName() + "Method"; + try { + Method method = TestMethodReflectValueOf.class.getMethod(methodName, primType); + Object result = method.invoke(new TestMethodReflectValueOf(), wrappedValue); + if (result != wrappedValue) { + throw new RuntimeException("Value " + wrappedValue + + " is not cached for type " + primType); + } + } catch ( NoSuchMethodException | SecurityException + | IllegalAccessException | IllegalArgumentException + | InvocationTargetException e) + { + throw new RuntimeException(e); + } + } + + public int intMethod(int value) { + return value; + } + + public long longMethod(long value) { + return value; + } + + public short shortMethod(short value) { + return value; + } + + public byte byteMethod(byte value) { + return value; + } + + public char charMethod(char value) { + return value; + } + + public boolean booleanMethod(boolean value) { + return value; + } + +} From andrej.golovnin at gmail.com Thu May 29 10:45:24 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 29 May 2014 12:45:24 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> Message-ID: <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> Hi Joel, >> When you have for example following method: >> >> public int method() { >> return 0; >> } >> >> And you invoke this method over the reflection API, >> then the first N invocations are done via the native code. > > Yes, this is before inflation. Inflation happens after 15 calls IIRC, which is why I don?t think it matters from a performance standpoint. I would say, It depends on how do you define "matters". I personally don't care about the native part in this case, as I always set "sun.reflect.noInflation=true". But I think the changes to Hotspot are just needed for the correctness of the fix. > > Your tests show that the valueOf caches are used which is good. However the byte code spinning is a core piece of reflection that is currently in production in countless places. A change in this area should not only be obviously correct and thouroghly tested That's why we do the code review. ;-) > , you must show "real world? benefit. Ideally you should be able to show significant reduction in allocation in some application. I'm working on a product which has ca. 3 million lines of code and make direct and indirect use of Reflection API. And in one of our use cases I see, that JVM allocates ca. 9GB of Boolean objects. All of them are allocated through the usage of Reflection API. Even that most of this objects are allocated in TLABs and are removed by GC when the use case is finished, I would say we have allocated 9GB of Boolean objects to much. Or do you see it differently? Let me know, if you need more data or if I should write some test. If don't want accept the patch, then it's OK. But in this case you should close the issue 5043030 and explain why it won't be fixed. Best regards, Andrej Golovnin From david.holmes at oracle.com Thu May 29 11:06:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 May 2014 21:06:23 +1000 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> Message-ID: <538714AF.4020105@oracle.com> Hi Andrej, The hotspot changes need to be reviewed by hotspot developers so I've cc'd the runtime team. On 29/05/2014 8:45 PM, Andrej Golovnin wrote: > Hi Joel, > >>> When you have for example following method: >>> >>> public int method() { >>> return 0; >>> } >>> >>> And you invoke this method over the reflection API, >>> then the first N invocations are done via the native code. >> >> Yes, this is before inflation. Inflation happens after 15 calls IIRC, which is why I don?t think it matters from a performance standpoint. > > I would say, It depends on how do you define "matters". I personally don't care > about the native part in this case, as I always set "sun.reflect.noInflation=true". > But I think the changes to Hotspot are just needed for the correctness of the fix. The valueOf calls may also allocate a new object so you can't just delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you can't tell whether a new object was allocated or not. It is only for the smaller primitive types that any kind of Object caching is mandated. David ----- >> >> Your tests show that the valueOf caches are used which is good. However the byte code spinning is a core piece of reflection that is currently in production in countless places. A change in this area should not only be obviously correct and thouroghly tested > > That's why we do the code review. ;-) > >> , you must show "real world? benefit. Ideally you should be able to show significant reduction in allocation in some application. > > I'm working on a product which has ca. 3 million lines of code and make > direct and indirect use of Reflection API. And in one of our use cases > I see, that JVM allocates ca. 9GB of Boolean objects. All of them are > allocated through the usage of Reflection API. Even that most of this > objects are allocated in TLABs and are removed by GC when the use > case is finished, I would say we have allocated 9GB of Boolean objects > to much. Or do you see it differently? > > Let me know, if you need more data or if I should write some test. > > If don't want accept the patch, then it's OK. But in this case you > should close the issue 5043030 and explain why it won't be fixed. > > Best regards, > Andrej Golovnin > From david.holmes at oracle.com Thu May 29 11:09:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 May 2014 21:09:28 +1000 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <538714AF.4020105@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> Message-ID: <53871568.8070203@oracle.com> Correction ... On 29/05/2014 9:06 PM, David Holmes wrote: > Hi Andrej, > > The hotspot changes need to be reviewed by hotspot developers so I've > cc'd the runtime team. > > On 29/05/2014 8:45 PM, Andrej Golovnin wrote: >> Hi Joel, >> >>>> When you have for example following method: >>>> >>>> public int method() { >>>> return 0; >>>> } >>>> >>>> And you invoke this method over the reflection API, >>>> then the first N invocations are done via the native code. >>> >>> Yes, this is before inflation. Inflation happens after 15 calls IIRC, >>> which is why I don?t think it matters from a performance standpoint. >> >> I would say, It depends on how do you define "matters". I personally >> don't care >> about the native part in this case, as I always set >> "sun.reflect.noInflation=true". >> But I think the changes to Hotspot are just needed for the correctness >> of the fix. > > The valueOf calls may also allocate a new object so you can't just > delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you > can't tell whether a new object was allocated or not. It is only for the > smaller primitive types that any kind of Object caching is mandated. It is only for the smaller values (-128 to +127) of the integer primitives types (plus boolean) that caching is mandated. Float.valueOf and Double.valueOf always create objects. David > David > ----- > >>> >>> Your tests show that the valueOf caches are used which is good. >>> However the byte code spinning is a core piece of reflection that is >>> currently in production in countless places. A change in this area >>> should not only be obviously correct and thouroghly tested >> >> That's why we do the code review. ;-) >> >>> , you must show "real world? benefit. Ideally you should be able to >>> show significant reduction in allocation in some application. >> >> I'm working on a product which has ca. 3 million lines of code and make >> direct and indirect use of Reflection API. And in one of our use cases >> I see, that JVM allocates ca. 9GB of Boolean objects. All of them are >> allocated through the usage of Reflection API. Even that most of this >> objects are allocated in TLABs and are removed by GC when the use >> case is finished, I would say we have allocated 9GB of Boolean objects >> to much. Or do you see it differently? >> >> Let me know, if you need more data or if I should write some test. >> >> If don't want accept the patch, then it's OK. But in this case you >> should close the issue 5043030 and explain why it won't be fixed. >> >> Best regards, >> Andrej Golovnin >> From info at kliemeck.de Thu May 29 11:38:55 2014 From: info at kliemeck.de (Hans-Joachim Kliemeck) Date: Thu, 29 May 2014 13:38:55 +0200 Subject: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail In-Reply-To: <5386F3F3.5040402@oracle.com> References: <537A08D0.9030404@oracle.com> <20140526185012.Horde.pqzOumYEioNbp1Op6FWtNw7@webmail.your-server.de> <5386F3F3.5040402@oracle.com> Message-ID: <20140529133855.Horde.VhYVNyIKgHCcP_a1m-jJ8Q2@webmail.your-server.de> Hey Miroslav, thanks! Regards Hans-Joachim Quoting Miroslav Kos : > Hi Hajo, > I agree with you, this issue means major loss of functionality. I > already started processing backport to jdk8 and after that will > continue with jdk7. > > Thanks > Miran > > > On 26/05/14 18:50, Hans-Joachim Kliemeck > wrote: >> Hey Miroslav, >> >> is this correct that the issue will be fixed on jdk9 only (as >> stated on https://bugs.openjdk.java.net/browse/JDK-8043129). Since >> this is a major loss of functionality which we encountered too, >> this should be fixed with the next jdk 7 release. >> >> Regards >> Hajo >> >> Quoting miroslav.kos at oracle.com: >> >>> Hi, >>> this is review request for: >>> >>> 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043129 >>> WEBREV: >>> http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/ >>> http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test) >>> >>> This solves conflict between JAF handlers for JAX-WS and javax.mail. The >>> issue has been introduced in the latest CPU. >>> >>> Thanks >>> Miran >> >> >> From bruno.do.medeiros at gmail.com Thu May 29 11:52:09 2014 From: bruno.do.medeiros at gmail.com (Bruno Medeiros) Date: Thu, 29 May 2014 12:52:09 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: References: Message-ID: Any update on this? Has it been placed in the JVM bug database and/or have people tried to replicated it? (again note, it only appears to happen on JVM 7) On Tue, May 6, 2014 at 9:20 PM, Bruno Medeiros wrote: > After much chopping, I have finally narrowed it down to a single source > file, and no external dependencies (other than starting Windows' cmd.exe > process) : > > https://github.com/bruno-medeiros/Scratchpad/blob/jvm-processio-issue/jvm_process_bug/src/JVMProcessBug.java > > In this final form, I am now able to replicated the bug in my machine on > many different runs of the program even beyond the first one after booting. > But it doesn't occur every time, only about two thirds the time. > Tried running it again with JVM 8 several times but never got it to > reproduce there. Maybe it really isn't present in JVM 8, only 7. Hopefully > this should be enough for JVM developers to replicate it. > > > -- > Bruno Medeiros > https://twitter.com/brunodomedeiros > -- Bruno Medeiros https://twitter.com/brunodomedeiros From andrej.golovnin at gmail.com Thu May 29 12:24:09 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Thu, 29 May 2014 14:24:09 +0200 Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection In-Reply-To: <53871568.8070203@oracle.com> References: <61880398-2F5F-4569-96E6-2C8A0D53BAE6@gmail.com> <55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com> <2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com> <538714AF.4020105@oracle.com> <53871568.8070203@oracle.com> Message-ID: Hi David, >> >> The valueOf calls may also allocate a new object so you can't just >> delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you >> can't tell whether a new object was allocated or not. It is only for the >> smaller primitive types that any kind of Object caching is mandated. > > It is only for the smaller values (-128 to +127) of the integer primitives types (plus boolean) that caching is mandated. Float.valueOf and Double.valueOf always create objects. > You are right, that #valueOf call may allocate an object. But as far as I understand currently the JvmtiExport::post_vm_object_alloc call is only needed, because today the native code itself allocates an object by calling java_lang_boxing_object::create(type, value, CHECK_NULL);. My code changes this behavior and delegates object allocation back to Java by calling JavaCalls::call_static(&boxed_value, klass_handle, vmSymbols::valueOf_name(), valueOf_signature, &args, THREAD); But maybe I misunderstood the implementation of JavaCalls. Best regards, Andrej Golovnin From roger.riggs at oracle.com Thu May 29 13:32:03 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 29 May 2014 09:32:03 -0400 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: References: Message-ID: <538736D3.6010400@oracle.com> Hi Bruno, Create an issue: JDK-8044321 EOF does not occur reading input from spawned cmd.exe process I was able to reproduce it on java 7 but not java 8. The implementation of Process does not mix handling of one Process instance with another so it may be an interaction specific to cmd.exe. Roger On 5/29/2014 7:52 AM, Bruno Medeiros wrote: > Any update on this? Has it been placed in the JVM bug database and/or have > people tried to replicated it? (again note, it only appears to happen on > JVM 7) > > > On Tue, May 6, 2014 at 9:20 PM, Bruno Medeiros > wrote: > >> After much chopping, I have finally narrowed it down to a single source >> file, and no external dependencies (other than starting Windows' cmd.exe >> process) : >> >> https://github.com/bruno-medeiros/Scratchpad/blob/jvm-processio-issue/jvm_process_bug/src/JVMProcessBug.java >> >> In this final form, I am now able to replicated the bug in my machine on >> many different runs of the program even beyond the first one after booting. >> But it doesn't occur every time, only about two thirds the time. >> Tried running it again with JVM 8 several times but never got it to >> reproduce there. Maybe it really isn't present in JVM 8, only 7. Hopefully >> this should be enough for JVM developers to replicate it. >> >> >> -- >> Bruno Medeiros >> https://twitter.com/brunodomedeiros >> > > From bruno.do.medeiros at gmail.com Thu May 29 13:41:16 2014 From: bruno.do.medeiros at gmail.com (Bruno Medeiros) Date: Thu, 29 May 2014 14:41:16 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: <538736D3.6010400@oracle.com> References: <538736D3.6010400@oracle.com> Message-ID: On Thu, May 29, 2014 at 2:32 PM, roger riggs wrote: > Hi Bruno, > > Create an issue: > JDK-8044321 EOF does > not occur reading input from spawned cmd.exe process > > I was able to reproduce it on java 7 but not java 8. > > Cool, thanks. > The implementation of Process does not mix handling of one Process > instance with another > so it may be an interaction specific to cmd.exe. > > Roger > > I don't think so: This bug originally occurred with processes other than cmd.exe (the two processes where not even from the same executable, BTW). I only changed it to cmd.exe for the sake of having a simpler example that anyone could try, since cmd.exe is included with Windows. -- Bruno Medeiros https://twitter.com/brunodomedeiros From roger.riggs at oracle.com Thu May 29 13:42:32 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 29 May 2014 09:42:32 -0400 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: References: <538736D3.6010400@oracle.com> Message-ID: <53873948.1030304@oracle.com> Thanks, feel free to add any additional information to the issue. Roger On 5/29/2014 9:41 AM, Bruno Medeiros wrote: > > > On Thu, May 29, 2014 at 2:32 PM, roger riggs > wrote: > > Hi Bruno, > > Create an issue: > JDK-8044321 EOF > does not occur reading input from spawned cmd.exe process > > I was able to reproduce it on java 7 but not java 8. > > > Cool, thanks. > > The implementation of Process does not mix handling of one Process > instance with another > so it may be an interaction specific to cmd.exe. > > Roger > > > I don't think so: This bug originally occurred with processes other > than cmd.exe (the two processes where not even from the same > executable, BTW). I only changed it to cmd.exe for the sake of having > a simpler example that anyone could try, since cmd.exe is included > with Windows. > > > -- > Bruno Medeiros > https://twitter.com/brunodomedeiros From Alan.Bateman at oracle.com Thu May 29 14:38:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 May 2014 15:38:53 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: <538736D3.6010400@oracle.com> References: <538736D3.6010400@oracle.com> Message-ID: <5387467D.8070102@oracle.com> On 29/05/2014 14:32, roger riggs wrote: > Hi Bruno, > > Create an issue: > JDK-8044321 EOF > does not occur reading input from spawned cmd.exe process > > I was able to reproduce it on java 7 but not java 8. Bruno - I just had a brief chat with Roger about this one as I suspect it's a dup of JDK-7147084, fixed in 7u60. It would be good if you could check that update. -Alan. From yiming.wang at oracle.com Fri May 30 07:27:41 2014 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 30 May 2014 15:27:41 +0800 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing Message-ID: <538832ED.8030809@oracle.com> Hi, Please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8004807 as below: http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.00/ The root cause of the failure is if Timer.cancel() is not called in time, the recurring timer task keeps running which cause the the assertion "check(latch.getCount() > 0)" failed. The fix includes: 1. As the purpose of the assertion "check(latch.getCount() > 0)" in timer task is used to check if the unrepeatable task is executed repeatedly and this assertion is meaningless for a repeatable task. it can be replaced by other way, see the webrev. 2. The timer thread should be terminated ASAP once all tasks are finished to avoid time spent on thread switch. 3. The test should be executed in othervm mode to avoid time spent on thread switch. Thanks, Eric From bruno.do.medeiros at gmail.com Fri May 30 12:32:37 2014 From: bruno.do.medeiros at gmail.com (Bruno Medeiros) Date: Fri, 30 May 2014 13:32:37 +0100 Subject: Thread hangs reading from process output streams, even though process has terminated. (possible JDK bug?) In-Reply-To: <5387467D.8070102@oracle.com> References: <538736D3.6010400@oracle.com> <5387467D.8070102@oracle.com> Message-ID: Indeed, I gave it a try with 7u60 and I couldn't replicated it. Seems like it was a dup of that one. On Thu, May 29, 2014 at 3:38 PM, Alan Bateman wrote: > On 29/05/2014 14:32, roger riggs wrote: > >> Hi Bruno, >> >> Create an issue: >> JDK-8044321 EOF does >> not occur reading input from spawned cmd.exe process >> >> I was able to reproduce it on java 7 but not java 8. >> > Bruno - I just had a brief chat with Roger about this one as I suspect > it's a dup of JDK-7147084, fixed in 7u60. It would be good if you could > check that update. > > -Alan. > -- Bruno Medeiros https://twitter.com/brunodomedeiros From paul.sandoz at oracle.com Fri May 30 14:53:50 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 30 May 2014 16:53:50 +0200 Subject: Please review: 8044046: [asm] refresh internal ASM version to v5.0.3 In-Reply-To: <53851DD4.30806@oracle.com> References: <53851DD4.30806@oracle.com> Message-ID: <7DEACF2F-2FA9-472B-A9AA-5C5449DEB89E@oracle.com> On May 28, 2014, at 1:20 AM, Kumar Srinivasan wrote: > Hello, > > Please review the following webrev which updates internal ASM to v5.0.3, the individual bug fixes are > listed in the JBS issue for reference, > > https://bugs.openjdk.java.net/browse/JDK-8044046#comment-13501358 > > All core regression tests have been run, additionally nashorn regressions, test262parallel, octane, > and all applicable JFR related tests have also been run. > > https://bugs.openjdk.java.net/browse/JDK-8044046 > > http://cr.openjdk.java.net/~ksrini/8044046/jdk9/webrev.00/ > Code changes look OK ro me. Paul. From sundararajan.athijegannathan at oracle.com Fri May 30 15:00:15 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 30 May 2014 20:30:15 +0530 Subject: Please review: 8044046: [asm] refresh internal ASM version to v5.0.3 In-Reply-To: <7DEACF2F-2FA9-472B-A9AA-5C5449DEB89E@oracle.com> References: <53851DD4.30806@oracle.com> <7DEACF2F-2FA9-472B-A9AA-5C5449DEB89E@oracle.com> Message-ID: <53889CFF.8040103@oracle.com> Looks good to me. -Sundar On Friday 30 May 2014 08:23 PM, Paul Sandoz wrote: > On May 28, 2014, at 1:20 AM, Kumar Srinivasan wrote: > >> Hello, >> >> Please review the following webrev which updates internal ASM to v5.0.3, the individual bug fixes are >> listed in the JBS issue for reference, >> >> https://bugs.openjdk.java.net/browse/JDK-8044046#comment-13501358 >> >> All core regression tests have been run, additionally nashorn regressions, test262parallel, octane, >> and all applicable JFR related tests have also been run. >> >> https://bugs.openjdk.java.net/browse/JDK-8044046 >> >> http://cr.openjdk.java.net/~ksrini/8044046/jdk9/webrev.00/ >> > Code changes look OK ro me. > > Paul. > From roger.riggs at oracle.com Fri May 30 18:30:19 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 30 May 2014 14:30:19 -0400 Subject: RFR 80044461: Cleanup new Boolean and single character strings Message-ID: <5388CE3B.4070205@oracle.com> A quick sanity check please for these cleanup changes to remove uses of new Boolean and using chars instead of single character strings contributed by Ot?vio Gon?alves de Santana. These changes update multiple classes in the jdk9-dev repo (except client packages). webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/ Issue: https://bugs.openjdk.java.net/browse/JDK-8044461 Thanks, Roger From Lance.Andersen at oracle.com Fri May 30 18:46:49 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Fri, 30 May 2014 14:46:49 -0400 Subject: RFR 80044461: Cleanup new Boolean and single character strings In-Reply-To: <5388CE3B.4070205@oracle.com> References: <5388CE3B.4070205@oracle.com> Message-ID: <7D86B773-EAEB-4AEE-B3B8-6F97F744CBD1@oracle.com> Looks fine On May 30, 2014, at 2:30 PM, roger riggs wrote: > A quick sanity check please for these cleanup changes to remove uses of > new Boolean and using chars instead of single character strings contributed > by Ot?vio Gon?alves de Santana. > > These changes update multiple classes in the jdk9-dev repo (except client packages). > > webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8044461 > > Thanks, Roger > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From tom.schindl at bestsolution.at Fri May 30 18:51:16 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 30 May 2014 19:51:16 +0100 Subject: inefficient indexof when String has one length In-Reply-To: References: Message-ID: <5388D324.5050401@bestsolution.at> On the same topic but still a bit different shouldn't indexOf(String) check for the size and call indexOf(char) when the length is 1, same for indexOf(String,int)? Tom On 26.04.14 11:56, Ot?vio Gon?alves de Santana wrote: > When a String has length just one, could be replaced by equivalent > character literals, gaining some performance enhancement. > From Alan.Bateman at oracle.com Fri May 30 19:07:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 May 2014 20:07:01 +0100 Subject: RFR 80044461: Cleanup new Boolean and single character strings In-Reply-To: <5388CE3B.4070205@oracle.com> References: <5388CE3B.4070205@oracle.com> Message-ID: <5388D6D5.2030709@oracle.com> On 30/05/2014 19:30, roger riggs wrote: > A quick sanity check please for these cleanup changes to remove uses of > new Boolean and using chars instead of single character strings > contributed > by Ot?vio Gon?alves de Santana. > > These changes update multiple classes in the jdk9-dev repo (except > client packages). > > webrev: http://cr.openjdk.java.net/~rriggs/webrev-8044461-cleanup/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8044461 You might want to check the alignment in VMOptionCompositeData and StackTraceElementCompositeData, otherwise I don't see any issues. -Alan. From martinrb at google.com Fri May 30 20:26:00 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 30 May 2014 13:26:00 -0700 Subject: RFR for bug JDK-8004807: java/util/Timer/Args.java failing intermittently in HS testing In-Reply-To: <538832ED.8030809@oracle.com> References: <538832ED.8030809@oracle.com> Message-ID: HI Eric, Thanks for working on my old dusty tests. I can't view the bug report - I get Permission Violation. It does look like you're making the test more robust, but at the cost of throwing away much of what the test is testing, which is not so good. This test hardcodes 1 second as the period - it assumes all 13 task invocations can be performed in 500ms, which may be a little over-optimistic. Nevertheless, this failure should be very rare, eh? But bump the period to a much higher number and we should be OK. I think making this an othervm test is overkill. Better to make the test itself more robust. I propose instead this major rewrite: public class Args { static final long DELAY_MS = 100 * 1000L; void schedule(final Timer t, final TimerTask task, final Date d) { t.schedule(task, d); assertThrows (IllegalStateException.class, () -> t.schedule(task, d)); } void schedule(final Timer t, final TimerTask task, final Date d, final long period) { t.schedule(task, d, period); assertThrows (IllegalStateException.class, () -> t.schedule(task, d, period)); } void scheduleAtFixedRate(final Timer t, final TimerTask task, final Date d, final long period) { t.scheduleAtFixedRate(task, d, period); assertThrows (IllegalStateException.class, () -> t.scheduleAtFixedRate(task, d, period)); } TimerTask counter(final CountDownLatch latch) { return new TimerTask() { public void run() { check(latch.getCount() > 0); latch.countDown(); }}; } TimerTask nop() { return new TimerTask() { public void run() { }}; } void test(String[] args) throws Throwable { final Timer t = new Timer(); try { test(t); } finally { // Ensure this test doesn't interfere with subsequent // tests even in case of failure. t.cancel(); } // Attempts to schedule tasks on a cancelled Timer result in ISE. final Date past = new Date(System.currentTimeMillis() - DELAY_MS); final Date future = new Date(System.currentTimeMillis() + DELAY_MS); assertThrows (IllegalStateException.class, () -> t.schedule(nop(), 42), () -> t.schedule(nop(), 42), () -> t.schedule(nop(), past), () -> t.schedule(nop(), 42, 42), () -> t.schedule(nop(), past, 42), () -> t.scheduleAtFixedRate(nop(), 42, 42), () -> t.scheduleAtFixedRate(nop(), past, 42), () -> t.scheduleAtFixedRate(nop(), future, 42)); } void test(Timer t) throws Throwable { final TimerTask x = new TimerTask() { public void run() {}}; assertThrows (IllegalArgumentException.class, () -> t.schedule(x, -42), () -> t.schedule(x, new Date(-42)), () -> t.schedule(x, Long.MAX_VALUE), () -> t.schedule(x, -42, 42), () -> t.schedule(x, new Date(-42), 42), () -> t.schedule(x, Long.MAX_VALUE, 42), () -> t.schedule(x, 42, 0), () -> t.schedule(x, new Date(42), 0), () -> t.schedule(x, 42, -42), () -> t.schedule(x, new Date(42), -42), () -> t.scheduleAtFixedRate(x, -42, 42), () -> t.scheduleAtFixedRate(x, new Date(-42), 42), () -> t.scheduleAtFixedRate(x, Long.MAX_VALUE, 42), () -> t.scheduleAtFixedRate(x, 42, 0), () -> t.scheduleAtFixedRate(x, new Date(42), 0), () -> t.scheduleAtFixedRate(x, 42, -42), () -> t.scheduleAtFixedRate(x, new Date(42), -42)); assertThrows (NullPointerException.class, () -> t.schedule(null, 42), () -> t.schedule(x, (Date)null), () -> t.schedule(null, 42, 42), () -> t.schedule(x, (Date)null, 42), () -> t.scheduleAtFixedRate(null, 42, 42), () -> t.scheduleAtFixedRate(x, (Date)null, 42)); final CountDownLatch y1 = new CountDownLatch(1); final CountDownLatch y2 = new CountDownLatch(1); final CountDownLatch y3 = new CountDownLatch(11); final long start = System.currentTimeMillis(); final Date past = new Date(start - (10 * DELAY_MS + DELAY_MS / 2)); schedule( t, counter(y1), past); schedule( t, counter(y2), past, DELAY_MS); scheduleAtFixedRate(t, counter(y3), past, DELAY_MS); y3.await(); y1.await(); y2.await(); final long elapsed = System.currentTimeMillis() - start; if (elapsed >= DELAY_MS / 2) fail(String.format("Test took too long: elapsed=%d%n", elapsed)); } //--------------------- Infrastructure --------------------------- volatile int passed = 0, failed = 0; void pass() {passed++;} void fail() {failed++; Thread.dumpStack();} void fail(String msg) {System.err.println(msg); fail();} void unexpected(Throwable t) {failed++; t.printStackTrace();} void check(boolean cond) {if (cond) pass(); else fail();} void equal(Object x, Object y) { if (x == null ? y == null : x.equals(y)) pass(); else fail(x + " not equal to " + y);} public static void main(String[] args) throws Throwable { new Args().instanceMain(args);} void instanceMain(String[] args) throws Throwable { try {test(args);} catch (Throwable t) {unexpected(t);} System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); if (failed > 0) throw new AssertionError("Some tests failed");} interface F { void f() throws Throwable; } void assertThrows(Class k, F... fs) { for (F f : fs) try {f.f(); fail("Expected " + k.getName() + " not thrown");} catch (Throwable t) { if (k.isAssignableFrom(t.getClass())) pass(); else unexpected(t);}} } On Fri, May 30, 2014 at 12:27 AM, Eric Wang wrote: > Hi, > > Please help to review the fix for bug https://bugs.openjdk.java.net/ > browse/JDK-8004807 as below: > http://cr.openjdk.java.net/~ewang/JDK-8004807/webrev.00/ > > The root cause of the failure is if Timer.cancel() is not called in time, > the recurring timer task keeps running which cause the the assertion > "check(latch.getCount() > 0)" failed. > > The fix includes: > 1. As the purpose of the assertion "check(latch.getCount() > 0)" in timer > task is used to check if the unrepeatable task is executed repeatedly and > this assertion is meaningless for a repeatable task. it can be replaced by > other way, see the webrev. > 2. The timer thread should be terminated ASAP once all tasks are finished > to avoid time spent on thread switch. > 3. The test should be executed in othervm mode to avoid time spent on > thread switch. > > Thanks, > Eric > From joe.darcy at oracle.com Fri May 30 23:28:40 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 May 2014 16:28:40 -0700 Subject: JDK 9 RFR of fallthrough fix in ASM Message-ID: <53891428.7050307@oracle.com> Hello, Please review this change to suppress a fall-through warning recently sync'ed into ASM: --- a/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 13:37:35 2014 -0700 +++ b/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 16:19:12 2014 -0700 @@ -230,6 +230,7 @@ * @param strVal3 * third part of the value of this item. */ + @SuppressWarnings("fallthrough") void set(final int type, final String strVal1, final String strVal2, final String strVal3) { this.type = type; The switch statement is switch (type) { case ClassWriter.CLASS: this.intVal = 0; // intVal of a class must be zero, see visitInnerClass case ClassWriter.UTF8: case ClassWriter.STR: case ClassWriter.MTYPE: case ClassWriter.TYPE_NORMAL: hashCode = 0x7FFFFFFF & (type + strVal1.hashCode()); return; case ClassWriter.NAME_TYPE: { hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() * strVal2.hashCode()); return; } // ClassWriter.FIELD: // ClassWriter.METH: // ClassWritehr.IMETH: // ClassWriter.HANDLE_BASE + 1..9 default: hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() * strVal2.hashCode() * strVal3.hashCode()); } } Thanks, -Joe From Lance.Andersen at oracle.com Fri May 30 23:32:28 2014 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Fri, 30 May 2014 19:32:28 -0400 Subject: JDK 9 RFR of fallthrough fix in ASM In-Reply-To: <53891428.7050307@oracle.com> References: <53891428.7050307@oracle.com> Message-ID: +1 On May 30, 2014, at 7:28 PM, Joe Darcy wrote: > Hello, > > Please review this change to suppress a fall-through warning recently sync'ed into ASM: > > --- a/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 13:37:35 2014 -0700 > +++ b/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 16:19:12 2014 -0700 > @@ -230,6 +230,7 @@ > * @param strVal3 > * third part of the value of this item. > */ > + @SuppressWarnings("fallthrough") > void set(final int type, final String strVal1, final String strVal2, > final String strVal3) { > this.type = type; > > > The switch statement is > > switch (type) { > case ClassWriter.CLASS: > this.intVal = 0; // intVal of a class must be zero, see visitInnerClass > case ClassWriter.UTF8: > case ClassWriter.STR: > case ClassWriter.MTYPE: > case ClassWriter.TYPE_NORMAL: > hashCode = 0x7FFFFFFF & (type + strVal1.hashCode()); > return; > case ClassWriter.NAME_TYPE: { > hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() > * strVal2.hashCode()); > return; > } > // ClassWriter.FIELD: > // ClassWriter.METH: > // ClassWritehr.IMETH: > // ClassWriter.HANDLE_BASE + 1..9 > default: > hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() > * strVal2.hashCode() * strVal3.hashCode()); > } > } > > Thanks, > > -Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Sat May 31 10:49:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 31 May 2014 12:49:38 +0200 Subject: JDK 9 RFR of fallthrough fix in ASM In-Reply-To: References: <53891428.7050307@oracle.com> Message-ID: <5389B3C2.4050205@univ-mlv.fr> Fixed on the ASM trunk too. http://websvn.ow2.org/diff.php?repname=asm&path=%2Ftrunk%2Fasm%2Fsrc%2Forg%2Fobjectweb%2Fasm%2FItem.java&rev=1749&peg=1749 cheers, R?mi On 05/31/2014 01:32 AM, Lance Andersen wrote: > +1 > On May 30, 2014, at 7:28 PM, Joe Darcy wrote: > >> Hello, >> >> Please review this change to suppress a fall-through warning recently sync'ed into ASM: >> >> --- a/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 13:37:35 2014 -0700 >> +++ b/src/share/classes/jdk/internal/org/objectweb/asm/Item.java Fri May 30 16:19:12 2014 -0700 >> @@ -230,6 +230,7 @@ >> * @param strVal3 >> * third part of the value of this item. >> */ >> + @SuppressWarnings("fallthrough") >> void set(final int type, final String strVal1, final String strVal2, >> final String strVal3) { >> this.type = type; >> >> >> The switch statement is >> >> switch (type) { >> case ClassWriter.CLASS: >> this.intVal = 0; // intVal of a class must be zero, see visitInnerClass >> case ClassWriter.UTF8: >> case ClassWriter.STR: >> case ClassWriter.MTYPE: >> case ClassWriter.TYPE_NORMAL: >> hashCode = 0x7FFFFFFF & (type + strVal1.hashCode()); >> return; >> case ClassWriter.NAME_TYPE: { >> hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() >> * strVal2.hashCode()); >> return; >> } >> // ClassWriter.FIELD: >> // ClassWriter.METH: >> // ClassWritehr.IMETH: >> // ClassWriter.HANDLE_BASE + 1..9 >> default: >> hashCode = 0x7FFFFFFF & (type + strVal1.hashCode() >> * strVal2.hashCode() * strVal3.hashCode()); >> } >> } >> >> Thanks, >> >> -Joe > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From mark.sheppard at oracle.com Sat May 31 16:33:12 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Sat, 31 May 2014 17:33:12 +0100 Subject: RFR: JDK-8044343 - Check jdk/src/windows/native/java/lang/ProcessEnvironment_md.c for JNI pending exceptions Message-ID: <538A0448.70905@oracle.com> Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8044343/webrev/ which addresses issue https://bugs.openjdk.java.net/browse/JDK-8044343 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8036603 the original changeset didn't apply cleanly and was applied manually http://hg.openjdk.java.net/jdk9/dev/jdk/rev/323b64a9dede regression tests ran ok and finally please approve backport to jdk8u-dev regards Mark From mark.sheppard at oracle.com Sat May 31 22:02:39 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Sat, 31 May 2014 23:02:39 +0100 Subject: RFR: 8041602 - (prefs) Check jdk/src/windows/native/java/util/WindowsPreference.c for JNI pending exceptions Message-ID: <538A517F.6090808@oracle.com> Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041602/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041602 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8035340 the original changeset didn't apply cleanly and was applied manually http://hg.openjdk.java.net/jdk9/dev/jdk/rev/740ffd98e35a regression tests ran ok and finally please approve backport to jdk8u-dev regards Mark