From huizhe.wang at oracle.com Mon Aug 1 01:04:08 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Sun, 31 Jul 2016 18:04:08 -0700 Subject: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace In-Reply-To: References: <260fda07-53fb-5686-efb5-b95f746d9da5@oracle.com> <8b1eb92519b745c8b60c87f14076975f@DEWDFE13DE11.global.corp.sap> <579BBDB5.50505@oracle.com> Message-ID: <579EA008.1040907@oracle.com> On 7/31/16, 2:25 PM, Langer, Christoph wrote: > > Thanks, Joe. > > I added some documentation to checkNodeNS8162598 and pushed: > http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/e66cdc2de6b0 > > Would you agree to downport this to jdk8? > Certainly. That's probably what the customer really needed. Best, Joe > Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 29. Juli 2016 22:34 > *To:* Langer, Christoph > *Cc:* Daniel Fuchs ; > core-libs-dev at openjdk.java.net > *Subject:* Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty > namespace declaration which is needed to undeclare default namespace > > Hi Christoph, > > All tests passed. Please add a note to the test on what's expected, or > some javadoc to the method checkNodeNS8162598. > > Best, > Joe > > On 7/29/16, 7:55 AM, Langer, Christoph wrote: > > Hi Joe, > > here is the webrev after merging: > http://cr.openjdk.java.net/~clanger/webrevs/8162598.2/ > > > Let me know when you have done your tests -- then I'll push it. > > @Daniel: Thanks for your help regarding Stack. You were right, > I could remove that "". > > Thanks & Best regards > > Christoph > > *From:*huizhe wang [mailto:huizhe.wang at oracle.com] > *Sent:* Freitag, 29. Juli 2016 08:04 > *To:* Langer, Christoph > ; Daniel Fuchs > > *Cc:* core-libs-dev at openjdk.java.net > > *Subject:* Re: RFR (JAXP): 8162598 XSLTC transformer swallows > empty namespace declaration which is needed to undeclare default > namespace > > Hi Christoph, > > On 7/28/2016 6:10 AM, Langer, Christoph wrote: > > Hi, > > please review my change for the XSLT namespace issue. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8162598.1/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162598 > > The issue has already been discussed in this thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042525.html > > Apart from the real fix in LiteralElement.java, method > translate(), I've done some further cleanups in a few places. > @Joe: The cleanups collide with some places of your proposed > change for https://bugs.openjdk.java.net/browse/JDK-8158084 > where we'd like to do the same things. So we'll have to > synchronize on pushing. > > > My patch has just pushed. Could you merge the changes and > re-generate webrev? The change looks to be sensitive. I'll build > and run all other tests for you. > > Best, > Joe > > > > I've also enhanced the test case "TransformerTest" and added a > method which does a regression test for the bug reported. > > Thanks in advance for reviewing. > > Best regards > > Christoph > From felix.yang at oracle.com Mon Aug 1 06:48:28 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 1 Aug 2016 14:48:28 +0800 Subject: RFR 8157135, Fix module dependencies javax/* EE tests Message-ID: Hi all, please review the patch for some tests, which explicitly declare module dependencies to EE modules. Bug: https://bugs.openjdk.java.net/browse/JDK-8157135 Webrev: http://cr.openjdk.java.net/~xiaofeya/8157135/webrev.00/ This is a partial fix left by https://bugs.openjdk.java.net/browse/JDK-8155088. The fix had been hold off for a moment, to wait for new jtreg with resolved https://bugs.openjdk.java.net/browse/CODETOOLS-7901671. Otherwise those tests will be ignored silently. Thanks, Felix From Alan.Bateman at oracle.com Mon Aug 1 12:00:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 05:00:05 -0700 Subject: RFR 8157135, Fix module dependencies javax/* EE tests In-Reply-To: References: Message-ID: <25b5a7ba-8818-e1e7-d563-120644b33813@oracle.com> On 31/07/2016 23:48, Felix Yang wrote: > Hi all, > > please review the patch for some tests, which explicitly declare > module dependencies to EE modules. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157135 > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157135/webrev.00/ > > This is a partial fix left by > https://bugs.openjdk.java.net/browse/JDK-8155088. The fix had been > hold off for a moment, to wait for new jtreg with resolved > https://bugs.openjdk.java.net/browse/CODETOOLS-7901671. Otherwise > those tests will be ignored silently. This looks okay. One thing to mention is that with the changes in jtreg then we should be able to drop -addmods from several of these tests. That is for a separate issue of course, also tied to the CLI changes as all these -addmods usages have been switched to --add-modules. -Alan From Roger.Riggs at Oracle.com Mon Aug 1 17:34:12 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 1 Aug 2016 13:34:12 -0400 Subject: [PATCH] JDK-8155102: Process.toString could include pid, isAlive, exitStatus In-Reply-To: References: <9066d1a2-4a7d-bff4-60d8-d62ff559272d@Oracle.com> Message-ID: <3698a11e-c224-14cc-a083-cc50b89efd2c@Oracle.com> Hi Andrey, Sorry to be slow in getting back to this. Thanks for the update; did you notice that Windows has a separate implementation of ProcessImpl and would also need a similar, though not identical toString() implementation? [jdk/src/java.base/windows/classes/java/lang/ProcessImpl.java ] Windows has a slightly different implementation of the internal state with respect to knowing if it has exited. See exitValue() and the native getExitCodeProcess() method. On 7/24/2016 7:42 AM, Andrey Dyachkov wrote: > Hi Roger, > > Thank you for reviewing it! I've prepared another version. > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > @@ -630,6 +630,21 @@ > return !hasExited; > } > > + /** > + * The {@code toString} method for class {@code ProcessImpl} > + * returns a string consisting of the native process ID of the > process, > + * exit code of the process and the status of the process. The javadoc for Process uses the terminology "exit value" or "exit status"; the usage should be consistent. > + * > + * @return a string representation of the object. > + */ > + @Override > + public String toString() { > + return new StringBuilder("ProcessImpl{pid=").append(pid) The implementation class should be hidden, use "Process". Other toString methods use '[]' to enclose the aggregate of the values. > + .append(", exitcode=").append(exitcode) 'exitcode=' -> "exitValue" to be consistent with the exitValue method. This will need an alternate value if the process has not exited, perhaps "not exited" > + .append(", hasExited=").append(hasExited) This isn't needed with the above 'not exited' string. > + .append("}").toString(); '}' -> ']' Also, I think this would be viewed more as an enhancement than a bug and we'll need to request an extension[1][2] for it when the code is complete. Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html [2] http://openjdk.java.net/projects/jdk9/fc-extension-process > + } > + > private static native void init(); > > static { > > On Mon, 9 May 2016 at 16:50 Roger Riggs > wrote: > > Hi Andrey, > > Since toString is a public method it needs to provide complete javadoc > specification > as providing values for debugging information. ToString methods > typically directly > reflect the state of the fields of the object. > > Why should the exitValue have the value of the pid if the process > is not > alive? > > Also, the if toString is providing the exitValue then it should be > identified as "exitValue", not exitCode. > the isAlive value should be identified as "isAlive". > The implementation class should not be exposed. (remove > this.getClass().getSimpleName()). > > The performance of what seems like a simple toString method is not > going > to be great > because of the native calls necessary to determine if the process is > alive (called twice) > and in the case of exitValue to handle the IllegalStateException. > > Some of the overhead could be avoided, by implementing toString in > each > of the ProcessImpl.java > files where the current state is known more conveniently with less > overhead. > > $.02, Roger > > > On 5/8/2016 2:47 PM, Andrey Dyachkov wrote: > > Hello, > > > > I have added toString() method in Process.java. > > > > diff --git a/src/java.base/share/classes/java/lang/Process.java > > b/src/java.base/share/classes/java/lang/Process.java > > --- a/src/java.base/share/classes/java/lang/Process.java > > +++ b/src/java.base/share/classes/java/lang/Process.java > > @@ -548,5 +548,16 @@ > > return toHandle().descendants(); > > } > > > > + @Override > > + public String toString() { > > + boolean isAlive = this.isAlive(); > > + return new > > StringBuilder(this.getClass().getSimpleName()).append("[") > > + .append("running=").append(isAlive).append(", ") > > + .append(isAlive ? "pid=" : "exitCode=") > > + .append(isAlive ? this.getPid() : > this.exitValue()) > > + .append("]") > > + .toString(); > > + } > > + > > > > } > > -- > > With great enthusiasm, > Andrey From iris.clark at oracle.com Mon Aug 1 18:31:04 2016 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 1 Aug 2016 11:31:04 -0700 (PDT) Subject: RFR: 8162439: Runtime.Version.parse needs fast-path for major versions In-Reply-To: <579ACA68.7070901@oracle.com> References: <57939A03.7080104@oracle.com> <5798F131.5020802@oracle.com> <579ACA68.7070901@oracle.com> Message-ID: Hi, Claes. > http://cr.openjdk.java.net/~redestad/8162439/webrev.02/ This looks good. Thanks, Iris From brian.burkhalter at oracle.com Mon Aug 1 18:37:01 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Aug 2016 11:37:01 -0700 Subject: Why is there no Math.ceilDiv? In-Reply-To: References: Message-ID: Hello Philipp, On Jul 31, 2016, at 12:45 PM, Philipp Nowak wrote: > I hope this is the right place to ask this question. If it is not, I would > kindly ask you to direct me to the correct place. The is the correct forum. > I was wondering why there is no Math.ceilDiv() method, when a floorDiv() > method got added in Java 8 through JDK-8023217 [1]. I think simply because it was not requested. > Is there any reason why such method did not get added with floorDiv(), and, > if not, is there any process to request such a method? Issues may be reported via JBS [1] if you have an account [2]. Otherwise they may be reported at [3]. Regards, Brian [1] https://bugs.openjdk.java.net/secure/Dashboard.jspa [2] https://wiki.openjdk.java.net/display/general/JBS+Overview [3] http://bugs.java.com > Best regards, > > Philipp Nowak > > ?[1] https://bugs.openjdk.java.net/browse/JDK-8023217? From kim.barrett at oracle.com Mon Aug 1 18:46:11 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Aug 2016 14:46:11 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> Message-ID: <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> This updated webrev addresses the concerns around initialization order for Throwable and OutOfMemoryError. It doesn't address the VM API used by the reference processor thread; that will be in a later webrev. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ The jdk tree is unchanged from webrev.01. I've backed out the change to initialize_java_lang_classes. (To verify this, look at the runtime/thread.cpp in the full webrev.) Instead, Universe::gen_out_of_memory_error now also requires Throwable to be initialized before it will attempt to fill in the stack trace. This means that VM generated OOMEs occurring early in initialization won't have a stack trace. An alternative that I considered was to remove the assert at the end of fill_in_stack_trace_of_preallocated_backtrace that requires java_lang_Throwable;:unassigned_stacktrace() to return non-NULL. I did some testing that seemed to work and provide stacktraces, relying on code in the Throwable class that special cases this "out of protocol" state. However, having read some of the history around that (JDK-6998871, JDK-7045138, JDK-7046490), that special casing seems to have been intended to be temporary, and expected to be removed. (Though I didn't find an RFE for doing so, and I'm not doing so here.) Even if we decided it wasn't going to be removed, this approach seems somewhat fragile. [Note to Coleen: This is the reverse of what you and I talked about a few days ago; I hadn't reviewed the history carefully then.] From kim.barrett at oracle.com Mon Aug 1 18:47:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Aug 2016 14:47:26 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: This updated webrev addresses concerns about the performance of the VM API used by the reference processor thread in the original webrev. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ The originally offered approach was an attempt to minimize changes. I was trying to be as similar to the existing code as possible, while moving part of it into the VM, where we have the necessary control over suspension and the like. We already know we want to make changes in this area, in order to eliminate the use of jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we should revisit that. As Peter pointed out, my original change introduces a small performance regression on a microbenchmark for reference processing throughput. It also showed a small performance benefit on a different microbenchmark (allocation rate for a stress test of direct byte buffers), as noted in the original RFR. I can reproduce both of those. I think reference processing thread throughput is the right measure to use, so long as others don't become horrible. Focusing on that, it's better to just let the reference processing thread do the processing, rather than slowing it down to allow for the rare case when there's another thread that could possibly help. This is especially true now that Cleaner has such limited usage. This leads to a different API for other threads; rather than tryHandlePending that other threads can call to help and to examine progress, we now have waitForReferenceProcessing. The VM API is also different; rather than popReferencePendingList to get or wait, we now have getAndClearReferencePendingList and checkReferencePendingList, the latter with an optional wait. The splitting of the VM API allows us to avoid a narrow race condition discussed by Peter in his prototypes. Peter suggested this race was ok because java.nio.Bits makes several retries. However, those retries are only done before throwing OOME. There are no retries before invoking GC, so this race could lead to unnecessary successive GCs. Doing all the processing on the reference processing thread eliminates execution of Cleaners on application threads, though that's not nearly as much an issue now that the use of Cleaner is so restricted. We've also eliminated a pre-existing issue where a helper could report no progress even though the reference processing thread (and other helpers) had removed a pending reference, but not yet processed it. This could result in the non-progressing helper invoking GC or reporting failure, even though it might have succeeded if it had waited for the other thread(s) to complete processing the reference(s) being worked on. I think the new waitForReferenceProcessing could be used to fix JDK-6306116, though that isn't part of this change, and was not really a motivating factor. I don't know if the new waitForReferenceProcessing will be used by whatever we eventually do for JDK-8149925, but I think the new VM API will suffice for that. That is, I think JDK-8149925 might require changes to the core-libs API used by nio.Bits, and won't require further VM API changes. From naoto.sato at oracle.com Mon Aug 1 20:45:25 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 1 Aug 2016 13:45:25 -0700 Subject: [9] RFR: 8162797: Code clean-up in IncludeLocalesPlugin Message-ID: <7d840ea0-eaee-5cee-a103-53f2759d5059@oracle.com> Hello, Please review this small change for the bug: https://bugs.openjdk.java.net/browse/JDK-8162797 The fix is located at: http://cr.openjdk.java.net/~naoto/8162797/webrev.00/ Naoto From joe.darcy at oracle.com Mon Aug 1 21:39:41 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 1 Aug 2016 14:39:41 -0700 Subject: JDK 9 RFR of JDK-8162817: Annotation toString output not reusable for source input Message-ID: <6a039169-5d99-002d-df19-e58bbfe458b2@oracle.com> As pointed out by recent core-libs-dev traffic ([1] [2]), the toString output for annotation objects cannot be directly reused as source input if the annotation values are any of: * Class values of array classes (uses JVM name) * Arrays (output uses brackets ("[]") rather than braces {"{}") In addition, there are problems with other situations including: * Strings don't have surrounding " characters. * Chars don't have surrounding ' charcters. * Long values outside of the int range don't have a "L" suffix. Please review the webrev for the change addressing these shortcomings: JDK-8162817: Annotation toString output not reusable for source input http://cr.openjdk.java.net/~darcy/8162817.1/ This change should cover 99 44/100 % of the annotation values that appear in practice; limited efforts were taken quoting characters in strings, etc. The basic approach is to introduce a family of overloaded toSourceString methods to wrap/filter different kinds of values coupled with methods to convert the various primitive arrays to Stream for final processing by a shared method to surround an array by "{" and "}" and add comma separators as needed. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042637.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042645.html From chris.plummer at oracle.com Mon Aug 1 22:46:16 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Aug 2016 15:46:16 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail Message-ID: Hello, Please review this simple change: https://bugs.openjdk.java.net/browse/JDK-8162670 http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ Note the copyright dates haven't been updated in this webrev, but I did update them locally after noticing that. Tested with jprt test case given in the CR, and also with a jprt run using "testset -hotspot" to make sure I didn't break anything. thanks, Chris From david.holmes at oracle.com Tue Aug 2 00:58:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Aug 2016 10:58:22 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: Message-ID: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> Hi Chris, On 2/08/2016 8:46 AM, Chris Plummer wrote: > Hello, > > Please review this simple change: > > https://bugs.openjdk.java.net/browse/JDK-8162670 > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ You've split a compound expression with your code: 227 jtregExitCode=$$? && \ 228 if [ $${jtregExitCode} == 1 ]; then \ 229 jtregExitCode=0; \ 230 fi ; \ 231 _summary="$(SUMMARY_TXT)"; \ I'm not clear exactly why the && was needed here but rather than find out later I suggest rearranging the above to: jtregExitCode=$$? && \ _summary="$(SUMMARY_TXT)"; \ if [ $${jtregExitCode} == 1 ]; then \ jtregExitCode=0; \ fi ; \ Thanks, David > Note the copyright dates haven't been updated in this webrev, but I did > update them locally after noticing that. > > Tested with jprt test case given in the CR, and also with a jprt run > using "testset -hotspot" to make sure I didn't break anything. > > thanks, > > Chris From chris.plummer at oracle.com Tue Aug 2 02:11:02 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Aug 2016 19:11:02 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> Message-ID: <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> On 8/1/16 5:58 PM, David Holmes wrote: > Hi Chris, > > On 2/08/2016 8:46 AM, Chris Plummer wrote: >> Hello, >> >> Please review this simple change: >> >> https://bugs.openjdk.java.net/browse/JDK-8162670 >> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ > > You've split a compound expression with your code: > > 227 jtregExitCode=$$? && \ > 228 if [ $${jtregExitCode} == 1 ]; then \ > 229 jtregExitCode=0; \ > 230 fi ; \ > 231 _summary="$(SUMMARY_TXT)"; \ > > I'm not clear exactly why the && was needed here but rather than find > out later I suggest rearranging the above to: > > jtregExitCode=$$? && \ > _summary="$(SUMMARY_TXT)"; \ > if [ $${jtregExitCode} == 1 ]; then \ > jtregExitCode=0; \ > fi ; \ > Yeah, that makes sense. I'll make the change. However, it's really unclear what the use case for && is here. How can jtregExitCode=$$? ever fail? thanks, Chris > Thanks, > David > >> Note the copyright dates haven't been updated in this webrev, but I did >> update them locally after noticing that. >> >> Tested with jprt test case given in the CR, and also with a jprt run >> using "testset -hotspot" to make sure I didn't break anything. >> >> thanks, >> >> Chris From david.holmes at oracle.com Tue Aug 2 02:25:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Aug 2016 12:25:28 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> Message-ID: <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> On 2/08/2016 12:11 PM, Chris Plummer wrote: > On 8/1/16 5:58 PM, David Holmes wrote: >> Hi Chris, >> >> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review this simple change: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >> >> You've split a compound expression with your code: >> >> 227 jtregExitCode=$$? && \ >> 228 if [ $${jtregExitCode} == 1 ]; then \ >> 229 jtregExitCode=0; \ >> 230 fi ; \ >> 231 _summary="$(SUMMARY_TXT)"; \ >> >> I'm not clear exactly why the && was needed here but rather than find >> out later I suggest rearranging the above to: >> >> jtregExitCode=$$? && \ >> _summary="$(SUMMARY_TXT)"; \ >> if [ $${jtregExitCode} == 1 ]; then \ >> jtregExitCode=0; \ >> fi ; \ >> > Yeah, that makes sense. I'll make the change. However, it's really > unclear what the use case for && is here. How can jtregExitCode=$$? ever > fail? I wonder if it evaluates to the $? value and so only sets _summary if we had a zero exit code? (Not that I understand why we would only set _summary in that context.) David > thanks, > > Chris >> Thanks, >> David >> >>> Note the copyright dates haven't been updated in this webrev, but I did >>> update them locally after noticing that. >>> >>> Tested with jprt test case given in the CR, and also with a jprt run >>> using "testset -hotspot" to make sure I didn't break anything. >>> >>> thanks, >>> >>> Chris > > From chris.plummer at oracle.com Tue Aug 2 04:30:41 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Aug 2016 21:30:41 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: On 8/1/16 7:25 PM, David Holmes wrote: > On 2/08/2016 12:11 PM, Chris Plummer wrote: >> On 8/1/16 5:58 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review this simple change: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>> >>> You've split a compound expression with your code: >>> >>> 227 jtregExitCode=$$? && \ >>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>> 229 jtregExitCode=0; \ >>> 230 fi ; \ >>> 231 _summary="$(SUMMARY_TXT)"; \ >>> >>> I'm not clear exactly why the && was needed here but rather than find >>> out later I suggest rearranging the above to: >>> >>> jtregExitCode=$$? && \ >>> _summary="$(SUMMARY_TXT)"; \ >>> if [ $${jtregExitCode} == 1 ]; then \ >>> jtregExitCode=0; \ >>> fi ; \ >>> >> Yeah, that makes sense. I'll make the change. However, it's really >> unclear what the use case for && is here. How can jtregExitCode=$$? ever >> fail? > > I wonder if it evaluates to the $? value and so only sets _summary if > we had a zero exit code? (Not that I understand why we would only set > _summary in that context.) I tried the following: bash-4.1$ x=0 && echo "foo"; And "foo" is always printed. I also tried non-zero values for x. Here are some other examples: bash-4.1$ (exit 1) && echo "foo" bash-4.1$ (exit 0) && echo "foo" foo Commands evaluate to true if the exit status is 0, and false otherwise, so I guess you could say commands evaluate to !?$. For &&, the rhs is only executed if the lhs has a zero exit status. Chris > > David > >> thanks, >> >> Chris >>> Thanks, >>> David >>> >>>> Note the copyright dates haven't been updated in this webrev, but I >>>> did >>>> update them locally after noticing that. >>>> >>>> Tested with jprt test case given in the CR, and also with a jprt run >>>> using "testset -hotspot" to make sure I didn't break anything. >>>> >>>> thanks, >>>> >>>> Chris >> >> From andrey.dyachkov at gmail.com Tue Aug 2 05:30:35 2016 From: andrey.dyachkov at gmail.com (Andrey Dyachkov) Date: Tue, 02 Aug 2016 05:30:35 +0000 Subject: [PATCH] JDK-8155102: Process.toString could include pid, isAlive, exitStatus In-Reply-To: <3698a11e-c224-14cc-a083-cc50b89efd2c@Oracle.com> References: <9066d1a2-4a7d-bff4-60d8-d62ff559272d@Oracle.com> <3698a11e-c224-14cc-a083-cc50b89efd2c@Oracle.com> Message-ID: Roger, I have changed impl according to your comments, thank you! Regarding fc-extension, I am not able to add comments in the bug tracker I think you can do it, correct? Also I am already in OCA list. diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java b/src/java.base/unix/classes/java/lang/ProcessImpl.java --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java @@ -630,6 +630,19 @@ return !hasExited; } + /** + * The {@code toString} method returns a string consisting of + * the native process ID of the process and the exit value of the process. + * + * @return a string representation of the object. + */ + @Override + public String toString() { + return new StringBuilder("Process[pid=").append(pid) + .append(", exitValue=").append(hasExited ? exitcode : "\"not exited\"") + .append("]").toString(); + } + private static native void init(); static { diff --git a/src/java.base/windows/classes/java/lang/ProcessImpl.java b/src/java.base/windows/classes/java/lang/ProcessImpl.java --- a/src/java.base/windows/classes/java/lang/ProcessImpl.java +++ b/src/java.base/windows/classes/java/lang/ProcessImpl.java @@ -564,6 +564,20 @@ private static native boolean isProcessAlive(long handle); /** + * The {@code toString} method returns a string consisting of + * the native process ID of the process and the exit value of the process. + * + * @return a string representation of the object. + */ + @Override + public String toString() { + int exitCode = getExitCodeProcess(handle); + return new StringBuilder("Process[pid=").append(getPid()) + .append(", exitValue=").append(exitCode == STILL_ACTIVE ? "\"not exited\"" : exitCode) + .append("]").toString(); + } + + /** * Create a process using the win32 function CreateProcess. * The method is synchronized due to MS kb315939 problem. * All native handles should restore the inherit flag at the end of call. On Mon, 1 Aug 2016 at 19:34 Roger Riggs wrote: > Hi Andrey, > > Sorry to be slow in getting back to this. > > Thanks for the update; did you notice that Windows has a separate > implementation of > ProcessImpl and would also need a similar, though not identical toString() > implementation? > [jdk/src/java.base/windows/classes/java/lang/ProcessImpl.java ] > > Windows has a slightly different implementation of the internal state with > respect to knowing if it has exited. > See exitValue() and the native getExitCodeProcess() method. > > > On 7/24/2016 7:42 AM, Andrey Dyachkov wrote: > > Hi Roger, > > Thank you for reviewing it! I've prepared another version. > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > @@ -630,6 +630,21 @@ > return !hasExited; > } > > + /** > + * The {@code toString} method for class {@code ProcessImpl} > + * returns a string consisting of the native process ID of the > process, > + * exit code of the process and the status of the process. > > The javadoc for Process uses the terminology "exit value" or "exit > status"; the usage should be consistent. > > + * > + * @return a string representation of the object. > + */ > + @Override > + public String toString() { > + return new StringBuilder("ProcessImpl{pid=").append(pid) > > The implementation class should be hidden, use "Process". > Other toString methods use '[]' to enclose the aggregate of the values. > > + .append(", exitcode=").append(exitcode) > > 'exitcode=' -> "exitValue" to be consistent with the exitValue method. > > This will need an alternate value if the process has not exited, perhaps > "not exited" > > + .append(", hasExited=").append(hasExited) > > This isn't needed with the above 'not exited' string. > > + .append("}").toString(); > > '}' -> ']' > > > Also, I think this would be viewed more as an enhancement than a bug and > we'll need > to request an extension[1][2] for it when the code is complete. > > Thanks, Roger > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > [2] http://openjdk.java.net/projects/jdk9/fc-extension-process > > > + } > + > private static native void init(); > > static { > > On Mon, 9 May 2016 at 16:50 Roger Riggs wrote: > >> Hi Andrey, >> >> Since toString is a public method it needs to provide complete javadoc >> specification >> as providing values for debugging information. ToString methods >> typically directly >> reflect the state of the fields of the object. >> >> Why should the exitValue have the value of the pid if the process is not >> alive? >> >> Also, the if toString is providing the exitValue then it should be >> identified as "exitValue", not exitCode. >> the isAlive value should be identified as "isAlive". >> The implementation class should not be exposed. (remove >> this.getClass().getSimpleName()). >> >> The performance of what seems like a simple toString method is not going >> to be great >> because of the native calls necessary to determine if the process is >> alive (called twice) >> and in the case of exitValue to handle the IllegalStateException. >> >> Some of the overhead could be avoided, by implementing toString in each >> of the ProcessImpl.java >> files where the current state is known more conveniently with less >> overhead. >> >> $.02, Roger >> >> >> On 5/8/2016 2:47 PM, Andrey Dyachkov wrote: >> > Hello, >> > >> > I have added toString() method in Process.java. >> > >> > diff --git a/src/java.base/share/classes/java/lang/Process.java >> > b/src/java.base/share/classes/java/lang/Process.java >> > --- a/src/java.base/share/classes/java/lang/Process.java >> > +++ b/src/java.base/share/classes/java/lang/Process.java >> > @@ -548,5 +548,16 @@ >> > return toHandle().descendants(); >> > } >> > >> > + @Override >> > + public String toString() { >> > + boolean isAlive = this.isAlive(); >> > + return new >> > StringBuilder(this.getClass().getSimpleName()).append("[") >> > + .append("running=").append(isAlive).append(", >> ") >> > + .append(isAlive ? "pid=" : "exitCode=") >> > + .append(isAlive ? this.getPid() : >> this.exitValue()) >> > + .append("]") >> > + .toString(); >> > + } >> > + >> > >> > } >> >> -- > > With great enthusiasm, > Andrey > > > -- With great enthusiasm, Andrey From kubota.yuji at gmail.com Tue Aug 2 05:33:59 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 2 Aug 2016 14:33:59 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: <565EF499.6040709@oracle.com> Message-ID: Hi all, Could you let me know when this fix will be backport to JDK 8? We need this backport to migrate our system from JDK 7 to JDK 8. Thanks, Yuji 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : > Hi Miroslav, > > Thank you for your sponsor! : https://bugs.openjdk.java.net/browse/JDK-8146086 > > Can I ask the schedule when does this fix backport to JDK8 ? > > Thanks, > Yuji > > 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >> Hi Yuji, >> thanks for the patch - it fixes the issue and looks ok to me. I'll integrate >> it to standalone JAX-WS repo and it will be integrated into openjdk during >> next syncup. >> >> Thanks >> Miran >> >> >> >> >> On 01/12/15 11:11, KUBOTA Yuji wrote: >>> >>> Hi Miroslav and all, >>> >>> Could you please review the below issue and patch? >>> >>> I got the advice by Alan at net-dev. So I want to ask you. >>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>> >>> ---- >>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>> community. This's second times from JavaOne14. :) >>> >>> We find an unexpected exception in JAX-WS, so I write a patch to fix it. >>> We think that this issue may block the migration to JDK9 from JDK7. >>> >>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>> following test code, JDK9 (and JDK8) returns "java.net.BindException: >>> Address already in use.? as the below. But JDK7 does NOT return the >>> exception. >>> >>> - Test code for reproduce >>> --- >>> import javax.jws.*; >>> import javax.xml.ws.*; >>> >>> public class WSTest{ >>> >>> @WebService >>> public static class Method1{ >>> @WebMethod >>> public String getMethod1Value(){ >>> return "from Method1"; >>> } >>> } >>> >>> @WebService >>> public static class Method2{ >>> @WebMethod >>> public String getMethod2Value(){ >>> return "from Method2"; >>> } >>> } >>> >>> public static void main(String[] args) throws Exception{ >>> Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1", >>> new >>> Method1()); >>> Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2", >>> new >>> Method2()); >>> >>> System.out.println("Sleep 3 secs..."); >>> >>> Thread.sleep(3000); >>> >>> endPoint2.stop(); >>> endPoint1.stop(); >>> } >>> >>> } >>> --- >>> >>> - StackTrace >>> --- >>> Exception in thread "main" >>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>> Error: java.net.BindException: Address already in use >>> at >>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>> at >>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>> at >>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>> at >>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>> at wstest.WSTest.main(WSTest.java:27) >>> Caused by: java.net.BindException: Address already in use >>> at sun.nio.ch.Net.bind0(Native Method) >>> at sun.nio.ch.Net.bind(Net.java:432) >>> at sun.nio.ch.Net.bind(Net.java:424) >>> at >>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>> at >>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>> at >>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>> at >>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>> at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>> at >>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>> ... 5 more >>> ----- >>> >>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>> been created by given address, then creates a HttpContext if do not >>> exist. >>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>> ServerSocket#getLocalSocketAddress() (server local address), so >>> returns BindException when 0.0.0.0 has been blinded already. >>> >>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>> about above situation. And JAX_WS-941 does not back port to JDK7. >>> >>> So I write a patch which is based jdk9/dev/jaxws >>> (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. >>> >>> Please review this patch :) >>> >>> [1]: https://java.net/jira/browse/JAX_WS-941 >>> >>> - Patch >>> --- >>> diff -r 2d84c6f4cbba >>> >>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>> --- >>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>> Thu Oct 22 08:47:47 2015 -0700 >>> +++ >>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>> Tue Oct 27 19:48:35 2015 +0900 >>> @@ -38,6 +38,7 @@ >>> import java.util.concurrent.ExecutorService; >>> import java.util.concurrent.Executors; >>> import java.util.logging.Logger; >>> +import java.util.Optional; >>> >>> /** >>> * Manages all the WebService HTTP servers created by JAXWS runtime. >>> @@ -81,24 +82,38 @@ >>> synchronized(servers) { >>> state = servers.get(inetAddress); >>> if (state == null) { >>> - logger.fine("Creating new HTTP Server at >>> "+inetAddress); >>> - // Creates server with default socket backlog >>> - server = HttpServer.create(inetAddress, 0); >>> - server.setExecutor(Executors.newCachedThreadPool()); >>> - String path = url.toURI().getPath(); >>> - logger.fine("Creating HTTP Context at = "+path); >>> - HttpContext context = server.createContext(path); >>> - server.start(); >>> + final int finalPortNum = port; >>> + Optional stateOpt = >>> + servers.values() >>> + .stream() >>> + .filter(s -> s.getServer() >>> + .getAddress() >>> + .getPort() == >>> finalPortNum) >>> + .findAny(); >>> >>> - // we have to get actual inetAddress from server, >>> which can differ from the original in some cases. >>> - // e.g. A port number of zero will let the system >>> pick up an ephemeral port in a bind operation, >>> - // or IP: 0.0.0.0 - which is used to monitor >>> network traffic from any valid IP address >>> - inetAddress = server.getAddress(); >>> + if (inetAddress.getAddress().isAnyLocalAddress() && >>> + stateOpt.isPresent()) { >>> + state = stateOpt.get(); >>> + } else { >>> + logger.fine("Creating new HTTP Server at >>> "+inetAddress); >>> + // Creates server with default socket backlog >>> + server = HttpServer.create(inetAddress, 0); >>> + >>> server.setExecutor(Executors.newCachedThreadPool()); >>> + String path = url.toURI().getPath(); >>> + logger.fine("Creating HTTP Context at = "+path); >>> + HttpContext context = server.createContext(path); >>> + server.start(); >>> >>> - logger.fine("HTTP server started = "+inetAddress); >>> - state = new ServerState(server, path); >>> - servers.put(inetAddress, state); >>> - return context; >>> + // we have to get actual inetAddress from >>> server, which can differ from the original in some cases. >>> + // e.g. A port number of zero will let the >>> system pick up an ephemeral port in a bind operation, >>> + // or IP: 0.0.0.0 - which is used to monitor >>> network traffic from any valid IP address >>> + inetAddress = server.getAddress(); >>> + >>> + logger.fine("HTTP server started = >>> "+inetAddress); >>> + state = new ServerState(server, path); >>> + servers.put(inetAddress, state); >>> + return context; >>> + } >>> } >>> } >>> server = state.getServer(); >>> --- >>> >>> Thanks, >>> Yuji >> >> From amy.lu at oracle.com Tue Aug 2 05:57:56 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 2 Aug 2016 13:57:56 +0800 Subject: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt Message-ID: <57A03664.1040804@oracle.com> tools/jlink/JLinkOptimTest.java This test has been removed in JDK-8160829 sun/tools/jinfo/JInfoSanityTest.java sun/tools/jinfo/JInfoRunningProcessFlagTest.java sun/tools/jmap/heapconfig/JMapHeapConfigTest.java These tests have been removed in JDK-8155091 Please review the patch to delete these tests from ProblemList.txt. bug: https://bugs.openjdk.java.net/browse/JDK-8161970 https://bugs.openjdk.java.net/browse/JDK-8157664 webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 +++ new/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 @@ -318,7 +318,7 @@ ############################################################################ -# jdk_tools +# core_tools tools/pack200/CommandLineTests.java 7143279,8059906 generic-all @@ -368,20 +368,14 @@ sun/tools/jcmd/TestJcmdSanity.java 8031482 windows-all -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all - sun/tools/jstatd/TestJstatdExternalRegistry.java 8046285 generic-all sun/tools/jps/TestJpsJar.java 8160923 generic-all sun/tools/jps/TestJpsJarRelative.java 6456333 generic-all -sun/tools/jinfo/JInfoRunningProcessFlagTest.java 6734748 generic-all - sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java 8057732 generic-all -sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all - demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java 8151899 generic-all ############################################################################ @@ -391,9 +385,3 @@ com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all ############################################################################ - -# core_tools - -tools/jlink/JLinkOptimTest.java 8159264 generic-all - -############################################################################ From sean.coffey at oracle.com Tue Aug 2 07:58:25 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Aug 2016 08:58:25 +0100 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: References: Message-ID: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> Volker, Have the jdk8u hotspot edits been reviewed ? Looks like they should be. Can you add a suitable noreg label to the master bug report also. Regards, Sean. On 29/07/2016 19:58, Volker Simonis wrote: > Ping! > > Can I please have an approval for backporting this change to 8u-dev? > > Thanks, > Volker > > > On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis > wrote: >> Hi, >> >> could you please approve the backport of the following, mostly ppc64 >> change to jdk8u-dev: >> >> 8152172: PPC64: Support AES intrinsics >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ >> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 >> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b >> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f >> >> As you can see, the change consists of two parts - the main one in the >> hotpsot repo and a small part in the jdk repo. >> >> The jdk part applied cleanly to jdk8u (with the usual directory shuffling). >> >> The hotspot part required a small tweak, but only in the ppc-only >> part. This is because the feature detection for the AES instructions >> was already active in jdk9 when the original change was made but is >> not available in jdk8u until now. You can find the additional changes >> at the end of this mail for your convenience. >> >> The required shared changes cleanly apply to jdk8u. >> >> As Vladimir pointed out in a previous thread, shared Hotspot changes >> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do >> that and synchronously push both parts. >> >> @Hiroshii: could you please verify that you are fine with the change? >> I've done some tests on Power8LE but just want to be sure this >> downport satisfies your needs as well. >> >> Thank you and best regards, >> Volker >> >> ===================== >> >> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp >> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 >> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 >> @@ -452,6 +476,7 @@ >> a->popcntw(R7, R5); // code[7] -> popcntw >> a->fcfids(F3, F4); // code[8] -> fcfids >> a->vand(VR0, VR0, VR0); // code[9] -> vand >> + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher >> a->blr(); >> >> // Emit function to set one cache line to zero. Emit function >> descriptor and get pointer to it. >> @@ -495,6 +520,7 @@ >> if (code[feature_cntr++]) features |= popcntw_m; >> if (code[feature_cntr++]) features |= fcfids_m; >> if (code[feature_cntr++]) features |= vand_m; >> + if (code[feature_cntr++]) features |= vcipher_m; >> >> // Print the detection code. >> if (PrintAssembly) { >> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp >> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 >> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 >> @@ -42,6 +42,7 @@ >> fcfids, >> vand, >> dcba, >> + vcipher, >> num_features // last entry to count features >> }; >> enum Feature_Flag_Set { >> @@ -56,6 +57,7 @@ >> fcfids_m = (1 << fcfids ), >> vand_m = (1 << vand ), >> dcba_m = (1 << dcba ), >> + vcipher_m = (1 << vcipher), >> all_features_m = -1 >> }; >> static int _features; >> @@ -83,6 +85,7 @@ >> static bool has_fcfids() { return (_features & fcfids_m) != 0; } >> static bool has_vand() { return (_features & vand_m) != 0; } >> static bool has_dcba() { return (_features & dcba_m) != 0; } >> + static bool has_vcipher() { return (_features & vcipher_m) != 0; } >> >> static const char* cpu_features() { return _features_str; } From peter.levart at gmail.com Tue Aug 2 08:59:01 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 2 Aug 2016 10:59:01 +0200 Subject: JDK 9 RFR of JDK-8162817: Annotation toString output not reusable for source input In-Reply-To: <6a039169-5d99-002d-df19-e58bbfe458b2@oracle.com> References: <6a039169-5d99-002d-df19-e58bbfe458b2@oracle.com> Message-ID: <841aa0f1-708c-bd3e-c6d9-98996c0799af@gmail.com> Hi Joe, I wonder why you compare the type obtained from an value.getClass() with class literals for primitive types (lines 174, 176, 178): 165 Class type = value.getClass(); 166 if (!type.isArray()) { 167 // primitive value, string, class, enum const, or annotation 168 if (type == Class.class) 169 return toSourceString((Class) value); 170 else if (type == String.class) 171 return toSourceString((String) value); 172 if (type == Character.class) 173 return toSourceString((char) value); 174 else if (type == double.class) 175 return toSourceString((double) value); 176 else if (type == float.class) 177 return toSourceString((float) value); 178 else if (type == long.class) 179 return toSourceString((long) value); 180 else 181 return value.toString(); 182 } else { They will never match! Also, sometimes you use "else if (...)" and sometimes just "if (...)". They are both logically correct as you always "return" in the body of the previous if statement, but it is not very consistent... Otherwise looks good. Regards, Peter On 08/01/2016 11:39 PM, joe darcy wrote: > This change should cover 99 44/100 % of the annotation values that > appear in practice; limited efforts were taken quoting characters in > strings, etc. > > The basic approach is to introduce a family of overloaded > toSourceString methods to wrap/filter different kinds of values > coupled with methods to convert the various primitive arrays to > Stream for final processing by a shared method to surround an > array by "{" and "}" and add comma separators as needed. > > Thanks, > > -Joe From frank.yuan at oracle.com Tue Aug 2 10:20:50 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 2 Aug 2016 18:20:50 +0800 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <57991402.1040308@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> Message-ID: <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> Hi Joe and Daniel I have finished the rework as your comments, please check http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ JAXP tests use Policy classes, as well as 3 other patterns provided by JAXPTestUtilities: 1. runWithAllPerm methods, are only used for user setup code, never run jaxp code with them. 2. tryRunWithPolicyManager method, is used to run some test methods with security manager and run the others without security manager in single test class 3. runWithTmpPermission methods, which may run jaxp code with some limited permissions, those permissions belong to user permissions and jaxp code won't doPrivileged for them. E.g. PropertyPermission("MyInputFactory", "read") or FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") Btw, some tests or test methods are disabled or commented sm support temporarily for some known jaxp security bugs. Thanks Frank From sundararajan.athijegannathan at oracle.com Tue Aug 2 11:39:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 2 Aug 2016 17:09:04 +0530 Subject: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file Message-ID: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8159487 OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another fix. Just adding "JAVA_VERSION" and a test change to check these properties exist in release file. Thanks -Sundar From sundararajan.athijegannathan at oracle.com Tue Aug 2 11:45:51 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 2 Aug 2016 17:15:51 +0530 Subject: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt In-Reply-To: <57A03664.1040804@oracle.com> References: <57A03664.1040804@oracle.com> Message-ID: +1 for the jlink test being removed from the problem test. -Sundar On 8/2/2016 11:27 AM, Amy Lu wrote: > tools/jlink/JLinkOptimTest.java > This test has been removed in JDK-8160829 > > sun/tools/jinfo/JInfoSanityTest.java > sun/tools/jinfo/JInfoRunningProcessFlagTest.java > sun/tools/jmap/heapconfig/JMapHeapConfigTest.java > These tests have been removed in JDK-8155091 > > Please review the patch to delete these tests from ProblemList.txt. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8161970 > https://bugs.openjdk.java.net/browse/JDK-8157664 > > webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/ > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > +++ new/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > @@ -318,7 +318,7 @@ > > ############################################################################ > > -# jdk_tools > +# core_tools > > tools/pack200/CommandLineTests.java 7143279,8059906 generic-all > > @@ -368,20 +368,14 @@ > > sun/tools/jcmd/TestJcmdSanity.java 8031482 windows-all > > -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all > - > sun/tools/jstatd/TestJstatdExternalRegistry.java 8046285 generic-all > > sun/tools/jps/TestJpsJar.java 8160923 generic-all > > sun/tools/jps/TestJpsJarRelative.java 6456333 generic-all > > -sun/tools/jinfo/JInfoRunningProcessFlagTest.java 6734748 generic-all > - > sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java 8057732 generic-all > > -sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all > - > demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java 8151899 generic-all > > ############################################################################ > @@ -391,9 +385,3 @@ > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all > > ############################################################################ > - > -# core_tools > - > -tools/jlink/JLinkOptimTest.java 8159264 generic-all > - > -############################################################################ > From sundararajan.athijegannathan at oracle.com Tue Aug 2 11:48:27 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 2 Aug 2016 17:18:27 +0530 Subject: [9] RFR: 8162797: Code clean-up in IncludeLocalesPlugin In-Reply-To: <7d840ea0-eaee-5cee-a103-53f2759d5059@oracle.com> References: <7d840ea0-eaee-5cee-a103-53f2759d5059@oracle.com> Message-ID: <5e04d0c5-8450-a708-1c88-b06e7366d479@oracle.com> +1 -Sundar On 8/2/2016 2:15 AM, Naoto Sato wrote: > Hello, > > Please review this small change for the bug: > > https://bugs.openjdk.java.net/browse/JDK-8162797 > > The fix is located at: > > http://cr.openjdk.java.net/~naoto/8162797/webrev.00/ > > Naoto From james.laskey at oracle.com Tue Aug 2 11:53:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 2 Aug 2016 08:53:10 -0300 Subject: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file In-Reply-To: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> References: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> Message-ID: <0D87F1D2-99CE-4059-9854-2E34FB84F71A@oracle.com> +1 > On Aug 2, 2016, at 8:39 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8159487 > > OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another > fix. Just adding "JAVA_VERSION" and a test change to check these > properties exist in release file. > > Thanks > > -Sundar > From dmitry.samersoff at oracle.com Tue Aug 2 11:55:42 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 2 Aug 2016 14:55:42 +0300 Subject: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt In-Reply-To: <57A03664.1040804@oracle.com> References: <57A03664.1040804@oracle.com> Message-ID: Amy, Looks good for me! -Dmitry On 2016-08-02 08:57, Amy Lu wrote: > tools/jlink/JLinkOptimTest.java > This test has been removed in JDK-8160829 > > sun/tools/jinfo/JInfoSanityTest.java > sun/tools/jinfo/JInfoRunningProcessFlagTest.java > sun/tools/jmap/heapconfig/JMapHeapConfigTest.java > These tests have been removed in JDK-8155091 > > Please review the patch to delete these tests from ProblemList.txt. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8161970 > https://bugs.openjdk.java.net/browse/JDK-8157664 > > webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/ > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > +++ new/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > @@ -318,7 +318,7 @@ > > ############################################################################ > > -# jdk_tools > +# core_tools > > tools/pack200/CommandLineTests.java 7143279,8059906 generic-all > > @@ -368,20 +368,14 @@ > > sun/tools/jcmd/TestJcmdSanity.java 8031482 windows-all > > -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all > - > sun/tools/jstatd/TestJstatdExternalRegistry.java 8046285 generic-all > > sun/tools/jps/TestJpsJar.java 8160923 generic-all > > sun/tools/jps/TestJpsJarRelative.java 6456333 generic-all > > -sun/tools/jinfo/JInfoRunningProcessFlagTest.java 6734748 generic-all > - > sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java 8057732 generic-all > > -sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all > - > demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java 8151899 generic-all > > ############################################################################ > @@ -391,9 +385,3 @@ > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all > > ############################################################################ > - > -# core_tools > - > -tools/jlink/JLinkOptimTest.java 8159264 generic-all > - > -############################################################################ > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Tue Aug 2 12:30:24 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Aug 2016 13:30:24 +0100 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> Message-ID: <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> Hi Frank, I am intrigued by these change which do not seem to have anything to do with the rest. I mean, I'm not opposed as long as they are intended and that Joe validates them: ======================================================== http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.frames.html 118 spf.setNamespaceAware(false); http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.frames.html http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.html http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html This looks like a desirable change - but what does it have to do with enabling security manager? Also: ======================================================== http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html 70 tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", true); Is this needed only when there is a security manager? ======================================================== http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html 119 /* 120 addPermission(new RuntimePermission("getClassLoader")); 121 addPermission(new RuntimePermission("createClassLoader")); 122 addPermission(new RuntimePermission("createSecurityManager")); 123 addPermission(new RuntimePermission("modifyThread")); 124 addPermission(new PropertyPermission("*", "read,write")); 125 126 addPermission(new RuntimePermission("setIO")); 127 addPermission(new RuntimePermission("setContextClassLoader")); 128 addPermission(new RuntimePermission("accessDeclaredMembers"));*/ Please remove before pushing. ======================================================== test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl It seems these two files have been removed, but shouldn't they have been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform instead? I see they are used by test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java Did you forget to hg add them? ======================================================== Otherwise the new JAXPPolicyManager & its Policy implementation look good. This is much simpler and better than the first iteration :-) This was a *very* long patch - so congratulations for seeing this through! cheers, -- daniel On 02/08/16 11:20, Frank Yuan wrote: > Hi Joe and Daniel > > I have finished the rework as your comments, please check http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ > > JAXP tests use Policy classes, as well as 3 other patterns provided by JAXPTestUtilities: > 1. runWithAllPerm methods, are only used for user setup code, never run jaxp code with them. > 2. tryRunWithPolicyManager method, is used to run some test methods with security manager and run the others without security > manager in single test class > 3. runWithTmpPermission methods, which may run jaxp code with some limited permissions, those permissions belong to user permissions > and jaxp code won't doPrivileged for them. E.g. PropertyPermission("MyInputFactory", "read") or > FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") > > > Btw, some tests or test methods are disabled or commented sm support temporarily for some known jaxp security bugs. > > Thanks > Frank > From peter.levart at gmail.com Tue Aug 2 12:55:20 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 2 Aug 2016 14:55:20 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: Hi Kim, This looks very good. I like the way you dealt with race between the ReferenceHandler thread and threads waiting for it to do some cleanup progress. I think the VM API is suitable for possible further development on JDK-8149925. It's also nice that the whole pending list is obtained in one native call, so further optimizations on Java side are possible. Regards, Peter On 08/01/2016 08:47 PM, Kim Barrett wrote: > This updated webrev addresses concerns about the performance of the VM > API used by the reference processor thread in the original webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ > > The originally offered approach was an attempt to minimize changes. I > was trying to be as similar to the existing code as possible, while > moving part of it into the VM, where we have the necessary control > over suspension and the like. We already know we want to make changes > in this area, in order to eliminate the use of > jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that > JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we > should revisit that. > > As Peter pointed out, my original change introduces a small > performance regression on a microbenchmark for reference processing > throughput. It also showed a small performance benefit on a different > microbenchmark (allocation rate for a stress test of direct byte > buffers), as noted in the original RFR. I can reproduce both of > those. > > I think reference processing thread throughput is the right measure to > use, so long as others don't become horrible. Focusing on that, it's > better to just let the reference processing thread do the processing, > rather than slowing it down to allow for the rare case when there's > another thread that could possibly help. This is especially true now > that Cleaner has such limited usage. > > This leads to a different API for other threads; rather than > tryHandlePending that other threads can call to help and to examine > progress, we now have waitForReferenceProcessing. The VM API is also > different; rather than popReferencePendingList to get or wait, we now > have getAndClearReferencePendingList and checkReferencePendingList, > the latter with an optional wait. > > The splitting of the VM API allows us to avoid a narrow race condition > discussed by Peter in his prototypes. Peter suggested this race was > ok because java.nio.Bits makes several retries. However, those > retries are only done before throwing OOME. There are no retries > before invoking GC, so this race could lead to unnecessary successive > GCs. > > Doing all the processing on the reference processing thread eliminates > execution of Cleaners on application threads, though that's not nearly > as much an issue now that the use of Cleaner is so restricted. > > We've also eliminated a pre-existing issue where a helper could report > no progress even though the reference processing thread (and other > helpers) had removed a pending reference, but not yet processed it. > This could result in the non-progressing helper invoking GC or > reporting failure, even though it might have succeeded if it had > waited for the other thread(s) to complete processing the reference(s) > being worked on. > > I think the new waitForReferenceProcessing could be used to fix > JDK-6306116, though that isn't part of this change, and was not really > a motivating factor. > > I don't know if the new waitForReferenceProcessing will be used by > whatever we eventually do for JDK-8149925, but I think the new VM API > will suffice for that. That is, I think JDK-8149925 might require > changes to the core-libs API used by nio.Bits, and won't require > further VM API changes. > > > From Roger.Riggs at Oracle.com Tue Aug 2 13:45:43 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 2 Aug 2016 09:45:43 -0400 Subject: RFR 9: [TESTBUG] 8160151: java/lang/ProcessBuilder/Zombies.java failed with error "1 zombies!" Message-ID: Please review a test fix for an intermittently failing ProcessBuilder test. The test should be run in a separate vm so it only sees Zombies from processes it creates. When run in-process with jtreg, it may see Zombies from other processes created by jtreg. Additional diagnostic information is added as well in case of recurrence. The test is moved back to tier1. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160151/ Issue: https://bugs.openjdk.java.net/browse/JDK-8160151 Thanks, Roger From daniel.fuchs at oracle.com Tue Aug 2 13:59:21 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Aug 2016 14:59:21 +0100 Subject: RFR 9: [TESTBUG] 8160151: java/lang/ProcessBuilder/Zombies.java failed with error "1 zombies!" In-Reply-To: References: Message-ID: <1b6769aa-86a6-e5c7-7868-d727271d1e05@oracle.com> Hi Roger, Running in othervm looks good to me. The only thing I wonder about is these lines which are removed: 79 // Log remaining processes 80 ProcessBuilder pb = new ProcessBuilder("/bin/ps", "-ef"); 81 pb.inheritIO(); 82 Process p2 = pb.start(); 83 p2.waitFor(); Isn't that removing diagnostic information? best regards, -- daniel On 02/08/16 14:45, Roger Riggs wrote: > Please review a test fix for an intermittently failing ProcessBuilder test. > The test should be run in a separate vm so it only sees Zombies from > processes it creates. > When run in-process with jtreg, it may see Zombies from other processes > created by jtreg. > Additional diagnostic information is added as well in case of recurrence. > > The test is moved back to tier1. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160151/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8160151 > > Thanks, Roger > From Roger.Riggs at Oracle.com Tue Aug 2 14:03:09 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 2 Aug 2016 10:03:09 -0400 Subject: RFR 9: [TESTBUG] 8160151: java/lang/ProcessBuilder/Zombies.java failed with error "1 zombies!" In-Reply-To: <1b6769aa-86a6-e5c7-7868-d727271d1e05@oracle.com> References: <1b6769aa-86a6-e5c7-7868-d727271d1e05@oracle.com> Message-ID: <11544c21-61ea-8430-3047-17759b13ab2a@Oracle.com> Hi Daniel, Those were added in a previous diagnostic iteration. They do a separate ps which might be too late to provide any using information. The first perl script retains and prints the suspect processes and should be enough debugging info. (There is no harm in retaining this extra info but I didn't think it was particularly useful.) Thanks, Roger On 8/2/2016 9:59 AM, Daniel Fuchs wrote: > Hi Roger, > > Running in othervm looks good to me. > The only thing I wonder about is these lines which are > removed: > > 79 // Log remaining processes > 80 ProcessBuilder pb = new ProcessBuilder("/bin/ps", > "-ef"); > 81 pb.inheritIO(); > 82 Process p2 = pb.start(); > 83 p2.waitFor(); > > Isn't that removing diagnostic information? > > best regards, > > -- daniel > > On 02/08/16 14:45, Roger Riggs wrote: >> Please review a test fix for an intermittently failing ProcessBuilder >> test. >> The test should be run in a separate vm so it only sees Zombies from >> processes it creates. >> When run in-process with jtreg, it may see Zombies from other processes >> created by jtreg. >> Additional diagnostic information is added as well in case of >> recurrence. >> >> The test is moved back to tier1. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160151/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8160151 >> >> Thanks, Roger >> > From daniel.fuchs at oracle.com Tue Aug 2 14:13:18 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 Aug 2016 15:13:18 +0100 Subject: RFR 9: [TESTBUG] 8160151: java/lang/ProcessBuilder/Zombies.java failed with error "1 zombies!" In-Reply-To: <11544c21-61ea-8430-3047-17759b13ab2a@Oracle.com> References: <1b6769aa-86a6-e5c7-7868-d727271d1e05@oracle.com> <11544c21-61ea-8430-3047-17759b13ab2a@Oracle.com> Message-ID: <4eec7823-3d43-7842-de54-698cd399dfbe@oracle.com> On 02/08/16 15:03, Roger Riggs wrote: > Hi Daniel, > > Those were added in a previous diagnostic iteration. > They do a separate ps which might be too late to provide any using > information. > The first perl script retains and prints the suspect processes and > should be enough debugging info. > (There is no harm in retaining this extra info but I didn't think it was > particularly useful.) Thanks Roger. No issue removing this code then. +1 -- daniel > > Thanks, Roger > > > On 8/2/2016 9:59 AM, Daniel Fuchs wrote: >> Hi Roger, >> >> Running in othervm looks good to me. >> The only thing I wonder about is these lines which are >> removed: >> >> 79 // Log remaining processes >> 80 ProcessBuilder pb = new ProcessBuilder("/bin/ps", >> "-ef"); >> 81 pb.inheritIO(); >> 82 Process p2 = pb.start(); >> 83 p2.waitFor(); >> >> Isn't that removing diagnostic information? >> >> best regards, >> >> -- daniel >> >> On 02/08/16 14:45, Roger Riggs wrote: >>> Please review a test fix for an intermittently failing ProcessBuilder >>> test. >>> The test should be run in a separate vm so it only sees Zombies from >>> processes it creates. >>> When run in-process with jtreg, it may see Zombies from other processes >>> created by jtreg. >>> Additional diagnostic information is added as well in case of >>> recurrence. >>> >>> The test is moved back to tier1. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-zombies-8160151/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8160151 >>> >>> Thanks, Roger >>> >> > From chris.plummer at oracle.com Tue Aug 2 14:50:30 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Aug 2016 07:50:30 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: On 8/1/16 9:30 PM, Chris Plummer wrote: > On 8/1/16 7:25 PM, David Holmes wrote: >> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>> On 8/1/16 5:58 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review this simple change: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>> >>>> You've split a compound expression with your code: >>>> >>>> 227 jtregExitCode=$$? && \ >>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>> 229 jtregExitCode=0; \ >>>> 230 fi ; \ >>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>> >>>> I'm not clear exactly why the && was needed here but rather than find >>>> out later I suggest rearranging the above to: >>>> >>>> jtregExitCode=$$? && \ >>>> _summary="$(SUMMARY_TXT)"; \ >>>> if [ $${jtregExitCode} == 1 ]; then \ >>>> jtregExitCode=0; \ >>>> fi ; \ >>>> >>> Yeah, that makes sense. I'll make the change. However, it's really >>> unclear what the use case for && is here. How can jtregExitCode=$$? >>> ever >>> fail? >> >> I wonder if it evaluates to the $? value and so only sets _summary if >> we had a zero exit code? (Not that I understand why we would only set >> _summary in that context.) > I tried the following: > > bash-4.1$ x=0 && echo "foo"; > > And "foo" is always printed. I also tried non-zero values for x. Here > are some other examples: > > bash-4.1$ (exit 1) && echo "foo" > bash-4.1$ (exit 0) && echo "foo" > foo > > Commands evaluate to true if the exit status is 0, and false > otherwise, so I guess you could say commands evaluate to !?$. For &&, > the rhs is only executed if the lhs has a zero exit status. Updated webrev: http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ thanks, Chris > > Chris >> >> David >> >>> thanks, >>> >>> Chris >>>> Thanks, >>>> David >>>> >>>>> Note the copyright dates haven't been updated in this webrev, but >>>>> I did >>>>> update them locally after noticing that. >>>>> >>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> >>> > From joe.darcy at oracle.com Tue Aug 2 17:16:02 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 2 Aug 2016 10:16:02 -0700 Subject: JDK 9 RFR of JDK-8162817: Annotation toString output not reusable for source input In-Reply-To: <841aa0f1-708c-bd3e-c6d9-98996c0799af@gmail.com> References: <6a039169-5d99-002d-df19-e58bbfe458b2@oracle.com> <841aa0f1-708c-bd3e-c6d9-98996c0799af@gmail.com> Message-ID: <0fbc8001-bc27-cf30-f9af-f64deec8e11e@oracle.com> Hi Peter, On 8/2/2016 1:59 AM, Peter Levart wrote: > Hi Joe, > > I wonder why you compare the type obtained from an value.getClass() > with class literals for primitive types (lines 174, 176, 178): > > 165 Class type = value.getClass(); > 166 if (!type.isArray()) { > 167 // primitive value, string, class, enum const, or > annotation > 168 if (type == Class.class) > 169 return toSourceString((Class) value); > 170 else if (type == String.class) > 171 return toSourceString((String) value); > 172 if (type == Character.class) > 173 return toSourceString((char) value); > 174 else if (type == double.class) > 175 return toSourceString((double) value); > 176 else if (type == float.class) > 177 return toSourceString((float) value); > 178 else if (type == long.class) > 179 return toSourceString((long) value); > 180 else > 181 return value.toString(); > 182 } else { > > They will never match! Indeed! Just goes to show the value of making sure there are no coverage gaps in one's regression tests ;-) In an updated version of the patch, http://cr.openjdk.java.net/~darcy/8162817.2/ I replaced 174 else if (type == double.class) 175 return toSourceString((double) value); 176 else if (type == float.class) 177 return toSourceString((float) value); 178 else if (type == long.class) 179 return toSourceString((long) value); 180 else 181 return value.toString(); with 174 else if (type == Double.class) 175 return toSourceString((double) value); 176 else if (type == Float.class) 177 return toSourceString((float) value); 178 else if (type == Long.class) 179 return toSourceString((long) value); 180 else 181 return value.toString(); and added a test case to check the following annotation: 76 @MostlyPrimitive( 77 c0='a', 78 c1='\'', 79 i0=1, 80 i1=2, 81 f0=1.0f, 82 f1=Float.NaN, 83 d0=0.0, 84 d1=2.0/0.0, 85 l0=5, 86 l1=Long.MAX_VALUE, 87 s0="Hello world.", 88 s1="a\"b", 89 class0=Obj[].class 90 ) Many of the new toString forms of these members differ from the current ones. > > Also, sometimes you use "else if (...)" and sometimes just "if (...)". > They are both logically correct as you always "return" in the body of > the previous if statement, but it is not very consistent... > > Otherwise looks good. The existing code in this class (most of it dating back to 2003!), was pretty consistent in its "if {return ...} - if {return ...}" usage. However, when there are logical alternatives, I find it marginally clearer to use a "if {return ...} else if {return ...}. ..." structure. (If there was switching on Class objects, this class would be a great candidate to use it.) However, I didn't think it was justified to update the rest of the class to use the if-else pattern. Thanks for the review, -Joe > > Regards, Peter > > On 08/01/2016 11:39 PM, joe darcy wrote: >> This change should cover 99 44/100 % of the annotation values that >> appear in practice; limited efforts were taken quoting characters in >> strings, etc. >> >> The basic approach is to introduce a family of overloaded >> toSourceString methods to wrap/filter different kinds of values >> coupled with methods to convert the various primitive arrays to >> Stream for final processing by a shared method to surround an >> array by "{" and "}" and add comma separators as needed. >> >> Thanks, >> >> -Joe > From kim.barrett at oracle.com Tue Aug 2 18:28:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Aug 2016 14:28:40 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: <5E608891-21D4-4518-BA75-66F7DE53C64E@oracle.com> > On Aug 2, 2016, at 8:55 AM, Peter Levart wrote: > > Hi Kim, > > This looks very good. I like the way you dealt with race between the ReferenceHandler thread and threads waiting for it to do some cleanup progress. I think the VM API is suitable for possible further development on JDK-8149925. It's also nice that the whole pending list is obtained in one native call, so further optimizations on Java side are possible. > > Regards, Peter Thanks! > > On 08/01/2016 08:47 PM, Kim Barrett wrote: >> This updated webrev addresses concerns about the performance of the VM >> API used by the reference processor thread in the original webrev. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ [snip] From volker.simonis at gmail.com Tue Aug 2 19:47:45 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Aug 2016 21:47:45 +0200 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> References: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> Message-ID: Hi Sean, thanks a lot for your reply. You're right - I'm still waiting for a review of the hotspot part. Any volunteers :) Regarding the noreg label: I used 'noreg-other' because there already exist AES tests (they have never been part of this original change). Is that the right label? There are simply too many different noreg labels without documentation so if I selected the wrong one, please advice which one to choose. Thanks, Volker On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey wrote: > Volker, > > Have the jdk8u hotspot edits been reviewed ? Looks like they should be. > > Can you add a suitable noreg label to the master bug report also. > > Regards, > Sean. > > > On 29/07/2016 19:58, Volker Simonis wrote: >> >> Ping! >> >> Can I please have an approval for backporting this change to 8u-dev? >> >> Thanks, >> Volker >> >> >> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis >> wrote: >>> >>> Hi, >>> >>> could you please approve the backport of the following, mostly ppc64 >>> change to jdk8u-dev: >>> >>> 8152172: PPC64: Support AES intrinsics >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ >>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ >>> Review: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 >>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b >>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f >>> >>> As you can see, the change consists of two parts - the main one in the >>> hotpsot repo and a small part in the jdk repo. >>> >>> The jdk part applied cleanly to jdk8u (with the usual directory >>> shuffling). >>> >>> The hotspot part required a small tweak, but only in the ppc-only >>> part. This is because the feature detection for the AES instructions >>> was already active in jdk9 when the original change was made but is >>> not available in jdk8u until now. You can find the additional changes >>> at the end of this mail for your convenience. >>> >>> The required shared changes cleanly apply to jdk8u. >>> >>> As Vladimir pointed out in a previous thread, shared Hotspot changes >>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do >>> that and synchronously push both parts. >>> >>> @Hiroshii: could you please verify that you are fine with the change? >>> I've done some tests on Power8LE but just want to be sure this >>> downport satisfies your needs as well. >>> >>> Thank you and best regards, >>> Volker >>> >>> ===================== >>> >>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp >>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 >>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 >>> @@ -452,6 +476,7 @@ >>> a->popcntw(R7, R5); // code[7] -> popcntw >>> a->fcfids(F3, F4); // code[8] -> fcfids >>> a->vand(VR0, VR0, VR0); // code[9] -> vand >>> + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher >>> a->blr(); >>> >>> // Emit function to set one cache line to zero. Emit function >>> descriptor and get pointer to it. >>> @@ -495,6 +520,7 @@ >>> if (code[feature_cntr++]) features |= popcntw_m; >>> if (code[feature_cntr++]) features |= fcfids_m; >>> if (code[feature_cntr++]) features |= vand_m; >>> + if (code[feature_cntr++]) features |= vcipher_m; >>> >>> // Print the detection code. >>> if (PrintAssembly) { >>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp >>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 >>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 >>> @@ -42,6 +42,7 @@ >>> fcfids, >>> vand, >>> dcba, >>> + vcipher, >>> num_features // last entry to count features >>> }; >>> enum Feature_Flag_Set { >>> @@ -56,6 +57,7 @@ >>> fcfids_m = (1 << fcfids ), >>> vand_m = (1 << vand ), >>> dcba_m = (1 << dcba ), >>> + vcipher_m = (1 << vcipher), >>> all_features_m = -1 >>> }; >>> static int _features; >>> @@ -83,6 +85,7 @@ >>> static bool has_fcfids() { return (_features & fcfids_m) != 0; } >>> static bool has_vand() { return (_features & vand_m) != 0; } >>> static bool has_dcba() { return (_features & dcba_m) != 0; } >>> + static bool has_vcipher() { return (_features & vcipher_m) != 0; } >>> >>> static const char* cpu_features() { return _features_str; } > > From huizhe.wang at oracle.com Tue Aug 2 21:56:07 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 02 Aug 2016 14:56:07 -0700 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> Message-ID: <57A116F7.3040605@oracle.com> On 8/2/16, 5:30 AM, Daniel Fuchs wrote: > Hi Frank, > > I am intrigued by these change which do not seem > to have anything to do with the rest. I mean, I'm not opposed > as long as they are intended and that Joe validates them: > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.frames.html > > > 118 spf.setNamespaceAware(false); Not sure why this was changed. > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.frames.html > The test itself wasn't very clear on the content it tests. If it only verifies whether a resolver is used as is said, then this and related changes in ResolverTest and publish.xml are fine. To the extent it verifies, it didn't have to output to a file. > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.html > We have to let Frank explain why namespace was turned off for these tests :-) In this case, XMLReaderNSTableTest. In general, I would say enabling security shouldn't change tests or gold files in this case. > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html > > This looks like a desirable change - but what does it have to do > with enabling security manager? Probably to remove the reference to that particular server? Seems to be fine as a cleanup. Again, it (the original test) only verifies a resolve is used, it didn't even need to write out a file to prove that. > > Also: > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html > > > 70 > tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", > true); > > Is this needed only when there is a security manager? Yes, when Security Manager is present, this feature is turned off by default. > > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html > > > > 119 /* > 120 addPermission(new RuntimePermission("getClassLoader")); > 121 addPermission(new RuntimePermission("createClassLoader")); > 122 addPermission(new > RuntimePermission("createSecurityManager")); > 123 addPermission(new RuntimePermission("modifyThread")); > 124 addPermission(new PropertyPermission("*", "read,write")); > 125 > 126 addPermission(new RuntimePermission("setIO")); > 127 addPermission(new > RuntimePermission("setContextClassLoader")); > 128 addPermission(new > RuntimePermission("accessDeclaredMembers"));*/ > > > Please remove before pushing. > > > ======================================================== > > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl > > It seems these two files have been removed, but shouldn't they have > been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform > instead? > I see they are used by > test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java > > Did you forget to hg add them? > > ======================================================== > > > Otherwise the new JAXPPolicyManager & its Policy implementation > look good. This is much simpler and better than the first > iteration :-) > > This was a *very* long patch - so congratulations for seeing > this through! Very long patch, indeed! Thanks for the great effort! Very well done with the unified Policy/Permission management. Best, Joe > > cheers, > > -- daniel > > > On 02/08/16 11:20, Frank Yuan wrote: >> Hi Joe and Daniel >> >> I have finished the rework as your comments, please check >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ >> >> JAXP tests use Policy classes, as well as 3 other patterns provided >> by JAXPTestUtilities: >> 1. runWithAllPerm methods, are only used for user setup code, never >> run jaxp code with them. >> 2. tryRunWithPolicyManager method, is used to run some test methods >> with security manager and run the others without security >> manager in single test class >> 3. runWithTmpPermission methods, which may run jaxp code with some >> limited permissions, those permissions belong to user permissions >> and jaxp code won't doPrivileged for them. E.g. >> PropertyPermission("MyInputFactory", "read") or >> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") >> >> >> Btw, some tests or test methods are disabled or commented sm support >> temporarily for some known jaxp security bugs. >> >> Thanks >> Frank >> > From kim.barrett at oracle.com Wed Aug 3 00:03:20 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Aug 2016 20:03:20 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: > On Aug 1, 2016, at 2:47 PM, Kim Barrett wrote: > > This updated webrev addresses concerns about the performance of the VM > API used by the reference processor thread in the original webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ Sorry, typo in the incremental webrev URLs ? ?incr? => ?inc?. From huizhe.wang at oracle.com Wed Aug 3 00:31:59 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 02 Aug 2016 17:31:59 -0700 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <57A116F7.3040605@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> Message-ID: <57A13B7F.7000002@oracle.com> other than that previously discussed, in test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/DocumentBuilderFactoryTest.java the comments related to the removed code can be removed as well test/javax/xml/jaxp/functional/javax/xml/parsers/ptests/SAXParserTest.java @Test(expectedExceptions = SAXException.class, dataProvider = "parser-provider", enabled = false) //disabled for 8162848 -- just a reminder, as we discussed, the test needs to be enabled, and 8162848 closed (also one in test/javax/xml/jaxp/unittest/common/Sources.java) what are runWithSecurityManager and runWithoutSecurityManager in some of the tests? I thought the whole test suite will be run with and without security manager, isn't that the plan? Once again, great work and nice to clean up the old security-testing code. Best, Joe On 8/2/16, 2:56 PM, Joe Wang wrote: > > > On 8/2/16, 5:30 AM, Daniel Fuchs wrote: >> Hi Frank, >> >> I am intrigued by these change which do not seem >> to have anything to do with the rest. I mean, I'm not opposed >> as long as they are intended and that Joe validates them: >> ======================================================== >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.frames.html >> >> >> 118 spf.setNamespaceAware(false); > > Not sure why this was changed. >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.frames.html >> > > The test itself wasn't very clear on the content it tests. If it only > verifies whether a resolver is used as is said, then this and related > changes in ResolverTest and publish.xml are fine. To the extent it > verifies, it didn't have to output to a file. >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.html >> > > We have to let Frank explain why namespace was turned off for these > tests :-) In this case, XMLReaderNSTableTest. In general, I would say > enabling security shouldn't change tests or gold files in this case. > >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html >> >> This looks like a desirable change - but what does it have to do >> with enabling security manager? > > Probably to remove the reference to that particular server? Seems to > be fine as a cleanup. Again, it (the original test) only verifies a > resolve is used, it didn't even need to write out a file to prove that. >> >> Also: >> ======================================================== >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html >> >> >> 70 >> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", >> true); >> >> Is this needed only when there is a security manager? > > Yes, when Security Manager is present, this feature is turned off by > default. >> >> ======================================================== >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html >> >> >> >> 119 /* >> 120 addPermission(new RuntimePermission("getClassLoader")); >> 121 addPermission(new RuntimePermission("createClassLoader")); >> 122 addPermission(new >> RuntimePermission("createSecurityManager")); >> 123 addPermission(new RuntimePermission("modifyThread")); >> 124 addPermission(new PropertyPermission("*", "read,write")); >> 125 >> 126 addPermission(new RuntimePermission("setIO")); >> 127 addPermission(new >> RuntimePermission("setContextClassLoader")); >> 128 addPermission(new >> RuntimePermission("accessDeclaredMembers"));*/ >> >> >> Please remove before pushing. >> >> >> ======================================================== >> >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml >> >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl >> >> It seems these two files have been removed, but shouldn't they have >> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform >> instead? >> I see they are used by >> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java >> >> Did you forget to hg add them? >> >> ======================================================== >> >> >> Otherwise the new JAXPPolicyManager & its Policy implementation >> look good. This is much simpler and better than the first >> iteration :-) >> >> This was a *very* long patch - so congratulations for seeing >> this through! > > Very long patch, indeed! Thanks for the great effort! Very well done > with the unified Policy/Permission management. > > Best, > Joe > >> >> cheers, >> >> -- daniel >> >> >> On 02/08/16 11:20, Frank Yuan wrote: >>> Hi Joe and Daniel >>> >>> I have finished the rework as your comments, please check >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ >>> >>> JAXP tests use Policy classes, as well as 3 other patterns provided >>> by JAXPTestUtilities: >>> 1. runWithAllPerm methods, are only used for user setup code, never >>> run jaxp code with them. >>> 2. tryRunWithPolicyManager method, is used to run some test methods >>> with security manager and run the others without security >>> manager in single test class >>> 3. runWithTmpPermission methods, which may run jaxp code with some >>> limited permissions, those permissions belong to user permissions >>> and jaxp code won't doPrivileged for them. E.g. >>> PropertyPermission("MyInputFactory", "read") or >>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") >>> >>> >>> Btw, some tests or test methods are disabled or commented sm support >>> temporarily for some known jaxp security bugs. >>> >>> Thanks >>> Frank >>> >> From david.holmes at oracle.com Wed Aug 3 02:04:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 12:04:30 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: <364119db-f315-2f9e-68c2-80ea382de535@oracle.com> Looks good. Thanks, David On 3/08/2016 12:50 AM, Chris Plummer wrote: > On 8/1/16 9:30 PM, Chris Plummer wrote: >> On 8/1/16 7:25 PM, David Holmes wrote: >>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple change: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>> >>>>> You've split a compound expression with your code: >>>>> >>>>> 227 jtregExitCode=$$? && \ >>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>> 229 jtregExitCode=0; \ >>>>> 230 fi ; \ >>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>> >>>>> I'm not clear exactly why the && was needed here but rather than find >>>>> out later I suggest rearranging the above to: >>>>> >>>>> jtregExitCode=$$? && \ >>>>> _summary="$(SUMMARY_TXT)"; \ >>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>> jtregExitCode=0; \ >>>>> fi ; \ >>>>> >>>> Yeah, that makes sense. I'll make the change. However, it's really >>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>> ever >>>> fail? >>> >>> I wonder if it evaluates to the $? value and so only sets _summary if >>> we had a zero exit code? (Not that I understand why we would only set >>> _summary in that context.) >> I tried the following: >> >> bash-4.1$ x=0 && echo "foo"; >> >> And "foo" is always printed. I also tried non-zero values for x. Here >> are some other examples: >> >> bash-4.1$ (exit 1) && echo "foo" >> bash-4.1$ (exit 0) && echo "foo" >> foo >> >> Commands evaluate to true if the exit status is 0, and false >> otherwise, so I guess you could say commands evaluate to !?$. For &&, >> the rhs is only executed if the lhs has a zero exit status. > Updated webrev: > > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ > > thanks, > > Chris >> >> Chris >>> >>> David >>> >>>> thanks, >>>> >>>> Chris >>>>> Thanks, >>>>> David >>>>> >>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>> I did >>>>>> update them locally after noticing that. >>>>>> >>>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>> >>>> >> > From frank.yuan at oracle.com Wed Aug 3 03:21:23 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 3 Aug 2016 11:21:23 +0800 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> Message-ID: <021901d1ed36$2180ef90$6482ceb0$@oracle.com> Hi Daniel > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests > > Hi Frank, > > I am intrigued by these change which do not seem > to have anything to do with the rest. I mean, I'm not opposed > as long as they are intended and that Joe validates them: I corrected, cleaned up some code during I addressed the major task, there are also some others besides you found, I even couldn't recall all of them now. Sorry it confused you... > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram > es.html > > 118 spf.setNamespaceAware(false); > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra me > s.html > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h t > ml > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html > This looks like a desirable change - but what does it have to do > with enabling security manager? > They are unrelated to sm enabling, XMLReaderNSTableTest was not added with @Test, so it was never run, after I added, I had to correct the golden file to let it passed. spf.setNamespaceAware(false); is redundant, I will replace with a comment line to state NamespaceAware is false by default. > Also: > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html > > 70 > tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", > true); > > Is this needed only when there is a security manager? > > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html > > > 119 /* > 120 addPermission(new RuntimePermission("getClassLoader")); > 121 addPermission(new RuntimePermission("createClassLoader")); > 122 addPermission(new RuntimePermission("createSecurityManager")); > 123 addPermission(new RuntimePermission("modifyThread")); > 124 addPermission(new PropertyPermission("*", "read,write")); > 125 > 126 addPermission(new RuntimePermission("setIO")); > 127 addPermission(new RuntimePermission("setContextClassLoader")); > 128 addPermission(new > RuntimePermission("accessDeclaredMembers"));*/ > > > Please remove before pushing. > > Yes, I will. Forgot yesterday... > ======================================================== > > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl > > It seems these two files have been removed, but shouldn't they have > been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform > instead? > I see they are used by > test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java > > Did you forget to hg add them? > The new destination directory which CLITest.java is moved to, contains same files. So don't need to move them. > ======================================================== > > > Otherwise the new JAXPPolicyManager & its Policy implementation > look good. This is much simpler and better than the first > iteration :-) > > This was a *very* long patch - so congratulations for seeing > this through! > Really thank you very much for having reviewed my changes and given me so much valuable comments! Frank > cheers, > > -- daniel > > > On 02/08/16 11:20, Frank Yuan wrote: > > Hi Joe and Daniel > > > > I have finished the rework as your comments, please check http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ > > > > JAXP tests use Policy classes, as well as 3 other patterns provided by JAXPTestUtilities: > > 1. runWithAllPerm methods, are only used for user setup code, never run jaxp code with them. > > 2. tryRunWithPolicyManager method, is used to run some test methods with security manager and run the others without security > > manager in single test class > > 3. runWithTmpPermission methods, which may run jaxp code with some limited permissions, those permissions belong to user permissions > > and jaxp code won't doPrivileged for them. E.g. PropertyPermission("MyInputFactory", "read") or > > FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") > > > > > > Btw, some tests or test methods are disabled or commented sm support temporarily for some known jaxp security bugs. > > > > Thanks > > Frank > > From david.holmes at oracle.com Wed Aug 3 07:41:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 17:41:54 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> Message-ID: On 2/08/2016 4:46 AM, Kim Barrett wrote: > This updated webrev addresses the concerns around initialization order > for Throwable and OutOfMemoryError. It doesn't address the VM API > used by the reference processor thread; that will be in a later > webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ > > The jdk tree is unchanged from webrev.01. > > I've backed out the change to initialize_java_lang_classes. (To > verify this, look at the runtime/thread.cpp in the full webrev.) > > Instead, Universe::gen_out_of_memory_error now also requires Throwable > to be initialized before it will attempt to fill in the stack trace. > This means that VM generated OOMEs occurring early in initialization > won't have a stack trace. This change looks good to me. Thanks, David > An alternative that I considered was to remove the assert at the end > of fill_in_stack_trace_of_preallocated_backtrace that requires > java_lang_Throwable;:unassigned_stacktrace() to return non-NULL. I > did some testing that seemed to work and provide stacktraces, relying > on code in the Throwable class that special cases this "out of > protocol" state. However, having read some of the history around that > (JDK-6998871, JDK-7045138, JDK-7046490), that special casing seems to > have been intended to be temporary, and expected to be removed. > (Though I didn't find an RFE for doing so, and I'm not doing so here.) > Even if we decided it wasn't going to be removed, this approach seems > somewhat fragile. > > [Note to Coleen: This is the reverse of what you and I talked about a > few days ago; I hadn't reviewed the history carefully then.] > From amy.lu at oracle.com Wed Aug 3 07:49:21 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 3 Aug 2016 15:49:21 +0800 Subject: JDK 9 RFR of JDK-8161024: Remove intermittent key from java/lang/Runtime/exec/LotsOfOutput.java Message-ID: <57A1A201.6020406@oracle.com> java/lang/Runtime/exec/LotsOfOutput.java This test was failing intermittently (JDK-8078582 JDK-8086117). Mentioned issues have been resolved and no open bug (no failure reported) till now. This patch is to remove @key intermittent from the test. bug: https://bugs.openjdk.java.net/browse/JDK-8161024 webrev: http://cr.openjdk.java.net/~amlu/8161024/webrev.00/ Thanks, Amy --- old/test/java/lang/Runtime/exec/LotsOfOutput.java 2016-08-03 15:47:45.000000000 +0800 +++ new/test/java/lang/Runtime/exec/LotsOfOutput.java 2016-08-03 15:47:45.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2016, 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 @@ -25,7 +25,6 @@ * @test * @bug 4369826 8078582 * @summary Process with lots of output should not crash VM - * @key intermittent * @author kladko */ From frank.yuan at oracle.com Wed Aug 3 10:12:55 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 3 Aug 2016 18:12:55 +0800 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <57A116F7.3040605@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> Message-ID: <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> Hi Joe Thank you for your review! I updated the tests according to the latest comments as well as had unittest/transform/TransformerTest.java up to date, please check http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ Thanks Frank -----Original Message----- From: Joe Wang [mailto:huizhe.wang at oracle.com] Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests On 8/2/16, 5:30 AM, Daniel Fuchs wrote: > Hi Frank, > > I am intrigued by these change which do not seem > to have anything to do with the rest. I mean, I'm not opposed > as long as they are intended and that Joe validates them: > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram es.html > > > 118 spf.setNamespaceAware(false); Not sure why this was changed. > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra mes.html > The test itself wasn't very clear on the content it tests. If it only verifies whether a resolver is used as is said, then this and related changes in ResolverTest and publish.xml are fine. To the extent it verifies, it didn't have to output to a file. > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h tml > We have to let Frank explain why namespace was turned off for these tests :-) In this case, XMLReaderNSTableTest. In general, I would say enabling security shouldn't change tests or gold files in this case. > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html > > This looks like a desirable change - but what does it have to do > with enabling security manager? Probably to remove the reference to that particular server? Seems to be fine as a cleanup. Again, it (the original test) only verifies a resolve is used, it didn't even need to write out a file to prove that. > > Also: > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html > > > 70 > tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", > true); > > Is this needed only when there is a security manager? Yes, when Security Manager is present, this feature is turned off by default. > > ======================================================== > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html > > > > 119 /* > 120 addPermission(new RuntimePermission("getClassLoader")); > 121 addPermission(new RuntimePermission("createClassLoader")); > 122 addPermission(new > RuntimePermission("createSecurityManager")); > 123 addPermission(new RuntimePermission("modifyThread")); > 124 addPermission(new PropertyPermission("*", "read,write")); > 125 > 126 addPermission(new RuntimePermission("setIO")); > 127 addPermission(new > RuntimePermission("setContextClassLoader")); > 128 addPermission(new > RuntimePermission("accessDeclaredMembers"));*/ > > > Please remove before pushing. > > > ======================================================== > > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl > > It seems these two files have been removed, but shouldn't they have > been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform > instead? > I see they are used by > test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java > > Did you forget to hg add them? > > ======================================================== > > > Otherwise the new JAXPPolicyManager & its Policy implementation > look good. This is much simpler and better than the first > iteration :-) > > This was a *very* long patch - so congratulations for seeing > this through! Very long patch, indeed! Thanks for the great effort! Very well done with the unified Policy/Permission management. Best, Joe > > cheers, > > -- daniel > > > On 02/08/16 11:20, Frank Yuan wrote: >> Hi Joe and Daniel >> >> I have finished the rework as your comments, please check >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ >> >> JAXP tests use Policy classes, as well as 3 other patterns provided >> by JAXPTestUtilities: >> 1. runWithAllPerm methods, are only used for user setup code, never >> run jaxp code with them. >> 2. tryRunWithPolicyManager method, is used to run some test methods >> with security manager and run the others without security >> manager in single test class >> 3. runWithTmpPermission methods, which may run jaxp code with some >> limited permissions, those permissions belong to user permissions >> and jaxp code won't doPrivileged for them. E.g. >> PropertyPermission("MyInputFactory", "read") or >> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") >> >> >> Btw, some tests or test methods are disabled or commented sm support >> temporarily for some known jaxp security bugs. >> >> Thanks >> Frank >> > From daniel.fuchs at oracle.com Wed Aug 3 10:45:11 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 3 Aug 2016 11:45:11 +0100 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> Message-ID: <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> Hi Frank, I looked at the diffs of the diffs between webrev.02 and webrev.03 and it looks good to me. +1 - provided all tests pass :-) But I have the same question than Joe: aren't all the test supposed to run twice: once with security manager and once without? (except for those test that might explicitly require a security manager) best regards, -- daniel On 03/08/16 11:12, Frank Yuan wrote: > Hi Joe > > Thank you for your review! > > I updated the tests according to the latest comments as well as had unittest/transform/TransformerTest.java up to date, please check > http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ > > > Thanks > Frank > > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests > > > > On 8/2/16, 5:30 AM, Daniel Fuchs wrote: >> Hi Frank, >> >> I am intrigued by these change which do not seem >> to have anything to do with the rest. I mean, I'm not opposed >> as long as they are intended and that Joe validates them: >> ======================================================== >> >> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram > es.html >> >> >> 118 spf.setNamespaceAware(false); > > Not sure why this was changed. >> >> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra > mes.html >> > > The test itself wasn't very clear on the content it tests. If it only > verifies whether a resolver is used as is said, then this and related > changes in ResolverTest and publish.xml are fine. To the extent it > verifies, it didn't have to output to a file. >> >> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h > tml >> > > We have to let Frank explain why namespace was turned off for these > tests :-) In this case, XMLReaderNSTableTest. In general, I would say > enabling security shouldn't change tests or gold files in this case. > >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html >> >> This looks like a desirable change - but what does it have to do >> with enabling security manager? > > Probably to remove the reference to that particular server? Seems to be > fine as a cleanup. Again, it (the original test) only verifies a resolve > is used, it didn't even need to write out a file to prove that. >> >> Also: >> ======================================================== >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html >> >> >> 70 >> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", >> true); >> >> Is this needed only when there is a security manager? > > Yes, when Security Manager is present, this feature is turned off by > default. >> >> ======================================================== >> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html >> >> >> >> 119 /* >> 120 addPermission(new RuntimePermission("getClassLoader")); >> 121 addPermission(new RuntimePermission("createClassLoader")); >> 122 addPermission(new >> RuntimePermission("createSecurityManager")); >> 123 addPermission(new RuntimePermission("modifyThread")); >> 124 addPermission(new PropertyPermission("*", "read,write")); >> 125 >> 126 addPermission(new RuntimePermission("setIO")); >> 127 addPermission(new >> RuntimePermission("setContextClassLoader")); >> 128 addPermission(new >> RuntimePermission("accessDeclaredMembers"));*/ >> >> >> Please remove before pushing. >> >> >> ======================================================== >> >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl >> >> It seems these two files have been removed, but shouldn't they have >> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform >> instead? >> I see they are used by >> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java >> >> Did you forget to hg add them? >> >> ======================================================== >> >> >> Otherwise the new JAXPPolicyManager & its Policy implementation >> look good. This is much simpler and better than the first >> iteration :-) >> >> This was a *very* long patch - so congratulations for seeing >> this through! > > Very long patch, indeed! Thanks for the great effort! Very well done > with the unified Policy/Permission management. > > Best, > Joe > >> >> cheers, >> >> -- daniel >> >> >> On 02/08/16 11:20, Frank Yuan wrote: >>> Hi Joe and Daniel >>> >>> I have finished the rework as your comments, please check >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ >>> >>> JAXP tests use Policy classes, as well as 3 other patterns provided >>> by JAXPTestUtilities: >>> 1. runWithAllPerm methods, are only used for user setup code, never >>> run jaxp code with them. >>> 2. tryRunWithPolicyManager method, is used to run some test methods >>> with security manager and run the others without security >>> manager in single test class >>> 3. runWithTmpPermission methods, which may run jaxp code with some >>> limited permissions, those permissions belong to user permissions >>> and jaxp code won't doPrivileged for them. E.g. >>> PropertyPermission("MyInputFactory", "read") or >>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") >>> >>> >>> Btw, some tests or test methods are disabled or commented sm support >>> temporarily for some known jaxp security bugs. >>> >>> Thanks >>> Frank >>> >> > From aleksej.efimov at oracle.com Wed Aug 3 10:56:18 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 3 Aug 2016 13:56:18 +0300 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: <565EF499.6040709@oracle.com> Message-ID: <854411e1-660d-3d28-e948-a6df074edf93@oracle.com> Hi Yuji, I've created JDK8 backport [1] for this issue and will work on it in the upcoming months. Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8162941 On 02/08/16 08:33, KUBOTA Yuji wrote: > Hi all, > > Could you let me know when this fix will be backport to JDK 8? > We need this backport to migrate our system from JDK 7 to JDK 8. > > Thanks, > Yuji > > 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >> Hi Miroslav, >> >> Thank you for your sponsor! : https://bugs.openjdk.java.net/browse/JDK-8146086 >> >> Can I ask the schedule when does this fix backport to JDK8 ? >> >> Thanks, >> Yuji >> >> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>> Hi Yuji, >>> thanks for the patch - it fixes the issue and looks ok to me. I'll integrate >>> it to standalone JAX-WS repo and it will be integrated into openjdk during >>> next syncup. >>> >>> Thanks >>> Miran >>> >>> >>> >>> >>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>> Hi Miroslav and all, >>>> >>>> Could you please review the below issue and patch? >>>> >>>> I got the advice by Alan at net-dev. So I want to ask you. >>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>> >>>> ---- >>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>> community. This's second times from JavaOne14. :) >>>> >>>> We find an unexpected exception in JAX-WS, so I write a patch to fix it. >>>> We think that this issue may block the migration to JDK9 from JDK7. >>>> >>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>> following test code, JDK9 (and JDK8) returns "java.net.BindException: >>>> Address already in use.? as the below. But JDK7 does NOT return the >>>> exception. >>>> >>>> - Test code for reproduce >>>> --- >>>> import javax.jws.*; >>>> import javax.xml.ws.*; >>>> >>>> public class WSTest{ >>>> >>>> @WebService >>>> public static class Method1{ >>>> @WebMethod >>>> public String getMethod1Value(){ >>>> return "from Method1"; >>>> } >>>> } >>>> >>>> @WebService >>>> public static class Method2{ >>>> @WebMethod >>>> public String getMethod2Value(){ >>>> return "from Method2"; >>>> } >>>> } >>>> >>>> public static void main(String[] args) throws Exception{ >>>> Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1", >>>> new >>>> Method1()); >>>> Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2", >>>> new >>>> Method2()); >>>> >>>> System.out.println("Sleep 3 secs..."); >>>> >>>> Thread.sleep(3000); >>>> >>>> endPoint2.stop(); >>>> endPoint1.stop(); >>>> } >>>> >>>> } >>>> --- >>>> >>>> - StackTrace >>>> --- >>>> Exception in thread "main" >>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>> Error: java.net.BindException: Address already in use >>>> at >>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>> at >>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>> at >>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>> at >>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>> at wstest.WSTest.main(WSTest.java:27) >>>> Caused by: java.net.BindException: Address already in use >>>> at sun.nio.ch.Net.bind0(Native Method) >>>> at sun.nio.ch.Net.bind(Net.java:432) >>>> at sun.nio.ch.Net.bind(Net.java:424) >>>> at >>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>> at >>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>> at >>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>> at >>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>> at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>> at >>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>> ... 5 more >>>> ----- >>>> >>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>> been created by given address, then creates a HttpContext if do not >>>> exist. >>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>> returns BindException when 0.0.0.0 has been blinded already. >>>> >>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>> >>>> So I write a patch which is based jdk9/dev/jaxws >>>> (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. >>>> >>>> Please review this patch :) >>>> >>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>> >>>> - Patch >>>> --- >>>> diff -r 2d84c6f4cbba >>>> >>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>> --- >>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>> Thu Oct 22 08:47:47 2015 -0700 >>>> +++ >>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>> Tue Oct 27 19:48:35 2015 +0900 >>>> @@ -38,6 +38,7 @@ >>>> import java.util.concurrent.ExecutorService; >>>> import java.util.concurrent.Executors; >>>> import java.util.logging.Logger; >>>> +import java.util.Optional; >>>> >>>> /** >>>> * Manages all the WebService HTTP servers created by JAXWS runtime. >>>> @@ -81,24 +82,38 @@ >>>> synchronized(servers) { >>>> state = servers.get(inetAddress); >>>> if (state == null) { >>>> - logger.fine("Creating new HTTP Server at >>>> "+inetAddress); >>>> - // Creates server with default socket backlog >>>> - server = HttpServer.create(inetAddress, 0); >>>> - server.setExecutor(Executors.newCachedThreadPool()); >>>> - String path = url.toURI().getPath(); >>>> - logger.fine("Creating HTTP Context at = "+path); >>>> - HttpContext context = server.createContext(path); >>>> - server.start(); >>>> + final int finalPortNum = port; >>>> + Optional stateOpt = >>>> + servers.values() >>>> + .stream() >>>> + .filter(s -> s.getServer() >>>> + .getAddress() >>>> + .getPort() == >>>> finalPortNum) >>>> + .findAny(); >>>> >>>> - // we have to get actual inetAddress from server, >>>> which can differ from the original in some cases. >>>> - // e.g. A port number of zero will let the system >>>> pick up an ephemeral port in a bind operation, >>>> - // or IP: 0.0.0.0 - which is used to monitor >>>> network traffic from any valid IP address >>>> - inetAddress = server.getAddress(); >>>> + if (inetAddress.getAddress().isAnyLocalAddress() && >>>> + stateOpt.isPresent()) { >>>> + state = stateOpt.get(); >>>> + } else { >>>> + logger.fine("Creating new HTTP Server at >>>> "+inetAddress); >>>> + // Creates server with default socket backlog >>>> + server = HttpServer.create(inetAddress, 0); >>>> + >>>> server.setExecutor(Executors.newCachedThreadPool()); >>>> + String path = url.toURI().getPath(); >>>> + logger.fine("Creating HTTP Context at = "+path); >>>> + HttpContext context = server.createContext(path); >>>> + server.start(); >>>> >>>> - logger.fine("HTTP server started = "+inetAddress); >>>> - state = new ServerState(server, path); >>>> - servers.put(inetAddress, state); >>>> - return context; >>>> + // we have to get actual inetAddress from >>>> server, which can differ from the original in some cases. >>>> + // e.g. A port number of zero will let the >>>> system pick up an ephemeral port in a bind operation, >>>> + // or IP: 0.0.0.0 - which is used to monitor >>>> network traffic from any valid IP address >>>> + inetAddress = server.getAddress(); >>>> + >>>> + logger.fine("HTTP server started = >>>> "+inetAddress); >>>> + state = new ServerState(server, path); >>>> + servers.put(inetAddress, state); >>>> + return context; >>>> + } >>>> } >>>> } >>>> server = state.getServer(); >>>> --- >>>> >>>> Thanks, >>>> Yuji >>> From sean.coffey at oracle.com Wed Aug 3 11:32:01 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Aug 2016 12:32:01 +0100 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: References: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> Message-ID: <57A1D631.10500@oracle.com> On 02/08/16 20:47, Volker Simonis wrote: > Hi Sean, > > thanks a lot for your reply. > > You're right - I'm still waiting for a review of the hotspot part. Any > volunteers :) OK - would be good to get a hotspot reviewer to look at those first. > > Regarding the noreg label: I used 'noreg-other' because there already > exist AES tests (they have never been part of this original change). > Is that the right label? There are simply too many different noreg > labels without documentation so if I selected the wrong one, please > advice which one to choose. noreg labels are documented at : http://openjdk.java.net/guide/changePlanning.html#noreg noreg-other seems fine. You might want to add a short comment to bug outlining your comment on existing AES tests. regards, Sean. > > Thanks, > Volker > > > On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey wrote: >> Volker, >> >> Have the jdk8u hotspot edits been reviewed ? Looks like they should be. >> >> Can you add a suitable noreg label to the master bug report also. >> >> Regards, >> Sean. >> >> >> On 29/07/2016 19:58, Volker Simonis wrote: >>> Ping! >>> >>> Can I please have an approval for backporting this change to 8u-dev? >>> >>> Thanks, >>> Volker >>> >>> >>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> could you please approve the backport of the following, mostly ppc64 >>>> change to jdk8u-dev: >>>> >>>> 8152172: PPC64: Support AES intrinsics >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ >>>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ >>>> Review: >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 >>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b >>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f >>>> >>>> As you can see, the change consists of two parts - the main one in the >>>> hotpsot repo and a small part in the jdk repo. >>>> >>>> The jdk part applied cleanly to jdk8u (with the usual directory >>>> shuffling). >>>> >>>> The hotspot part required a small tweak, but only in the ppc-only >>>> part. This is because the feature detection for the AES instructions >>>> was already active in jdk9 when the original change was made but is >>>> not available in jdk8u until now. You can find the additional changes >>>> at the end of this mail for your convenience. >>>> >>>> The required shared changes cleanly apply to jdk8u. >>>> >>>> As Vladimir pointed out in a previous thread, shared Hotspot changes >>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do >>>> that and synchronously push both parts. >>>> >>>> @Hiroshii: could you please verify that you are fine with the change? >>>> I've done some tests on Power8LE but just want to be sure this >>>> downport satisfies your needs as well. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> ===================== >>>> >>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp >>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 >>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 >>>> @@ -452,6 +476,7 @@ >>>> a->popcntw(R7, R5); // code[7] -> popcntw >>>> a->fcfids(F3, F4); // code[8] -> fcfids >>>> a->vand(VR0, VR0, VR0); // code[9] -> vand >>>> + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher >>>> a->blr(); >>>> >>>> // Emit function to set one cache line to zero. Emit function >>>> descriptor and get pointer to it. >>>> @@ -495,6 +520,7 @@ >>>> if (code[feature_cntr++]) features |= popcntw_m; >>>> if (code[feature_cntr++]) features |= fcfids_m; >>>> if (code[feature_cntr++]) features |= vand_m; >>>> + if (code[feature_cntr++]) features |= vcipher_m; >>>> >>>> // Print the detection code. >>>> if (PrintAssembly) { >>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp >>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 >>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 >>>> @@ -42,6 +42,7 @@ >>>> fcfids, >>>> vand, >>>> dcba, >>>> + vcipher, >>>> num_features // last entry to count features >>>> }; >>>> enum Feature_Flag_Set { >>>> @@ -56,6 +57,7 @@ >>>> fcfids_m = (1 << fcfids ), >>>> vand_m = (1 << vand ), >>>> dcba_m = (1 << dcba ), >>>> + vcipher_m = (1 << vcipher), >>>> all_features_m = -1 >>>> }; >>>> static int _features; >>>> @@ -83,6 +85,7 @@ >>>> static bool has_fcfids() { return (_features & fcfids_m) != 0; } >>>> static bool has_vand() { return (_features & vand_m) != 0; } >>>> static bool has_dcba() { return (_features & dcba_m) != 0; } >>>> + static bool has_vcipher() { return (_features & vcipher_m) != 0; } >>>> >>>> static const char* cpu_features() { return _features_str; } >> From dmitrij.pochepko at oracle.com Wed Aug 3 13:25:18 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 3 Aug 2016 16:25:18 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <579BA386.20608@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> Message-ID: <57A1F0BE.7040505@oracle.com> Hi, can somebody with official reviewer role review this? Thanks, Dmitrij On 29.07.2016 21:42, Dmitrij Pochepko wrote: > Sure, > > now including core-libs-dev > > Thanks, > Dmitrij > > On 29.07.2016 20:16, joe darcy wrote: >> Hello, >> >> I also recommend sending this review request over to core-libs-dev >> since it affect the jdk repo. >> >> Thanks, >> >> -Joe >> >> >> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>> Hi Dmitrij, >>> >>> The change itself looks good. >>> >>> One note: this change adds a little overhead (a very little) for >>> running tests in jdk repository, but it's required only for VM >>> specific tests stored in jdk. As alternative of this change I can >>> suggest moving VM specific tests from the 'jdk' to 'hotspot' >>> repository. Perhaps, such massive update is too late for JDK9 time >>> frame and could be done only in JDK10. >>> So, if the changes depending on 8162727 are not so critical and >>> could be deferred I would prefer to postpone this fix. >>> >>> Thanks, >>> Dima >>> >>> >>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>> It affects all groups. Should be reviewed on hotspot-dev. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> please review small patch for 8162727 - Testbug: additional >>>>> requires properties can't be used for filtering server vm in jdk >>>>> jtreg tests >>>>> >>>>> A problem is that tests under jdk repo can't use additional jtreg >>>>> requires properties(like vm.flavor to filter out client or server >>>>> vm). The same functionality was introduced for hotspot repo as part >>>>> of JDK-8154956. So, in order to filter tests using these >>>>> additional properties a small fix is created. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>> >>>>> Thanks, >>>>> Dmitrij >>> >> > From joe.darcy at oracle.com Wed Aug 3 14:44:37 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 3 Aug 2016 07:44:37 -0700 Subject: JDK 9 RFR of JDK-8161024: Remove intermittent key from java/lang/Runtime/exec/LotsOfOutput.java In-Reply-To: <57A1A201.6020406@oracle.com> References: <57A1A201.6020406@oracle.com> Message-ID: <55add89d-7978-fd82-c29c-3627dfa3d798@oracle.com> Hi Amy, The changes looks good; we'll keep an eye on the test to make sure it doesn't start misbehaving again :-) Thanks, -Joe On 8/3/2016 12:49 AM, Amy Lu wrote: > java/lang/Runtime/exec/LotsOfOutput.java > > This test was failing intermittently (JDK-8078582 JDK-8086117). > Mentioned issues have been resolved and no open bug (no failure > reported) till now. > > This patch is to remove @key intermittent from the test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8161024 > webrev: http://cr.openjdk.java.net/~amlu/8161024/webrev.00/ > > > Thanks, > Amy > > --- old/test/java/lang/Runtime/exec/LotsOfOutput.java 2016-08-03 > 15:47:45.000000000 +0800 > +++ new/test/java/lang/Runtime/exec/LotsOfOutput.java 2016-08-03 > 15:47:45.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2002, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2002, 2016, 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 > @@ -25,7 +25,6 @@ > * @test > * @bug 4369826 8078582 > * @summary Process with lots of output should not crash VM > - * @key intermittent > * @author kladko > */ > > > From kim.barrett at oracle.com Wed Aug 3 18:21:17 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Aug 2016 14:21:17 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> Message-ID: <687D0D66-6E84-49FA-9384-D4CB111755AF@oracle.com> > On Aug 3, 2016, at 3:41 AM, David Holmes wrote: > > On 2/08/2016 4:46 AM, Kim Barrett wrote: >> This updated webrev addresses the concerns around initialization order >> for Throwable and OutOfMemoryError. It doesn't address the VM API >> used by the reference processor thread; that will be in a later >> webrev. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ >> >> The jdk tree is unchanged from webrev.01. >> >> I've backed out the change to initialize_java_lang_classes. (To >> verify this, look at the runtime/thread.cpp in the full webrev.) >> >> Instead, Universe::gen_out_of_memory_error now also requires Throwable >> to be initialized before it will attempt to fill in the stack trace. >> This means that VM generated OOMEs occurring early in initialization >> won't have a stack trace. > > This change looks good to me. Thanks! From boris.x.shukhat at barclays.com Wed Aug 3 17:55:55 2016 From: boris.x.shukhat at barclays.com (boris.x.shukhat at barclays.com) Date: Wed, 3 Aug 2016 13:55:55 -0400 Subject: HttpURLConnection.getResponseCode() documentation comment Message-ID: <1476E35DC8A56B43A1B3419373C38BCD0D92F10B98@NYKPCMMGMB03.INTRANET.BARCAPINT.COM> To whom it may concern, This comment is about API documentation on HttpURLConnection.getResponseCode() and it is based on the implementation details as well. HttpURLConnection implementation caches response code that allows to repeatedly get a response code from HttpURLConnection even after disconnect() is called. If a response code had been cached before disconnect() was called then its value is returned. But if the return code has not been cached, it (under some circumstances) opens a connection and leaves it opened if disconnect() is not called again. If called in the loop multiple times this design potentially can cause connection leakage and it happens in open source library https://github.com/elastic/elasticsearch-metrics-reporter-java/blob/master/src/main/java/org/elasticsearch/metrics/ElasticsearchReporter.java lines 397-406 I do not think that it is reasonable to change the implementation at this point because it can break existing software but it has to be reflected in API help on HttpURLConnection.getResponseCode() that it can leave connection open and another disconnect() may need to be called. The problem can be reproduced by running the following code long enough and using ss Linux command (netstat command on Windows) to periodically monitor sockets with established connection. public class Test { public static void main(String...args) throws Exception { while(true) { URL url=new URL("..."); HttpURLConnection connection=(HttpURLConnection)url.openConnection(); connection.connect(); connection.disconnect(); int responseCode=connection.getResponseCode(); Thread.sleep(10); } } } Thanks, Boris Shukhat _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________ From david.holmes at oracle.com Wed Aug 3 20:56:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 06:56:29 +1000 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <57A1F0BE.7040505@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: Hi Dmitrij, I know this reflects the changes made in hotspot/test but I have a query. Does this: + requires.extraPropDefns.vmOpts = -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:bootClasses mean that the VM under test is executed with those additional flags when running the tests? Or is it run once with those flags to establish the "requires" properties? If the latter then I have no concern and this change seems fine. Thanks, David On 3/08/2016 11:25 PM, Dmitrij Pochepko wrote: > Hi, > > can somebody with official reviewer role review this? > > Thanks, > Dmitrij > > On 29.07.2016 21:42, Dmitrij Pochepko wrote: >> Sure, >> >> now including core-libs-dev >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 20:16, joe darcy wrote: >>> Hello, >>> >>> I also recommend sending this review request over to core-libs-dev >>> since it affect the jdk repo. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>> Hi Dmitrij, >>>> >>>> The change itself looks good. >>>> >>>> One note: this change adds a little overhead (a very little) for >>>> running tests in jdk repository, but it's required only for VM >>>> specific tests stored in jdk. As alternative of this change I can >>>> suggest moving VM specific tests from the 'jdk' to 'hotspot' >>>> repository. Perhaps, such massive update is too late for JDK9 time >>>> frame and could be done only in JDK10. >>>> So, if the changes depending on 8162727 are not so critical and >>>> could be deferred I would prefer to postpone this fix. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> please review small patch for 8162727 - Testbug: additional >>>>>> requires properties can't be used for filtering server vm in jdk >>>>>> jtreg tests >>>>>> >>>>>> A problem is that tests under jdk repo can't use additional jtreg >>>>>> requires properties(like vm.flavor to filter out client or server >>>>>> vm). The same functionality was introduced for hotspot repo as part >>>>>> of JDK-8154956. So, in order to filter tests using these >>>>>> additional properties a small fix is created. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>> >>> >> > From kubota.yuji at gmail.com Thu Aug 4 00:35:47 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Thu, 4 Aug 2016 09:35:47 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: <854411e1-660d-3d28-e948-a6df074edf93@oracle.com> References: <565EF499.6040709@oracle.com> <854411e1-660d-3d28-e948-a6df074edf93@oracle.com> Message-ID: Hi Aleksej, Thank you very much! If you need some help about the patch, please mention me :) Thanks, Yuji 2016-08-03 19:56 GMT+09:00 Aleks Efimov : > Hi Yuji, > > I've created JDK8 backport [1] for this issue and will work on it in the > upcoming months. > > Best Regards, > > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8162941 > > > > On 02/08/16 08:33, KUBOTA Yuji wrote: >> >> Hi all, >> >> Could you let me know when this fix will be backport to JDK 8? >> We need this backport to migrate our system from JDK 7 to JDK 8. >> >> Thanks, >> Yuji >> >> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >>> >>> Hi Miroslav, >>> >>> Thank you for your sponsor! : >>> https://bugs.openjdk.java.net/browse/JDK-8146086 >>> >>> Can I ask the schedule when does this fix backport to JDK8 ? >>> >>> Thanks, >>> Yuji >>> >>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>>> >>>> Hi Yuji, >>>> thanks for the patch - it fixes the issue and looks ok to me. I'll >>>> integrate >>>> it to standalone JAX-WS repo and it will be integrated into openjdk >>>> during >>>> next syncup. >>>> >>>> Thanks >>>> Miran >>>> >>>> >>>> >>>> >>>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>>> >>>>> Hi Miroslav and all, >>>>> >>>>> Could you please review the below issue and patch? >>>>> >>>>> I got the advice by Alan at net-dev. So I want to ask you. >>>>> >>>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>>> >>>>> ---- >>>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>>> community. This's second times from JavaOne14. :) >>>>> >>>>> We find an unexpected exception in JAX-WS, so I write a patch to fix >>>>> it. >>>>> We think that this issue may block the migration to JDK9 from JDK7. >>>>> >>>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>>> following test code, JDK9 (and JDK8) returns "java.net.BindException: >>>>> Address already in use.? as the below. But JDK7 does NOT return the >>>>> exception. >>>>> >>>>> - Test code for reproduce >>>>> --- >>>>> import javax.jws.*; >>>>> import javax.xml.ws.*; >>>>> >>>>> public class WSTest{ >>>>> >>>>> @WebService >>>>> public static class Method1{ >>>>> @WebMethod >>>>> public String getMethod1Value(){ >>>>> return "from Method1"; >>>>> } >>>>> } >>>>> >>>>> @WebService >>>>> public static class Method2{ >>>>> @WebMethod >>>>> public String getMethod2Value(){ >>>>> return "from Method2"; >>>>> } >>>>> } >>>>> >>>>> public static void main(String[] args) throws Exception{ >>>>> Endpoint endPoint1 = >>>>> Endpoint.publish("http://0.0.0.0:8081/method1", >>>>> new >>>>> Method1()); >>>>> Endpoint endPoint2 = >>>>> Endpoint.publish("http://0.0.0.0:8081/method2", >>>>> new >>>>> Method2()); >>>>> >>>>> System.out.println("Sleep 3 secs..."); >>>>> >>>>> Thread.sleep(3000); >>>>> >>>>> endPoint2.stop(); >>>>> endPoint1.stop(); >>>>> } >>>>> >>>>> } >>>>> --- >>>>> >>>>> - StackTrace >>>>> --- >>>>> Exception in thread "main" >>>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>>> Error: java.net.BindException: Address already in use >>>>> at >>>>> >>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>>> at >>>>> >>>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>>> at >>>>> >>>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>>> at >>>>> >>>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>>> at wstest.WSTest.main(WSTest.java:27) >>>>> Caused by: java.net.BindException: Address already in use >>>>> at sun.nio.ch.Net.bind0(Native Method) >>>>> at sun.nio.ch.Net.bind(Net.java:432) >>>>> at sun.nio.ch.Net.bind(Net.java:424) >>>>> at >>>>> >>>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>>> at >>>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>>> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>>> at >>>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>>> at >>>>> >>>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>>> at >>>>> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>>> at >>>>> >>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>>> ... 5 more >>>>> ----- >>>>> >>>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>>> been created by given address, then creates a HttpContext if do not >>>>> exist. >>>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>>> returns BindException when 0.0.0.0 has been blinded already. >>>>> >>>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>>> >>>>> So I write a patch which is based jdk9/dev/jaxws >>>>> (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. >>>>> >>>>> Please review this patch :) >>>>> >>>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>>> >>>>> - Patch >>>>> --- >>>>> diff -r 2d84c6f4cbba >>>>> >>>>> >>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>> --- >>>>> >>>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>> Thu Oct 22 08:47:47 2015 -0700 >>>>> +++ >>>>> >>>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>> Tue Oct 27 19:48:35 2015 +0900 >>>>> @@ -38,6 +38,7 @@ >>>>> import java.util.concurrent.ExecutorService; >>>>> import java.util.concurrent.Executors; >>>>> import java.util.logging.Logger; >>>>> +import java.util.Optional; >>>>> >>>>> /** >>>>> * Manages all the WebService HTTP servers created by JAXWS runtime. >>>>> @@ -81,24 +82,38 @@ >>>>> synchronized(servers) { >>>>> state = servers.get(inetAddress); >>>>> if (state == null) { >>>>> - logger.fine("Creating new HTTP Server at >>>>> "+inetAddress); >>>>> - // Creates server with default socket backlog >>>>> - server = HttpServer.create(inetAddress, 0); >>>>> - >>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>> - String path = url.toURI().getPath(); >>>>> - logger.fine("Creating HTTP Context at = "+path); >>>>> - HttpContext context = server.createContext(path); >>>>> - server.start(); >>>>> + final int finalPortNum = port; >>>>> + Optional stateOpt = >>>>> + servers.values() >>>>> + .stream() >>>>> + .filter(s -> s.getServer() >>>>> + .getAddress() >>>>> + .getPort() == >>>>> finalPortNum) >>>>> + .findAny(); >>>>> >>>>> - // we have to get actual inetAddress from server, >>>>> which can differ from the original in some cases. >>>>> - // e.g. A port number of zero will let the system >>>>> pick up an ephemeral port in a bind operation, >>>>> - // or IP: 0.0.0.0 - which is used to monitor >>>>> network traffic from any valid IP address >>>>> - inetAddress = server.getAddress(); >>>>> + if (inetAddress.getAddress().isAnyLocalAddress() >>>>> && >>>>> + stateOpt.isPresent()) { >>>>> + state = stateOpt.get(); >>>>> + } else { >>>>> + logger.fine("Creating new HTTP Server at >>>>> "+inetAddress); >>>>> + // Creates server with default socket backlog >>>>> + server = HttpServer.create(inetAddress, 0); >>>>> + >>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>> + String path = url.toURI().getPath(); >>>>> + logger.fine("Creating HTTP Context at = >>>>> "+path); >>>>> + HttpContext context = >>>>> server.createContext(path); >>>>> + server.start(); >>>>> >>>>> - logger.fine("HTTP server started = "+inetAddress); >>>>> - state = new ServerState(server, path); >>>>> - servers.put(inetAddress, state); >>>>> - return context; >>>>> + // we have to get actual inetAddress from >>>>> server, which can differ from the original in some cases. >>>>> + // e.g. A port number of zero will let the >>>>> system pick up an ephemeral port in a bind operation, >>>>> + // or IP: 0.0.0.0 - which is used to monitor >>>>> network traffic from any valid IP address >>>>> + inetAddress = server.getAddress(); >>>>> + >>>>> + logger.fine("HTTP server started = >>>>> "+inetAddress); >>>>> + state = new ServerState(server, path); >>>>> + servers.put(inetAddress, state); >>>>> + return context; >>>>> + } >>>>> } >>>>> } >>>>> server = state.getServer(); >>>>> --- >>>>> >>>>> Thanks, >>>>> Yuji >>>> >>>> > From huizhe.wang at oracle.com Thu Aug 4 00:52:35 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 03 Aug 2016 17:52:35 -0700 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> Message-ID: <57A291D3.5060301@oracle.com> On 8/3/16, 3:45 AM, Daniel Fuchs wrote: > Hi Frank, > > I looked at the diffs of the diffs between webrev.02 and webrev.03 and > it looks good to me. > > +1 - provided all tests pass :-) +1, thanks for re-enabling the tests that had dependencies on 8162848. I also closed 8162848. > > But I have the same question than Joe: aren't all the test supposed > to run twice: once with security manager and once without? > (except for those test that might explicitly require a security manager) I agree, all of the tests need to run with and without security manager. It would be good to combine the runWithSecurityManager and runWithoutSecurityManager methods into one with a condition that determines whether a security manager is present. Best, Joe > > best regards, > > -- daniel > > On 03/08/16 11:12, Frank Yuan wrote: >> Hi Joe >> >> Thank you for your review! >> >> I updated the tests according to the latest comments as well as had >> unittest/transform/TransformerTest.java up to date, please check >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ >> >> >> Thanks >> Frank >> >> -----Original Message----- >> From: Joe Wang [mailto:huizhe.wang at oracle.com] >> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP >> unit tests >> >> >> >> On 8/2/16, 5:30 AM, Daniel Fuchs wrote: >>> Hi Frank, >>> >>> I am intrigued by these change which do not seem >>> to have anything to do with the rest. I mean, I'm not opposed >>> as long as they are intended and that Joe validates them: >>> ======================================================== >>> >>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram >> >> es.html >>> >>> >>> 118 spf.setNamespaceAware(false); >> >> Not sure why this was changed. >>> >>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra >> >> mes.html >>> >> >> The test itself wasn't very clear on the content it tests. If it only >> verifies whether a resolver is used as is said, then this and related >> changes in ResolverTest and publish.xml are fine. To the extent it >> verifies, it didn't have to output to a file. >>> >>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h >> >> tml >>> >> >> We have to let Frank explain why namespace was turned off for these >> tests :-) In this case, XMLReaderNSTableTest. In general, I would say >> enabling security shouldn't change tests or gold files in this case. >> >>> >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html >>> >>> >>> This looks like a desirable change - but what does it have to do >>> with enabling security manager? >> >> Probably to remove the reference to that particular server? Seems to be >> fine as a cleanup. Again, it (the original test) only verifies a resolve >> is used, it didn't even need to write out a file to prove that. >>> >>> Also: >>> ======================================================== >>> >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html >>> >>> >>> >>> 70 >>> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", >>> >>> true); >>> >>> Is this needed only when there is a security manager? >> >> Yes, when Security Manager is present, this feature is turned off by >> default. >>> >>> ======================================================== >>> >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html >>> >>> >>> >>> >>> 119 /* >>> 120 addPermission(new RuntimePermission("getClassLoader")); >>> 121 addPermission(new RuntimePermission("createClassLoader")); >>> 122 addPermission(new >>> RuntimePermission("createSecurityManager")); >>> 123 addPermission(new RuntimePermission("modifyThread")); >>> 124 addPermission(new PropertyPermission("*", "read,write")); >>> 125 >>> 126 addPermission(new RuntimePermission("setIO")); >>> 127 addPermission(new >>> RuntimePermission("setContextClassLoader")); >>> 128 addPermission(new >>> RuntimePermission("accessDeclaredMembers"));*/ >>> >>> >>> Please remove before pushing. >>> >>> >>> ======================================================== >>> >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml >>> >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl >>> >>> It seems these two files have been removed, but shouldn't they have >>> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform >>> instead? >>> I see they are used by >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java >>> >>> Did you forget to hg add them? >>> >>> ======================================================== >>> >>> >>> Otherwise the new JAXPPolicyManager & its Policy implementation >>> look good. This is much simpler and better than the first >>> iteration :-) >>> >>> This was a *very* long patch - so congratulations for seeing >>> this through! >> >> Very long patch, indeed! Thanks for the great effort! Very well done >> with the unified Policy/Permission management. >> >> Best, >> Joe >> >>> >>> cheers, >>> >>> -- daniel >>> >>> >>> On 02/08/16 11:20, Frank Yuan wrote: >>>> Hi Joe and Daniel >>>> >>>> I have finished the rework as your comments, please check >>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ >>>> >>>> JAXP tests use Policy classes, as well as 3 other patterns provided >>>> by JAXPTestUtilities: >>>> 1. runWithAllPerm methods, are only used for user setup code, never >>>> run jaxp code with them. >>>> 2. tryRunWithPolicyManager method, is used to run some test methods >>>> with security manager and run the others without security >>>> manager in single test class >>>> 3. runWithTmpPermission methods, which may run jaxp code with some >>>> limited permissions, those permissions belong to user permissions >>>> and jaxp code won't doPrivileged for them. E.g. >>>> PropertyPermission("MyInputFactory", "read") or >>>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") >>>> >>>> >>>> Btw, some tests or test methods are disabled or commented sm support >>>> temporarily for some known jaxp security bugs. >>>> >>>> Thanks >>>> Frank >>>> >>> >> > From chris.plummer at oracle.com Thu Aug 4 04:35:09 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 3 Aug 2016 21:35:09 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: Unfortunately I need another review of these changes. I ran into a minor problem. Although all the jprt testing I tried passed, when I looked into the log files I noticed an issue. I saw the following: Test results: passed: 1 Report written to /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html Results written to /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork /bin/sh: 15: [: 0: unexpected operator Summary: TEST STATS: name= run=1 pass=1 fail=0 EXIT CODE: 0 EXIT CODE: 0 Notice the "unexpected operator" message in the middle. This only happens on our arm platforms. It doesn't seem to affect the test results, but should be cleaned up anyway. The "0" turns out to be the exit code. I see the same message if a test fails, except the 0 changes to a 2. Looking more closely at the code I added, I see I used ==, whereas other code nearby uses =. I change it to = and the error message went away. I retested with various test cases that fail, pass, or run no tests, and all of them do as expected still. New webrev can be found at: http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ thanks, Chris On 8/2/16 7:50 AM, Chris Plummer wrote: > On 8/1/16 9:30 PM, Chris Plummer wrote: >> On 8/1/16 7:25 PM, David Holmes wrote: >>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple change: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>> >>>>> You've split a compound expression with your code: >>>>> >>>>> 227 jtregExitCode=$$? && \ >>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>> 229 jtregExitCode=0; \ >>>>> 230 fi ; \ >>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>> >>>>> I'm not clear exactly why the && was needed here but rather than find >>>>> out later I suggest rearranging the above to: >>>>> >>>>> jtregExitCode=$$? && \ >>>>> _summary="$(SUMMARY_TXT)"; \ >>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>> jtregExitCode=0; \ >>>>> fi ; \ >>>>> >>>> Yeah, that makes sense. I'll make the change. However, it's really >>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>> ever >>>> fail? >>> >>> I wonder if it evaluates to the $? value and so only sets _summary >>> if we had a zero exit code? (Not that I understand why we would only >>> set _summary in that context.) >> I tried the following: >> >> bash-4.1$ x=0 && echo "foo"; >> >> And "foo" is always printed. I also tried non-zero values for x. Here >> are some other examples: >> >> bash-4.1$ (exit 1) && echo "foo" >> bash-4.1$ (exit 0) && echo "foo" >> foo >> >> Commands evaluate to true if the exit status is 0, and false >> otherwise, so I guess you could say commands evaluate to !?$. For &&, >> the rhs is only executed if the lhs has a zero exit status. > Updated webrev: > > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ > > thanks, > > Chris >> >> Chris >>> >>> David >>> >>>> thanks, >>>> >>>> Chris >>>>> Thanks, >>>>> David >>>>> >>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>> I did >>>>>> update them locally after noticing that. >>>>>> >>>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>> >>>> >> > From david.holmes at oracle.com Thu Aug 4 07:31:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 17:31:55 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: <9a249ef1-2466-28da-a818-d0cb42ebe58d@oracle.com> On 4/08/2016 2:35 PM, Chris Plummer wrote: > Unfortunately I need another review of these changes. I ran into a minor > problem. Although all the jprt testing I tried passed, when I looked > into the log files I noticed an issue. I saw the following: > > Test results: passed: 1 > Report written to > /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html > > Results written to > /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork > /bin/sh: 15: [: 0: unexpected operator > Summary: > TEST STATS: name= run=1 pass=1 fail=0 > EXIT CODE: 0 > EXIT CODE: 0 > > Notice the "unexpected operator" message in the middle. This only > happens on our arm platforms. It doesn't seem to affect the test > results, but should be cleaned up anyway. The "0" turns out to be the > exit code. I see the same message if a test fails, except the 0 changes > to a 2. Looking more closely at the code I added, I see I used ==, > whereas other code nearby uses =. I change it to = and the error message > went away. I retested with various test cases that fail, pass, or run no > tests, and all of them do as expected still. Must be an old sh that uses a [ built-in which doesn't alias == to =. Changes look fine. Thanks, David > New webrev can be found at: > > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ > > thanks, > > Chris > > On 8/2/16 7:50 AM, Chris Plummer wrote: >> On 8/1/16 9:30 PM, Chris Plummer wrote: >>> On 8/1/16 7:25 PM, David Holmes wrote: >>>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this simple change: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>>> >>>>>> You've split a compound expression with your code: >>>>>> >>>>>> 227 jtregExitCode=$$? && \ >>>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>>> 229 jtregExitCode=0; \ >>>>>> 230 fi ; \ >>>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>>> >>>>>> I'm not clear exactly why the && was needed here but rather than find >>>>>> out later I suggest rearranging the above to: >>>>>> >>>>>> jtregExitCode=$$? && \ >>>>>> _summary="$(SUMMARY_TXT)"; \ >>>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>>> jtregExitCode=0; \ >>>>>> fi ; \ >>>>>> >>>>> Yeah, that makes sense. I'll make the change. However, it's really >>>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>>> ever >>>>> fail? >>>> >>>> I wonder if it evaluates to the $? value and so only sets _summary >>>> if we had a zero exit code? (Not that I understand why we would only >>>> set _summary in that context.) >>> I tried the following: >>> >>> bash-4.1$ x=0 && echo "foo"; >>> >>> And "foo" is always printed. I also tried non-zero values for x. Here >>> are some other examples: >>> >>> bash-4.1$ (exit 1) && echo "foo" >>> bash-4.1$ (exit 0) && echo "foo" >>> foo >>> >>> Commands evaluate to true if the exit status is 0, and false >>> otherwise, so I guess you could say commands evaluate to !?$. For &&, >>> the rhs is only executed if the lhs has a zero exit status. >> Updated webrev: >> >> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ >> >> thanks, >> >> Chris >>> >>> Chris >>>> >>>> David >>>> >>>>> thanks, >>>>> >>>>> Chris >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>>> I did >>>>>>> update them locally after noticing that. >>>>>>> >>>>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>> >>>>> >>> >> > From dmitry.fazunenko at oracle.com Thu Aug 4 07:55:00 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 4 Aug 2016 10:55:00 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: <8df0b483-4f52-facf-be76-f44070371ab0@oracle.com> Hi David, On 03.08.2016 23:56, David Holmes wrote: > Hi Dmitrij, > > I know this reflects the changes made in hotspot/test but I have a > query. Does this: > > + requires.extraPropDefns.vmOpts = -XX:+UnlockDiagnosticVMOptions > -XX:+WhiteBoxAPI -Xbootclasspath/a:bootClasses > > mean that the VM under test is executed with those additional flags > when running the tests? Or is it run once with those flags to > establish the "requires" properties? That flags are used only once for establishing the "requires" properties. Thanks, Dima > > If the latter then I have no concern and this change seems fine. > > Thanks, > David > > On 3/08/2016 11:25 PM, Dmitrij Pochepko wrote: >> Hi, >> >> can somebody with official reviewer role review this? >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>> Sure, >>> >>> now including core-libs-dev >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 20:16, joe darcy wrote: >>>> Hello, >>>> >>>> I also recommend sending this review request over to core-libs-dev >>>> since it affect the jdk repo. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>> Hi Dmitrij, >>>>> >>>>> The change itself looks good. >>>>> >>>>> One note: this change adds a little overhead (a very little) for >>>>> running tests in jdk repository, but it's required only for VM >>>>> specific tests stored in jdk. As alternative of this change I can >>>>> suggest moving VM specific tests from the 'jdk' to 'hotspot' >>>>> repository. Perhaps, such massive update is too late for JDK9 time >>>>> frame and could be done only in JDK10. >>>>> So, if the changes depending on 8162727 are not so critical and >>>>> could be deferred I would prefer to postpone this fix. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review small patch for 8162727 - Testbug: additional >>>>>>> requires properties can't be used for filtering server vm in jdk >>>>>>> jtreg tests >>>>>>> >>>>>>> A problem is that tests under jdk repo can't use additional jtreg >>>>>>> requires properties(like vm.flavor to filter out client or server >>>>>>> vm). The same functionality was introduced for hotspot repo as part >>>>>>> of JDK-8154956. So, in order to filter tests using these >>>>>>> additional properties a small fix is created. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>> >>>> >>> >> From igor.ignatyev at oracle.com Thu Aug 4 08:46:28 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 4 Aug 2016 11:46:28 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <57A1F0BE.7040505@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: Dima, I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. so how many tests which need these properties do we have now? Thanks, ? Igor > On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: > > Hi, > > can somebody with official reviewer role review this? > > Thanks, > Dmitrij > > On 29.07.2016 21:42, Dmitrij Pochepko wrote: >> Sure, >> >> now including core-libs-dev >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 20:16, joe darcy wrote: >>> Hello, >>> >>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>> Hi Dmitrij, >>>> >>>> The change itself looks good. >>>> >>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>> >>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>> >>> >> > From frank.yuan at oracle.com Thu Aug 4 10:05:39 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 4 Aug 2016 18:05:39 +0800 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <57A291D3.5060301@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> <57A291D3.5060301@oracle.com> Message-ID: <016901d1ee37$c2a8cf30$47fa6d90$@oracle.com> > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests > > > > On 8/3/16, 3:45 AM, Daniel Fuchs wrote: > > Hi Frank, > > > > I looked at the diffs of the diffs between webrev.02 and webrev.03 and > > it looks good to me. > > > > +1 - provided all tests pass :-) > > +1, thanks for re-enabling the tests that had dependencies on 8162848. I > also closed 8162848. > > > > > But I have the same question than Joe: aren't all the test supposed > > to run twice: once with security manager and once without? > > (except for those test that might explicitly require a security manager) > > I agree, all of the tests need to run with and without security manager. > It would be good to combine the runWithSecurityManager and > runWithoutSecurityManager methods into one with a condition that > determines whether a security manager is present. > Alright, I will make the tests run twice. To impl this, I have to add jtreg tags like the following: /* * @test * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest * @run testng/othervm -DrunSecMngr=true common.Bug6350682 * @run testng/othervm common.Bug6350682 */ And modify the Policy class accordingly. I am writing a small program to update the tests, will send the new version tomorrow... Frank > Best, > Joe > > > > > best regards, > > > > -- daniel > > > > On 03/08/16 11:12, Frank Yuan wrote: > >> Hi Joe > >> > >> Thank you for your review! > >> > >> I updated the tests according to the latest comments as well as had > >> unittest/transform/TransformerTest.java up to date, please check > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ > >> > >> > >> Thanks > >> Frank > >> > >> -----Original Message----- > >> From: Joe Wang [mailto:huizhe.wang at oracle.com] > >> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP > >> unit tests > >> > >> > >> > >> On 8/2/16, 5:30 AM, Daniel Fuchs wrote: > >>> Hi Frank, > >>> > >>> I am intrigued by these change which do not seem > >>> to have anything to do with the rest. I mean, I'm not opposed > >>> as long as they are intended and that Joe validates them: > >>> ======================================================== > >>> > >>> > >> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram > >> > >> es.html > >>> > >>> > >>> 118 spf.setNamespaceAware(false); > >> > >> Not sure why this was changed. > >>> > >>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra > >> > >> mes.html > >>> > >> > >> The test itself wasn't very clear on the content it tests. If it only > >> verifies whether a resolver is used as is said, then this and related > >> changes in ResolverTest and publish.xml are fine. To the extent it > >> verifies, it didn't have to output to a file. > >>> > >>> > >> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h > >> > >> tml > >>> > >> > >> We have to let Frank explain why namespace was turned off for these > >> tests :-) In this case, XMLReaderNSTableTest. In general, I would say > >> enabling security shouldn't change tests or gold files in this case. > >> > >>> > >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/functional/org/xml/sax/xmlfiles/publish.xml.frames.html > >>> > >>> > >>> This looks like a desirable change - but what does it have to do > >>> with enabling security manager? > >> > >> Probably to remove the reference to that particular server? Seems to be > >> fine as a cleanup. Again, it (the original test) only verifies a resolve > >> is used, it didn't even need to write out a file to prove that. > >>> > >>> Also: > >>> ======================================================== > >>> > >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/unittest/transform/XSLTFunctionsTest.java.frames.html > >>> > >>> > >>> > >>> 70 > >>> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions", > >>> > >>> true); > >>> > >>> Is this needed only when there is a security manager? > >> > >> Yes, when Security Manager is present, this feature is turned off by > >> default. > >>> > >>> ======================================================== > >>> > >>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java.html > >>> > >>> > >>> > >>> > >>> 119 /* > >>> 120 addPermission(new RuntimePermission("getClassLoader")); > >>> 121 addPermission(new RuntimePermission("createClassLoader")); > >>> 122 addPermission(new > >>> RuntimePermission("createSecurityManager")); > >>> 123 addPermission(new RuntimePermission("modifyThread")); > >>> 124 addPermission(new PropertyPermission("*", "read,write")); > >>> 125 > >>> 126 addPermission(new RuntimePermission("setIO")); > >>> 127 addPermission(new > >>> RuntimePermission("setContextClassLoader")); > >>> 128 addPermission(new > >>> RuntimePermission("accessDeclaredMembers"));*/ > >>> > >>> > >>> Please remove before pushing. > >>> > >>> > >>> ======================================================== > >>> > >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml > >>> > >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl > >>> > >>> It seems these two files have been removed, but shouldn't they have > >>> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform > >>> instead? > >>> I see they are used by > >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java > >>> > >>> Did you forget to hg add them? > >>> > >>> ======================================================== > >>> > >>> > >>> Otherwise the new JAXPPolicyManager & its Policy implementation > >>> look good. This is much simpler and better than the first > >>> iteration :-) > >>> > >>> This was a *very* long patch - so congratulations for seeing > >>> this through! > >> > >> Very long patch, indeed! Thanks for the great effort! Very well done > >> with the unified Policy/Permission management. > >> > >> Best, > >> Joe > >> > >>> > >>> cheers, > >>> > >>> -- daniel > >>> > >>> > >>> On 02/08/16 11:20, Frank Yuan wrote: > >>>> Hi Joe and Daniel > >>>> > >>>> I have finished the rework as your comments, please check > >>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ > >>>> > >>>> JAXP tests use Policy classes, as well as 3 other patterns provided > >>>> by JAXPTestUtilities: > >>>> 1. runWithAllPerm methods, are only used for user setup code, never > >>>> run jaxp code with them. > >>>> 2. tryRunWithPolicyManager method, is used to run some test methods > >>>> with security manager and run the others without security > >>>> manager in single test class > >>>> 3. runWithTmpPermission methods, which may run jaxp code with some > >>>> limited permissions, those permissions belong to user permissions > >>>> and jaxp code won't doPrivileged for them. E.g. > >>>> PropertyPermission("MyInputFactory", "read") or > >>>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") > >>>> > >>>> > >>>> Btw, some tests or test methods are disabled or commented sm support > >>>> temporarily for some known jaxp security bugs. > >>>> > >>>> Thanks > >>>> Frank > >>>> > >>> > >> > > From dmitrij.pochepko at oracle.com Thu Aug 4 10:56:23 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 4 Aug 2016 13:56:23 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: <57A31F57.3020606@oracle.com> Hi, I'm aware of one test only so far. Shoud I move this single test or a whole testgroup which this test belongs to? Thanks, Dmitrij > Dima, > > I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. > > so how many tests which need these properties do we have now? > > Thanks, > ? Igor > >> On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: >> >> Hi, >> >> can somebody with official reviewer role review this? >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>> Sure, >>> >>> now including core-libs-dev >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 20:16, joe darcy wrote: >>>> Hello, >>>> >>>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>> Hi Dmitrij, >>>>> >>>>> The change itself looks good. >>>>> >>>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>>> >>>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij From ivan.gerasimov at oracle.com Thu Aug 4 12:52:14 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 4 Aug 2016 15:52:14 +0300 Subject: [jdk9] RFR (XXS): 8163180: Typos around @code javadoc tag usage Message-ID: <70885b18-e3b6-7983-305c-0092a9b8597a@oracle.com> Hello! In a few places the @code javadoc tag misses the curly bracket. Would you please review a trivial fix? http://cr.openjdk.java.net/~igerasim/8163180/00/webrev/ With kind regards, Ivan From daniel.fuchs at oracle.com Thu Aug 4 12:55:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 4 Aug 2016 13:55:30 +0100 Subject: [jdk9] RFR (XXS): 8163180: Typos around @code javadoc tag usage In-Reply-To: <70885b18-e3b6-7983-305c-0092a9b8597a@oracle.com> References: <70885b18-e3b6-7983-305c-0092a9b8597a@oracle.com> Message-ID: <690a83f8-cd9a-99f3-ea74-0ee6a622dab0@oracle.com> Hi Ivan, Looks good! best regards, -- daniel On 04/08/16 13:52, Ivan Gerasimov wrote: > Hello! > > In a few places the @code javadoc tag misses the curly bracket. > Would you please review a trivial fix? > http://cr.openjdk.java.net/~igerasim/8163180/00/webrev/ > > With kind regards, > Ivan From dmitry.fazunenko at oracle.com Thu Aug 4 12:56:11 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 4 Aug 2016 15:56:11 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: Igor, Regardless this change I agree with you: VM specific tests should be moved from jdk to hotspot. But we can't get rid of VM specific tests in the jdk repository at all. Tests for java.lang.management belong to JDK, but may use VM specific... I count 11 open and 100 closed jdk tests which use @requires vm.*. I don't see s a big problem in having a few lines duplicated in TEST.ROOT. We don't duplicate the code, but repeat a sort of "import" statements. So, I'm okay with the proposed change. Thanks, Dima On 04.08.2016 11:46, Igor Ignatyev wrote: > Dima, > > I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. > > so how many tests which need these properties do we have now? > > Thanks, > ? Igor > >> On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: >> >> Hi, >> >> can somebody with official reviewer role review this? >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>> Sure, >>> >>> now including core-libs-dev >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 20:16, joe darcy wrote: >>>> Hello, >>>> >>>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>> Hi Dmitrij, >>>>> >>>>> The change itself looks good. >>>>> >>>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>>> >>>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij From scolebourne at joda.org Thu Aug 4 14:01:58 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 4 Aug 2016 15:01:58 +0100 Subject: Why is there no Math.ceilDiv? In-Reply-To: References: Message-ID: On 31 July 2016 at 20:45, Philipp Nowak wrote: > I was wondering why there is no Math.ceilDiv() method, when a floorDiv() > method got added in Java 8 through JDK-8023217 [1]. > > Is there any reason why such method did not get added with floorDiv() floorDiv() was added as part of creating java.time, which had no need for a ceilDiv() method. Stephen From igor.ignatyev at oracle.com Thu Aug 4 16:29:43 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 4 Aug 2016 19:29:43 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: > On Aug 4, 2016, at 3:56 PM, Dmitry Fazunenko wrote: > > Igor, > > Regardless this change I agree with you: VM specific tests should be moved from jdk to hotspot. > > But we can't get rid of VM specific tests in the jdk repository at all. Tests for java.lang.management belong to JDK, but may use VM specific... > I count 11 open and 100 closed jdk tests which use @requires vm.*. > Well, I looked thru them and almost all of them look as hotspot tests. > I don't see s a big problem in having a few lines duplicated in TEST.ROOT. We don't duplicate the code, but repeat a sort of "import" statements. > So, I'm okay with the proposed change. the problem is not in code duplication, it is in making that easy to have hotspot tests in jdk. > > Thanks, > Dima > > > On 04.08.2016 11:46, Igor Ignatyev wrote: >> Dima, >> >> I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. >> >> so how many tests which need these properties do we have now? >> >> Thanks, >> ? Igor >> >>> On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: >>> >>> Hi, >>> >>> can somebody with official reviewer role review this? >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>>> Sure, >>>> >>>> now including core-libs-dev >>>> >>>> Thanks, >>>> Dmitrij >>>> >>>> On 29.07.2016 20:16, joe darcy wrote: >>>>> Hello, >>>>> >>>>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>>> Hi Dmitrij, >>>>>> >>>>>> The change itself looks good. >>>>>> >>>>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>>>> >>>>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij > From patrick at reini.net Thu Aug 4 17:33:38 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 4 Aug 2016 19:33:38 +0200 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> Message-ID: <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> Hi Paul, I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) On 15.07.2016 17:10, Paul Sandoz wrote: >> When I understand you correctly here we should concentrate on the public >> methods naming firstly? I initially was not sure, what a proper naming >> for the steams method was. It seem to me reasonable the way Stuart pointed >> them out on his first comment to name them something like this: >> >> Stream resources(String name) >> Stream systemResources(String name) >> >> >> Yes. I have a first proposal for the new methods and their documentation to start with the discussion about the actual API without the implementation jet: /** * Finds all the resources with the given name. A resource is some data * (images, audio, text, etc) that can be accessed by class code in a way * that is independent of the location of the code. * * Resources in a named module are private to that module. This method does * not find resources in named modules. * *

The name of a resource is a /-separated path name that * identifies the resource. * *

The search order is described in the documentation for {@link * #getResource(String)}.

* * @apiNote When overriding this method it is recommended that an * implementation ensures that any delegation is consistent with the {@link * #getResource(java.lang.String) getResource(String)} method. This should * ensure that the first element returned by the stream is the same * resource that the {@code getResource(String)} method would return. * * @param name * The resource name * * @return An stream of {@link java.net.URL URL} objects for * the resource. If no resources could be found, the stream * will be empty. Resources that the class loader doesn't have * access to will not be in the stream. * * @throws IOException * If I/O errors occur * * @see #findResources(String) * * @since 1.9 */ public Stream resources(String name) throws IOException { // to be implemented later } /** * Finds all resources of the specified name from the search path used to * load classes. The resources thus found are returned as an * {@link java.util.stream.Stream Stream} of {@link * java.net.URL URL} objects. * * Resources in a named module are private to that module. This method does * not find resources in named modules. * *

The search order is described in the documentation for {@link * #getSystemResource(String)}.

* * @param name * The resource name * * @return An stream of resource {@link java.net.URL URL} * objects * * @throws IOException * If I/O errors occur * @since 1.9 */ public static Stream systemResources(String name) throws IOException { // to be implemented later } >> Has anyone a better naming suggestion? For me those names would fit so >> far. If we look into the stream characteristics I would suggest that it >> has a unknown size and is immutable in both cases. Maybe the entries are >> also distinct, but there I'm not sure. >> > I would expect the URLs to be distinct, but that might not be consistent with URL.equals i.e. i don?t trust URL handlers :-) therefore i would be wary of including the DISTINCT characteristic. > > Paul. So, I was right to no be completely sure about the DISTINCT :-) - then I would go for NONNULL and IMMUTABLE characteristics to start with... From claes.redestad at oracle.com Thu Aug 4 19:02:59 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 4 Aug 2016 12:02:59 -0700 Subject: RFR (XS): 8162815: unnecessary object creation in reflection Message-ID: <57A39163.4060807@oracle.com> Hi, I'd like to sponsor this bug fix provided by Tom?? H?rka to remove a new and dup left behind in generated accessor methods after moving these to use appropriate valueOf methods for boxing primitive returns. Bug: https://bugs.openjdk.java.net/browse/JDK-8162815 Webrev: http://cr.openjdk.java.net/~redestad/8162815/webrev.01/ This appears to have a very limited effect to peak performance in HotSpot (interpreter and C1 level code seem to hurt a bit), but should be fixed for correctness. Thanks! /Claes From huizhe.wang at oracle.com Thu Aug 4 22:06:32 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 04 Aug 2016 15:06:32 -0700 Subject: RFR (JAXP) 8160069: RuntimeException thrown by XPathFactory::newInstance missing the cause Message-ID: <57A3BC68.4010504@oracle.com> Hi, Please review the patch that sets the cause to the Exception: http://cr.openjdk.java.net/~joehw/jdk9/8160069/webrev/ Thanks, Joe From stanislav.smirnov at oracle.com Thu Aug 4 22:36:21 2016 From: stanislav.smirnov at oracle.com (Stas Smirnov) Date: Thu, 4 Aug 2016 15:36:21 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <9a249ef1-2466-28da-a818-d0cb42ebe58d@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> <9a249ef1-2466-28da-a818-d0cb42ebe58d@oracle.com> Message-ID: <5a059e4f-ac30-12e4-9779-df13d87e0f8f@oracle.com> I am ok with the recent changes On 04.08.2016 00:31, David Holmes wrote: > On 4/08/2016 2:35 PM, Chris Plummer wrote: >> Unfortunately I need another review of these changes. I ran into a minor >> problem. Although all the jprt testing I tried passed, when I looked >> into the log files I noticed an issue. I saw the following: >> >> Test results: passed: 1 >> Report written to >> /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html >> >> >> Results written to >> /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork >> /bin/sh: 15: [: 0: unexpected operator >> Summary: >> TEST STATS: name= run=1 pass=1 fail=0 >> EXIT CODE: 0 >> EXIT CODE: 0 >> >> Notice the "unexpected operator" message in the middle. This only >> happens on our arm platforms. It doesn't seem to affect the test >> results, but should be cleaned up anyway. The "0" turns out to be the >> exit code. I see the same message if a test fails, except the 0 changes >> to a 2. Looking more closely at the code I added, I see I used ==, >> whereas other code nearby uses =. I change it to = and the error message >> went away. I retested with various test cases that fail, pass, or run no >> tests, and all of them do as expected still. > > Must be an old sh that uses a [ built-in which doesn't alias == to =. > > Changes look fine. > > Thanks, > David > >> New webrev can be found at: >> >> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ >> >> thanks, >> >> Chris >> >> On 8/2/16 7:50 AM, Chris Plummer wrote: >>> On 8/1/16 9:30 PM, Chris Plummer wrote: >>>> On 8/1/16 7:25 PM, David Holmes wrote: >>>>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this simple change: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>>>> >>>>>>> You've split a compound expression with your code: >>>>>>> >>>>>>> 227 jtregExitCode=$$? && \ >>>>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>>>> 229 jtregExitCode=0; \ >>>>>>> 230 fi ; \ >>>>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>>>> >>>>>>> I'm not clear exactly why the && was needed here but rather than >>>>>>> find >>>>>>> out later I suggest rearranging the above to: >>>>>>> >>>>>>> jtregExitCode=$$? && \ >>>>>>> _summary="$(SUMMARY_TXT)"; \ >>>>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>>>> jtregExitCode=0; \ >>>>>>> fi ; \ >>>>>>> >>>>>> Yeah, that makes sense. I'll make the change. However, it's really >>>>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>>>> ever >>>>>> fail? >>>>> >>>>> I wonder if it evaluates to the $? value and so only sets _summary >>>>> if we had a zero exit code? (Not that I understand why we would only >>>>> set _summary in that context.) >>>> I tried the following: >>>> >>>> bash-4.1$ x=0 && echo "foo"; >>>> >>>> And "foo" is always printed. I also tried non-zero values for x. Here >>>> are some other examples: >>>> >>>> bash-4.1$ (exit 1) && echo "foo" >>>> bash-4.1$ (exit 0) && echo "foo" >>>> foo >>>> >>>> Commands evaluate to true if the exit status is 0, and false >>>> otherwise, so I guess you could say commands evaluate to !?$. For &&, >>>> the rhs is only executed if the lhs has a zero exit status. >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ >>> >>> thanks, >>> >>> Chris >>>> >>>> Chris >>>>> >>>>> David >>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>>>> I did >>>>>>>> update them locally after noticing that. >>>>>>>> >>>>>>>> Tested with jprt test case given in the CR, and also with a >>>>>>>> jprt run >>>>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>> >>>>>> >>>> >>> >> From lance.andersen at oracle.com Thu Aug 4 23:27:29 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 4 Aug 2016 19:27:29 -0400 Subject: RFR (JAXP) 8160069: RuntimeException thrown by XPathFactory::newInstance missing the cause In-Reply-To: <57A3BC68.4010504@oracle.com> References: <57A3BC68.4010504@oracle.com> Message-ID: +1 Joe > On Aug 4, 2016, at 6:06 PM, Joe Wang wrote: > > Hi, > > Please review the patch that sets the cause to the Exception: > http://cr.openjdk.java.net/~joehw/jdk9/8160069/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 huizhe.wang at oracle.com Fri Aug 5 00:31:48 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 04 Aug 2016 17:31:48 -0700 Subject: RFR (JAXP) 8160069: RuntimeException thrown by XPathFactory::newInstance missing the cause In-Reply-To: References: <57A3BC68.4010504@oracle.com> Message-ID: <57A3DE74.6060201@oracle.com> Thanks Lance! Joe On 8/4/16, 4:27 PM, Lance Andersen wrote: > +1 Joe > >> On Aug 4, 2016, at 6:06 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review the patch that sets the cause to the Exception: >> http://cr.openjdk.java.net/~joehw/jdk9/8160069/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 Alan.Bateman at oracle.com Fri Aug 5 04:18:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Aug 2016 21:18:39 -0700 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> Message-ID: <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> On 04/08/2016 10:33, Patrick Reinhart wrote: > Hi Paul, > > I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) > > On 15.07.2016 17:10, Paul Sandoz wrote: >>> When I understand you correctly here we should concentrate on the public >>> methods naming firstly? I initially was not sure, what a proper naming >>> for the steams method was. It seem to me reasonable the way Stuart pointed >>> them out on his first comment to name them something like this: >>> >>> Stream resources(String name) >>> Stream systemResources(String name) >>> >>> >>> Yes. > I have a first proposal for the new methods and their documentation to start with the discussion about the actual API without the implementation jet: The method names look right but I don't think `throws IOException` is needed. If overridden then the implementations could be truely lazy and the method will need to specify how stream operations will wrap the errors in UncheckedIOExceptions. For the initial sentence then it might be better to say that it "Returns a stream that loads the resources ...". As I was mentioned previously, we will be replacing the javadoc for the existing methods and this will impact the wording for the new methods. It's okay to align the wording for the new methods with the old and we'll adjust once there is agreement on the proposal in JSR 376 and we bring the changes to JDK 9. -Alan From abhijit.r.roy at oracle.com Fri Aug 5 10:48:12 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Fri, 5 Aug 2016 16:18:12 +0530 Subject: Review request for JDK-8163266 : Doc for ValidationEvent#getSeverity() In-Reply-To: <12eea865-5de6-400b-8b8f-c445bcb35ada@default> References: <567260F6.2070508@oracle.com> <7f1d3edc-b17d-47d9-97d5-069664a219e3@default> <2b3a86bc-807a-4a56-a85c-c4adeee62dc5@default> <12eea865-5de6-400b-8b8f-c445bcb35ada@default> Message-ID: <828fcb2d-9baf-eb76-1449-fa97659f825a@oracle.com> Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8163266 Bug - Doc for ValidationEvent#getSeverity() should say it returns a constant from ValidationEvent instead of ValidationError Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8163266/webrev.00/ I have just rectified and modified those errors. And moving forward it for review. Regards, Abhijit From frank.yuan at oracle.com Fri Aug 5 13:26:54 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Fri, 5 Aug 2016 21:26:54 +0800 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <016a01d1ee37$c47be180$4d73a480$@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> <57A291D3.5060301@oracle.com> <016a01d1ee37$c47be180$4d73a480$@oracle.com> Message-ID: <024101d1ef1d$0d138c50$273aa4f0$@oracle.com> Hi Joe and Daniel Please review the update: http://cr.openjdk.java.net/~fyuan/8067170/webrev.04/ In this version, I 1. made all tests run twice, to pass in the different argument to the jtreg TestNG test, it has to run in othervm(jaxp test also run in othervm before this but it's possible to run in agentvm), however, I didn't delete the code supporting agentvm from JAXPPolicyManager.java because jtreg may provide more support in agentvm mode someday:) 2. enabled sm in unittest/catalog/CatalogTest.java as jdk-8161176's conclusion 3. fixed the bug in runWithTmpPermission methods, Daniel mentioned it but I didn't understand at that time :P Thanks Frank > -----Original Message----- > From: Frank Yuan [mailto:frank.yuan at oracle.com] > Sent: Thursday, August 04, 2016 6:06 PM > To: 'Joe Wang'; 'Daniel Fuchs' > Cc: 'core-libs-dev' > Subject: RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests > > > > > -----Original Message----- > > From: Joe Wang [mailto:huizhe.wang at oracle.com] > > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP > unit tests > > > > > > > > On 8/3/16, 3:45 AM, Daniel Fuchs wrote: > > > Hi Frank, > > > > > > I looked at the diffs of the diffs between webrev.02 and webrev.03 and > > > it looks good to me. > > > > > > +1 - provided all tests pass :-) > > > > +1, thanks for re-enabling the tests that had dependencies on 8162848. I > > also closed 8162848. > > > > > > > > But I have the same question than Joe: aren't all the test supposed > > > to run twice: once with security manager and once without? > > > (except for those test that might explicitly require a security > manager) > > > > I agree, all of the tests need to run with and without security manager. > > It would be good to combine the runWithSecurityManager and > > runWithoutSecurityManager methods into one with a condition that > > determines whether a security manager is present. > > > > Alright, I will make the tests run twice. To impl this, I have to add > jtreg tags like the following: > /* > * @test > * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest > * @run testng/othervm -DrunSecMngr=true common.Bug6350682 > * @run testng/othervm common.Bug6350682 > */ > > And modify the Policy class accordingly. I am writing a small program to > update the tests, will send the new version tomorrow... > > Frank > > > > Best, > > Joe > > > > > > > > best regards, > > > > > > -- daniel > > > > > > On 03/08/16 11:12, Frank Yuan wrote: > > >> Hi Joe > > >> > > >> Thank you for your review! > > >> > > >> I updated the tests according to the latest comments as well as had > > >> unittest/transform/TransformerTest.java up to date, please check > > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ > > >> > > >> > > >> Thanks > > >> Frank > > >> > > >> -----Original Message----- > > >> From: Joe Wang [mailto:huizhe.wang at oracle.com] > > >> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP > > >> unit tests > > >> > > >> > > >> > > >> On 8/2/16, 5:30 AM, Daniel Fuchs wrote: > > >>> Hi Frank, > > >>> > > >>> I am intrigued by these change which do not seem > > >>> to have anything to do with the rest. I mean, I'm not opposed > > >>> as long as they are intended and that Joe validates them: > > >>> ======================================================== > > >>> > > >>> > > >> > > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > nctional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram > > >> > > >> es.html > > >>> > > >>> > > >>> 118 spf.setNamespaceAware(false); > > >> > > >> Not sure why this was changed. > > >>> > > >>> > > >> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > nctional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra > > >> > > >> mes.html > > >>> > > >> > > >> The test itself wasn't very clear on the content it tests. If it only > > >> verifies whether a resolver is used as is said, then this and related > > >> changes in ResolverTest and publish.xml are fine. To the extent it > > >> verifies, it didn't have to output to a file. > > >>> > > >>> > > >> > > > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > nctional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h > > >> > > >> tml > > >>> > > >> > > >> We have to let Frank explain why namespace was turned off for these > > >> tests :-) In this case, XMLReaderNSTableTest. In general, I would > say > > >> enabling security shouldn't change tests or gold files in this case. > > >> > > >>> > > >>> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > nctional/org/xml/sax/xmlfiles/publish.xml.frames.html > > >>> > > >>> > > >>> This looks like a desirable change - but what does it have to do > > >>> with enabling security manager? > > >> > > >> Probably to remove the reference to that particular server? Seems to > be > > >> fine as a cleanup. Again, it (the original test) only verifies a > resolve > > >> is used, it didn't even need to write out a file to prove that. > > >>> > > >>> Also: > > >>> ======================================================== > > >>> > > >>> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/un > ittest/transform/XSLTFunctionsTest.java.frames.html > > >>> > > >>> > > >>> > > >>> 70 > > >>> > tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFu > nctions", > > >>> > > >>> true); > > >>> > > >>> Is this needed only when there is a security manager? > > >> > > >> Yes, when Security Manager is present, this feature is turned off by > > >> default. > > >>> > > >>> ======================================================== > > >>> > > >>> > http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/li > bs/jaxp/library/JAXPPolicyManager.java.html > > >>> > > >>> > > >>> > > >>> > > >>> 119 /* > > >>> 120 addPermission(new RuntimePermission("getClassLoader")); > > >>> 121 addPermission(new > RuntimePermission("createClassLoader")); > > >>> 122 addPermission(new > > >>> RuntimePermission("createSecurityManager")); > > >>> 123 addPermission(new RuntimePermission("modifyThread")); > > >>> 124 addPermission(new PropertyPermission("*", > "read,write")); > > >>> 125 > > >>> 126 addPermission(new RuntimePermission("setIO")); > > >>> 127 addPermission(new > > >>> RuntimePermission("setContextClassLoader")); > > >>> 128 addPermission(new > > >>> RuntimePermission("accessDeclaredMembers"));*/ > > >>> > > >>> > > >>> Please remove before pushing. > > >>> > > >>> > > >>> ======================================================== > > >>> > > >>> > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml > > >>> > > >>> > test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl > > >>> > > >>> It seems these two files have been removed, but shouldn't they have > > >>> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform > > >>> instead? > > >>> I see they are used by > > >>> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java > > >>> > > >>> Did you forget to hg add them? > > >>> > > >>> ======================================================== > > >>> > > >>> > > >>> Otherwise the new JAXPPolicyManager & its Policy implementation > > >>> look good. This is much simpler and better than the first > > >>> iteration :-) > > >>> > > >>> This was a *very* long patch - so congratulations for seeing > > >>> this through! > > >> > > >> Very long patch, indeed! Thanks for the great effort! Very well done > > >> with the unified Policy/Permission management. > > >> > > >> Best, > > >> Joe > > >> > > >>> > > >>> cheers, > > >>> > > >>> -- daniel > > >>> > > >>> > > >>> On 02/08/16 11:20, Frank Yuan wrote: > > >>>> Hi Joe and Daniel > > >>>> > > >>>> I have finished the rework as your comments, please check > > >>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ > > >>>> > > >>>> JAXP tests use Policy classes, as well as 3 other patterns provided > > >>>> by JAXPTestUtilities: > > >>>> 1. runWithAllPerm methods, are only used for user setup code, never > > >>>> run jaxp code with them. > > >>>> 2. tryRunWithPolicyManager method, is used to run some test methods > > >>>> with security manager and run the others without security > > >>>> manager in single test class > > >>>> 3. runWithTmpPermission methods, which may run jaxp code with some > > >>>> limited permissions, those permissions belong to user permissions > > >>>> and jaxp code won't doPrivileged for them. E.g. > > >>>> PropertyPermission("MyInputFactory", "read") or > > >>>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") > > >>>> > > >>>> > > >>>> Btw, some tests or test methods are disabled or commented sm > support > > >>>> temporarily for some known jaxp security bugs. > > >>>> > > >>>> Thanks > > >>>> Frank > > >>>> > > >>> > > >> > > > From Roger.Riggs at Oracle.com Fri Aug 5 13:41:01 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 5 Aug 2016 09:41:01 -0400 Subject: Review request for JDK-8163266 : Doc for ValidationEvent#getSeverity() In-Reply-To: <828fcb2d-9baf-eb76-1449-fa97659f825a@oracle.com> References: <567260F6.2070508@oracle.com> <7f1d3edc-b17d-47d9-97d5-069664a219e3@default> <2b3a86bc-807a-4a56-a85c-c4adeee62dc5@default> <12eea865-5de6-400b-8b8f-c445bcb35ada@default> <828fcb2d-9baf-eb76-1449-fa97659f825a@oracle.com> Message-ID: <9afb719a-1bed-08ee-1098-1865d59da33c@Oracle.com> looks fine. Roger On 8/5/2016 6:48 AM, Abhijit Roy wrote: > Hi all, > > Please review a fix for Bug - > https://bugs.openjdk.java.net/browse/JDK-8163266 > Bug - Doc for ValidationEvent#getSeverity() should say it returns a > constant from ValidationEvent instead of ValidationError > Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8163266/webrev.00/ > > I have just rectified and modified those errors. And moving forward it > for review. > > Regards, > Abhijit > > From sean.coffey at oracle.com Fri Aug 5 14:05:42 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Aug 2016 15:05:42 +0100 Subject: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize Message-ID: <57A49D36.8060203@oracle.com> Hoping to get a review on this issue that's been sitting on my plate for a long while. Pavel drew up the bulk of the edits for this one (Thanks) The fix basically delegates polling and timeout management to the BlockingQueue.poll(timeout.. ) method. As a result it makes Connection readReply logic much easier to handle. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8139965.9/webrev/ bug report : https://bugs.openjdk.java.net/browse/JDK-8139965 -- Regards, Sean. From Roger.Riggs at Oracle.com Fri Aug 5 14:50:10 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 5 Aug 2016 10:50:10 -0400 Subject: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <57A49D36.8060203@oracle.com> References: <57A49D36.8060203@oracle.com> Message-ID: Hi Sean, Looks like a cleaner solution to synchronize writer and readers. I don't quite understand the 80% capacity value. It is related to the obsolete highWatermark but that does not seem relevant with the update. If the caller is going to specify a replyQueueCapacity then why should it be downgraded to 80%? Roger On 8/5/2016 10:05 AM, Se?n Coffey wrote: > Hoping to get a review on this issue that's been sitting on my plate > for a long while. Pavel drew up the bulk of the edits for this one > (Thanks) > > The fix basically delegates polling and timeout management to the > BlockingQueue.poll(timeout.. ) method. As a result it makes Connection > readReply logic much easier to handle. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8139965.9/webrev/ > bug report : https://bugs.openjdk.java.net/browse/JDK-8139965 > From sean.coffey at oracle.com Fri Aug 5 15:46:25 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Aug 2016 16:46:25 +0100 Subject: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: References: <57A49D36.8060203@oracle.com> Message-ID: <57A4B4D1.8070803@oracle.com> Sorry - cc'ed the wrong Pavel earlier. Corrected. I thought the consumer/producer model was best served by delegating to the BlockingQueue. Is there a need to synchronize as a result ? The 80% logic is only implemented in the rare case where the com.sun.jndi.ldap.search.replyQueueSize ldap context property is set. It seems to be legacy behaviour from the old code where the reader thread was paused at 80% capacity. Setting the BlockingQueue to the same '80%' size should have the same net effect. Regards, Sean. On 05/08/16 15:50, Roger Riggs wrote: > Hi Sean, > > Looks like a cleaner solution to synchronize writer and readers. > > I don't quite understand the 80% capacity value. It is related to the > obsolete highWatermark > but that does not seem relevant with the update. > > If the caller is going to specify a replyQueueCapacity then why should > it be downgraded to 80%? > > Roger > > > > On 8/5/2016 10:05 AM, Se?n Coffey wrote: >> Hoping to get a review on this issue that's been sitting on my plate >> for a long while. Pavel drew up the bulk of the edits for this one >> (Thanks) >> >> The fix basically delegates polling and timeout management to the >> BlockingQueue.poll(timeout.. ) method. As a result it makes >> Connection readReply logic much easier to handle. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8139965.9/webrev/ >> bug report : https://bugs.openjdk.java.net/browse/JDK-8139965 >> > From Roger.Riggs at Oracle.com Fri Aug 5 15:48:11 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 5 Aug 2016 11:48:11 -0400 Subject: RFR 9: JDK-8155102: Process.toString could include pid, isAlive, exitStatus In-Reply-To: References: <9066d1a2-4a7d-bff4-60d8-d62ff559272d@Oracle.com> <3698a11e-c224-14cc-a083-cc50b89efd2c@Oracle.com> Message-ID: <74a67413-c510-be0d-db92-481e228e72d6@Oracle.com> Hi Andrey, I added a test to test/java/lang/ProcessBuilder/Basic.java. Every change must have a test. http://cr.openjdk.java.net/~rriggs/webrev-process-8155102/ I can handle the extension request. Addition review comments welcome. Roger On 8/2/2016 1:30 AM, Andrey Dyachkov wrote: > Roger, > > I have changed impl according to your comments, thank you! > Regarding fc-extension, I am not able to add comments in the bug > tracker I think you can do it, correct? Also I am already in OCA list. > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > @@ -630,6 +630,19 @@ > return !hasExited; > } > > + /** > + * The {@code toString} method returns a string consisting of > + * the native process ID of the process and the exit value of the > process. > + * > + * @return a string representation of the object. > + */ > + @Override > + public String toString() { > + return new StringBuilder("Process[pid=").append(pid) > + .append(", exitValue=").append(hasExited ? exitcode : "\"not > exited\"") > + .append("]").toString(); > + } > + > private static native void init(); > > static { > diff --git a/src/java.base/windows/classes/java/lang/ProcessImpl.java > b/src/java.base/windows/classes/java/lang/ProcessImpl.java > --- a/src/java.base/windows/classes/java/lang/ProcessImpl.java > +++ b/src/java.base/windows/classes/java/lang/ProcessImpl.java > @@ -564,6 +564,20 @@ > private static native boolean isProcessAlive(long handle); > > /** > + * The {@code toString} method returns a string consisting of > + * the native process ID of the process and the exit value of the > process. > + * > + * @return a string representation of the object. > + */ > + @Override > + public String toString() { > + int exitCode = getExitCodeProcess(handle); > + return new StringBuilder("Process[pid=").append(getPid()) > + .append(", exitValue=").append(exitCode == > STILL_ACTIVE ? "\"not exited\"" : exitCode) > + .append("]").toString(); > + } > + > + /** > * Create a process using the win32 function CreateProcess. > * The method is synchronized due to MS kb315939 problem. > * All native handles should restore the inherit flag at the end > of call. > > > > On Mon, 1 Aug 2016 at 19:34 Roger Riggs > wrote: > > Hi Andrey, > > Sorry to be slow in getting back to this. > > Thanks for the update; did you notice that Windows has a > separate implementation of > ProcessImpl and would also need a similar, though not identical > toString() implementation? > [jdk/src/java.base/windows/classes/java/lang/ProcessImpl.java ] > > Windows has a slightly different implementation of the internal > state with respect to knowing if it has exited. > See exitValue() and the native getExitCodeProcess() method. > > > On 7/24/2016 7:42 AM, Andrey Dyachkov wrote: >> Hi Roger, >> >> Thank you for reviewing it! I've prepared another version. >> >> diff --git >> a/src/java.base/unix/classes/java/lang/ProcessImpl.java >> b/src/java.base/unix/classes/java/lang/ProcessImpl.java >> --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java >> +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java >> @@ -630,6 +630,21 @@ >> return !hasExited; >> } >> >> + /** >> + * The {@code toString} method for class {@code ProcessImpl} >> + * returns a string consisting of the native process ID of >> the process, >> + * exit code of the process and the status of the process. > The javadoc for Process uses the terminology "exit value" or "exit > status"; the usage should be consistent. > >> + * >> + * @return a string representation of the object. >> + */ >> + @Override >> + public String toString() { >> + return new StringBuilder("ProcessImpl{pid=").append(pid) > The implementation class should be hidden, use "Process". > Other toString methods use '[]' to enclose the aggregate of the > values. > >> + .append(", exitcode=").append(exitcode) > 'exitcode=' -> "exitValue" to be consistent with the exitValue method. > > This will need an alternate value if the process has not exited, > perhaps "not exited" > >> + .append(", hasExited=").append(hasExited) > This isn't needed with the above 'not exited' string. >> + .append("}").toString(); > '}' -> ']' > > > Also, I think this would be viewed more as an enhancement than a > bug and we'll need > to request an extension[1][2] for it when the code is complete. > > Thanks, Roger > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004443.html > [2] http://openjdk.java.net/projects/jdk9/fc-extension-process > > >> + } >> + >> private static native void init(); >> >> static { >> >> On Mon, 9 May 2016 at 16:50 Roger Riggs > > wrote: >> >> Hi Andrey, >> >> Since toString is a public method it needs to provide >> complete javadoc >> specification >> as providing values for debugging information. ToString methods >> typically directly >> reflect the state of the fields of the object. >> >> Why should the exitValue have the value of the pid if the >> process is not >> alive? >> >> Also, the if toString is providing the exitValue then it >> should be >> identified as "exitValue", not exitCode. >> the isAlive value should be identified as "isAlive". >> The implementation class should not be exposed. (remove >> this.getClass().getSimpleName()). >> >> The performance of what seems like a simple toString method >> is not going >> to be great >> because of the native calls necessary to determine if the >> process is >> alive (called twice) >> and in the case of exitValue to handle the IllegalStateException. >> >> Some of the overhead could be avoided, by implementing >> toString in each >> of the ProcessImpl.java >> files where the current state is known more conveniently with >> less overhead. >> >> $.02, Roger >> >> >> On 5/8/2016 2:47 PM, Andrey Dyachkov wrote: >> > Hello, >> > >> > I have added toString() method in Process.java. >> > >> > diff --git a/src/java.base/share/classes/java/lang/Process.java >> > b/src/java.base/share/classes/java/lang/Process.java >> > --- a/src/java.base/share/classes/java/lang/Process.java >> > +++ b/src/java.base/share/classes/java/lang/Process.java >> > @@ -548,5 +548,16 @@ >> > return toHandle().descendants(); >> > } >> > >> > + @Override >> > + public String toString() { >> > + boolean isAlive = this.isAlive(); >> > + return new >> > StringBuilder(this.getClass().getSimpleName()).append("[") >> > + .append("running=").append(isAlive).append(", ") >> > + .append(isAlive ? "pid=" : >> "exitCode=") >> > + .append(isAlive ? this.getPid() : >> this.exitValue()) >> > + .append("]") >> > + .toString(); >> > + } >> > + >> > >> > } >> >> -- >> >> With great enthusiasm, >> Andrey > > -- > > With great enthusiasm, > Andrey From Roger.Riggs at Oracle.com Fri Aug 5 15:56:54 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 5 Aug 2016 11:56:54 -0400 Subject: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <57A4B4D1.8070803@oracle.com> References: <57A49D36.8060203@oracle.com> <57A4B4D1.8070803@oracle.com> Message-ID: Hi Sean, I agree that the 80% reflects the previous coding and is ok. I don't have enough background on this code to know whether the 80% is now spurious and confusing and could be removed. Roger On 8/5/2016 11:46 AM, Se?n Coffey wrote: > Sorry - cc'ed the wrong Pavel earlier. Corrected. > > I thought the consumer/producer model was best served by delegating to > the BlockingQueue. Is there a need to synchronize as a result ? > > The 80% logic is only implemented in the rare case where the > com.sun.jndi.ldap.search.replyQueueSize ldap context property is set. > It seems to be legacy behaviour from the old code where the reader > thread was paused at 80% capacity. Setting the BlockingQueue to the > same '80%' size should have the same net effect. > > Regards, > Sean. > > On 05/08/16 15:50, Roger Riggs wrote: >> Hi Sean, >> >> Looks like a cleaner solution to synchronize writer and readers. >> >> I don't quite understand the 80% capacity value. It is related to >> the obsolete highWatermark >> but that does not seem relevant with the update. >> >> If the caller is going to specify a replyQueueCapacity then why >> should it be downgraded to 80%? >> >> Roger >> >> >> >> On 8/5/2016 10:05 AM, Se?n Coffey wrote: >>> Hoping to get a review on this issue that's been sitting on my plate >>> for a long while. Pavel drew up the bulk of the edits for this one >>> (Thanks) >>> >>> The fix basically delegates polling and timeout management to the >>> BlockingQueue.poll(timeout.. ) method. As a result it makes >>> Connection readReply logic much easier to handle. >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8139965.9/webrev/ >>> bug report : https://bugs.openjdk.java.net/browse/JDK-8139965 >>> >> > From vincent.x.ryan at oracle.com Fri Aug 5 16:19:57 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 5 Aug 2016 17:19:57 +0100 Subject: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: References: <57A49D36.8060203@oracle.com> <57A4B4D1.8070803@oracle.com> Message-ID: <01B52E08-9CCE-4882-99B5-1648EB3416D4@oracle.com> IIRC pausing the receiver was introduced to prevent an LDAP client (with limited memory) from being overwhelmed by server results and having no opportunity to transmit an abandon request. The 80% value was chosen to balance maximising queue capacity against the risk of an OOME. If that behaviour is maintained via a BlockingQueue then all is well. > On 5 Aug 2016, at 16:56, Roger Riggs wrote: > > Hi Sean, > > I agree that the 80% reflects the previous coding and is ok. > > I don't have enough background on this code to know whether the 80% is now spurious and confusing and could be removed. > > Roger > > > On 8/5/2016 11:46 AM, Se?n Coffey wrote: >> Sorry - cc'ed the wrong Pavel earlier. Corrected. >> >> I thought the consumer/producer model was best served by delegating to the BlockingQueue. Is there a need to synchronize as a result ? >> >> The 80% logic is only implemented in the rare case where the com.sun.jndi.ldap.search.replyQueueSize ldap context property is set. It seems to be legacy behaviour from the old code where the reader thread was paused at 80% capacity. Setting the BlockingQueue to the same '80%' size should have the same net effect. >> >> Regards, >> Sean. >> >> On 05/08/16 15:50, Roger Riggs wrote: >>> Hi Sean, >>> >>> Looks like a cleaner solution to synchronize writer and readers. >>> >>> I don't quite understand the 80% capacity value. It is related to the obsolete highWatermark >>> but that does not seem relevant with the update. >>> >>> If the caller is going to specify a replyQueueCapacity then why should it be downgraded to 80%? >>> >>> Roger >>> >>> >>> >>> On 8/5/2016 10:05 AM, Se?n Coffey wrote: >>>> Hoping to get a review on this issue that's been sitting on my plate for a long while. Pavel drew up the bulk of the edits for this one (Thanks) >>>> >>>> The fix basically delegates polling and timeout management to the BlockingQueue.poll(timeout.. ) method. As a result it makes Connection readReply logic much easier to handle. >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8139965.9/webrev/ >>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8139965 >>>> >>> >> > From greggwon at cox.net Fri Aug 5 05:05:51 2016 From: greggwon at cox.net (Gregg Wonderly) Date: Fri, 5 Aug 2016 00:05:51 -0500 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> Message-ID: <4A036D1B-B6FA-48D3-B245-AE985D6F9D24@cox.net> Sent from my iPad > On Aug 4, 2016, at 11:18 PM, Alan Bateman wrote: > >> On 04/08/2016 10:33, Patrick Reinhart wrote: >> >> Hi Paul, >> >> I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) >> >> On 15.07.2016 17:10, Paul Sandoz wrote: >>>> When I understand you correctly here we should concentrate on the public >>>> methods naming firstly? I initially was not sure, what a proper naming >>>> for the steams method was. It seem to me reasonable the way Stuart pointed >>>> them out on his first comment to name them something like this: >>>> >>>> Stream resources(String name) >>>> Stream systemResources(String name) >>>> >>>> >>>> Yes. >> I have a first proposal for the new methods and their documentation to start with the discussion about the actual API without the implementation jet: > The method names look right but I don't think `throws IOException` is needed. If overridden then the implementations could be truely lazy and the method will need to specify how stream operations will wrap the errors in UncheckedIOExceptions. > > For the initial sentence then it might be better to say that it "Returns a stream that loads the resources ...". I think that the use of the Stream should throw checked exceptions and these method invocations should only throw RuntimeException instances to make it clear that lazy implementations are expected. Gregg From huizhe.wang at oracle.com Fri Aug 5 17:59:01 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 05 Aug 2016 10:59:01 -0700 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <024101d1ef1d$0d138c50$273aa4f0$@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> <57A291D3.5060301@oracle.com> <016a01d1ee37$c47be180$4d73a480$@oracle.com> <024101d1ef1d$0d138c50$273aa4f0$@oracle.com> Message-ID: <57A4D3E5.7030107@oracle.com> Hi Frank, Looks good overall. Thanks for adding runs with/without SM, that's a lot of tedious work! I wish there's a way to do this in a general configuration. But it's fine since it does serve the purpose. Thanks, Joe On 8/5/16, 6:26 AM, Frank Yuan wrote: > Hi Joe and Daniel > > Please review the update: http://cr.openjdk.java.net/~fyuan/8067170/webrev.04/ > In this version, I > 1. made all tests run twice, to pass in the different argument to the jtreg TestNG test, it has to run in othervm(jaxp test also run > in othervm before this but it's possible to run in agentvm), however, I didn't delete the code supporting agentvm from > JAXPPolicyManager.java because jtreg may provide more support in agentvm mode someday:) > 2. enabled sm in unittest/catalog/CatalogTest.java as jdk-8161176's conclusion > 3. fixed the bug in runWithTmpPermission methods, Daniel mentioned it but I didn't understand at that time :P > > Thanks > Frank > >> -----Original Message----- >> From: Frank Yuan [mailto:frank.yuan at oracle.com] >> Sent: Thursday, August 04, 2016 6:06 PM >> To: 'Joe Wang'; 'Daniel Fuchs' >> Cc: 'core-libs-dev' >> Subject: RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests >> >> >> >>> -----Original Message----- >>> From: Joe Wang [mailto:huizhe.wang at oracle.com] >>> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP >> unit tests >>> >>> >>> On 8/3/16, 3:45 AM, Daniel Fuchs wrote: >>>> Hi Frank, >>>> >>>> I looked at the diffs of the diffs between webrev.02 and webrev.03 and >>>> it looks good to me. >>>> >>>> +1 - provided all tests pass :-) >>> +1, thanks for re-enabling the tests that had dependencies on 8162848. I >>> also closed 8162848. >>> >>>> But I have the same question than Joe: aren't all the test supposed >>>> to run twice: once with security manager and once without? >>>> (except for those test that might explicitly require a security >> manager) >>> I agree, all of the tests need to run with and without security manager. >>> It would be good to combine the runWithSecurityManager and >>> runWithoutSecurityManager methods into one with a condition that >>> determines whether a security manager is present. >>> >> Alright, I will make the tests run twice. To impl this, I have to add >> jtreg tags like the following: >> /* >> * @test >> * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest >> * @run testng/othervm -DrunSecMngr=true common.Bug6350682 >> * @run testng/othervm common.Bug6350682 >> */ >> >> And modify the Policy class accordingly. I am writing a small program to >> update the tests, will send the new version tomorrow... >> >> Frank >> >> >>> Best, >>> Joe >>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 03/08/16 11:12, Frank Yuan wrote: >>>>> Hi Joe >>>>> >>>>> Thank you for your review! >>>>> >>>>> I updated the tests according to the latest comments as well as had >>>>> unittest/transform/TransformerTest.java up to date, please check >>>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ >>>>> >>>>> >>>>> Thanks >>>>> Frank >>>>> >>>>> -----Original Message----- >>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com] >>>>> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP >>>>> unit tests >>>>> >>>>> >>>>> >>>>> On 8/2/16, 5:30 AM, Daniel Fuchs wrote: >>>>>> Hi Frank, >>>>>> >>>>>> I am intrigued by these change which do not seem >>>>>> to have anything to do with the rest. I mean, I'm not opposed >>>>>> as long as they are intended and that Joe validates them: >>>>>> ======================================================== >>>>>> >>>>>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu >> nctional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram >>>>> es.html >>>>>> >>>>>> 118 spf.setNamespaceAware(false); >>>>> Not sure why this was changed. >>>>>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu >> nctional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra >>>>> mes.html >>>>> The test itself wasn't very clear on the content it tests. If it only >>>>> verifies whether a resolver is used as is said, then this and related >>>>> changes in ResolverTest and publish.xml are fine. To the extent it >>>>> verifies, it didn't have to output to a file. >>>>>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu >> nctional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h >>>>> tml >>>>> We have to let Frank explain why namespace was turned off for these >>>>> tests :-) In this case, XMLReaderNSTableTest. In general, I would >> say >>>>> enabling security shouldn't change tests or gold files in this case. >>>>> >>>>>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu >> nctional/org/xml/sax/xmlfiles/publish.xml.frames.html >>>>>> >>>>>> This looks like a desirable change - but what does it have to do >>>>>> with enabling security manager? >>>>> Probably to remove the reference to that particular server? Seems to >> be >>>>> fine as a cleanup. Again, it (the original test) only verifies a >> resolve >>>>> is used, it didn't even need to write out a file to prove that. >>>>>> Also: >>>>>> ======================================================== >>>>>> >>>>>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/un >> ittest/transform/XSLTFunctionsTest.java.frames.html >>>>>> >>>>>> >>>>>> 70 >>>>>> >> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFu >> nctions", >>>>>> true); >>>>>> >>>>>> Is this needed only when there is a security manager? >>>>> Yes, when Security Manager is present, this feature is turned off by >>>>> default. >>>>>> ======================================================== >>>>>> >>>>>> >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/li >> bs/jaxp/library/JAXPPolicyManager.java.html >>>>>> >>>>>> >>>>>> >>>>>> 119 /* >>>>>> 120 addPermission(new RuntimePermission("getClassLoader")); >>>>>> 121 addPermission(new >> RuntimePermission("createClassLoader")); >>>>>> 122 addPermission(new >>>>>> RuntimePermission("createSecurityManager")); >>>>>> 123 addPermission(new RuntimePermission("modifyThread")); >>>>>> 124 addPermission(new PropertyPermission("*", >> "read,write")); >>>>>> 125 >>>>>> 126 addPermission(new RuntimePermission("setIO")); >>>>>> 127 addPermission(new >>>>>> RuntimePermission("setContextClassLoader")); >>>>>> 128 addPermission(new >>>>>> RuntimePermission("accessDeclaredMembers"));*/ >>>>>> >>>>>> >>>>>> Please remove before pushing. >>>>>> >>>>>> >>>>>> ======================================================== >>>>>> >>>>>> >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml >>>>>> >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl >>>>>> It seems these two files have been removed, but shouldn't they have >>>>>> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform >>>>>> instead? >>>>>> I see they are used by >>>>>> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java >>>>>> >>>>>> Did you forget to hg add them? >>>>>> >>>>>> ======================================================== >>>>>> >>>>>> >>>>>> Otherwise the new JAXPPolicyManager& its Policy implementation >>>>>> look good. This is much simpler and better than the first >>>>>> iteration :-) >>>>>> >>>>>> This was a *very* long patch - so congratulations for seeing >>>>>> this through! >>>>> Very long patch, indeed! Thanks for the great effort! Very well done >>>>> with the unified Policy/Permission management. >>>>> >>>>> Best, >>>>> Joe >>>>> >>>>>> cheers, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> >>>>>> On 02/08/16 11:20, Frank Yuan wrote: >>>>>>> Hi Joe and Daniel >>>>>>> >>>>>>> I have finished the rework as your comments, please check >>>>>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ >>>>>>> >>>>>>> JAXP tests use Policy classes, as well as 3 other patterns provided >>>>>>> by JAXPTestUtilities: >>>>>>> 1. runWithAllPerm methods, are only used for user setup code, never >>>>>>> run jaxp code with them. >>>>>>> 2. tryRunWithPolicyManager method, is used to run some test methods >>>>>>> with security manager and run the others without security >>>>>>> manager in single test class >>>>>>> 3. runWithTmpPermission methods, which may run jaxp code with some >>>>>>> limited permissions, those permissions belong to user permissions >>>>>>> and jaxp code won't doPrivileged for them. E.g. >>>>>>> PropertyPermission("MyInputFactory", "read") or >>>>>>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") >>>>>>> >>>>>>> >>>>>>> Btw, some tests or test methods are disabled or commented sm >> support >>>>>>> temporarily for some known jaxp security bugs. >>>>>>> >>>>>>> Thanks >>>>>>> Frank >>>>>>> From claes.redestad at oracle.com Fri Aug 5 19:36:49 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 5 Aug 2016 12:36:49 -0700 Subject: RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors In-Reply-To: <578E7CAE.6070705@oracle.com> References: <578E7CAE.6070705@oracle.com> Message-ID: <57A4EAD1.1020208@oracle.com> Withdrawing this as clearing exceptions actually doesn't seem to get rid of overhead(!), making this change moot. The overhead for my use case is small but annoying. Sorry for the noise. /Claes On 07/19/2016 12:17 PM, Claes Redestad wrote: > Hi, > > please review this bug fix to ensure MemberName::resolveOrNull doesn't > throw exceptions when speculatively looking up members that aren't > there. > > HS: http://cr.openjdk.java.net/~redestad/8161588/hs.01 > JDK: http://cr.openjdk.java.net/~redestad/8161588/jdk.01 > > This avoids throwing NoSuchMethodError etc just to be ignored, avoiding > a performance penalty when looking things up speculatively (which is key > to possible upcoming work to generate more JLI code with jlink). > > There's a pre-existing issue not dealt with by this fix in that the > exceptions thrown in MHN_resolve_Mem are never observed, instead the > exceptions thrown from various LinkResolver methods are observed. We > could clear all pending exceptions in resolve_MemberName, but this > breaks tests that are very particular about which exception is thrown > when and where, thus I opted to add the clear_pending boolean to > allow clearing the exception conditionally instead, keeping behavior > identical for MemberName::resolveOrFail > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Aug 5 19:37:34 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 5 Aug 2016 12:37:34 -0700 Subject: RFR: 8161379: Force inline methods calling Reflection.getCallerClass In-Reply-To: <578E4431.7060603@oracle.com> References: <578E4431.7060603@oracle.com> Message-ID: <57A4EAFE.1020404@oracle.com> Anyone? On 07/19/2016 08:16 AM, Claes Redestad wrote: > Hi, > > most @CallerSensitive methodscall Reflection.getCallerClass(), which > turn out to have problematic performance characteristics when it fails > to inline. > > Making @CallerSensitive imply @ForceInline actually works rather well > across benchmarks, but didn't meet with approval from hotspot-compiler > because it's a hack (unlike @ForceInline /s). > > Instead, here is a patch to explicitly @ForceInline those methods where > it can plausibly be helping with performance: > > Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8161379 > > Thanks! > > /Claes > From aleksey.shipilev at gmail.com Fri Aug 5 19:56:55 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 5 Aug 2016 22:56:55 +0300 Subject: RFR: 8161379: Force inline methods calling Reflection.getCallerClass In-Reply-To: <57A4EAFE.1020404@oracle.com> References: <578E4431.7060603@oracle.com> <57A4EAFE.1020404@oracle.com> Message-ID: <1c1f4f19-1f57-8ef4-e32f-3fcb5cc9cf78@gmail.com> This looks good to me, Claes. I wouldn't mind to have a comment at @ForceInline line mentioning this is for Reflection.getCallerClass() optimization. But, it might be recoverable from the source control anyway. Thanks, -Aleksey On 08/05/2016 10:37 PM, Claes Redestad wrote: > Anyone? > > On 07/19/2016 08:16 AM, Claes Redestad wrote: >> Hi, >> >> most @CallerSensitive methodscall Reflection.getCallerClass(), which >> turn out to have problematic performance characteristics when it fails >> to inline. >> >> Making @CallerSensitive imply @ForceInline actually works rather well >> across benchmarks, but didn't meet with approval from hotspot-compiler >> because it's a hack (unlike @ForceInline /s). >> >> Instead, here is a patch to explicitly @ForceInline those methods where >> it can plausibly be helping with performance: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8161379 >> >> Thanks! >> >> /Claes >> > From claes.redestad at oracle.com Fri Aug 5 20:22:36 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 5 Aug 2016 13:22:36 -0700 Subject: RFR: 8161379: Force inline methods calling Reflection.getCallerClass In-Reply-To: <1c1f4f19-1f57-8ef4-e32f-3fcb5cc9cf78@gmail.com> References: <578E4431.7060603@oracle.com> <57A4EAFE.1020404@oracle.com> <1c1f4f19-1f57-8ef4-e32f-3fcb5cc9cf78@gmail.com> Message-ID: <57A4F58C.6020602@oracle.com> On 08/05/2016 12:56 PM, Aleksey Shipilev wrote: > This looks good to me, Claes. Thanks! > > I wouldn't mind to have a comment at @ForceInline line mentioning this > is for Reflection.getCallerClass() optimization. But, it might be > recoverable from the source control anyway. Sure, how about: @ForceInline // to ensure Reflection.getCallerClass optimization http://cr.openjdk.java.net/~redestad/8161379/jdk.02/ While source control history helps, I think it's alright with some additional verbiage here in case someone figures out a way to implement any of these without Reflection.getCallerClass (since we ideally don't want to @ForceInline in too many places) /Claes > > Thanks, > -Aleksey > > On 08/05/2016 10:37 PM, Claes Redestad wrote: >> Anyone? >> >> On 07/19/2016 08:16 AM, Claes Redestad wrote: >>> Hi, >>> >>> most @CallerSensitive methodscall Reflection.getCallerClass(), which >>> turn out to have problematic performance characteristics when it fails >>> to inline. >>> >>> Making @CallerSensitive imply @ForceInline actually works rather well >>> across benchmarks, but didn't meet with approval from hotspot-compiler >>> because it's a hack (unlike @ForceInline /s). >>> >>> Instead, here is a patch to explicitly @ForceInline those methods where >>> it can plausibly be helping with performance: >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161379 >>> >>> Thanks! >>> >>> /Claes >>> > From aleksey.shipilev at gmail.com Fri Aug 5 20:29:01 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 5 Aug 2016 23:29:01 +0300 Subject: RFR: 8161379: Force inline methods calling Reflection.getCallerClass In-Reply-To: <57A4F58C.6020602@oracle.com> References: <578E4431.7060603@oracle.com> <57A4EAFE.1020404@oracle.com> <1c1f4f19-1f57-8ef4-e32f-3fcb5cc9cf78@gmail.com> <57A4F58C.6020602@oracle.com> Message-ID: <57c7195c-9261-579c-e223-0313c5f3d1d7@gmail.com> On 08/05/2016 11:22 PM, Claes Redestad wrote: > On 08/05/2016 12:56 PM, Aleksey Shipilev wrote: >> I wouldn't mind to have a comment at @ForceInline line mentioning this >> is for Reflection.getCallerClass() optimization. But, it might be >> recoverable from the source control anyway. > > Sure, how about: > > @ForceInline // to ensure Reflection.getCallerClass optimization > > http://cr.openjdk.java.net/~redestad/8161379/jdk.02/ +1 -Aleksey From mandy.chung at oracle.com Fri Aug 5 21:55:59 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Aug 2016 14:55:59 -0700 Subject: RFR: 8161379: Force inline methods calling Reflection.getCallerClass In-Reply-To: <57A4F58C.6020602@oracle.com> References: <578E4431.7060603@oracle.com> <57A4EAFE.1020404@oracle.com> <1c1f4f19-1f57-8ef4-e32f-3fcb5cc9cf78@gmail.com> <57A4F58C.6020602@oracle.com> Message-ID: <67A789B2-3AE6-4C77-9C79-AEEFB3B993F1@oracle.com> > On Aug 5, 2016, at 1:22 PM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8161379/jdk.02/ > Looks fine. How much improvement do you see from the benchmark run with this patch? Mandy From claes.redestad at oracle.com Fri Aug 5 22:00:29 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 05 Aug 2016 15:00:29 -0700 Subject: RFR: 8161379: Force inline methods calling Reflection.getCallerClass In-Reply-To: <67A789B2-3AE6-4C77-9C79-AEEFB3B993F1@oracle.com> References: <578E4431.7060603@oracle.com> <57A4EAFE.1020404@oracle.com> <1c1f4f19-1f57-8ef4-e32f-3fcb5cc9cf78@gmail.com> <57A4F58C.6020602@oracle.com> <67A789B2-3AE6-4C77-9C79-AEEFB3B993F1@oracle.com> Message-ID: <9DF11B27-BE55-41E2-911B-C041B4658937@oracle.com> Thanks! Up to 12-15x on some reflection micros, but it varies wildly. This change does not improve the best case performance, but rather eliminates a cause for degradation and high run to run variance. /Claes Mandy Chung skrev: (5 augusti 2016 14:55:59 GMT-07:00) > >> On Aug 5, 2016, at 1:22 PM, Claes Redestad > wrote: >> >> http://cr.openjdk.java.net/~redestad/8161379/jdk.02/ >> > >Looks fine. > >How much improvement do you see from the benchmark run with this patch? > >Mandy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From steve.drach at oracle.com Fri Aug 5 23:06:32 2016 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 5 Aug 2016 16:06:32 -0700 Subject: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs Message-ID: <73918ABC-872F-4180-B142-70597A96B008@oracle.com> Hi, Please review this changset that makes jlink multi-release jar aware. issue: https://bugs.openjdk.java.net/browse/JDK-8156499 webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.00/index.html Thanks Steve From cs at schulte.it Sun Aug 7 22:51:01 2016 From: cs at schulte.it (Christian Schulte) Date: Mon, 8 Aug 2016 00:51:01 +0200 Subject: Executors enhancement Message-ID: <57A7BB55.2040003@schulte.it> Hello, whenever I need to update an existing codebase to add some kind of parallelization, I am in the need of an executor matching the number of processors available at runtime. Most of the time I end up using something like: 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' If every library used by an application needs to maintain its' own executors the application ends up with starting number of libraries used times number of available processors threads. That does not scale. I think there really is a need for some kind of default executor provided by the platform. I am suprised I cannot find anything like that anywhere. I would like to request an enhancement providing such a default platform executor everyone can use to add parallelization without ending up with tons of threads when all you want is making use of the system's parallelization capabilities. Regards, -- Christian From claes.redestad at oracle.com Sun Aug 7 23:16:21 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Aug 2016 01:16:21 +0200 Subject: Executors enhancement In-Reply-To: <57A7BB55.2040003@schulte.it> References: <57A7BB55.2040003@schulte.it> Message-ID: <57A7C145.40901@oracle.com> Hi Christian, have you looked at java.util.concurrent.ForkJoinPool.commonPool()? /Claes On 2016-08-08 00:51, Christian Schulte wrote: > Hello, > > whenever I need to update an existing codebase to add some kind of > parallelization, I am in the need of an executor matching the number of > processors available at runtime. Most of the time I end up using > something like: > > 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' > > If every library used by an application needs to maintain its' own > executors the application ends up with starting number of libraries used > times number of available processors threads. That does not scale. I > think there really is a need for some kind of default executor provided > by the platform. I am suprised I cannot find anything like that > anywhere. I would like to request an enhancement providing such a > default platform executor everyone can use to add parallelization > without ending up with tons of threads when all you want is making use > of the system's parallelization capabilities. > > Regards, > From david.holmes at oracle.com Mon Aug 8 00:00:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2016 10:00:06 +1000 Subject: Executors enhancement In-Reply-To: <57A7C145.40901@oracle.com> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> Message-ID: <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> Hi Christian, On 8/08/2016 9:16 AM, Claes Redestad wrote: > Hi Christian, > > have you looked at java.util.concurrent.ForkJoinPool.commonPool()? That isn't quite the same thing as a general shared executor. > /Claes > > On 2016-08-08 00:51, Christian Schulte wrote: >> Hello, >> >> whenever I need to update an existing codebase to add some kind of >> parallelization, I am in the need of an executor matching the number of >> processors available at runtime. Most of the time I end up using >> something like: >> >> 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' >> >> >> If every library used by an application needs to maintain its' own >> executors the application ends up with starting number of libraries used >> times number of available processors threads. That does not scale. I Libraries in general should not be defining how their functionality gets executed. If a "library" is really a subsystem that might utilize/benefit-from parallelization then it should not encapsulate/hide that aspect but make it explicitly part of the initialization API for itself ie it should be able to accept an Executor/ExecutorService to use. Ultimately it is the application that has to try and control these things, so libraries must provide API's to allow for cooperation with their hosting applications. The default FJPool was a special case to support the parallel streams libraries. It is not an ideal solution. My 2c. Cheers, David >> think there really is a need for some kind of default executor provided >> by the platform. I am suprised I cannot find anything like that >> anywhere. I would like to request an enhancement providing such a >> default platform executor everyone can use to add parallelization >> without ending up with tons of threads when all you want is making use >> of the system's parallelization capabilities. >> >> Regards, >> From brian.goetz at oracle.com Mon Aug 8 00:04:13 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 7 Aug 2016 17:04:13 -0700 Subject: Executors enhancement In-Reply-To: <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> Message-ID: David is right about common pool not being a general-purpose executor. However, its intent is slightly broader than ?just for streams?; it is intended as a general-purpose FJ Pool for any library that wants to spew parallel calculations into a shared FJPool and be a good citizen. Creating multiple FJPools without a coordinated global resource management strategy is likely to be suboptimal. If a library wants to offer a customization point where it accepts an FJPool, clients should be encouraged to pass the common pool (and the common pool is a good default) unless there are specific reasons not to. > On Aug 7, 2016, at 5:00 PM, David Holmes wrote: > > Hi Christian, > > On 8/08/2016 9:16 AM, Claes Redestad wrote: >> Hi Christian, >> >> have you looked at java.util.concurrent.ForkJoinPool.commonPool()? > > That isn't quite the same thing as a general shared executor. > >> /Claes >> >> On 2016-08-08 00:51, Christian Schulte wrote: >>> Hello, >>> >>> whenever I need to update an existing codebase to add some kind of >>> parallelization, I am in the need of an executor matching the number of >>> processors available at runtime. Most of the time I end up using >>> something like: >>> >>> 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' >>> >>> >>> If every library used by an application needs to maintain its' own >>> executors the application ends up with starting number of libraries used >>> times number of available processors threads. That does not scale. I > > Libraries in general should not be defining how their functionality gets executed. If a "library" is really a subsystem that might utilize/benefit-from parallelization then it should not encapsulate/hide that aspect but make it explicitly part of the initialization API for itself ie it should be able to accept an Executor/ExecutorService to use. Ultimately it is the application that has to try and control these things, so libraries must provide API's to allow for cooperation with their hosting applications. > > The default FJPool was a special case to support the parallel streams libraries. It is not an ideal solution. > > My 2c. > > Cheers, > David > >>> think there really is a need for some kind of default executor provided >>> by the platform. I am suprised I cannot find anything like that >>> anywhere. I would like to request an enhancement providing such a >>> default platform executor everyone can use to add parallelization >>> without ending up with tons of threads when all you want is making use >>> of the system's parallelization capabilities. >>> >>> Regards, From david.holmes at oracle.com Mon Aug 8 00:11:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2016 10:11:17 +1000 Subject: Executors enhancement In-Reply-To: References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> Message-ID: <6774ef01-d34b-53ba-deba-f55aabe8a39e@oracle.com> On 8/08/2016 10:04 AM, Brian Goetz wrote: > David is right about common pool not being a general-purpose executor. > However, its intent is slightly broader than ?just for streams?; it is > intended as a general-purpose FJ Pool for any library that wants to spew > parallel calculations into a shared FJPool and be a good citizen. > Creating multiple FJPools without a coordinated global resource > management strategy is likely to be suboptimal. > > If a library wants to offer a customization point where it accepts an > FJPool, clients should be encouraged to pass the common pool (and the > common pool is a good default) unless there are specific reasons not to. Good points Brian! I'll also add that being a special kind of Executor FJPool has already hard-wired some of the many configuration/policy choices that an arbitrary Executor may have. The level of configurability makes it hard to define a common shared Executor instance for general-purpose use. Cheers, David >> On Aug 7, 2016, at 5:00 PM, David Holmes > > wrote: >> >> Hi Christian, >> >> On 8/08/2016 9:16 AM, Claes Redestad wrote: >>> Hi Christian, >>> >>> have you looked at java.util.concurrent.ForkJoinPool.commonPool()? >> >> That isn't quite the same thing as a general shared executor. >> >>> /Claes >>> >>> On 2016-08-08 00:51, Christian Schulte wrote: >>>> Hello, >>>> >>>> whenever I need to update an existing codebase to add some kind of >>>> parallelization, I am in the need of an executor matching the number of >>>> processors available at runtime. Most of the time I end up using >>>> something like: >>>> >>>> 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' >>>> >>>> >>>> If every library used by an application needs to maintain its' own >>>> executors the application ends up with starting number of libraries used >>>> times number of available processors threads. That does not scale. I >> >> Libraries in general should not be defining how their functionality >> gets executed. If a "library" is really a subsystem that might >> utilize/benefit-from parallelization then it should not >> encapsulate/hide that aspect but make it explicitly part of the >> initialization API for itself ie it should be able to accept an >> Executor/ExecutorService to use. Ultimately it is the application that >> has to try and control these things, so libraries must provide API's >> to allow for cooperation with their hosting applications. >> >> The default FJPool was a special case to support the parallel streams >> libraries. It is not an ideal solution. >> >> My 2c. >> >> Cheers, >> David >> >>>> think there really is a need for some kind of default executor provided >>>> by the platform. I am suprised I cannot find anything like that >>>> anywhere. I would like to request an enhancement providing such a >>>> default platform executor everyone can use to add parallelization >>>> without ending up with tons of threads when all you want is making use >>>> of the system's parallelization capabilities. >>>> >>>> Regards, > From frank.yuan at oracle.com Mon Aug 8 09:11:09 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Mon, 8 Aug 2016 17:11:09 +0800 Subject: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests In-Reply-To: <57A4D3E5.7030107@oracle.com> References: <022401d1e0d7$54111090$fc3331b0$@oracle.com> <578CA476.7030407@oracle.com> <03a601d1e3e6$92c45a60$b84d0f20$@oracle.com> <040101d1e3f9$9d19a340$d74ce9c0$@oracle.com> <88977a21-e4d1-e792-00db-1debc3162b08@oracle.com> <024a01d1e659$7dcefcd0$796cf670$@oracle.com> <27ea3634-6e47-70e9-4099-69bd86d3d635@oracle.com> <027101d1e6ed$5107d340$f31779c0$@oracle.com> <903949ef-50a5-ccd9-07cd-ebdd65d65fa5@oracle.com> <032801d1e7e9$22162d50$664287f0$@oracle.com> <57991402.1040308@oracle.com> <02ae01d1eca7$8fcd8740$af6895c0$@oracle.com> <9c43ecb3-d26c-7900-e0b2-55e0b916f87f@oracle.com> <57A116F7.3040605@oracle.com> <02bf01d1ed6f$9e959150$dbc0b3f0$@oracle.com> <2204357c-75e2-0fcd-30ee-244e9645d6ac@oracle.com> <57A291D3.5060301@oracle.com> <016a01d1ee37$c47be180$4d73a480$@oracle.com> <024101d1ef1d$0d138c50$273aa4f0$@oracle.com> <57A4D3! E5.7030107@oracle.com> Message-ID: <012001d1f154$d1d96fd0$758c4f70$@oracle.com> Thank you! I pushed the change into jaxp repo. Frank > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Saturday, August 06, 2016 1:59 AM > To: Frank Yuan > Cc: 'Daniel Fuchs'; 'core-libs-dev' > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests > > Hi Frank, > > Looks good overall. Thanks for adding runs with/without SM, that's a lot > of tedious work! I wish there's a way to do this in a general > configuration. But it's fine since it does serve the purpose. > > Thanks, > Joe > > On 8/5/16, 6:26 AM, Frank Yuan wrote: > > Hi Joe and Daniel > > > > Please review the update: http://cr.openjdk.java.net/~fyuan/8067170/webrev.04/ > > In this version, I > > 1. made all tests run twice, to pass in the different argument to the jtreg TestNG test, it has to run in othervm(jaxp test also run > > in othervm before this but it's possible to run in agentvm), however, I didn't delete the code supporting agentvm from > > JAXPPolicyManager.java because jtreg may provide more support in agentvm mode someday:) > > 2. enabled sm in unittest/catalog/CatalogTest.java as jdk-8161176's conclusion > > 3. fixed the bug in runWithTmpPermission methods, Daniel mentioned it but I didn't understand at that time :P > > > > Thanks > > Frank > > > >> -----Original Message----- > >> From: Frank Yuan [mailto:frank.yuan at oracle.com] > >> Sent: Thursday, August 04, 2016 6:06 PM > >> To: 'Joe Wang'; 'Daniel Fuchs' > >> Cc: 'core-libs-dev' > >> Subject: RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests > >> > >> > >> > >>> -----Original Message----- > >>> From: Joe Wang [mailto:huizhe.wang at oracle.com] > >>> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP > >> unit tests > >>> > >>> > >>> On 8/3/16, 3:45 AM, Daniel Fuchs wrote: > >>>> Hi Frank, > >>>> > >>>> I looked at the diffs of the diffs between webrev.02 and webrev.03 and > >>>> it looks good to me. > >>>> > >>>> +1 - provided all tests pass :-) > >>> +1, thanks for re-enabling the tests that had dependencies on 8162848. I > >>> also closed 8162848. > >>> > >>>> But I have the same question than Joe: aren't all the test supposed > >>>> to run twice: once with security manager and once without? > >>>> (except for those test that might explicitly require a security > >> manager) > >>> I agree, all of the tests need to run with and without security manager. > >>> It would be good to combine the runWithSecurityManager and > >>> runWithoutSecurityManager methods into one with a condition that > >>> determines whether a security manager is present. > >>> > >> Alright, I will make the tests run twice. To impl this, I have to add > >> jtreg tags like the following: > >> /* > >> * @test > >> * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest > >> * @run testng/othervm -DrunSecMngr=true common.Bug6350682 > >> * @run testng/othervm common.Bug6350682 > >> */ > >> > >> And modify the Policy class accordingly. I am writing a small program to > >> update the tests, will send the new version tomorrow... > >> > >> Frank > >> > >> > >>> Best, > >>> Joe > >>> > >>>> best regards, > >>>> > >>>> -- daniel > >>>> > >>>> On 03/08/16 11:12, Frank Yuan wrote: > >>>>> Hi Joe > >>>>> > >>>>> Thank you for your review! > >>>>> > >>>>> I updated the tests according to the latest comments as well as had > >>>>> unittest/transform/TransformerTest.java up to date, please check > >>>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ > >>>>> > >>>>> > >>>>> Thanks > >>>>> Frank > >>>>> > >>>>> -----Original Message----- > >>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com] > >>>>> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP > >>>>> unit tests > >>>>> > >>>>> > >>>>> > >>>>> On 8/2/16, 5:30 AM, Daniel Fuchs wrote: > >>>>>> Hi Frank, > >>>>>> > >>>>>> I am intrigued by these change which do not seem > >>>>>> to have anything to do with the rest. I mean, I'm not opposed > >>>>>> as long as they are intended and that Joe validates them: > >>>>>> ======================================================== > >>>>>> > >>>>>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > >> nctional/org/xml/sax/ptests/XMLReaderNSTableTest.java.fram > >>>>> es.html > >>>>>> > >>>>>> 118 spf.setNamespaceAware(false); > >>>>> Not sure why this was changed. > >>>>>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > >> nctional/org/xml/sax/xmlfiles/out/EntityResolverGF.out.fra > >>>>> mes.html > >>>>> The test itself wasn't very clear on the content it tests. If it only > >>>>> verifies whether a resolver is used as is said, then this and related > >>>>> changes in ResolverTest and publish.xml are fine. To the extent it > >>>>> verifies, it didn't have to output to a file. > >>>>>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > >> nctional/org/xml/sax/xmlfiles/out/NSTableFTGF.out.frames.h > >>>>> tml > >>>>> We have to let Frank explain why namespace was turned off for these > >>>>> tests :-) In this case, XMLReaderNSTableTest. In general, I would > >> say > >>>>> enabling security shouldn't change tests or gold files in this case. > >>>>> > >>>>>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/fu > >> nctional/org/xml/sax/xmlfiles/publish.xml.frames.html > >>>>>> > >>>>>> This looks like a desirable change - but what does it have to do > >>>>>> with enabling security manager? > >>>>> Probably to remove the reference to that particular server? Seems to > >> be > >>>>> fine as a cleanup. Again, it (the original test) only verifies a > >> resolve > >>>>> is used, it didn't even need to write out a file to prove that. > >>>>>> Also: > >>>>>> ======================================================== > >>>>>> > >>>>>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/un > >> ittest/transform/XSLTFunctionsTest.java.frames.html > >>>>>> > >>>>>> > >>>>>> 70 > >>>>>> > >> tf.setFeature("http://www.oracle.com/xml/jaxp/properties/enableExtensionFu > >> nctions", > >>>>>> true); > >>>>>> > >>>>>> Is this needed only when there is a security manager? > >>>>> Yes, when Security Manager is present, this feature is turned off by > >>>>> default. > >>>>>> ======================================================== > >>>>>> > >>>>>> > >> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/test/javax/xml/jaxp/li > >> bs/jaxp/library/JAXPPolicyManager.java.html > >>>>>> > >>>>>> > >>>>>> > >>>>>> 119 /* > >>>>>> 120 addPermission(new RuntimePermission("getClassLoader")); > >>>>>> 121 addPermission(new > >> RuntimePermission("createClassLoader")); > >>>>>> 122 addPermission(new > >>>>>> RuntimePermission("createSecurityManager")); > >>>>>> 123 addPermission(new RuntimePermission("modifyThread")); > >>>>>> 124 addPermission(new PropertyPermission("*", > >> "read,write")); > >>>>>> 125 > >>>>>> 126 addPermission(new RuntimePermission("setIO")); > >>>>>> 127 addPermission(new > >>>>>> RuntimePermission("setContextClassLoader")); > >>>>>> 128 addPermission(new > >>>>>> RuntimePermission("accessDeclaredMembers"));*/ > >>>>>> > >>>>>> > >>>>>> Please remove before pushing. > >>>>>> > >>>>>> > >>>>>> ======================================================== > >>>>>> > >>>>>> > >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest-in.xml > >>>>>> > >> test/javax/xml/jaxp/internaltest/javax/xml/transform/cli/tigertest.xsl > >>>>>> It seems these two files have been removed, but shouldn't they have > >>>>>> been moved to test/javax/xml/jaxp/internaltest/javax/xml/transform > >>>>>> instead? > >>>>>> I see they are used by > >>>>>> test/javax/xml/jaxp/internaltest/javax/xml/transform/CLITest.java > >>>>>> > >>>>>> Did you forget to hg add them? > >>>>>> > >>>>>> ======================================================== > >>>>>> > >>>>>> > >>>>>> Otherwise the new JAXPPolicyManager& its Policy implementation > >>>>>> look good. This is much simpler and better than the first > >>>>>> iteration :-) > >>>>>> > >>>>>> This was a *very* long patch - so congratulations for seeing > >>>>>> this through! > >>>>> Very long patch, indeed! Thanks for the great effort! Very well done > >>>>> with the unified Policy/Permission management. > >>>>> > >>>>> Best, > >>>>> Joe > >>>>> > >>>>>> cheers, > >>>>>> > >>>>>> -- daniel > >>>>>> > >>>>>> > >>>>>> On 02/08/16 11:20, Frank Yuan wrote: > >>>>>>> Hi Joe and Daniel > >>>>>>> > >>>>>>> I have finished the rework as your comments, please check > >>>>>>> http://cr.openjdk.java.net/~fyuan/8067170/webrev.02/ > >>>>>>> > >>>>>>> JAXP tests use Policy classes, as well as 3 other patterns provided > >>>>>>> by JAXPTestUtilities: > >>>>>>> 1. runWithAllPerm methods, are only used for user setup code, never > >>>>>>> run jaxp code with them. > >>>>>>> 2. tryRunWithPolicyManager method, is used to run some test methods > >>>>>>> with security manager and run the others without security > >>>>>>> manager in single test class > >>>>>>> 3. runWithTmpPermission methods, which may run jaxp code with some > >>>>>>> limited permissions, those permissions belong to user permissions > >>>>>>> and jaxp code won't doPrivileged for them. E.g. > >>>>>>> PropertyPermission("MyInputFactory", "read") or > >>>>>>> FilePermission("/tmp/this/does/not/exist/but/that/is/ok", "read") > >>>>>>> > >>>>>>> > >>>>>>> Btw, some tests or test methods are disabled or commented sm > >> support > >>>>>>> temporarily for some known jaxp security bugs. > >>>>>>> > >>>>>>> Thanks > >>>>>>> Frank > >>>>>>> From claes.redestad at oracle.com Mon Aug 8 11:46:23 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Aug 2016 13:46:23 +0200 Subject: RFR: 8163369: Enable generating DMH classes at link time Message-ID: <57A8710F.6070806@oracle.com> Hi, please review this change to add the ability to generate DirectMethodHandles to the --generate-jli-classes jlink plugin. The implementation generates all the specified DMHs as methods into a single class, java.lang.invoke.DirectMethodHandle$DMH. At runtime when a DMH's LF is set up, we speculatively resolve the member from this class instead of generating and loading the bytecode as a distinct anonymous class. This avoids loading a potentially large number of anonymous classes at runtime, and also enables other startup optimizations such as allowing CDS to see and dump this class to the shared archive. webrev: http://cr.openjdk.java.net/~redestad/8163369/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8163369 This is a sub-task of https://bugs.openjdk.java.net/browse/JDK-8086045, which captures more information about the ongoing effort to reduce j.l.invoke initialization overheads. Thanks! /Claes From per.liden at oracle.com Mon Aug 8 12:16:11 2016 From: per.liden at oracle.com (Per Liden) Date: Mon, 8 Aug 2016 14:16:11 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> Hi Kim, On 2016-08-01 20:47, Kim Barrett wrote: > This updated webrev addresses concerns about the performance of the VM > API used by the reference processor thread in the original webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ Overall I think you managed to hit a good balance here, keeping the VM API straight forward without loosing flexibility. Having the ReferenceHandler doing the actual work seems sound and avoids some complexity, which I like. I have one suggestion though, regarding CheckReferencePendingList(). While reviewing I found that I had to check several times what its return value actually meant, the "check" part of the name doesn't quite reveal that. Further, it seems to me that the waiting path of this function has fairly little in common with the non-waiting path, e.g. it always returns true. So, to make both the naming and implementation more clear I'd like to suggest that we split this into two separate functions, HasReferencePendingList() and WaitForReferencePendingList(), like this: JVM_ENTRY(jboolean, JVM_HasReferencePendingList(JNIEnv* env)) JVMWrapper("JVM_HasReferencePendingList"); MonitorLockerEx ml(Heap_lock); return Universe::has_reference_pending_list(); JVM_END JVM_ENTRY(void, JVM_WaitForReferencePendingList(JNIEnv* env)) JVMWrapper("JVM_WaitForReferencePendingList"); MonitorLockerEx ml(Heap_lock); while (!Universe::has_reference_pending_list()) { ml.wait(); } JVM_END And of course, this would then also be reflected in j.l.r.Reference, which would have: private static native boolean hasReferencePendingList(); private static native void waitForReferencePendingList(); Other than this I think the patch looks good. > > The originally offered approach was an attempt to minimize changes. I > was trying to be as similar to the existing code as possible, while > moving part of it into the VM, where we have the necessary control > over suspension and the like. We already know we want to make changes > in this area, in order to eliminate the use of > jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that > JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we > should revisit that. Is JDK-8149925 the correct bug id? Looks like that bug has already been fixed in 9. cheers, Per > > As Peter pointed out, my original change introduces a small > performance regression on a microbenchmark for reference processing > throughput. It also showed a small performance benefit on a different > microbenchmark (allocation rate for a stress test of direct byte > buffers), as noted in the original RFR. I can reproduce both of > those. > > I think reference processing thread throughput is the right measure to > use, so long as others don't become horrible. Focusing on that, it's > better to just let the reference processing thread do the processing, > rather than slowing it down to allow for the rare case when there's > another thread that could possibly help. This is especially true now > that Cleaner has such limited usage. > > This leads to a different API for other threads; rather than > tryHandlePending that other threads can call to help and to examine > progress, we now have waitForReferenceProcessing. The VM API is also > different; rather than popReferencePendingList to get or wait, we now > have getAndClearReferencePendingList and checkReferencePendingList, > the latter with an optional wait. > > The splitting of the VM API allows us to avoid a narrow race condition > discussed by Peter in his prototypes. Peter suggested this race was > ok because java.nio.Bits makes several retries. However, those > retries are only done before throwing OOME. There are no retries > before invoking GC, so this race could lead to unnecessary successive > GCs. > > Doing all the processing on the reference processing thread eliminates > execution of Cleaners on application threads, though that's not nearly > as much an issue now that the use of Cleaner is so restricted. > > We've also eliminated a pre-existing issue where a helper could report > no progress even though the reference processing thread (and other > helpers) had removed a pending reference, but not yet processed it. > This could result in the non-progressing helper invoking GC or > reporting failure, even though it might have succeeded if it had > waited for the other thread(s) to complete processing the reference(s) > being worked on. > > I think the new waitForReferenceProcessing could be used to fix > JDK-6306116, though that isn't part of this change, and was not really > a motivating factor. > > I don't know if the new waitForReferenceProcessing will be used by > whatever we eventually do for JDK-8149925, but I think the new VM API > will suffice for that. That is, I think JDK-8149925 might require > changes to the core-libs API used by nio.Bits, and won't require > further VM API changes. > > > From aleksey.shipilev at gmail.com Mon Aug 8 12:28:46 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Mon, 8 Aug 2016 15:28:46 +0300 Subject: RFR: 8163369: Enable generating DMH classes at link time In-Reply-To: <57A8710F.6070806@oracle.com> References: <57A8710F.6070806@oracle.com> Message-ID: <3b521714-6369-d847-86f3-9409e5147518@gmail.com> On 08/08/2016 02:46 PM, Claes Redestad wrote: > Hi, > > please review this change to add the ability to generate > DirectMethodHandles to the --generate-jli-classes jlink plugin. > > The implementation generates all the specified DMHs as methods into a > single class, java.lang.invoke.DirectMethodHandle$DMH. At runtime when a > DMH's LF is set up, we speculatively resolve the member from this class > instead of generating and loading the bytecode as a distinct anonymous > class. This avoids loading a potentially large number of anonymous > classes at runtime, and also enables other startup optimizations such as > allowing CDS to see and dump this class to the shared archive. > > webrev: http://cr.openjdk.java.net/~redestad/8163369/webrev.01/ DirectMethodHandle: * DMH placeholder class might better be called DirectMethodHandle.Holder, or something else that clearly spells out the intent? InvokerBytecodeGenerator: * Both generateNamedFunctionInvokerImpl() and generateLambdaFormInterpreterEntryPointBytes() have methodEpilog() call, but no methodPrologue()? classFilePrologue() used to do the prologue. GenerateJLIClassesPlugin: * Do we actually need this block in this form? // DirectMethodHandles // Enable by default boolean dmhEnabled = true; if (mainArgument != null) { Set args = Arrays.stream(mainArgument.split(",")) .collect(Collectors.toSet()); if (!args.contains(DMH_PARAM)) { dmhEnabled = false; } } seems equivalent to a simpler: boolean dmhEnabled = true; if (mainArgument != null) { List args = Arrays.asList(mainArgument.split(",")); if (!args.contains(DMH_PARAM)) { dmhEnabled = false; } } You can even split the mainArgument once and reuse throughout configure()? * This block does not check the first argument as the comment suggests, only checks the second group: String[] typeParts = type.split("_"); if (typeParts.length != 2 || typeParts[1].length() != 1 || "LJIFDV".indexOf(typeParts[1].charAt(0)) == -1) { throw new PluginException( "Method type signature must be of form [LJIFD]*_[LJIFDV]"); } * primitiveType('Z') would throw a misleading "Not a primitive: Z" * This can iterate over values only: for (Map.Entry> entry : dmhMethods.entrySet()) { count += entry.getValue().size(); } * I don't know the module visibility rules between jlink and java.base, but can we reference DirectMethodHandle.DMH class as literal from the plugin? * requireBasicType(last) is loop invariant here: for (int j = 1; j < count; j++) { requireBasicType(last); sb.append(last); } Thanks, -Aleksey From claes.redestad at oracle.com Mon Aug 8 13:18:16 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Aug 2016 15:18:16 +0200 Subject: RFR: 8163369: Enable generating DMH classes at link time In-Reply-To: <3b521714-6369-d847-86f3-9409e5147518@gmail.com> References: <57A8710F.6070806@oracle.com> <3b521714-6369-d847-86f3-9409e5147518@gmail.com> Message-ID: <57A88698.3020604@oracle.com> On 2016-08-08 14:28, Aleksey Shipilev wrote: > On 08/08/2016 02:46 PM, Claes Redestad wrote: >> Hi, >> >> please review this change to add the ability to generate >> DirectMethodHandles to the --generate-jli-classes jlink plugin. >> >> The implementation generates all the specified DMHs as methods into a >> single class, java.lang.invoke.DirectMethodHandle$DMH. At runtime when a >> DMH's LF is set up, we speculatively resolve the member from this class >> instead of generating and loading the bytecode as a distinct anonymous >> class. This avoids loading a potentially large number of anonymous >> classes at runtime, and also enables other startup optimizations such as >> allowing CDS to see and dump this class to the shared archive. >> >> webrev: http://cr.openjdk.java.net/~redestad/8163369/webrev.01/ > DirectMethodHandle: > > * DMH placeholder class might better be called > DirectMethodHandle.Holder, or something else that clearly spells out the > intent? Sure. > > InvokerBytecodeGenerator: > > * Both generateNamedFunctionInvokerImpl() and > generateLambdaFormInterpreterEntryPointBytes() have methodEpilog() call, > but no methodPrologue()? classFilePrologue() used to do the prologue. Nice catch, there was even 2 failed tests I had missed due to this. > > GenerateJLIClassesPlugin: > > * Do we actually need this block in this form? > > // DirectMethodHandles > // Enable by default > boolean dmhEnabled = true; > if (mainArgument != null) { > Set args = Arrays.stream(mainArgument.split(",")) > .collect(Collectors.toSet()); > if (!args.contains(DMH_PARAM)) { > dmhEnabled = false; > } > } > > seems equivalent to a simpler: > > boolean dmhEnabled = true; > if (mainArgument != null) { > List args = Arrays.asList(mainArgument.split(",")); > if (!args.contains(DMH_PARAM)) { > dmhEnabled = false; > } > } > > You can even split the mainArgument once and reuse throughout configure()? Fixed. > > * This block does not check the first argument as the comment suggests, > only checks the second group: > > String[] typeParts = type.split("_"); > if (typeParts.length != 2 || typeParts[1].length() != 1 > || "LJIFDV".indexOf(typeParts[1].charAt(0)) == -1) { > throw new PluginException( > "Method type signature must be of form [LJIFD]*_[LJIFDV]"); > } I'm checking the return type here (the char after _ in "LL_L") and then checking the first part inside expandSignature. Clarified the intent with comments. > > * primitiveType('Z') would throw a misleading "Not a primitive: Z" Yes, added special casing for sub-int primitives (B, S, Z, C) to indicate that 'I' should be used instead. > > * This can iterate over values only: > > for (Map.Entry> entry : dmhMethods.entrySet()) { > count += entry.getValue().size(); > } Sure. > > * I don't know the module visibility rules between jlink and java.base, > but can we reference DirectMethodHandle.DMH class as literal from the > plugin? No, while java.lang.invoke is exported, DirectMethodHandle is package-private which prohibits static visibility from the plugin. > > * requireBasicType(last) is loop invariant here: > > for (int j = 1; j < count; j++) { > requireBasicType(last); > sb.append(last); > } Sure. http://cr.openjdk.java.net/~redestad/8163369/webrev.02/ /Claes > > Thanks, > -Aleksey > From aleksey.shipilev at gmail.com Mon Aug 8 13:50:41 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Mon, 8 Aug 2016 16:50:41 +0300 Subject: RFR: 8163369: Enable generating DMH classes at link time In-Reply-To: <57A88698.3020604@oracle.com> References: <57A8710F.6070806@oracle.com> <3b521714-6369-d847-86f3-9409e5147518@gmail.com> <57A88698.3020604@oracle.com> Message-ID: On 08/08/2016 04:18 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8163369/webrev.02/ Looks good. -Aleksey From pbenedict at apache.org Mon Aug 8 15:51:06 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 8 Aug 2016 10:51:06 -0500 Subject: RFE to re-purpose option --version: Message-ID: Dear Committers, In Java 9, the --version: has been deprecated. The error message returned to me is: Error: Specifying an alternate JDK/JRE version is no longer supported. The use of the flag '-version:' is no longer valid. Please download and execute the appropriate version. Unrecognized option: -version:9 I am happy with that. This is not a complain on removing that "alternate" feature. However, I would like to propose bringing back the option with a different purpose. I would like to use --version: as a validation check. I want Java to execute ONLY if the version specified matches the actual platform version. This would be a wonderful help to scripts that require a particular version of the Java platform, and should fail if the environment has been accidentally setup with the wrong Java platform version. Examples: java --version:9 java --version:9.1 AFAICT, the only way to do this now is to execute Java twice. Once to pipe --version to some find/grep command and check return code, and then execute java again if the check pass. Loading the runtime twice is not optimal, wouldn't you agree? Yet if you agree to this proposal, it would be a big win for script writers, I believe. Opinions please. Thank you. Cheers, Paul From patrick at reini.net Mon Aug 8 16:29:34 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 8 Aug 2016 18:29:34 +0200 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> Message-ID: On 05.08.2016 06:18, Alan Bateman wrote: > On 04/08/2016 10:33, Patrick Reinhart wrote: > >> I was quit busy lately and this comes a bit late, I guess you do not >> have less work ;-) >> >> On 15.07.2016 17:10, Paul Sandoz wrote: >>>> When I understand you correctly here we should concentrate on the >>>> public >>>> methods naming firstly? I initially was not sure, what a proper naming >>>> for the steams method was. It seem to me reasonable the way Stuart >>>> pointed >>>> them out on his first comment to name them something like this: >>>> >>>> Stream resources(String name) >>>> Stream systemResources(String name) >>>> >>>> >>>> Yes. >> I have a first proposal for the new methods and their documentation >> to start with the discussion about the actual API without the >> implementation jet: > The method names look right but I don't think `throws IOException` is > needed. If overridden then the implementations could be truely lazy > and the method will need to specify how stream operations will wrap > the errors in UncheckedIOExceptions. > > For the initial sentence then it might be better to say that it > "Returns a stream that loads the resources ...". > > As I was mentioned previously, we will be replacing the javadoc for > the existing methods and this will impact the wording for the new > methods. It's okay to align the wording for the new methods with the > old and we'll adjust once there is agreement on the proposal in JSR > 376 and we bring the changes to JDK 9. > > -Alan I tried to integrate your suggested changes here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.01 Patrick From lordpixel at mac.com Mon Aug 8 00:37:07 2016 From: lordpixel at mac.com (Andrew Thompson) Date: Sun, 07 Aug 2016 17:37:07 -0700 Subject: Executors enhancement In-Reply-To: <57A7BB55.2040003@schulte.it> References: <57A7BB55.2040003@schulte.it> Message-ID: <52A294A9-AC2B-40F2-B32F-80E35BE8BFF8@mac.com> Christian, A number of years ago I put together two small libraries to provide access to Apple's Grand Central Dispatch from Java. My thought was precisely to play nicely with the host operating system, power management etc. I've often thought something similar to fork-join's common pool that each platform implements with the best native alternative would be a good platform addition, but I've not developed the idea any further. http://pixel.recoil.org/code/rococoa/ Andrew > On Aug 7, 2016, at 3:51 PM, Christian Schulte wrote: > > Hello, > > whenever I need to update an existing codebase to add some kind of > parallelization, I am in the need of an executor matching the number of > processors available at runtime. Most of the time I end up using > something like: > > 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' > > If every library used by an application needs to maintain its' own > executors the application ends up with starting number of libraries used > times number of available processors threads. That does not scale. I > think there really is a need for some kind of default executor provided > by the platform. I am suprised I cannot find anything like that > anywhere. I would like to request an enhancement providing such a > default platform executor everyone can use to add parallelization > without ending up with tons of threads when all you want is making use > of the system's parallelization capabilities. > > Regards, > -- > Christian From Alan.Bateman at oracle.com Mon Aug 8 16:55:51 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Aug 2016 17:55:51 +0100 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> Message-ID: <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> On 08/08/2016 17:29, Patrick Reinhart wrote: > : > I tried to integrate your suggested changes here: > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.01 > I should have been clearer. A lazy implementation of resources/systemResources methods won't throw any exceptions, instead any I/O exceptions will be wrapped with an UncheckedIOException and then thrown from the method that caused the access to take place. There are several examples of this already. For the javadoc then this will be described in the method description rather than a @throws. -Alan From volker.simonis at gmail.com Mon Aug 8 17:17:34 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Aug 2016 19:17:34 +0200 Subject: What's correct: "--modulepath" or "--module-path"? Message-ID: Hi, currently (in jdk9/dev), tools like jlink/jmod support only "--modulepath" but not "--module-path". But notice that they support "--class-path" and "--module-version". As far as I can see, JEP 293: Guidelines for JDK Command-Line Tool Options [1] recommends "--module-path". Also, the current help text for jmod in the jmod.properties resource file, contains this message: err.modulepath.must.be.specified=--module-path must be specified when hashing modules but jmod itself only understands "--modulepath" Is somebody taking care to harmonize all these command line options? Will this be done as part of JEP 293? Regards, Volker [1] http://openjdk.java.net/jeps/293 From scolebourne at joda.org Mon Aug 8 17:29:06 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 8 Aug 2016 18:29:06 +0100 Subject: NIO Path enhancements? Message-ID: I've been using the java.nio.file.Path API in the last few days and have found it a little tricky to use. I'd like to understand if the following ideas were ever considered (to consider whether an issue should be raised). Currently, developers create a Path instance and it contains various methods for managing the path, plus a few that actually access the filing system. However, for most filing system operations, developers have to use the static methods on Files. This feels very non-intuitive and hard to discover. Current code: Path path = Paths.get("/my/path/to/file.txt"); if (Files.exists(path)) { boolean dir = Files.isDirectory(path); ... } Almost all methods on Files simply obtain the FileSystemProvider from the FileSystem and invoke methods on that. Why not add a new class PathOperations that binds the Path to the static methods? Path path = Paths.get("/my/path/to/file.txt"); if (path.operations().exists()) { boolean dir = path.operations().isDirectory(); ... } I can't see any reason why this wouldn't work, but perhaps I'm missing something obvious. (All methods on Files would need to be replicated on PathOperations, and maybe Files could be deprecated if the deprecation tools improve.) Separately, it is a little tricky grasping the ZIP file system, and that it needs to be opened and closed separately. Could we see a new method to indicate if a given path/file can be expanded to another FileSystem? if (path.operations().isExpandableToFileSystem()) { try (FileSystem fs = path.operations().expand()) { // work with ZIP or similar } } This would be a lot more discoverable with appropriate docs. BTW, this also relates to Jigsaw as the new JFS provider may make expandable paths more widely used. Stephen From Alan.Bateman at oracle.com Mon Aug 8 17:40:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Aug 2016 18:40:45 +0100 Subject: What's correct: "--modulepath" or "--module-path"? In-Reply-To: References: Message-ID: <9effb20a-5aa4-1050-db00-4c69aed3367a@oracle.com> On 08/08/2016 18:17, Volker Simonis wrote: > Hi, > > currently (in jdk9/dev), tools like jlink/jmod support only > "--modulepath" but not "--module-path". But notice that they support > "--class-path" and "--module-version". As far as I can see, JEP 293: > Guidelines for JDK Command-Line Tool Options [1] recommends > "--module-path". > The changes to align with JEP 293 aren't in jdk9/dev yet but Mandy is in the process of bringing the changes in (discussion is on jigsaw-dev [1]). -Alan [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009025.html From patrick at reini.net Mon Aug 8 19:14:25 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 8 Aug 2016 21:14:25 +0200 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> Message-ID: <20A5AEB1-F4A9-4C0E-9F28-521D691FAB03@reini.net> > Am 08.08.2016 um 18:55 schrieb Alan Bateman : > > On 08/08/2016 17:29, Patrick Reinhart wrote: > >> : >> I tried to integrate your suggested changes here: >> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.01 >> > I should have been clearer. A lazy implementation of resources/systemResources methods won't throw any exceptions, instead any I/O exceptions will be wrapped with an UncheckedIOException and then thrown from the method that caused the access to take place. There are several examples of this already. For the javadoc then this will be described in the method description rather than a @throws. > > -Alan I hope that this version is more likely that what you meant? http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.02 Patrick From paul.sandoz at oracle.com Mon Aug 8 21:09:33 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 8 Aug 2016 14:09:33 -0700 Subject: RFR (XS): 8162815: unnecessary object creation in reflection In-Reply-To: <57A39163.4060807@oracle.com> References: <57A39163.4060807@oracle.com> Message-ID: <5FFF41ED-AF7E-477B-B214-48128B60FA1E@oracle.com> > On 4 Aug 2016, at 12:02, Claes Redestad wrote: > > Hi, > > I'd like to sponsor this bug fix provided by Tom?? H?rka to remove a new and dup left behind in generated accessor methods after moving these to use appropriate valueOf methods for boxing primitive returns. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162815 > Webrev: http://cr.openjdk.java.net/~redestad/8162815/webrev.01/ > > This appears to have a very limited effect to peak performance in HotSpot (interpreter and C1 level code seem to hurt a bit), but should be fixed for correctness. > +1 Paul. From kumar.x.srinivasan at oracle.com Mon Aug 8 21:20:36 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 08 Aug 2016 14:20:36 -0700 Subject: RFE to re-purpose option --version: In-Reply-To: References: Message-ID: <57A8F7A4.9080700@oracle.com> Hello Paul, There is a light weight method to get the version from the launcher, "-fullversion" noting that, this does not invoke the VM, and obtains the version string set at build time in the launcher itself. However you would have to exec java twice, once to get the version, another to invoke it. Thanks Kumar > Dear Committers, > > In Java 9, the --version: has been deprecated. The error message > returned to me is: > > Error: Specifying an alternate JDK/JRE version is no longer supported. > The use of the flag '-version:' is no longer valid. > Please download and execute the appropriate version. > Unrecognized option: -version:9 > > I am happy with that. This is not a complain on removing that "alternate" > feature. > > However, I would like to propose bringing back the option with a different > purpose. I would like to use --version: as a validation check. I > want Java to execute ONLY if the version specified matches the actual > platform version. This would be a wonderful help to scripts that require a > particular version of the Java platform, and should fail if the environment > has been accidentally setup with the wrong Java platform version. > > Examples: > java --version:9 > java --version:9.1 > > AFAICT, the only way to do this now is to execute Java twice. Once to pipe > --version to some find/grep command and check return code, and then execute > java again if the check pass. Loading the runtime twice is not optimal, > wouldn't you agree? Yet if you agree to this proposal, it would be a big > win for script writers, I believe. > > Opinions please. Thank you. > > Cheers, > Paul From kim.barrett at oracle.com Tue Aug 9 01:25:44 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Aug 2016 21:25:44 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> Message-ID: <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> > On Aug 8, 2016, at 8:16 AM, Per Liden wrote: > > Hi Kim, > > On 2016-08-01 20:47, Kim Barrett wrote: >> This updated webrev addresses concerns about the performance of the VM >> API used by the reference processor thread in the original webrev. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ > > Overall I think you managed to hit a good balance here, keeping the VM API straight forward without loosing flexibility. Having the ReferenceHandler doing the actual work seems sound and avoids some complexity, which I like. Thanks for looking at this. > I have one suggestion though, regarding CheckReferencePendingList(). While reviewing I found that I had to check several times what its return value actually meant, the "check" part of the name doesn't quite reveal that. > Further, it seems to me that the waiting path of this function has fairly little in common with the non-waiting path, e.g. it always returns true. So, to make both the naming and implementation more clear I'd like to suggest that we split this into two separate functions, HasReferencePendingList() and WaitForReferencePendingList(), like this: I was thinking about splitting things way, and ended up not doing so for no good reason I can think of. And it does seem clearer that way, so... New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04.inc/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ > Other than this I think the patch looks good. > >> >> The originally offered approach was an attempt to minimize changes. I >> was trying to be as similar to the existing code as possible, while >> moving part of it into the VM, where we have the necessary control >> over suspension and the like. We already know we want to make changes >> in this area, in order to eliminate the use of >> jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that >> JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we >> should revisit that. > > Is JDK-8149925 the correct bug id? Looks like that bug has already been fixed in 9. That CR was originally for removing all the uses. During review the nio.Bits / direct buffer use was separated, and is the last one. There was a bunch of discussion about removing that final one in that review (especially later parts) http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038663.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039315.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/039862.html and also here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039561.html. However, I don't see a followup CR for removing the nio.Bits use. Maybe that didn't get created when we split the issue, or maybe I'm just failing to find it. Peter? Note that the consensus back in March/April was to defer it, along with the dependent actual removal of the internal Cleaner, to JDK 10. From amaembo at gmail.com Tue Aug 9 05:31:05 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Tue, 9 Aug 2016 12:31:05 +0700 Subject: Collectors.toSet() small performance improvement Message-ID: <51903419.20160809123105@gmail.com> Hello! I'd like to propose a simple performance patch for Collectors.toSet(): --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 @@ -295,7 +295,12 @@ public static Collector> toSet() { return new CollectorImpl<>((Supplier>) HashSet::new, Set::add, - (left, right) -> { left.addAll(right); return left; }, + (left, right) -> { + if (left.size() < right.size()) { + right.addAll(left); return right; + } + left.addAll(right); return left; + }, CH_UNORDERED_ID); } This will add the smaller set to the larger which may improve parallel performance when subtasks produced uneven results. In normal case the additional overhead is insignificant (additional HashSet size comparison per each combine operation which usually performed ~4*parallelism times). Here's simple JDK benchmark with results (Core-i7-4702MQ 4 HT cores, Win7, JDK 9-ea+129 64bit) which confirms the speedup: http://cr.openjdk.java.net/~tvaleev/patches/toSet/ When data is unevenly distributed, it's significantly faster: Original: ToSet.toSetParallel 10000 true avgt 50 88,580 ? 0,874 us/op ToSet.toSetParallel 100000 true avgt 50 676,243 ? 41,188 us/op ToSet.toSetParallel 1000000 true avgt 50 9126,399 ? 83,260 us/op Patched: ToSet.toSetParallel 10000 true avgt 50 62,121 ? 1,207 us/op ToSet.toSetParallel 100000 true avgt 50 556,968 ? 37,404 us/op ToSet.toSetParallel 1000000 true avgt 50 6572,372 ? 183,466 us/op When data is evenly distributed, no statistically significant changes observed: Original: ToSet.toSetParallel 10000 false avgt 50 177,137 ? 5,941 us/op ToSet.toSetParallel 100000 false avgt 50 2056,332 ? 87,433 us/op ToSet.toSetParallel 1000000 false avgt 50 51864,198 ? 560,883 us/op Patched: ToSet.toSetParallel 10000 false avgt 50 172,606 ? 7,321 us/op ToSet.toSetParallel 100000 false avgt 50 1922,478 ? 79,593 us/op ToSet.toSetParallel 1000000 false avgt 50 52648,100 ? 621,526 us/op What do you think? Should I open an issue? With best regards, Tagir Valeev. From aleksey.shipilev at gmail.com Tue Aug 9 06:45:15 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Tue, 9 Aug 2016 09:45:15 +0300 Subject: RFR (XS): 8162815: unnecessary object creation in reflection In-Reply-To: <5FFF41ED-AF7E-477B-B214-48128B60FA1E@oracle.com> References: <57A39163.4060807@oracle.com> <5FFF41ED-AF7E-477B-B214-48128B60FA1E@oracle.com> Message-ID: <5ba9541c-6181-6ac6-78c4-0920b18c7d7e@gmail.com> On 08/09/2016 12:09 AM, Paul Sandoz wrote: >> On 4 Aug 2016, at 12:02, Claes Redestad >> wrote: >> Hi, >> >> I'd like to sponsor this bug fix provided by Tom?? H?rka to remove >> a new and dup left behind in generated accessor methods after >> moving these to use appropriate valueOf methods for boxing >> primitive returns. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8162815 Webrev: >> http://cr.openjdk.java.net/~redestad/8162815/webrev.01/ >> >> This appears to have a very limited effect to peak performance in >> HotSpot (interpreter and C1 level code seem to hurt a bit), but >> should be fixed for correctness. >> > > +1 Looks good to me too. Thanks, -Aleksey From aleksey.shipilev at gmail.com Tue Aug 9 07:12:07 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Tue, 9 Aug 2016 10:12:07 +0300 Subject: Collectors.toSet() small performance improvement In-Reply-To: <51903419.20160809123105@gmail.com> References: <51903419.20160809123105@gmail.com> Message-ID: On 08/09/2016 08:31 AM, Tagir F. Valeev wrote: > --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 > +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 > @@ -295,7 +295,12 @@ > public static > Collector> toSet() { > return new CollectorImpl<>((Supplier>) HashSet::new, Set::add, > - (left, right) -> { left.addAll(right); return left; }, > + (left, right) -> { > + if (left.size() < right.size()) { > + right.addAll(left); return right; > + } > + left.addAll(right); return left; > + }, > CH_UNORDERED_ID); > } Good trick, but does it work properly with the sets that care about the add order, e.g. LinkedHashSet? I guess our saving grace here is Collector.toSet() is declared UNORDERED, so we can disturb the encounter order without violating the API contract. I would make it a bit cleaner though: (left, right) -> { if (left.size() < right.size()) { right.addAll(left); return right; } else { left.addAll(right); return left; } } Thanks, -Aleksey From amaembo at gmail.com Tue Aug 9 07:19:44 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Tue, 9 Aug 2016 14:19:44 +0700 Subject: Collectors.toSet() small performance improvement In-Reply-To: References: <51903419.20160809123105@gmail.com> Message-ID: <1869699536.20160809141944@gmail.com> Hello, Aleksey! Thank you for review. AS> Good trick, but does it work properly with the sets that care about the AS> add order, e.g. LinkedHashSet? I guess our saving grace here is AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter AS> order without violating the API contract. This implementation is bound to HashSet which is created right here, in supplier: return new CollectorImpl<>((Supplier>) HashSet::new, Set::add,... ) No other set implementation is possible here. Users who want to use custom set should use Collectors.toCollection(LinkedHashSet::new) which I'm not going to change as indeed here order might be important. AS> I would make it a bit cleaner though: AS> (left, right) -> { AS> if (left.size() < right.size()) { AS> right.addAll(left); return right; AS> } else { AS> left.addAll(right); return left; AS> } AS> } Agreed. With best regards, Tagir Valeev. From aleksey.shipilev at gmail.com Tue Aug 9 07:25:56 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Tue, 9 Aug 2016 10:25:56 +0300 Subject: Collectors.toSet() small performance improvement In-Reply-To: <1869699536.20160809141944@gmail.com> References: <51903419.20160809123105@gmail.com> <1869699536.20160809141944@gmail.com> Message-ID: <19c33027-8cfc-e046-cfe7-f00336b06b94@gmail.com> On 08/09/2016 10:19 AM, Tagir F. Valeev wrote: > AS> Good trick, but does it work properly with the sets that care about the > AS> add order, e.g. LinkedHashSet? I guess our saving grace here is > AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter > AS> order without violating the API contract. > > This implementation is bound to HashSet which is created right here, > in supplier: > > return new CollectorImpl<>((Supplier>) HashSet::new, Set::add,... ) > > No other set implementation is possible here. Users who want to use > custom set should use Collectors.toCollection(LinkedHashSet::new) > which I'm not going to change as indeed here order might be important. Right. (seeps some green tea trying to wake up) Looks good then. Thanks, -Aleksey From per.liden at oracle.com Tue Aug 9 07:52:52 2016 From: per.liden at oracle.com (Per Liden) Date: Tue, 9 Aug 2016 09:52:52 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> Message-ID: <02b55776-08c3-01b0-9a15-79e86794e3ee@oracle.com> Hi Kim, On 2016-08-09 03:25, Kim Barrett wrote: >> On Aug 8, 2016, at 8:16 AM, Per Liden wrote: >> >> Hi Kim, >> >> On 2016-08-01 20:47, Kim Barrett wrote: >>> This updated webrev addresses concerns about the performance of the VM >>> API used by the reference processor thread in the original webrev. >>> >>> New webrevs: >>> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ >>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ >>> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ >>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ >> >> Overall I think you managed to hit a good balance here, keeping the VM API straight forward without loosing flexibility. Having the ReferenceHandler doing the actual work seems sound and avoids some complexity, which I like. > > Thanks for looking at this. > >> I have one suggestion though, regarding CheckReferencePendingList(). While reviewing I found that I had to check several times what its return value actually meant, the "check" part of the name doesn't quite reveal that. >> Further, it seems to me that the waiting path of this function has fairly little in common with the non-waiting path, e.g. it always returns true. So, to make both the naming and implementation more clear I'd like to suggest that we split this into two separate functions, HasReferencePendingList() and WaitForReferencePendingList(), like this: > > I was thinking about splitting things way, and ended up not doing so > for no good reason I can think of. And it does seem clearer that way, > so... > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04.inc/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ Thanks for fixing, looks good. cheers, Per > >> Other than this I think the patch looks good. >> >>> >>> The originally offered approach was an attempt to minimize changes. I >>> was trying to be as similar to the existing code as possible, while >>> moving part of it into the VM, where we have the necessary control >>> over suspension and the like. We already know we want to make changes >>> in this area, in order to eliminate the use of >>> jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that >>> JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we >>> should revisit that. >> >> Is JDK-8149925 the correct bug id? Looks like that bug has already been fixed in 9. > > That CR was originally for removing all the uses. During review the > nio.Bits / direct buffer use was separated, and is the last one. > There was a bunch of discussion about removing that final one in that > review (especially later parts) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038663.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039315.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/039862.html > > and also here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039561.html. > > However, I don't see a followup CR for removing the nio.Bits use. > Maybe that didn't get created when we split the issue, or maybe I'm > just failing to find it. Peter? > > Note that the consensus back in March/April was to defer it, along > with the dependent actual removal of the internal Cleaner, to JDK 10. > > From claes.redestad at oracle.com Tue Aug 9 07:49:17 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 09:49:17 +0200 Subject: RFR (XS): 8162815: unnecessary object creation in reflection In-Reply-To: <5ba9541c-6181-6ac6-78c4-0920b18c7d7e@gmail.com> References: <57A39163.4060807@oracle.com> <5FFF41ED-AF7E-477B-B214-48128B60FA1E@oracle.com> <5ba9541c-6181-6ac6-78c4-0920b18c7d7e@gmail.com> Message-ID: <57A98AFD.9040507@oracle.com> On 2016-08-09 08:45, Aleksey Shipilev wrote: > On 08/09/2016 12:09 AM, Paul Sandoz wrote: >> >> +1 > Looks good to me too. Thanks! Pushed. /Claes From claes.redestad at oracle.com Tue Aug 9 08:11:36 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 10:11:36 +0200 Subject: RFR: 8163369: Enable generating DMH classes at link time In-Reply-To: References: <57A8710F.6070806@oracle.com> <3b521714-6369-d847-86f3-9409e5147518@gmail.com> <57A88698.3020604@oracle.com> Message-ID: <57A99038.3020601@oracle.com> On 2016-08-08 15:50, Aleksey Shipilev wrote: > On 08/08/2016 04:18 PM, Claes Redestad wrote: >> http://cr.openjdk.java.net/~redestad/8163369/webrev.02/ > Looks good. > > -Aleksey Thanks! Pushed. /Claes From sha.jiang at oracle.com Tue Aug 9 08:34:55 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 9 Aug 2016 16:34:55 +0800 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues Message-ID: Hi, The below issues have been closed, JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, JDK-8031555 but the associated items still be contained by ProblemList.txt. This small patch removes them. Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 Best regards, John Jiang From daniel.fuchs at oracle.com Tue Aug 9 09:53:01 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 9 Aug 2016 10:53:01 +0100 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: References: Message-ID: Hi John, JDK-8061177 [1] has been resolved as a duplicate of JDK-8065756 [2] which is still open. The correct action for this one might be to leave the test in the problem list but change the bug ID. The rest looks good to me - even though two of these test have been fixed by either adding diagnosis information or fixed as 'Cannot Reproduce'. Since most of these tests are in the serviceability area however, it might be good to get someone from serviceability-dev (added in cc:) to confirm whether they want to get these out of the problem list. best regards, [1] https://bugs.openjdk.java.net/browse/JDK-8061177 [2] https://bugs.openjdk.java.net/browse/JDK-8065756 -- daniel On 09/08/16 09:34, John Jiang wrote: > Hi, > The below issues have been closed, > JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, > JDK-8031555 > but the associated items still be contained by ProblemList.txt. This > small patch removes them. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 > Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 > > Best regards, > John Jiang > From claes.redestad at oracle.com Tue Aug 9 11:48:53 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 13:48:53 +0200 Subject: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 Message-ID: <57A9C325.3030805@oracle.com> Hi, change to enable DMH pre-generation caused a subtle change in the stacktrace, which caused this test to fail. Please review this patch which reverts the stackframe to look like before for non-pregenerated DMHs, while also updating the test to accept pregenerated DMHs. To verify this works I added invokeVirtual_LL_V (used in the test) to the list of pre-generated DMHs in GenerateJLIClassesPlugin and verified that the test pass both on a jlinked image and an exploded image. Webrev: http://cr.openjdk.java.net/~redestad/8163476/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8163476 Thanks! /Claes From claes.redestad at oracle.com Tue Aug 9 12:04:49 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 14:04:49 +0200 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke Message-ID: <57A9C6E1.4060100@oracle.com> Hi, please review this set of small changes to reduce the number of classes defined and pulled in when initializing java.lang.invoke Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 - Using an EnumMap in sun.misc.invoke.ValueConversions pulls in 5 EnumMap-related classes, and - Using result.addAll(Arrays.asList(buf).subList(0, bufCount)) rather than a simple for-loop pulls in 5 classes - A few private enum classes can profitably be replaced with alternative logic, removing 4 classes Thanks! /Claes From ivan.gerasimov at oracle.com Tue Aug 9 12:31:05 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 9 Aug 2016 15:31:05 +0300 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: <57A9C6E1.4060100@oracle.com> References: <57A9C6E1.4060100@oracle.com> Message-ID: Hi Claes! src/java.base/share/classes/sun/invoke/util/ValueConversions.java: 43 /** EnumMap uses preconstructed array internally, which is constant during it's lifetime. */ 44 @Stable 45 private final MethodHandle[] map = new MethodHandle[Wrapper.COUNT]; The comment at line 43 seems outdated. With kind regards, Ivan On 09.08.2016 15:04, Claes Redestad wrote: > Hi, > > please review this set of small changes to reduce the number of > classes defined and pulled in when initializing java.lang.invoke > > Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 > > - Using an EnumMap in > sun.misc.invoke.ValueConversions pulls in 5 EnumMap-related classes, and > - Using result.addAll(Arrays.asList(buf).subList(0, bufCount)) rather > than a simple for-loop pulls in 5 classes > - A few private enum classes can profitably be replaced with > alternative logic, removing 4 classes > > Thanks! > > /Claes > From claes.redestad at oracle.com Tue Aug 9 12:26:23 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 14:26:23 +0200 Subject: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 In-Reply-To: <57A9C325.3030805@oracle.com> References: <57A9C325.3030805@oracle.com> Message-ID: <57A9CBEF.9070209@oracle.com> On 2016-08-09 13:48, Claes Redestad wrote: > Hi, > > change to enable DMH pre-generation caused a subtle change in the > stacktrace, which caused this test to fail. > > Please review this patch which reverts the stackframe to look like > before for non-pregenerated DMHs, while also updating the test to > accept pregenerated DMHs. > > To verify this works I added invokeVirtual_LL_V (used in the test) to > the list of pre-generated DMHs in GenerateJLIClassesPlugin and > verified that the test pass both on a jlinked image and an exploded > image. > > Webrev: http://cr.openjdk.java.net/~redestad/8163476/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8163476 > > Thanks! > > /Claes From claes.redestad at oracle.com Tue Aug 9 12:28:46 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 14:28:46 +0200 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: References: <57A9C6E1.4060100@oracle.com> Message-ID: <57A9CC7E.3090107@oracle.com> On 2016-08-09 14:31, Ivan Gerasimov wrote: > Hi Claes! > > src/java.base/share/classes/sun/invoke/util/ValueConversions.java: > > 43 /** EnumMap uses preconstructed array internally, which > is constant during it's lifetime. */ > 44 @Stable > 45 private final MethodHandle[] map = new > MethodHandle[Wrapper.COUNT]; > > The comment at line 43 seems outdated. Removed and updated in-place: http://cr.openjdk.java.net/~redestad/8163370/webrev/ Thanks! /Claes > > With kind regards, > Ivan > > On 09.08.2016 15:04, Claes Redestad wrote: >> Hi, >> >> please review this set of small changes to reduce the number of >> classes defined and pulled in when initializing java.lang.invoke >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 >> >> - Using an EnumMap in >> sun.misc.invoke.ValueConversions pulls in 5 EnumMap-related classes, and >> - Using result.addAll(Arrays.asList(buf).subList(0, bufCount)) rather >> than a simple for-loop pulls in 5 classes >> - A few private enum classes can profitably be replaced with >> alternative logic, removing 4 classes >> >> Thanks! >> >> /Claes >> > From ivan.gerasimov at oracle.com Tue Aug 9 12:41:31 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 9 Aug 2016 15:41:31 +0300 Subject: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 In-Reply-To: <57A9CBEF.9070209@oracle.com> References: <57A9C325.3030805@oracle.com> <57A9CBEF.9070209@oracle.com> Message-ID: <867580a2-0cd8-014e-783b-218d94d42a08@oracle.com> Hi Claes! Not a thorough review, but a minor comment. 209 .replaceAll("DMH.invoke", "DMH/xxxxxxxx.invoke") The dot in the regexp needs to be escaped here. With kind regards, Ivan On 09.08.2016 15:26, Claes Redestad wrote: > > > On 2016-08-09 13:48, Claes Redestad wrote: >> Hi, >> >> change to enable DMH pre-generation caused a subtle change in the >> stacktrace, which caused this test to fail. >> >> Please review this patch which reverts the stackframe to look like >> before for non-pregenerated DMHs, while also updating the test to >> accept pregenerated DMHs. >> >> To verify this works I added invokeVirtual_LL_V (used in the test) to >> the list of pre-generated DMHs in GenerateJLIClassesPlugin and >> verified that the test pass both on a jlinked image and an exploded >> image. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163476/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163476 >> >> Thanks! >> >> /Claes > > From chris.hegarty at oracle.com Tue Aug 9 12:45:45 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 9 Aug 2016 13:45:45 +0100 Subject: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 In-Reply-To: <57A9CBEF.9070209@oracle.com> References: <57A9C325.3030805@oracle.com> <57A9CBEF.9070209@oracle.com> Message-ID: > On 9 Aug 2016, at 13:26, Claes Redestad wrote: > > > > On 2016-08-09 13:48, Claes Redestad wrote: >> Hi, >> >> change to enable DMH pre-generation caused a subtle change in the stacktrace, which caused this test to fail. >> >> Please review this patch which reverts the stackframe to look like before for non-pregenerated DMHs, while also updating the test to accept pregenerated DMHs. >> >> To verify this works I added invokeVirtual_LL_V (used in the test) to the list of pre-generated DMHs in GenerateJLIClassesPlugin and verified that the test pass both on a jlinked image and an exploded image. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163476/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163476 Looks fine Claes. -Chris. From claes.redestad at oracle.com Tue Aug 9 12:58:57 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 14:58:57 +0200 Subject: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 In-Reply-To: <867580a2-0cd8-014e-783b-218d94d42a08@oracle.com> References: <57A9C325.3030805@oracle.com> <57A9CBEF.9070209@oracle.com> <867580a2-0cd8-014e-783b-218d94d42a08@oracle.com> Message-ID: <57A9D391.30002@oracle.com> On 2016-08-09 14:41, Ivan Gerasimov wrote: > Hi Claes! > > Not a thorough review, but a minor comment. > > 209 .replaceAll("DMH.invoke", "DMH/xxxxxxxx.invoke") > > The dot in the regexp needs to be escaped here. "Needs" is a strong word here, but I agree it's more correct. I'll fix and push. :-) Thanks! /Claes From ivan.gerasimov at oracle.com Tue Aug 9 13:07:38 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 9 Aug 2016 16:07:38 +0300 Subject: RFR: 8163476: java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 In-Reply-To: <57A9D391.30002@oracle.com> References: <57A9C325.3030805@oracle.com> <57A9CBEF.9070209@oracle.com> <867580a2-0cd8-014e-783b-218d94d42a08@oracle.com> <57A9D391.30002@oracle.com> Message-ID: <9cda8057-c623-3a60-ba6f-75003510a12c@oracle.com> On 09.08.2016 15:58, Claes Redestad wrote: > On 2016-08-09 14:41, Ivan Gerasimov wrote: >> Hi Claes! >> >> Not a thorough review, but a minor comment. >> >> 209 .replaceAll("DMH.invoke", "DMH/xxxxxxxx.invoke") >> >> The dot in the regexp needs to be escaped here. > > "Needs" is a strong word here, but I agree it's more correct. I'll fix > and push. :-) > Would like to be escaped? :) > Thanks! > > /Claes > From sha.jiang at oracle.com Tue Aug 9 13:17:39 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 9 Aug 2016 21:17:39 +0800 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: References: Message-ID: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> Hi Daniel, Thanks for your review! Please take a look at this updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ Best regards, John Jiang On 2016/8/9 17:53, Daniel Fuchs wrote: > Hi John, > > JDK-8061177 [1] has been resolved as a duplicate of > JDK-8065756 [2] which is still open. > The correct action for this one might be to leave the > test in the problem list but change the bug ID. > > The rest looks good to me - even though > two of these test have been fixed by either adding > diagnosis information or fixed as 'Cannot Reproduce'. > > Since most of these tests are in the serviceability > area however, it might be good to get someone from > serviceability-dev (added in cc:) to confirm whether > they want to get these out of the problem list. > > best regards, > > [1] https://bugs.openjdk.java.net/browse/JDK-8061177 > [2] https://bugs.openjdk.java.net/browse/JDK-8065756 > > -- daniel > > On 09/08/16 09:34, John Jiang wrote: >> Hi, >> The below issues have been closed, >> JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, >> JDK-8031555 >> but the associated items still be contained by ProblemList.txt. This >> small patch removes them. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 >> Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 >> >> Best regards, >> John Jiang >> > > From pbenedict at apache.org Tue Aug 9 14:13:35 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 9 Aug 2016 09:13:35 -0500 Subject: RFE to re-purpose option --version: In-Reply-To: <57A8F7A4.9080700@oracle.com> References: <57A8F7A4.9080700@oracle.com> Message-ID: Kumar, thank you for that information. I find that useful too. Now with regard to this email's proposal, are there any further opinions? If this has merit, I would appreciate if someone could create a ticket for consideration? Cheers, Paul On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > > Hello Paul, > > There is a light weight method to get the version from the launcher, > "-fullversion" noting that, this does not invoke the VM, and obtains > the version string set at build time in the launcher itself. > > However you would have to exec java twice, once to get the version, > another to invoke it. > > Thanks > > Kumar > > > Dear Committers, >> >> In Java 9, the --version: has been deprecated. The error message >> returned to me is: >> >> Error: Specifying an alternate JDK/JRE version is no longer supported. >> The use of the flag '-version:' is no longer valid. >> Please download and execute the appropriate version. >> Unrecognized option: -version:9 >> >> I am happy with that. This is not a complain on removing that "alternate" >> feature. >> >> However, I would like to propose bringing back the option with a different >> purpose. I would like to use --version: as a validation check. I >> want Java to execute ONLY if the version specified matches the actual >> platform version. This would be a wonderful help to scripts that require a >> particular version of the Java platform, and should fail if the >> environment >> has been accidentally setup with the wrong Java platform version. >> >> Examples: >> java --version:9 >> java --version:9.1 >> >> AFAICT, the only way to do this now is to execute Java twice. Once to pipe >> --version to some find/grep command and check return code, and then >> execute >> java again if the check pass. Loading the runtime twice is not optimal, >> wouldn't you agree? Yet if you agree to this proposal, it would be a big >> win for script writers, I believe. >> >> Opinions please. Thank you. >> >> Cheers, >> Paul >> > > From paul.sandoz at oracle.com Tue Aug 9 14:27:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Aug 2016 07:27:42 -0700 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: <57A9C6E1.4060100@oracle.com> References: <57A9C6E1.4060100@oracle.com> Message-ID: <86FE148E-A909-49CD-8BF2-609C68FDF0E3@oracle.com> > On 9 Aug 2016, at 05:04, Claes Redestad wrote: > > Hi, > > please review this set of small changes to reduce the number of classes defined and pulled in when initializing java.lang.invoke > > Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 > > - Using an EnumMap in sun.misc.invoke.ValueConversions pulls in 5 EnumMap-related classes, and > - Using result.addAll(Arrays.asList(buf).subList(0, bufCount)) rather than a simple for-loop pulls in 5 classes > - A few private enum classes can profitably be replaced with alternative logic, removing 4 classes > I browsed this quite quickly, looks good. Glad you added the assert in Wrapper.java. Paul. From claes.redestad at oracle.com Tue Aug 9 14:32:15 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 16:32:15 +0200 Subject: RFE to re-purpose option --version: In-Reply-To: References: <57A8F7A4.9080700@oracle.com> Message-ID: <57A9E96F.8080608@oracle.com> Opinions! 1. --version:9 is ambiguous, maybe --require-version=9 would be better... 2. ... but it still doesn't seem worth the hours of testing, maintenance and subsequent bug-fixing for this niche use case 3. ... and even if it did get in there'd be a very long time until all versions of java installed will have the flag, limiting the usefulness for years to come, forcing scripts to workaround using, say, java -fullversion anyhow Thanks! /Claes On 2016-08-09 16:13, Paul Benedict wrote: > Kumar, thank you for that information. I find that useful too. Now with > regard to this email's proposal, are there any further opinions? If this > has merit, I would appreciate if someone could create a ticket for > consideration? > > Cheers, > Paul > > On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan < > kumar.x.srinivasan at oracle.com> wrote: > >> Hello Paul, >> >> There is a light weight method to get the version from the launcher, >> "-fullversion" noting that, this does not invoke the VM, and obtains >> the version string set at build time in the launcher itself. >> >> However you would have to exec java twice, once to get the version, >> another to invoke it. >> >> Thanks >> >> Kumar >> >> >> Dear Committers, >>> In Java 9, the --version: has been deprecated. The error message >>> returned to me is: >>> >>> Error: Specifying an alternate JDK/JRE version is no longer supported. >>> The use of the flag '-version:' is no longer valid. >>> Please download and execute the appropriate version. >>> Unrecognized option: -version:9 >>> >>> I am happy with that. This is not a complain on removing that "alternate" >>> feature. >>> >>> However, I would like to propose bringing back the option with a different >>> purpose. I would like to use --version: as a validation check. I >>> want Java to execute ONLY if the version specified matches the actual >>> platform version. This would be a wonderful help to scripts that require a >>> particular version of the Java platform, and should fail if the >>> environment >>> has been accidentally setup with the wrong Java platform version. >>> >>> Examples: >>> java --version:9 >>> java --version:9.1 >>> >>> AFAICT, the only way to do this now is to execute Java twice. Once to pipe >>> --version to some find/grep command and check return code, and then >>> execute >>> java again if the check pass. Loading the runtime twice is not optimal, >>> wouldn't you agree? Yet if you agree to this proposal, it would be a big >>> win for script writers, I believe. >>> >>> Opinions please. Thank you. >>> >>> Cheers, >>> Paul >>> >> From pbenedict at apache.org Tue Aug 9 14:50:39 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 9 Aug 2016 09:50:39 -0500 Subject: RFE to re-purpose option --version: In-Reply-To: <57A9E96F.8080608@oracle.com> References: <57A8F7A4.9080700@oracle.com> <57A9E96F.8080608@oracle.com> Message-ID: Claes, thanks for your feedback. My comments to your comments: 1. I like your alternate name. 2. I am in no position to agree or disagree. I'll take your word. 3. It is no less "limiting the usefulness" than any of the new options being introduced in 9. Yes, limited, but no more limited than they too. Cheers, Paul On Tue, Aug 9, 2016 at 9:32 AM, Claes Redestad wrote: > Opinions! > > 1. --version:9 is ambiguous, maybe --require-version=9 would be better... > 2. ... but it still doesn't seem worth the hours of testing, maintenance > and subsequent bug-fixing for this niche use case > 3. ... and even if it did get in there'd be a very long time until all > versions of java installed will have the flag, limiting the usefulness for > years to come, forcing scripts to workaround using, say, java -fullversion > anyhow > > Thanks! > > /Claes > > > On 2016-08-09 16:13, Paul Benedict wrote: > >> Kumar, thank you for that information. I find that useful too. Now with >> regard to this email's proposal, are there any further opinions? If this >> has merit, I would appreciate if someone could create a ticket for >> consideration? >> >> Cheers, >> Paul >> >> On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan < >> kumar.x.srinivasan at oracle.com> wrote: >> >> Hello Paul, >>> >>> There is a light weight method to get the version from the launcher, >>> "-fullversion" noting that, this does not invoke the VM, and obtains >>> the version string set at build time in the launcher itself. >>> >>> However you would have to exec java twice, once to get the version, >>> another to invoke it. >>> >>> Thanks >>> >>> Kumar >>> >>> >>> Dear Committers, >>> >>>> In Java 9, the --version: has been deprecated. The error >>>> message >>>> returned to me is: >>>> >>>> Error: Specifying an alternate JDK/JRE version is no longer supported. >>>> The use of the flag '-version:' is no longer valid. >>>> Please download and execute the appropriate version. >>>> Unrecognized option: -version:9 >>>> >>>> I am happy with that. This is not a complain on removing that >>>> "alternate" >>>> feature. >>>> >>>> However, I would like to propose bringing back the option with a >>>> different >>>> purpose. I would like to use --version: as a validation check. >>>> I >>>> want Java to execute ONLY if the version specified matches the actual >>>> platform version. This would be a wonderful help to scripts that >>>> require a >>>> particular version of the Java platform, and should fail if the >>>> environment >>>> has been accidentally setup with the wrong Java platform version. >>>> >>>> Examples: >>>> java --version:9 >>>> java --version:9.1 >>>> >>>> AFAICT, the only way to do this now is to execute Java twice. Once to >>>> pipe >>>> --version to some find/grep command and check return code, and then >>>> execute >>>> java again if the check pass. Loading the runtime twice is not optimal, >>>> wouldn't you agree? Yet if you agree to this proposal, it would be a big >>>> win for script writers, I believe. >>>> >>>> Opinions please. Thank you. >>>> >>>> Cheers, >>>> Paul >>>> >>>> >>> > From claes.redestad at oracle.com Tue Aug 9 15:34:24 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 17:34:24 +0200 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke Message-ID: <57A9F800.2060409@oracle.com> Hi, please review this patch to replace reflection calls into java.lang.invoke from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 Thanks! /Claes From claes.redestad at oracle.com Tue Aug 9 16:18:58 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Aug 2016 18:18:58 +0200 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: <86FE148E-A909-49CD-8BF2-609C68FDF0E3@oracle.com> References: <57A9C6E1.4060100@oracle.com> <86FE148E-A909-49CD-8BF2-609C68FDF0E3@oracle.com> Message-ID: <57AA0272.6090607@oracle.com> On 2016-08-09 16:27, Paul Sandoz wrote: >> On 9 Aug 2016, at 05:04, Claes Redestad wrote: >> >> Hi, >> >> please review this set of small changes to reduce the number of classes defined and pulled in when initializing java.lang.invoke >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 >> >> - Using an EnumMap in sun.misc.invoke.ValueConversions pulls in 5 EnumMap-related classes, and >> - Using result.addAll(Arrays.asList(buf).subList(0, bufCount)) rather than a simple for-loop pulls in 5 classes >> - A few private enum classes can profitably be replaced with alternative logic, removing 4 classes >> > I browsed this quite quickly, looks good. Thanks! > > Glad you added the assert in Wrapper.java. I'd not sleep well without that assert. :-) /Claes From cs at schulte.it Tue Aug 9 16:36:30 2016 From: cs at schulte.it (Christian Schulte) Date: Tue, 9 Aug 2016 18:36:30 +0200 Subject: Executors enhancement In-Reply-To: <57A7C145.40901@oracle.com> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> Message-ID: <57AA068E.403@schulte.it> Am 08/08/16 um 01:16 schrieb Claes Redestad: > Hi Christian, > > have you looked at java.util.concurrent.ForkJoinPool.commonPool()? Thanks for pointing that out. I looked at Java 7 documentation and did not notice a common pool got added in Java 8. I will postpone any effort on parallelization until targetting Java 8. I am not sure if that is really what I am looking for, however. Need to gather experience to find out about. As Brian Goetz has pointed out, it is about being "a good citizen". Before asking, I looked at some open source projects to find out how they are implementing parallelization. Very few do. Numbers seem to be increasing. Developers are talking about it. Most of the time they start with employing theire own executors internally. So maybe the common pool should be pushed somehow so it gets more attention on e.g. Stackoverflow. The Java tutorials only contain a basic explanation of the fork/join framework at . They really should be enhanced to teach how to use the common pool properly. Regards, -- Christian From cs at schulte.it Tue Aug 9 16:37:23 2016 From: cs at schulte.it (Christian Schulte) Date: Tue, 9 Aug 2016 18:37:23 +0200 Subject: Executors enhancement In-Reply-To: References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> Message-ID: <57AA06C3.1040702@schulte.it> Am 08/08/16 um 02:04 schrieb Brian Goetz: > If a library wants to offer a customization point where it accepts an > FJPool, clients should be encouraged to pass the common pool (and the > common pool is a good default) unless there are specific reasons not to. Exposing parallelization at API level is what I want to avoid. I consider parallelization an implementation detail. Nothing to be exposed at API level. In my opinion this is not about library context. Not even application context. Having such common executor really is platform context. I thought about re-designing libraries to make use of 'java.beans.beancontext' just to be able to access some kind of services internally. There is no way to re-design the APIs just because the implementation wants to employ parallelization and needs a common pool. So I am glad something like that is provided in Java 8. Regards, -- Christian From mandy.chung at oracle.com Tue Aug 9 16:40:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 Aug 2016 09:40:36 -0700 Subject: RFE to re-purpose option --version: In-Reply-To: References: Message-ID: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> > On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote: > > However, I would like to propose bringing back the option with a different > purpose. I would like to use --version: as a validation check. I > want Java to execute ONLY if the version specified matches the actual > platform version. This would be a wonderful help to scripts that require a > particular version of the Java platform, and should fail if the environment > has been accidentally setup with the wrong Java platform version. > > Examples: > java --version:9 > java --version:9.1 > > AFAICT, the only way to do this now is to execute Java twice. Once to pipe > --version to some find/grep command and check return code, and then execute > java again if the check pass. Loading the runtime twice is not optimal, > wouldn't you agree? Yet if you agree to this proposal, it would be a big > win for script writers, I believe. Have you considered checking the JAVA_VERSION property in $JAVA_HOME/release file? jlink creates the `release` file containing certain properties about the runtime image. Mandy From pbenedict at apache.org Tue Aug 9 16:49:46 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 9 Aug 2016 11:49:46 -0500 Subject: RFE to re-purpose option --version: In-Reply-To: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> Message-ID: No, I haven't considered that. Thank you, Mandy. Good tip. And I see that file also contains JAVA_FULL_VERSION, whose value is identical to the -fullversion option output. Cheers, Paul On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung wrote: > > > On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote: > > > > However, I would like to propose bringing back the option with a > different > > purpose. I would like to use --version: as a validation check. I > > want Java to execute ONLY if the version specified matches the actual > > platform version. This would be a wonderful help to scripts that require > a > > particular version of the Java platform, and should fail if the > environment > > has been accidentally setup with the wrong Java platform version. > > > > Examples: > > java --version:9 > > java --version:9.1 > > > > AFAICT, the only way to do this now is to execute Java twice. Once to > pipe > > --version to some find/grep command and check return code, and then > execute > > java again if the check pass. Loading the runtime twice is not optimal, > > wouldn't you agree? Yet if you agree to this proposal, it would be a big > > win for script writers, I believe. > > Have you considered checking the JAVA_VERSION property in > $JAVA_HOME/release file? jlink creates the `release` file containing > certain properties about the runtime image. > > Mandy From kim.barrett at oracle.com Tue Aug 9 16:51:39 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Aug 2016 12:51:39 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <02b55776-08c3-01b0-9a15-79e86794e3ee@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <02b55776-08c3-01b0-9a15-79e86794e3ee@oracle.com> Message-ID: <2B865CC5-C021-452B-8A40-BA450D4F81E2@oracle.com> > On Aug 9, 2016, at 3:52 AM, Per Liden wrote: > > Hi Kim, > > On 2016-08-09 03:25, Kim Barrett wrote: >>> On Aug 8, 2016, at 8:16 AM, Per Liden wrote: >>> I have one suggestion though, regarding CheckReferencePendingList(). While reviewing I found that I had to check several times what its return value actually meant, the "check" part of the name doesn't quite reveal that. >>> Further, it seems to me that the waiting path of this function has fairly little in common with the non-waiting path, e.g. it always returns true. So, to make both the naming and implementation more clear I'd like to suggest that we split this into two separate functions, HasReferencePendingList() and WaitForReferencePendingList(), like this: >> >> I was thinking about splitting things way, and ended up not doing so >> for no good reason I can think of. And it does seem clearer that way, >> so... >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04.inc/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ > > Thanks for fixing, looks good. Thanks! > > cheers, > Per > >> >>> Other than this I think the patch looks good. From vladimir.x.ivanov at oracle.com Tue Aug 9 17:00:36 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 9 Aug 2016 10:00:36 -0700 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: <57A9F800.2060409@oracle.com> References: <57A9F800.2060409@oracle.com> Message-ID: Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes() in MemberName? Otherwise, looks fine. Best regards, Vladimir Ivanov On 8/9/16 8:34 AM, Claes Redestad wrote: > Hi, > > please review this patch to replace reflection calls into > java.lang.invoke from GenerateJLIClassesPlugin with an internal API > exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. > > Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 > > Thanks! > > /Claes > > From ecki at zusammenkunft.net Tue Aug 9 17:04:16 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Tue, 9 Aug 2016 19:04:16 +0200 Subject: AW: Executors enhancement In-Reply-To: <57AA06C3.1040702@schulte.it> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> <57AA06C3.1040702@schulte.it> Message-ID: <57aa0d10.10a81c0a.cf6f6.776f@mx.google.com> This is nice in theory but has a number of drawbacks. First of all the common pool is not very easy to configure. It takes the available CPUs and if you run more than one VM you overcommit. Secondly different strategies to deal with longrunning or blocked jobs, with priority inheritance, with finegrained concurrency (you don't want to block all threads with some ill behaved tasks and therefore block all paralllel streams. So it is a good idea to find a good shared default, but an API quite seldomly can isolate itself and the users about those aspects. So always allow to provide an alternate Executor. This also helps with thread naming, thread context, interceptors and error handlers. Also, Once you have file or network or database jobs your task parallelity is not related with system CPUs anymore (and the runtimes become so unpredictable that it especially hurts parallelStream and and forkjoin users Gruss Bernd -- http://bernd.eckenfels.net >From Win 10 Mobile Von: Christian Schulte From claes.redestad at oracle.com Tue Aug 9 17:08:19 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 09 Aug 2016 19:08:19 +0200 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: References: <57A9F800.2060409@oracle.com> Message-ID: MemberName defines the implementation of JavaLangInvokeAccess for some reason, so that's unfortunately necessary. /Claes Vladimir Ivanov skrev: (9 augusti 2016 19:00:36 CEST) >Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes() > >in MemberName? > >Otherwise, looks fine. > >Best regards, >Vladimir Ivanov > >On 8/9/16 8:34 AM, Claes Redestad wrote: >> Hi, >> >> please review this patch to replace reflection calls into >> java.lang.invoke from GenerateJLIClassesPlugin with an internal API >> exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 >> >> Thanks! >> >> /Claes >> >> From vladimir.x.ivanov at oracle.com Tue Aug 9 17:30:48 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 9 Aug 2016 10:30:48 -0700 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: References: <57A9F800.2060409@oracle.com> Message-ID: > MemberName defines the implementation of JavaLangInvokeAccess for some > reason, so that's unfortunately necessary. Oh, I see. I suggest to move the whole thing to MethodHandleImpl then. It was exposing MemberName internals before your change, but it isn't anymore. Best regards, Vladimir Ivanov > > Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes() > in MemberName? > > Otherwise, looks fine. > > Best regards, > Vladimir Ivanov > > On 8/9/16 8:34 AM, Claes Redestad wrote: > > Hi, > > please review this patch to replace reflection calls into > java.lang.invoke from GenerateJLIClassesPlugin with an internal API > exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. > > Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 > > Thanks! > > /Claes > > > From mandy.chung at oracle.com Tue Aug 9 17:30:25 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 Aug 2016 10:30:25 -0700 Subject: RFE to re-purpose option --version: In-Reply-To: References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> Message-ID: <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> If you are only looking for the version, would JAVA_VERSION satisfy your need? JAVA_FULL_VERSION is only present in JDK and JRE image but not custom image since the property is supplied by the jdk build. Mandy > On Aug 9, 2016, at 9:49 AM, Paul Benedict wrote: > > No, I haven't considered that. Thank you, Mandy. Good tip. And I see that file also contains JAVA_FULL_VERSION, whose value is identical to the -fullversion option output. > > Cheers, > Paul > > On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung wrote: > > > On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote: > > > > However, I would like to propose bringing back the option with a different > > purpose. I would like to use --version: as a validation check. I > > want Java to execute ONLY if the version specified matches the actual > > platform version. This would be a wonderful help to scripts that require a > > particular version of the Java platform, and should fail if the environment > > has been accidentally setup with the wrong Java platform version. > > > > Examples: > > java --version:9 > > java --version:9.1 > > > > AFAICT, the only way to do this now is to execute Java twice. Once to pipe > > --version to some find/grep command and check return code, and then execute > > java again if the check pass. Loading the runtime twice is not optimal, > > wouldn't you agree? Yet if you agree to this proposal, it would be a big > > win for script writers, I believe. > > Have you considered checking the JAVA_VERSION property in $JAVA_HOME/release file? jlink creates the `release` file containing certain properties about the runtime image. > > Mandy > From cs at schulte.it Tue Aug 9 22:51:18 2016 From: cs at schulte.it (Christian Schulte) Date: Wed, 10 Aug 2016 00:51:18 +0200 Subject: Executors enhancement In-Reply-To: <57aa0d10.10a81c0a.cf6f6.776f@mx.google.com> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> <57AA06C3.1040702@schulte.it> <57aa0d10.10a81c0a.cf6f6.776f@mx.google.com> Message-ID: <57AA5E66.9080700@schulte.it> Am 08/09/16 um 19:04 schrieb ecki at zusammenkunft.net: > This is nice in theory but has a number of drawbacks. First of all the > common pool is not very easy to configure. It takes the available CPUs > and if you run more than one VM you overcommit. Secondly different > strategies to deal with longrunning or blocked jobs, with priority > inheritance, with finegrained concurrency (you don't want to block all > threads with some ill behaved tasks and therefore block all paralllel > streams. > > > > So it is a good idea to find a good shared default, but an API quite > seldomly can isolate itself and the users about those aspects. So always > allow to provide an alternate Executor. This also helps with thread > naming, thread context, interceptors and error handlers. > > > > Also, Once you have file or network or database jobs your task > parallelity is not related with system CPUs anymore (and the runtimes > become so unpredictable that it especially hurts parallelStream and and > forkjoin users That are mainly the reasons why I was looking for something making all of this the burden of the OS scheduler. That is the only entity with the capabilities to prioritize threads and to also know about what a specific thread is currently doing (wait states, blocked by IO, network, etc.). Maintaining executors at library or application context it would be needed to query the OS for capabilities (query resource limits, ulimit, etc.) and setup things matching the current OS in its current state (multiple VMs) and to re-configure things when something changes. So maybe the common pool should auto-configure itself dynamically based on more than just the number of available processors and make use of the OS resource management facilities. Regards, -- Christian From david.holmes at oracle.com Tue Aug 9 23:26:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Aug 2016 09:26:54 +1000 Subject: Executors enhancement In-Reply-To: <57AA06C3.1040702@schulte.it> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> <57AA06C3.1040702@schulte.it> Message-ID: <10024d6d-4769-63e9-6e96-adf4867e7409@oracle.com> On 10/08/2016 2:37 AM, Christian Schulte wrote: > Am 08/08/16 um 02:04 schrieb Brian Goetz: >> If a library wants to offer a customization point where it accepts an >> FJPool, clients should be encouraged to pass the common pool (and the >> common pool is a good default) unless there are specific reasons not to. > > Exposing parallelization at API level is what I want to avoid. I > consider parallelization an implementation detail. Nothing to be exposed > at API level. Transparent parallelization is like transparent distribution - might sound nice but in practice is unrealistic. This is why you have to opt-in to parallelization in the Stream framework. Other libraries also need to expose some hook to opt-in and allow configuration of parallelisation. That doesn't have to be exposed in the primary API but should be exposed through some kind of configuration API. The idea that parallelization is just an implementation detail is only considering the functional aspect in my opinion. David ----- In my opinion this is not about library context. Not even > application context. Having such common executor really is platform > context. I thought about re-designing libraries to make use of > 'java.beans.beancontext' just to be able to access some kind of services > internally. There is no way to re-design the APIs just because the > implementation wants to employ parallelization and needs a common pool. > So I am glad something like that is provided in Java 8. > > Regards, > From mandy.chung at oracle.com Wed Aug 10 00:02:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 Aug 2016 17:02:41 -0700 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: <57A9F800.2060409@oracle.com> References: <57A9F800.2060409@oracle.com> Message-ID: <5E236A42-1557-479D-B9E9-4588BB096DD6@oracle.com> > On Aug 9, 2016, at 8:34 AM, Claes Redestad wrote: > > Hi, > > please review this patch to replace reflection calls into java.lang.invoke from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. > > Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 MemberName.java Since JavaLangInvokeAccess is now extended for other purpose, MemberName doesn?t seem the most appropriate place to set JavaLangInvokeAccess. Maybe Vladimir or other can recommend another class to setJavaLangInvokeAccess. If it stays in MemberName, can you move line 1156-1157 to JavaLangInvokeAccess interface. GenerateJLIClassesHelper I actually think it?s better to keep the generate* methods in BoundMethodHandle and DirectMethodHandle is better, closer to the relevant context/impl. This helper class doesn?t seem necessary. GenerateJLIClassesPlugin.java Would be good to make JLIA final. Otherwise looks okay. Mandy From ivan.gerasimov at oracle.com Wed Aug 10 00:12:34 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 10 Aug 2016 03:12:34 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) Message-ID: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> Hello! Two classes from java.io package may experience the integer overflow problem in their read() methods. Would you please help review the obvious fix? The regression tests are @ignored by default, as they require 4+ GB of the heap to run. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163518 WEBREV: http://cr.openjdk.java.net/~igerasim/8163518/00/webrev/ With kind regards, Ivan From Paul.Sandoz at oracle.com Wed Aug 10 00:14:09 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Aug 2016 17:14:09 -0700 Subject: RFR 8161444 VarHandles should provide access bitwise atomics Message-ID: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> Hi Please review the following webrev which combines: 8161444 VarHandles should provide access bitwise atomics 8162107 Add acquire/release variants for getAndSet and getAndAdd http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/specdiff/overview-summary.html The set of access modes are expanded for support bitwise or/and/xor operations for volatile/acquire/release. Acquire/release getAndAdd and getAndSet access modes are also added (a future webrev will remove getAndAdd). This gets closer to parity with C++ atomics. As a follow on i will: - update the Hotspot Unsafe tests as a separate issue (the VarHandle tests implicitly test the Unsafe methods). - log HotSpot bugs for making the Unsafe bitwise atomics intrinsic for various platforms. Thanks, Paul. From Paul.Sandoz at oracle.com Wed Aug 10 00:15:27 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Tue, 9 Aug 2016 17:15:27 -0700 Subject: RFR 8162106 Remove VarHandle.addAndGet Message-ID: <760C271E-43C2-418B-8480-6C4A403FCAC6@oracle.com> Hi, Please review the following webrev which removes VarHandle.addAndGet: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ This turns out to be really just a helper method which is built upon getAndAdd. I had to update some classes in j.u.concurrent.atomics. Thanks, Paul. From weijun.wang at oracle.com Wed Aug 10 01:25:58 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Aug 2016 09:25:58 +0800 Subject: How to change locale in a Windows terminal? Message-ID: <77e948e8-6181-08ec-f451-f8fafbb21d78@oracle.com> My Windows 10 is English, but I want the java command to show Chinese help screen temporarily. I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works. Thanks Max From rednaxelafx at gmail.com Wed Aug 10 01:33:14 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 9 Aug 2016 18:33:14 -0700 Subject: How to change locale in a Windows terminal? In-Reply-To: <77e948e8-6181-08ec-f451-f8fafbb21d78@oracle.com> References: <77e948e8-6181-08ec-f451-f8fafbb21d78@oracle.com> Message-ID: Hi Max, Does setting -Duser.country=CN work for you? (I don't remember what the correct name for China should be, but setting that to US forces java to print the help message in English) - Kris On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang wrote: > My Windows 10 is English, but I want the java command to show Chinese help > screen temporarily. > > I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works. > > Thanks > Max > > From weijun.wang at oracle.com Wed Aug 10 02:52:25 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Aug 2016 10:52:25 +0800 Subject: How to change locale in a Windows terminal? In-Reply-To: References: <77e948e8-6181-08ec-f451-f8fafbb21d78@oracle.com> Message-ID: <2844d3cf-b07b-4daf-2927-599fb9f91afa@oracle.com> Hi Kris Yes, it works, with -Duser.language. Unfortunately, I am looking for a way to change the default/initial locale, and then using these system properties to change the effective locale again. :-) Precisely, there is a test using grep to match warning messages and on a Chinese Windows it cannot find the hardcoded English text. Since I only have Windows in English, I need to a way to mimic a Chinese Windows first, and then see if adding -Duser.language=en -Duser.country=US to the test will make it work again. On a Mac it's much easier. Thanks Max On 8/10/2016 9:33, Krystal Mok wrote: > Hi Max, > > Does setting -Duser.country=CN work for you? (I don't remember what the > correct name for China should be, but setting that to US forces java to > print the help message in English) > > - Kris > > On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang > wrote: > > My Windows 10 is English, but I want the java command to show > Chinese help screen temporarily. > > I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works. > > Thanks > Max > > From naoto.sato at oracle.com Wed Aug 10 04:34:18 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 9 Aug 2016 21:34:18 -0700 Subject: How to change locale in a Windows terminal? In-Reply-To: <2844d3cf-b07b-4daf-2927-599fb9f91afa@oracle.com> References: <77e948e8-6181-08ec-f451-f8fafbb21d78@oracle.com> <2844d3cf-b07b-4daf-2927-599fb9f91afa@oracle.com> Message-ID: <87ce7bfb-f68e-391e-26ce-b69425fb31c5@oracle.com> Hi Max, Java's default locale follows the default UI Language on Windows. So your Windows has to have Chinese UI package installed and selected as the default UI language. I don't have Windows 10 at hand, but Windows used to be capable of downloading/installing UI language packs on certain flavor of their Windows variations. Naoto On 8/9/16 7:52 PM, Weijun Wang wrote: > Hi Kris > > Yes, it works, with -Duser.language. > > Unfortunately, I am looking for a way to change the default/initial > locale, and then using these system properties to change the effective > locale again. :-) > > Precisely, there is a test using grep to match warning messages and on a > Chinese Windows it cannot find the hardcoded English text. Since I only > have Windows in English, I need to a way to mimic a Chinese Windows > first, and then see if adding -Duser.language=en -Duser.country=US to > the test will make it work again. > > On a Mac it's much easier. > > Thanks > Max > > On 8/10/2016 9:33, Krystal Mok wrote: >> Hi Max, >> >> Does setting -Duser.country=CN work for you? (I don't remember what the >> correct name for China should be, but setting that to US forces java to >> print the help message in English) >> >> - Kris >> >> On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang > > wrote: >> >> My Windows 10 is English, but I want the java command to show >> Chinese help screen temporarily. >> >> I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works. >> >> Thanks >> Max >> >> From volker.simonis at gmail.com Wed Aug 10 07:34:14 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Aug 2016 09:34:14 +0200 Subject: What's correct: "--modulepath" or "--module-path"? In-Reply-To: <9effb20a-5aa4-1050-db00-4c69aed3367a@oracle.com> References: <9effb20a-5aa4-1050-db00-4c69aed3367a@oracle.com> Message-ID: Hi Alan, thanks for the link, Volker On Mon, Aug 8, 2016 at 7:40 PM, Alan Bateman wrote: > On 08/08/2016 18:17, Volker Simonis wrote: > >> Hi, >> >> currently (in jdk9/dev), tools like jlink/jmod support only >> "--modulepath" but not "--module-path". But notice that they support >> "--class-path" and "--module-version". As far as I can see, JEP 293: >> Guidelines for JDK Command-Line Tool Options [1] recommends >> "--module-path". >> > The changes to align with JEP 293 aren't in jdk9/dev yet but Mandy is in the > process of bringing the changes in (discussion is on jigsaw-dev [1]). > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009025.html From frank.yuan at oracle.com Wed Aug 10 08:06:46 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 10 Aug 2016 16:06:46 +0800 Subject: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently Message-ID: <04b301d1f2de$2832e2a0$7898a7e0$@oracle.com> Hi, Would you like to review http://cr.openjdk.java.net/~fyuan/8163468/webrev.00/ It is to fix https://bugs.openjdk.java.net/browse/JDK-8163468 Please check the bug comment for the root cause, this patch moved the code which requires file permission to the main test method, that can guarantee to have the permission. And try to wait the children threads to complete in the main test method, that make the test method more graceful. Thanks Frank From claes.redestad at oracle.com Wed Aug 10 09:13:29 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 10 Aug 2016 11:13:29 +0200 Subject: RFR 8162106 Remove VarHandle.addAndGet In-Reply-To: <760C271E-43C2-418B-8480-6C4A403FCAC6@oracle.com> References: <760C271E-43C2-418B-8480-6C4A403FCAC6@oracle.com> Message-ID: <57AAF039.9020603@oracle.com> On 2016-08-10 02:15, Paul Sandoz wrote: > Hi, > > Please review the following webrev which removes VarHandle.addAndGet: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ Changes look good in general, but unless I'm reading this wrong it seems some of the tests covered overflows previously, but no longer does so. In: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template.udiff.html ... instead of: $type$ o = ($type$) hs.get(TestAccessMode.GET_AND_ADD).invokeExact(recv, $value2$); assertEquals(o, $value1$, "getAndAdd $type$"); $type$ x = ($type$) hs.get(TestAccessMode.GET).invokeExact(recv); assertEquals(x, ($type$)($value1$ + $value2$), "getAndAdd $type$ value"); ... consider doing something like this: $type$ o = ($type$) hs.get(TestAccessMode.GET_AND_ADD).invokeExact(recv, $value2$); assertEquals(o, $value1$, "getAndAdd $type$"); o = ($type$) hs.get(TestAccessMode.GET_AND_ADD).invokeExact(recv, $value2$); assertEquals(o, ($type$)($value1$ + $value2$), "getAndAdd $type$"); $type$ x = ($type$) hs.get(TestAccessMode.GET).invokeExact(recv); assertEquals(x, ($type$)($value1$ + $value2$ + $value2$), "get $type$ value"); Thanks! /Claes > > This turns out to be really just a helper method which is built upon getAndAdd. > > I had to update some classes in j.u.concurrent.atomics. > > Thanks, > Paul. From claes.redestad at oracle.com Wed Aug 10 09:32:18 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 10 Aug 2016 11:32:18 +0200 Subject: RFR 8161444 VarHandles should provide access bitwise atomics In-Reply-To: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> References: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> Message-ID: <57AAF4A2.2040008@oracle.com> On 2016-08-10 02:14, Paul Sandoz wrote: > Hi > > Please review the following webrev which combines: > > 8161444 VarHandles should provide access bitwise atomics > 8162107 Add acquire/release variants for getAndSet and getAndAdd > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/specdiff/overview-summary.html Looks good to me! /Claes From daniel.fuchs at oracle.com Wed Aug 10 11:17:24 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 10 Aug 2016 12:17:24 +0100 Subject: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently In-Reply-To: <04b301d1f2de$2832e2a0$7898a7e0$@oracle.com> References: <04b301d1f2de$2832e2a0$7898a7e0$@oracle.com> Message-ID: <365f2126-764b-8ea3-0824-f2cf0f9c3208@oracle.com> Hi Frank, Good analysis of the failure root cause! The proposed fix looks good to me. As a side note, are there other multi-threaded tests in JAXP? If so maybe you'll need a special method in JAXPSecurityManager to transfer the permissions of the current to another thread (I mean - find a way to make the other thread run its runnable in a similar runWithTmpPermission(...) call than the main thread, I believe InheritableThreadLocal would not be appropriate nor sufficient for that). JAXP multi-threaded tests might need to be revisited with that in mind. best regards, -- daniel On 10/08/16 09:06, Frank Yuan wrote: > Hi, > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8163468/webrev.00/ > > It is to fix https://bugs.openjdk.java.net/browse/JDK-8163468 > > > > Please check the bug comment for the root cause, this patch moved the code which requires file permission to the main test method, > that can guarantee to have the permission. And try to wait the children threads to complete in the main test method, that make the > test method more graceful. > > > > > > Thanks > > Frank > From Roger.Riggs at Oracle.com Wed Aug 10 13:43:39 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 10 Aug 2016 09:43:39 -0400 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> Message-ID: <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> Hi Ivan, The change looks fine. For the tests, is there an @requires for memory that would allow the test to run if the heap was really large. Mostly it would have the same effect at @ignore but would be explicit about its requirements. Roger On 8/9/2016 8:12 PM, Ivan Gerasimov wrote: > Hello! > > Two classes from java.io package may experience the integer overflow > problem in their read() methods. > Would you please help review the obvious fix? > > The regression tests are @ignored by default, as they require 4+ GB of > the heap to run. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163518 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163518/00/webrev/ > > With kind regards, > Ivan > > From claes.redestad at oracle.com Wed Aug 10 14:17:30 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 10 Aug 2016 16:17:30 +0200 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: <5E236A42-1557-479D-B9E9-4588BB096DD6@oracle.com> References: <57A9F800.2060409@oracle.com> <5E236A42-1557-479D-B9E9-4588BB096DD6@oracle.com> Message-ID: <57AB377A.9000702@oracle.com> On 2016-08-10 02:02, Mandy Chung wrote: >> On Aug 9, 2016, at 8:34 AM, Claes Redestad wrote: >> >> Hi, >> >> please review this patch to replace reflection calls into java.lang.invoke from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 > MemberName.java > Since JavaLangInvokeAccess is now extended for other purpose, MemberName doesn?t seem the most appropriate place to set JavaLangInvokeAccess. Maybe Vladimir or other can recommend another class to setJavaLangInvokeAccess. If it stays in MemberName, can you move line 1156-1157 to JavaLangInvokeAccess interface. Per suggestion from Vladimir I've moved the JLIA definition to MethodHandleImpl. > > GenerateJLIClassesHelper > I actually think it?s better to keep the generate* methods in BoundMethodHandle and DirectMethodHandle is better, closer to the relevant context/impl. This helper class doesn?t seem necessary. Vladimir asked me to do it like this, since isolating as much as possible of the logic pertaining to the plugin better allows us to keep the concerns separate and reduce distracting alternative code paths in core j.l.invoke code that is not relevant to normal execution. > > GenerateJLIClassesPlugin.java > Would be good to make JLIA final. Done. http://cr.openjdk.java.net/~redestad/8163373/webrev.02/ /Claes > > Otherwise looks okay. > Mandy From paul.sandoz at oracle.com Wed Aug 10 14:37:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 07:37:24 -0700 Subject: RFR 8162106 Remove VarHandle.addAndGet In-Reply-To: <57AAF039.9020603@oracle.com> References: <760C271E-43C2-418B-8480-6C4A403FCAC6@oracle.com> <57AAF039.9020603@oracle.com> Message-ID: <48ECE675-621C-4839-BF59-A66FECAF1545@oracle.com> Hi Claes, Thanks for the review. The previous incarnation of those tests was awkwardly designed to test a combination of getAndAdd and addAndGet rather than test specifically for overflow. With the removal of addAndGet i simplified it to be the same as the acquire/release variants. Paul. > On 10 Aug 2016, at 02:13, Claes Redestad wrote: > > > > On 2016-08-10 02:15, Paul Sandoz wrote: >> Hi, >> >> Please review the following webrev which removes VarHandle.addAndGet: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ > > Changes look good in general, but unless I'm reading this wrong it seems some of the tests covered overflows previously, but no longer does so. > > In: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template.udiff.html > > ... instead of: > > $type$ o = ($type$) hs.get(TestAccessMode.GET_AND_ADD).invokeExact(recv, $value2$); > assertEquals(o, $value1$, "getAndAdd $type$"); > $type$ x = ($type$) hs.get(TestAccessMode.GET).invokeExact(recv); > assertEquals(x, ($type$)($value1$ + $value2$), "getAndAdd $type$ value"); > > ... consider doing something like this: > > $type$ o = ($type$) hs.get(TestAccessMode.GET_AND_ADD).invokeExact(recv, $value2$); > assertEquals(o, $value1$, "getAndAdd $type$"); > o = ($type$) hs.get(TestAccessMode.GET_AND_ADD).invokeExact(recv, $value2$); > assertEquals(o, ($type$)($value1$ + $value2$), "getAndAdd $type$"); > $type$ x = ($type$) hs.get(TestAccessMode.GET).invokeExact(recv); > assertEquals(x, ($type$)($value1$ + $value2$ + $value2$), "get $type$ value"); > > Thanks! > > /Claes > >> >> This turns out to be really just a helper method which is built upon getAndAdd. >> >> I had to update some classes in j.u.concurrent.atomics. > > > > > > > > >> >> Thanks, >> Paul. > From aleksey.shipilev at gmail.com Wed Aug 10 15:07:34 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 18:07:34 +0300 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: <57A9C6E1.4060100@oracle.com> References: <57A9C6E1.4060100@oracle.com> Message-ID: <6738afda-5626-eeef-3912-1fa0b0fb1660@gmail.com> On 08/09/2016 03:04 PM, Claes Redestad wrote: > please review this set of small changes to reduce the number of classes > defined and pulled in when initializing java.lang.invoke > > Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 I'm too late here, but the change in StringConcatFactory code style is for the worse, IMO. Having a switch over enum does add readability. You might get the same class-count reduce effect by exposing the RecipeElement.tag as byte/int and switching over it. Thanks, -Aleksey From aleksey.shipilev at gmail.com Wed Aug 10 15:20:50 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 18:20:50 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> Message-ID: <03ce3ac1-93b3-62bf-aa02-c08071578869@gmail.com> On 08/10/2016 03:12 AM, Ivan Gerasimov wrote: > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163518 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163518/00/webrev/ Looks good to me. Thanks, -Aleksey From claes.redestad at oracle.com Wed Aug 10 15:20:26 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 10 Aug 2016 17:20:26 +0200 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: <6738afda-5626-eeef-3912-1fa0b0fb1660@gmail.com> References: <57A9C6E1.4060100@oracle.com> <6738afda-5626-eeef-3912-1fa0b0fb1660@gmail.com> Message-ID: <57AB463A.4050102@oracle.com> On 2016-08-10 17:07, Aleksey Shipilev wrote: > On 08/09/2016 03:04 PM, Claes Redestad wrote: >> please review this set of small changes to reduce the number of classes >> defined and pulled in when initializing java.lang.invoke >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 > I'm too late here, but the change in StringConcatFactory code style is > for the worse, IMO. Having a switch over enum does add readability. You > might get the same class-count reduce effect by exposing the > RecipeElement.tag as byte/int and switching over it. Not sure I agree on readability, but using a int/byte works for me. Do we expect the number of tags to increase over time? If you insist I have a few other startup-oriented micro-optimizations I'd like to try out on StringConcatFactory (mostly silly things). I could create an RFE for that and reverse switch-cases into that. /Claes From aleksey.shipilev at gmail.com Wed Aug 10 15:29:59 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 18:29:59 +0300 Subject: RFR 8162106 Remove VarHandle.addAndGet In-Reply-To: <48ECE675-621C-4839-BF59-A66FECAF1545@oracle.com> References: <760C271E-43C2-418B-8480-6C4A403FCAC6@oracle.com> <57AAF039.9020603@oracle.com> <48ECE675-621C-4839-BF59-A66FECAF1545@oracle.com> Message-ID: On 08/10/2016 05:37 PM, Paul Sandoz wrote: > Please review the following webrev which removes > VarHandle.addAndGet: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ The removal looks good. +1 from me. > The previous incarnation of those tests was awkwardly designed to > test a combination of getAndAdd and addAndGet rather than test > specifically for overflow. With the removal of addAndGet i simplified > it to be the same as the acquire/release variants. Yes, and the overflow tests should really be more complex anyway: e.g. for sub-long getAndAdd we should check that we did not accidentally overflow into the adjacent element. Thanks, -Aleksey From claes.redestad at oracle.com Wed Aug 10 15:27:13 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 10 Aug 2016 17:27:13 +0200 Subject: RFR 8162106 Remove VarHandle.addAndGet In-Reply-To: References: <760C271E-43C2-418B-8480-6C4A403FCAC6@oracle.com> <57AAF039.9020603@oracle.com> <48ECE675-621C-4839-BF59-A66FECAF1545@oracle.com> Message-ID: <57AB47D1.4090909@oracle.com> On 2016-08-10 17:29, Aleksey Shipilev wrote: > On 08/10/2016 05:37 PM, Paul Sandoz wrote: >> Please review the following webrev which removes >> VarHandle.addAndGet: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162106-vhs-rm-addAndGet/webrev/ > The removal looks good. +1 from me. > >> The previous incarnation of those tests was awkwardly designed to >> test a combination of getAndAdd and addAndGet rather than test >> specifically for overflow. With the removal of addAndGet i simplified >> it to be the same as the acquire/release variants. > Yes, and the overflow tests should really be more complex anyway: e.g. > for sub-long getAndAdd we should check that we did not accidentally > overflow into the adjacent element. Good point. Is there an RFE for this? /Claes From aleksey.shipilev at gmail.com Wed Aug 10 15:34:46 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 18:34:46 +0300 Subject: RFR: 8163370: Reduce number of classes loaded by common usage of java.lang.invoke In-Reply-To: <57AB463A.4050102@oracle.com> References: <57A9C6E1.4060100@oracle.com> <6738afda-5626-eeef-3912-1fa0b0fb1660@gmail.com> <57AB463A.4050102@oracle.com> Message-ID: <227ea8e3-f2ee-dad7-ef3b-f6e90437849b@gmail.com> On 08/10/2016 06:20 PM, Claes Redestad wrote: > On 2016-08-10 17:07, Aleksey Shipilev wrote: >> On 08/09/2016 03:04 PM, Claes Redestad wrote: >>> please review this set of small changes to reduce the number of classes >>> defined and pulled in when initializing java.lang.invoke >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163370 >> I'm too late here, but the change in StringConcatFactory code style is >> for the worse, IMO. Having a switch over enum does add readability. You >> might get the same class-count reduce effect by exposing the >> RecipeElement.tag as byte/int and switching over it. > > Not sure I agree on readability, but using a int/byte works for me. Do > we expect the number of tags to increase over time? We used to have much more tags than \1 and \2, we might introduce more in a backwards-compatible manner. Maybe syncing up RecipeElement.tag values with the actual tag values from the recipe could count as cleanup. I.e. make RecipeElement store either TAG_CONST or TAG_ARG in its "tag" field, and later switch over the tags. Thanks, -Aleksey From mandy.chung at oracle.com Wed Aug 10 16:16:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Aug 2016 09:16:07 -0700 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: <57AB377A.9000702@oracle.com> References: <57A9F800.2060409@oracle.com> <5E236A42-1557-479D-B9E9-4588BB096DD6@oracle.com> <57AB377A.9000702@oracle.com> Message-ID: > On Aug 10, 2016, at 7:17 AM, Claes Redestad wrote: > > > > On 2016-08-10 02:02, Mandy Chung wrote: >>> On Aug 9, 2016, at 8:34 AM, Claes Redestad wrote: >>> >>> Hi, >>> >>> please review this patch to replace reflection calls into java.lang.invoke from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 >> MemberName.java >> Since JavaLangInvokeAccess is now extended for other purpose, MemberName doesn?t seem the most appropriate place to set JavaLangInvokeAccess. Maybe Vladimir or other can recommend another class to setJavaLangInvokeAccess. If it stays in MemberName, can you move line 1156-1157 to JavaLangInvokeAccess interface. > > Per suggestion from Vladimir I've moved the JLIA definition to MethodHandleImpl. > That?s a good place to set JLIA. >> >> GenerateJLIClassesHelper >> I actually think it?s better to keep the generate* methods in BoundMethodHandle and DirectMethodHandle is better, closer to the relevant context/impl. This helper class doesn?t seem necessary. > > Vladimir asked me to do it like this, since isolating as much as possible of the logic pertaining to the plugin better allows us to keep the concerns separate and reduce distracting alternative code paths in core j.l.invoke code that is not relevant to normal execution. > OK. >> >> GenerateJLIClassesPlugin.java >> Would be good to make JLIA final. > > Done. > > http://cr.openjdk.java.net/~redestad/8163373/webrev.02/ Looks fine to me. Mandy From mandy.chung at oracle.com Wed Aug 10 16:21:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Aug 2016 09:21:30 -0700 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> Message-ID: <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> > On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ This looks pretty good. Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. Mandy From aleksey.shipilev at gmail.com Wed Aug 10 16:41:18 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 19:41:18 +0300 Subject: RFR 8161444 VarHandles should provide access bitwise atomics In-Reply-To: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> References: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> Message-ID: <13ac843d-82f6-001e-9d51-c7dc378dfcd3@gmail.com> On 08/10/2016 03:14 AM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ *) I probably missed this discussion, but why do we have bitwise ops on boolean? I don't think boolean is a integral type to have exposed bit representation. (Edit: this seems useful to get atomic {add, or, xor} over the booleans themselves, not their "bits" -- confusing at first.) *) I wonder if weakCASAcquire is redundant in cases like these, and relaxed weakCAS can be used instead? You definitely need weakCAS{Volatile|Release} for *{Volatile|Release} methods, but *Acquire seems special -- we would only exit with the value "acquired" by the get*Acquire read inside the loop: @ForceInline public final int getAndAddIntAcquire(Object o, long offset, int delta) { int v; do { v = getIntAcquire(o, offset); } while (!weakCompareAndSwapIntAcquire(o, offset, v, v + return v; } Thanks, -Aleksey From huizhe.wang at oracle.com Wed Aug 10 16:48:14 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 10 Aug 2016 09:48:14 -0700 Subject: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently In-Reply-To: <365f2126-764b-8ea3-0824-f2cf0f9c3208@oracle.com> References: <04b301d1f2de$2832e2a0$7898a7e0$@oracle.com> <365f2126-764b-8ea3-0824-f2cf0f9c3208@oracle.com> Message-ID: <57AB5ACE.50904@oracle.com> +1, good to identify the cause. -Joe On 8/10/16, 4:17 AM, Daniel Fuchs wrote: > Hi Frank, > > Good analysis of the failure root cause! > > The proposed fix looks good to me. > > As a side note, are there other multi-threaded tests in JAXP? > > If so maybe you'll need a special method in JAXPSecurityManager > to transfer the permissions of the current to another thread > (I mean - find a way to make the other thread run its > runnable in a similar runWithTmpPermission(...) call > than the main thread, I believe InheritableThreadLocal would not > be appropriate nor sufficient for that). > > JAXP multi-threaded tests might need to be revisited with that > in mind. > > best regards, > > -- daniel > > > On 10/08/16 09:06, Frank Yuan wrote: >> Hi, >> >> >> >> Would you like to review >> http://cr.openjdk.java.net/~fyuan/8163468/webrev.00/ >> >> It is to fix https://bugs.openjdk.java.net/browse/JDK-8163468 >> >> >> >> Please check the bug comment for the root cause, this patch moved the >> code which requires file permission to the main test method, >> that can guarantee to have the permission. And try to wait the >> children threads to complete in the main test method, that make the >> test method more graceful. >> >> >> >> >> >> Thanks >> >> Frank >> > From vladimir.x.ivanov at oracle.com Wed Aug 10 17:21:42 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Aug 2016 10:21:42 -0700 Subject: RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke In-Reply-To: References: <57A9F800.2060409@oracle.com> <5E236A42-1557-479D-B9E9-4588BB096DD6@oracle.com> <57AB377A.9000702@oracle.com> Message-ID: >> http://cr.openjdk.java.net/~redestad/8163373/webrev.02/ Looks good. Best regards, Vladimir Ivanov From hboehm at google.com Wed Aug 10 17:31:17 2016 From: hboehm at google.com (Hans Boehm) Date: Wed, 10 Aug 2016 10:31:17 -0700 Subject: RFR 8161444 VarHandles should provide access bitwise atomics In-Reply-To: <13ac843d-82f6-001e-9d51-c7dc378dfcd3@gmail.com> References: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> <13ac843d-82f6-001e-9d51-c7dc378dfcd3@gmail.com> Message-ID: On Wed, Aug 10, 2016 at 9:41 AM, Aleksey Shipilev < aleksey.shipilev at gmail.com> wrote: > ... > *) I wonder if weakCASAcquire is redundant in cases like these, and > relaxed weakCAS can be used instead? You definitely need > weakCAS{Volatile|Release} for *{Volatile|Release} methods, but *Acquire > seems special -- we would only exit with the value "acquired" by the > get*Acquire read inside the loop: > > @ForceInline > public final int getAndAddIntAcquire(Object o, long offset, int delta) { > int v; > do { > v = getIntAcquire(o, offset); > } while (!weakCompareAndSwapIntAcquire(o, offset, v, v + > return v; > } > I would have written this with a plain initial get and acquire CAS. I always think of the get as only providing a hint, and the CAS as doing the work. Hans > > Thanks, > -Aleksey > From pbenedict at apache.org Wed Aug 10 17:34:27 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 10 Aug 2016 12:34:27 -0500 Subject: RFE to re-purpose option --version: In-Reply-To: <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> Message-ID: Many, thanks again for following up. Unfortunately, the "release" file is not available in my operating environment. The installed JDK/JRE images on my servers have been slimmed down by system administrators. I suppose my recourse will simply have to be executing Java twice -- once for the version check (piping, parsing, etc.) and another if the check succeeds. I wanted to avoid this situation but I don't see another avenue as of today. Anecdotally, sometimes there is a delay in spinning up Java the first time, but it doesn't always happen, and I also don't understand why (especially since it's just to spit out the version). When Claes opined earlier, he considered my proposal a "niche use case" but I don't share that opinion. In my experience with Java on the server-side, I find three perspectives on booting applications: (1) Just assume the right Java version (runtime exceptions will let you know otherwise) (2) Check the Java version first via shell scripting (3) Check the Java version first in application main() My proposal aims to make case #1 inexcusable, improve the usability of case #2, and eliminate the need for case #3. In my world, servers usually have multiple versions of Java installed. Some applications can run without error on multiple Java versions, but policy dictates just one (for such reasons like QA and/or maintaining vendor support). So I don't consider this proposal to be all that niche. It really comes down to verifying the platform major version (and possibly minor version) before going any further. Cheers, Paul On Tue, Aug 9, 2016 at 12:30 PM, Mandy Chung wrote: > If you are only looking for the version, would JAVA_VERSION satisfy your > need? JAVA_FULL_VERSION is only present in JDK and JRE image but not custom > image since the property is supplied by the jdk build. > > Mandy > > > On Aug 9, 2016, at 9:49 AM, Paul Benedict wrote: > > > > No, I haven't considered that. Thank you, Mandy. Good tip. And I see > that file also contains JAVA_FULL_VERSION, whose value is identical to the > -fullversion option output. > > > > Cheers, > > Paul > > > > On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung > wrote: > > > > > On Aug 8, 2016, at 8:51 AM, Paul Benedict > wrote: > > > > > > However, I would like to propose bringing back the option with a > different > > > purpose. I would like to use --version: as a validation > check. I > > > want Java to execute ONLY if the version specified matches the actual > > > platform version. This would be a wonderful help to scripts that > require a > > > particular version of the Java platform, and should fail if the > environment > > > has been accidentally setup with the wrong Java platform version. > > > > > > Examples: > > > java --version:9 > > > java --version:9.1 > > > > > > AFAICT, the only way to do this now is to execute Java twice. Once to > pipe > > > --version to some find/grep command and check return code, and then > execute > > > java again if the check pass. Loading the runtime twice is not optimal, > > > wouldn't you agree? Yet if you agree to this proposal, it would be a > big > > > win for script writers, I believe. > > > > Have you considered checking the JAVA_VERSION property in > $JAVA_HOME/release file? jlink creates the `release` file containing > certain properties about the runtime image. > > > > Mandy > > > > From ivan.gerasimov at oracle.com Wed Aug 10 17:55:35 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 10 Aug 2016 20:55:35 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> Message-ID: <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> Thank you Roger and Aleksey for reviews! On 10.08.2016 16:43, Roger Riggs wrote: > Hi Ivan, > > The change looks fine. > > For the tests, is there an @requires for memory that would allow the > test to run if the heap was really large. > Mostly it would have the same effect at @ignore but would be explicit > about its requirements. > Good point. I've just found out that there's os.maxMemory property recognized by @requires tag, so I used it in place of @ignored. Additionally, yet another source of numeric overflow was just discovered (that is in CharArrayReader.skip()), so here's the updated webrev. http://cr.openjdk.java.net/~igerasim/8163518/01/webrev/ Would you please help review it once again? With kind regards, Ivan From paul.sandoz at oracle.com Wed Aug 10 18:25:44 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 11:25:44 -0700 Subject: RFR 8161444 VarHandles should provide access bitwise atomics In-Reply-To: References: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> <13ac843d-82f6-001e-9d51-c7dc378dfcd3@gmail.com> Message-ID: <54E4FB37-8C95-48F5-A0B5-4AA86F3395F7@oracle.com> > On 10 Aug 2016, at 10:31, Hans Boehm wrote: > > > > On Wed, Aug 10, 2016 at 9:41 AM, Aleksey Shipilev > wrote: > > ... > > > *) I wonder if weakCASAcquire is redundant in cases like these, and > > relaxed weakCAS can be used instead? You definitely need > > weakCAS{Volatile|Release} for *{Volatile|Release} methods, but *Acquire > > seems special -- we would only exit with the value "acquired" by the > > get*Acquire read inside the loop: > > > > @ForceInline > > public final int getAndAddIntAcquire(Object o, long offset, int delta) { > > int v; > > do { > > v = getIntAcquire(o, offset); > > } while (!weakCompareAndSwapIntAcquire(o, offset, v, v + > > return v; > > } > > > I would have written this with a plain initial get and acquire CAS. I always think of the get as only providing a hint, and the CAS as doing the work. > That makes sense to me. I will update and include a comment noting the hint (memo to self: we need jcstress tests for these). Thanks, Paul. From mandy.chung at oracle.com Wed Aug 10 18:31:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Aug 2016 11:31:53 -0700 Subject: RFE to re-purpose option --version: In-Reply-To: References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> Message-ID: <35007DB9-DBC5-42DC-BE56-6F3A9A2BA408@oracle.com> `release` contains the version info you need and the file is very small that I don?t see any issue having it on a production system. I think it doesn?t worth the effort to add ?-version:9 in the launcher. Mandy > On Aug 10, 2016, at 10:34 AM, Paul Benedict wrote: > > Many, thanks again for following up. Unfortunately, the "release" file is not available in my operating environment. The installed JDK/JRE images on my servers have been slimmed down by system administrators. I suppose my recourse will simply have to be executing Java twice -- once for the version check (piping, parsing, etc.) and another if the check succeeds. I wanted to avoid this situation but I don't see another avenue as of today. Anecdotally, sometimes there is a delay in spinning up Java the first time, but it doesn't always happen, and I also don't understand why (especially since it's just to spit out the version). > > When Claes opined earlier, he considered my proposal a "niche use case" but I don't share that opinion. In my experience with Java on the server-side, I find three perspectives on booting applications: > (1) Just assume the right Java version (runtime exceptions will let you know otherwise) > (2) Check the Java version first via shell scripting > (3) Check the Java version first in application main() > > My proposal aims to make case #1 inexcusable, improve the usability of case #2, and eliminate the need for case #3. In my world, servers usually have multiple versions of Java installed. Some applications can run without error on multiple Java versions, but policy dictates just one (for such reasons like QA and/or maintaining vendor support). So I don't consider this proposal to be all that niche. It really comes down to verifying the platform major version (and possibly minor version) before going any further. > > Cheers, > Paul > > On Tue, Aug 9, 2016 at 12:30 PM, Mandy Chung wrote: > If you are only looking for the version, would JAVA_VERSION satisfy your need? JAVA_FULL_VERSION is only present in JDK and JRE image but not custom image since the property is supplied by the jdk build. > > Mandy > > > On Aug 9, 2016, at 9:49 AM, Paul Benedict wrote: > > > > No, I haven't considered that. Thank you, Mandy. Good tip. And I see that file also contains JAVA_FULL_VERSION, whose value is identical to the -fullversion option output. > > > > Cheers, > > Paul > > > > On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung wrote: > > > > > On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote: > > > > > > However, I would like to propose bringing back the option with a different > > > purpose. I would like to use --version: as a validation check. I > > > want Java to execute ONLY if the version specified matches the actual > > > platform version. This would be a wonderful help to scripts that require a > > > particular version of the Java platform, and should fail if the environment > > > has been accidentally setup with the wrong Java platform version. > > > > > > Examples: > > > java --version:9 > > > java --version:9.1 > > > > > > AFAICT, the only way to do this now is to execute Java twice. Once to pipe > > > --version to some find/grep command and check return code, and then execute > > > java again if the check pass. Loading the runtime twice is not optimal, > > > wouldn't you agree? Yet if you agree to this proposal, it would be a big > > > win for script writers, I believe. > > > > Have you considered checking the JAVA_VERSION property in $JAVA_HOME/release file? jlink creates the `release` file containing certain properties about the runtime image. > > > > Mandy > > > > From martinrb at google.com Wed Aug 10 18:36:49 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Aug 2016 11:36:49 -0700 Subject: RFE to re-purpose option --version: In-Reply-To: References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> Message-ID: On Wed, Aug 10, 2016 at 10:34 AM, Paul Benedict wrote: > Unfortunately, the "release" file is > not available in my operating environment. The installed JDK/JRE images on > my servers have been slimmed down by system administrators. Your system administrators have __broken__ the installed JDK/JRE images! From paul.sandoz at oracle.com Wed Aug 10 18:41:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 11:41:12 -0700 Subject: RFR 8161444 VarHandles should provide access bitwise atomics In-Reply-To: <13ac843d-82f6-001e-9d51-c7dc378dfcd3@gmail.com> References: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> <13ac843d-82f6-001e-9d51-c7dc378dfcd3@gmail.com> Message-ID: <2C7F8784-9F8E-4D92-B95C-B08ED1BF9213@oracle.com> > On 10 Aug 2016, at 09:41, Aleksey Shipilev wrote: > > On 08/10/2016 03:14 AM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ > > *) I probably missed this discussion, but why do we have bitwise ops on > boolean? I don't think boolean is a integral type to have exposed bit > representation. (Edit: this seems useful to get atomic {add, or, xor} > over the booleans themselves, not their "bits" -- confusing at first.) > I included boolean for completeness, but i agree it?s a little confusing, it should be a ?Logical? in this context e.g.: https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.22.2 Perhaps we can add a note stating this? Paul. From pbenedict at apache.org Wed Aug 10 18:52:04 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 10 Aug 2016 13:52:04 -0500 Subject: RFE to re-purpose option --version: In-Reply-To: References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> Message-ID: Martin, what do you have in mind when saying it's "broken"? Functionally, everything is fine -- I can delete "release" locally without issue (so it appears) -- so I imagine there's humor here I am missing? :-) Cheers, Paul On Wed, Aug 10, 2016 at 1:36 PM, Martin Buchholz wrote: > > > On Wed, Aug 10, 2016 at 10:34 AM, Paul Benedict > wrote: > >> Unfortunately, the "release" file is >> not available in my operating environment. The installed JDK/JRE images on >> my servers have been slimmed down by system administrators. > > > Your system administrators have __broken__ the installed JDK/JRE images! > From aleksey.shipilev at gmail.com Wed Aug 10 19:40:12 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 22:40:12 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> Message-ID: On 08/10/2016 08:55 PM, Ivan Gerasimov wrote: > http://cr.openjdk.java.net/~igerasim/8163518/01/webrev/ > > Would you please help review it once again? I wonder, shouldn't it be (n <= k) here: 164 long k = count - pos; 165 if (n < k) { 166 k = (n <= 0) ? 0 : n; 167 } 168 pos += k; 169 return k; "k" is the max number of chars to skip. It should be possible to skip all remaining chars when (n == k), right? Thanks, -Aleksey From Roger.Riggs at Oracle.com Wed Aug 10 19:52:42 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 10 Aug 2016 15:52:42 -0400 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> Message-ID: <2a56b327-f486-b8dd-534e-f7dbbb31088c@Oracle.com> Hi, It might be simpler to use: k = Math.max(n, 0); // non-negative or zero k = Math.min(k, count - pos); // the smaller of the request and what's available (or combine in a single expression) Roger On 8/10/2016 3:40 PM, Aleksey Shipilev wrote: > On 08/10/2016 08:55 PM, Ivan Gerasimov wrote: >> http://cr.openjdk.java.net/~igerasim/8163518/01/webrev/ >> >> Would you please help review it once again? > I wonder, shouldn't it be (n <= k) here: > > 164 long k = count - pos; > 165 if (n < k) { > 166 k = (n <= 0) ? 0 : n; > 167 } > 168 pos += k; > 169 return k; > > "k" is the max number of chars to skip. It should be possible to skip > all remaining chars when (n == k), right? > > Thanks, > -Aleksey > > > From aleksey.shipilev at gmail.com Wed Aug 10 19:54:04 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 22:54:04 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> Message-ID: On 08/10/2016 10:40 PM, Aleksey Shipilev wrote: > On 08/10/2016 08:55 PM, Ivan Gerasimov wrote: >> http://cr.openjdk.java.net/~igerasim/8163518/01/webrev/ >> >> Would you please help review it once again? > > I wonder, shouldn't it be (n <= k) here: > > 164 long k = count - pos; > 165 if (n < k) { > 166 k = (n <= 0) ? 0 : n; > 167 } > 168 pos += k; > 169 return k; > > "k" is the max number of chars to skip. It should be possible to skip > all remaining chars when (n == k), right? Wait, the code confused me. Of course, when (n == k), we have a proper "k" already. Suggestion: let's not be overly cunning, and do a clearly understandable boundary recovery: long k = count - pos; if (n > k) { // overflow n = k; } if (n < 0) { // underflow n = 0; } pos += n; return n; This is similar to other two changed pieces. Thanks, -Aleksey From paul.sandoz at oracle.com Wed Aug 10 20:49:30 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 13:49:30 -0700 Subject: RFR 8161444 VarHandles should provide access bitwise atomics In-Reply-To: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> References: <171F6FC1-87C4-4D9D-A89F-BA1D4A25413A@oracle.com> Message-ID: <939240B0-6262-4CF7-8FE1-2DEB511DC343@oracle.com> Hi, I updated the webrev in place. The doc of each bitwise access mode now includes: *

If the variable type is the non-integral {@code boolean} type then a * logical OR is performed instead of a bitwise OR. The unsafe bitwise acquire CAS methods have: @ForceInline public final int getAndBitwiseOrIntAcquire(Object o, long offset, int mask) { int current; do { // Plain read, the value is a hint, the acquire CAS does the work current = getInt(o, offset); } while (!weakCompareAndSwapIntAcquire(o, offset, current, current | mask)); return current; } Thanks, Paul. > On 9 Aug 2016, at 17:14, Paul Sandoz wrote: > > Hi > > Please review the following webrev which combines: > > 8161444 VarHandles should provide access bitwise atomics > 8162107 Add acquire/release variants for getAndSet and getAndAdd > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/specdiff/overview-summary.html > > The set of access modes are expanded for support bitwise or/and/xor operations for volatile/acquire/release. Acquire/release getAndAdd and getAndSet access modes are also added (a future webrev will remove getAndAdd). This gets closer to parity with C++ atomics. > > As a follow on i will: > > - update the Hotspot Unsafe tests as a separate issue (the VarHandle tests implicitly test the Unsafe methods). > > - log HotSpot bugs for making the Unsafe bitwise atomics intrinsic for various platforms. > > Thanks, > Paul. From claes.redestad at oracle.com Wed Aug 10 20:58:22 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 10 Aug 2016 22:58:22 +0200 Subject: RFR: 8163814: JDK build has been failing after 8163373 Message-ID: <57AB956E.9080501@oracle.com> Hi, missed adding src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java to the outgoing changeset for 8163373, breaking the build. Please approve pushing it under this bug ID ASAP: http://cr.openjdk.java.net/~redestad/8163373/webrev.02/src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java.html Thanks, and sorry /Claes From michael.haupt at oracle.com Wed Aug 10 21:01:28 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 10 Aug 2016 14:01:28 -0700 Subject: RFR: 8163814: JDK build has been failing after 8163373 In-Reply-To: <57AB956E.9080501@oracle.com> References: <57AB956E.9080501@oracle.com> Message-ID: Hi Claes, thumbs *way* up. Thanks, Michael > Am 10.08.2016 um 13:58 schrieb Claes Redestad : > > Hi, > > missed adding src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java to the outgoing changeset for 8163373, breaking the build. > > Please approve pushing it under this bug ID ASAP: http://cr.openjdk.java.net/~redestad/8163373/webrev.02/src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java.html > > Thanks, and sorry > > /Claes > -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From mandy.chung at oracle.com Wed Aug 10 21:01:46 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Aug 2016 14:01:46 -0700 Subject: RFR: 8163814: JDK build has been failing after 8163373 In-Reply-To: <57AB956E.9080501@oracle.com> References: <57AB956E.9080501@oracle.com> Message-ID: <69D5C88E-B91A-4E01-96C7-0C71AD45B47D@oracle.com> +1 > On Aug 10, 2016, at 1:58 PM, Claes Redestad wrote: > > Hi, > > missed adding src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java to the outgoing changeset for 8163373, breaking the build. > > Please approve pushing it under this bug ID ASAP: http://cr.openjdk.java.net/~redestad/8163373/webrev.02/src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java.html > > Thanks, and sorry > > /Claes > From peter.levart at gmail.com Wed Aug 10 21:06:17 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 10 Aug 2016 23:06:17 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> Message-ID: <51639efb-8fc9-24a8-bfb4-d8e3a23e2660@gmail.com> Hi Daniel, This is not strictly necessary, but here are a couple of things you might consider doing while changing this code: Using new JDK 8 Map API, the following could be simplified: 580 static synchronized void add(Level l) { 581 purge(); 582 // the mirroredLevel object is always added to the list 583 // before the custom Level instance 584 KnownLevel o = new KnownLevel(l); 585 List list = nameToLevels.get(l.name); 586 if (list == null) { 587 list = new ArrayList<>(); 588 nameToLevels.put(l.name, list); 589 } 590 list.add(o); 591 592 list = intToLevels.get(l.value); 593 if (list == null) { 594 list = new ArrayList<>(); 595 intToLevels.put(l.value, list); 596 } 597 list.add(o); 598 } into... static synchronized void add(Level l) { purge(); KnownLevel o = new KnownLevel(l); nameToLevels.computeIfAbsent(l.name, n -> new ArrayList<>()).add(o); intToLevels.computeIfAbsent(l.value, v -> new ArrayList<>()).add(o); } Removing a KnownLevel could also remove ArrayList(s) when they become empty: 561 private void remove() { 562 Optional.ofNullable(nameToLevels.get(mirroredLevel.name)).ifPresent((x) -> x.remove(this)); 563 Optional.ofNullable(intToLevels.get(mirroredLevel.value)).ifPresent((x) -> x.remove(this)); 564 } ... private void remove() { nameToLevels.computeIfPresent(mirroredLevel.name, (n, l) -> l.remove(this) && l.isEmpty() ? null : l); intToLevels.computeIfPresent(mirroredLevel.value, (v, l) -> l.remove(this) && l.isEmpty() ? null : l); } Regards, Peter And if you implement Mandy's suggestion to return Optional On 08/10/2016 06:21 PM, Mandy Chung wrote: >> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ > This looks pretty good. > > Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. > > Mandy From huizhe.wang at oracle.com Wed Aug 10 22:35:17 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 10 Aug 2016 15:35:17 -0700 Subject: RFR (JAXP) 8163535: javax/xml/jaxp/unittest/catalog/CatalogSupport2.java failed due to SocketTimeoutException Message-ID: <57ABAC25.2010609@oracle.com> Hi, These tests shall accept any IOException. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8163535 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8163535/webrev/ Thanks, Joe From martinrb at google.com Wed Aug 10 22:46:10 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Aug 2016 15:46:10 -0700 Subject: RFE to re-purpose option --version: In-Reply-To: References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> Message-ID: On Wed, Aug 10, 2016 at 11:52 AM, Paul Benedict wrote: > Martin, what do you have in mind when saying it's "broken"? Functionally, > everything is fine -- I can delete "release" locally without issue (so it > appears) -- so I imagine there's humor here I am missing? :-) > The release file is a user interface. Removing it is just like removing any other part of the product (e.g. bin/javap) that users may have built a dependency on. It's broken, just not totally broken! From ivan.gerasimov at oracle.com Wed Aug 10 23:20:07 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 11 Aug 2016 02:20:07 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> Message-ID: <4bee41c0-95b9-c27e-04bf-b104a813ba54@oracle.com> Okay, I simplified that confusing part of the fix and made a minimal change to minimize chances of any unintended changes in behavior. http://cr.openjdk.java.net/~igerasim/8163518/02/webrev/ Is it good to push now? Btw, that @requires (os.simpleArch == "x64" & os.maxMemory > XX) logic works quite well. I've seen that on different hosts one, two or all three tests were run, depending on the environment. I think, we may consider enabling some of the memory-demanding tests that are currently ignored. With kind regards, Ivan From paul.sandoz at oracle.com Thu Aug 11 00:03:21 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 17:03:21 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet Message-ID: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> Hi Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/ This is a refactoring to produce a consistent naming scheme for the VarHandle Read Modify Write (RMW) methods. The unqualified methods default to volatile access. (And i hope this is the last modifying to the API signatures) This touches 166 classes that use or refer to the weak plain/volatile methods. The plan is to follow up deprecating (*not* for removal) the weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add weakCompareAndSetPlain methods. Analysis via grepcode shows very little usages of the Atomic*.weakCompareAndSet methods. A further plan is to rename the Unsafe methods s/Swap/Set, add Plain qualifier etc. Paul. From martinrb at google.com Thu Aug 11 01:34:38 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Aug 2016 18:34:38 -0700 Subject: RFR: jsr166 jdk9 integration wave 9 Message-ID: Again, no spec changes, but larger than expected. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ --- Joe and Amy may be interested in http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/test-stabilization/ where we rewrite flaky tests with new mechanisms that are hopefully less flaky. We have some footprint tests that try to catch memory leaks, using reflective methods that the jigsaw folks might frown upon. There seems to be a need for module-privileged code for e.g. whitebox testing and running a debugger. Perhaps these tests will be an example of code so privileged, someday. Or we could decide such tests are more trouble than they're worth and simply discard them. From frank.yuan at oracle.com Thu Aug 11 03:30:52 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 11 Aug 2016 11:30:52 +0800 Subject: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently In-Reply-To: <365f2126-764b-8ea3-0824-f2cf0f9c3208@oracle.com> References: <04b301d1f2de$2832e2a0$7898a7e0$@oracle.com> <365f2126-764b-8ea3-0824-f2cf0f9c3208@oracle.com> Message-ID: <01bd01d1f380$c7f39d50$57dad7f0$@oracle.com> Hi Daniel Thank you very much for review! > -----Original Message----- > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] > Subject: Re: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently > > Hi Frank, > > Good analysis of the failure root cause! > > The proposed fix looks good to me. > > As a side note, are there other multi-threaded tests in JAXP? > I searched yesterday, there is no other such issue in jaxp tests. E.g. common.WarningsTestBase also starts multiple threads in its test method, but it already awaitTermination in the test method. Another one is stream.Bug6688002Test, which uses Thread.join() in its test method. > If so maybe you'll need a special method in JAXPSecurityManager > to transfer the permissions of the current to another thread > (I mean - find a way to make the other thread run its > runnable in a similar runWithTmpPermission(...) call > than the main thread, I believe InheritableThreadLocal would not > be appropriate nor sufficient for that). > Because the System SecurityManager and the java.security.Policy instance are global, the children threads have the same SM and Policy as the main thread. In this test failure, the childrent threads had enough permission until TestNG invoked onFinish(because the code in test method finished), in the call-back function JAXPPolicyManager restored the default SM and Policy, which had no enough permission. In the race condition, children thread got a non-null SecurityManager and then got the default Policy. So the challenge is how to keep the TestPolicy till the children threads finish. I can use a read-write lock, the children threads hold the read lock and JAXPPolicyManager needs to get the write lock before it sets SM and Policy, but this is actually equivalent to Thread.join() in the test method, and I think it's reasonable to wait for all children threads finished in the test method. This test failure is very frequent in Mach5, since current proposed fix is also OK to you and Joe, I pushed it at first :) Thanks Frank > JAXP multi-threaded tests might need to be revisited with that > in mind. > > best regards, > > -- daniel > > > On 10/08/16 09:06, Frank Yuan wrote: > > Hi, > > > > > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8163468/webrev.00/ > > > > It is to fix https://bugs.openjdk.java.net/browse/JDK-8163468 > > > > > > > > Please check the bug comment for the root cause, this patch moved the code which requires file permission to the main test method, > > that can guarantee to have the permission. And try to wait the children threads to complete in the main test method, that make the > > test method more graceful. > > > > > > > > > > > > Thanks > > > > Frank > > From aleksey.shipilev at gmail.com Thu Aug 11 04:09:13 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 11 Aug 2016 07:09:13 +0300 Subject: [9] RFR 8163518: Integer overflow in StringBufferInputStream.read(byte[], int, int) and CharArrayReader.read(char[], int, int) In-Reply-To: <4bee41c0-95b9-c27e-04bf-b104a813ba54@oracle.com> References: <88375f1d-3e5f-1b7b-6d75-0503982fc092@oracle.com> <042b992e-faf7-9692-a183-0598060587b4@Oracle.com> <2e14c100-d0ce-b0c7-5847-ddeaa77773d4@oracle.com> <4bee41c0-95b9-c27e-04bf-b104a813ba54@oracle.com> Message-ID: Yes, looks good. Thanks, -Aleksey On Thu, Aug 11, 2016 at 2:20 AM, Ivan Gerasimov wrote: > Okay, I simplified that confusing part of the fix and made a minimal > change to minimize chances of any unintended changes in behavior. > > http://cr.openjdk.java.net/~igerasim/8163518/02/webrev/ > > Is it good to push now? > > Btw, that @requires (os.simpleArch == "x64" & os.maxMemory > XX) logic > works quite well. > I've seen that on different hosts one, two or all three tests were run, > depending on the environment. > I think, we may consider enabling some of the memory-demanding tests that > are currently ignored. > > With kind regards, > Ivan > > From david.holmes at oracle.com Thu Aug 11 04:29:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Aug 2016 14:29:03 +1000 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: <4605bfdd-232d-dceb-74a9-8aaf5c6be6ee@oracle.com> Hi Martin, On 11/08/2016 11:34 AM, Martin Buchholz wrote: > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ The StampedLock functional changes look okay. Thanks, David > --- > > Joe and Amy may be interested in > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/test-stabilization/ > where we rewrite flaky tests with new mechanisms that are hopefully less > flaky. > > We have some footprint tests that try to catch memory leaks, using > reflective methods that the jigsaw folks might frown upon. There seems > to be a need for module-privileged code for e.g. whitebox testing and > running a debugger. Perhaps these tests will be an example of code so > privileged, someday. Or we could decide such tests are more trouble > than they're worth and simply discard them. From sha.jiang at oracle.com Thu Aug 11 06:30:36 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 11 Aug 2016 14:30:36 +0800 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> References: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> Message-ID: Hi, Please review another updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all The above line shouldn't be removed, and 8031555 should be replaced by 6902121. Because JDK-8031555 is closed as a duplicate of JDK-6902121, which is still open. Best regards, John Jiang On 2016/8/9 21:17, John Jiang wrote: > Hi Daniel, > Thanks for your review! > > Please take a look at this updated webrev: > http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ > > Best regards, > John Jiang > > > On 2016/8/9 17:53, Daniel Fuchs wrote: >> Hi John, >> >> JDK-8061177 [1] has been resolved as a duplicate of >> JDK-8065756 [2] which is still open. >> The correct action for this one might be to leave the >> test in the problem list but change the bug ID. >> >> The rest looks good to me - even though >> two of these test have been fixed by either adding >> diagnosis information or fixed as 'Cannot Reproduce'. >> >> Since most of these tests are in the serviceability >> area however, it might be good to get someone from >> serviceability-dev (added in cc:) to confirm whether >> they want to get these out of the problem list. >> >> best regards, >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8061177 >> [2] https://bugs.openjdk.java.net/browse/JDK-8065756 >> >> -- daniel >> >> On 09/08/16 09:34, John Jiang wrote: >>> Hi, >>> The below issues have been closed, >>> JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, >>> JDK-8031555 >>> but the associated items still be contained by ProblemList.txt. This >>> small patch removes them. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 >>> >>> Best regards, >>> John Jiang >>> >> >> > > From daniel.fuchs at oracle.com Thu Aug 11 09:29:10 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 11 Aug 2016 10:29:10 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> Message-ID: On 10/08/16 17:21, Mandy Chung wrote: >> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >> > >> > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ > This looks pretty good. > > Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. We need to return KnownLevel because sometimes we need the level object and sometimes the mirror. I tried returning Optional but it does not make the code any simpler. best regards, -- daniel From frank.yuan at oracle.com Thu Aug 11 09:31:18 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 11 Aug 2016 17:31:18 +0800 Subject: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently In-Reply-To: <57AB5ACE.50904@oracle.com> References: <04b301d1f2de$2832e2a0$7898a7e0$@oracle.com> <365f2126-764b-8ea3-0824-f2cf0f9c3208@oracle.com> <57AB5ACE.50904@oracle.com> Message-ID: <01f801d1f3b3$1ea6f9d0$5bf4ed70$@oracle.com> > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Subject: Re: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently > > +1, good to identify the cause. Amy helped me to identify it, so thanks to Amy! Frank > > -Joe > > On 8/10/16, 4:17 AM, Daniel Fuchs wrote: > > Hi Frank, > > > > Good analysis of the failure root cause! > > > > The proposed fix looks good to me. > > > > As a side note, are there other multi-threaded tests in JAXP? > > > > If so maybe you'll need a special method in JAXPSecurityManager > > to transfer the permissions of the current to another thread > > (I mean - find a way to make the other thread run its > > runnable in a similar runWithTmpPermission(...) call > > than the main thread, I believe InheritableThreadLocal would not > > be appropriate nor sufficient for that). > > > > JAXP multi-threaded tests might need to be revisited with that > > in mind. > > > > best regards, > > > > -- daniel > > > > > > On 10/08/16 09:06, Frank Yuan wrote: > >> Hi, > >> > >> > >> > >> Would you like to review > >> http://cr.openjdk.java.net/~fyuan/8163468/webrev.00/ > >> > >> It is to fix https://bugs.openjdk.java.net/browse/JDK-8163468 > >> > >> > >> > >> Please check the bug comment for the root cause, this patch moved the > >> code which requires file permission to the main test method, > >> that can guarantee to have the permission. And try to wait the > >> children threads to complete in the main test method, that make the > >> test method more graceful. > >> > >> > >> > >> > >> > >> Thanks > >> > >> Frank > >> > > From daniel.fuchs at oracle.com Thu Aug 11 09:33:54 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 11 Aug 2016 10:33:54 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <51639efb-8fc9-24a8-bfb4-d8e3a23e2660@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <51639efb-8fc9-24a8-bfb4-d8e3a23e2660@gmail.com> Message-ID: <16a28fcb-941c-f04a-80c0-183b8eb99a15@oracle.com> Hi Peter, On 10/08/16 22:06, Peter Levart wrote: > static synchronized void add(Level l) { > purge(); > KnownLevel o = new KnownLevel(l); > nameToLevels.computeIfAbsent(l.name, n -> new ArrayList<>()).add(o); > intToLevels.computeIfAbsent(l.value, v -> new ArrayList<>()).add(o); > } I agree that's a much cleaner piece of code :-) However I purposefully stayed away from lambdas in KnownLevel.add because that will be called in the static initializer of the Level class (when creating standard levels) - and I didn't want to trigger the initialization of the lambda infrastructure too early. This may or may not be an issue any more though. best regards, -- daniel From ramanand.patil at oracle.com Thu Aug 11 14:17:29 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 11 Aug 2016 07:17:29 -0700 (PDT) Subject: RFR: 8161016: Strange behavior of URLConnection with proxy Message-ID: <7f985cb6-480e-497f-aa8f-55598b81df96@default> Hi all, Please review the fix for Bug ?- https://bugs.openjdk.java.net/browse/JDK-8161016 Bug Description: When ProxySelector is present, i.e. there is minimum one proxy set (by System Property or System Default or using Custom ProxySelector implementation) connection should be opened through those set proxies and not through a DIRECT connection. Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.00/ Fix: Instead of falling back to direct connection when last proxy fails to open connection, re-try once with the last proxy. An alternate solution can also be- don't try to open any connection when all set proxies fails to open a connection. Regards, Ramanand. From joe.darcy at oracle.com Thu Aug 11 16:05:40 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Aug 2016 09:05:40 -0700 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: References: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> Message-ID: <87d2d0f4-62e4-a861-52ac-78ccb3433e17@oracle.com> Looks fine; thanks, -Joe On 8/10/2016 11:30 PM, John Jiang wrote: > Hi, > Please review another updated webrev: > http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ > > com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all > The above line shouldn't be removed, and 8031555 should be replaced by > 6902121. > Because JDK-8031555 is closed as a duplicate of JDK-6902121, which is > still open. > > Best regards, > John Jiang > > > On 2016/8/9 21:17, John Jiang wrote: >> Hi Daniel, >> Thanks for your review! >> >> Please take a look at this updated webrev: >> http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ >> >> Best regards, >> John Jiang >> >> >> On 2016/8/9 17:53, Daniel Fuchs wrote: >>> Hi John, >>> >>> JDK-8061177 [1] has been resolved as a duplicate of >>> JDK-8065756 [2] which is still open. >>> The correct action for this one might be to leave the >>> test in the problem list but change the bug ID. >>> >>> The rest looks good to me - even though >>> two of these test have been fixed by either adding >>> diagnosis information or fixed as 'Cannot Reproduce'. >>> >>> Since most of these tests are in the serviceability >>> area however, it might be good to get someone from >>> serviceability-dev (added in cc:) to confirm whether >>> they want to get these out of the problem list. >>> >>> best regards, >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8061177 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8065756 >>> >>> -- daniel >>> >>> On 09/08/16 09:34, John Jiang wrote: >>>> Hi, >>>> The below issues have been closed, >>>> JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, >>>> JDK-8031555 >>>> but the associated items still be contained by ProblemList.txt. This >>>> small patch removes them. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 >>>> >>>> Best regards, >>>> John Jiang >>>> >>> >>> >> >> > From aleksey.shipilev at gmail.com Thu Aug 11 16:39:47 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 11 Aug 2016 19:39:47 +0300 Subject: RFR: 8161016: Strange behavior of URLConnection with proxy In-Reply-To: <7f985cb6-480e-497f-aa8f-55598b81df96@default> References: <7f985cb6-480e-497f-aa8f-55598b81df96@default> Message-ID: <471c04ca-510b-da6b-3245-84475da47e79@gmail.com> On 08/11/2016 05:17 PM, Ramanand Patil wrote: > Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.00/ > > Fix: Instead of falling back to direct connection when last proxy > fails to open connection, re-try once with the last proxy. An > alternate solution can also be- don't try to open any connection when > all set proxies fails to open a connection. I wonder if the code should traverse the last proxy within the loop, not trying to special-case it in the exception handler -- otherwise we would miss logging, exceptions, and ProxySelector notifications coming from the last proxy? E.g. instead of: 1116 } catch (IOException ioex) { 1117 if (p != Proxy.NO_PROXY) { 1118 sel.connectFailed(uri, p.address(), ioex); 1119 if (!it.hasNext()) { 1120 // re-try once with the last Proxy 1121 http = getNewHttpClient(url, p, connectTimeout, false); 1122 http.setReadTimeout(readTimeout); 1123 break; 1124 } 1125 } else { 1126 throw ioex; 1127 } 1128 continue; 1129 } ...do: } catch (IOException ioex) { if (p == Proxy.NO_PROXY) { throw ioex; } sel.connectFailed(uri, p.address(), ioex); if (it.hasNext()) { continue; // try the next Proxy } else { throw ioex; // that was the last Proxy, time to fail } } Thanks, -Aleksey From ivan.gerasimov at oracle.com Thu Aug 11 17:33:42 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 11 Aug 2016 20:33:42 +0300 Subject: RFR 8163877: Tests added in JDK-8163518 fail on some platforms Message-ID: <99b03331-3e19-0fff-c13c-c0e10c13fd0a@oracle.com> Hello! The freshly added tests fail when 32-bit JVM is tested on 64-bit OS. The fix is to use more appropriate condition under the @requires tag. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163877 WEBREV: http://cr.openjdk.java.net/~igerasim/8163877/00/webrev/ With kind regards, Ivan From joe.darcy at oracle.com Thu Aug 11 17:36:34 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Aug 2016 10:36:34 -0700 Subject: RFR 8163877: Tests added in JDK-8163518 fail on some platforms In-Reply-To: <99b03331-3e19-0fff-c13c-c0e10c13fd0a@oracle.com> References: <99b03331-3e19-0fff-c13c-c0e10c13fd0a@oracle.com> Message-ID: Hi Ivan, The change looks okay, but if the test turns out to take a long time to run, I think we should reconsider whether or not the test is worth running all the time. Cheers, -Joe On 8/11/2016 10:33 AM, Ivan Gerasimov wrote: > Hello! > > The freshly added tests fail when 32-bit JVM is tested on 64-bit OS. > > The fix is to use more appropriate condition under the @requires tag. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163877 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163877/00/webrev/ > > With kind regards, > Ivan > From aleksey.shipilev at gmail.com Thu Aug 11 17:40:25 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 11 Aug 2016 20:40:25 +0300 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: On 08/11/2016 04:34 AM, Martin Buchholz wrote: > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is hopefully intrinsified completely? I like the single-CAS version too, but it probably warrants some explanation. Suggestion: "Since there are only two boolean values, single CAS is enough, because there are only two possibilities: a) CAS succeeds: the actual value needed change, and therefore it was a complement of new value; b) CAS fails: the actual value was exactly the new value." Any benchmarks backing up this optimization? Thanks, -Aleksey From claes.redestad at oracle.com Thu Aug 11 17:55:38 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 11 Aug 2016 19:55:38 +0200 Subject: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke Message-ID: <57ACBC1A.3090105@oracle.com> Hi, while further untangling the bootstrap of java.lang.invoke I found a number of trivial/minor/small contrivances, including: - calling of private methods and constants in parent classes generates and heavily exercise synthetic bridge methods; carefully making more of these package-private cleans the air - use of MethodType.parameterList() and .subList() pull in extra classes in places I missed during JDK-8163370 analysis; preferring parameterType/parameterCount/Arrays.copyOf also reduces allocations - removed some pointless bookkeeping and duplicate checks of constant placeholders in InvokerBytecodeGenerator - since I was already changing around in StringConcatFactory I reworked some changes I made during JDK-8163370 that proved controversial Webrev: http://cr.openjdk.java.net/~redestad/8163878/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163878 All in all -45K executed bytecodes and 9 fewer loaded classes in my favored startup test. Thanks! /Claes From martinrb at google.com Thu Aug 11 18:59:43 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Aug 2016 11:59:43 -0700 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev < aleksey.shipilev at gmail.com> wrote: > On 08/11/2016 04:34 AM, Martin Buchholz wrote: > > Again, no spec changes, but larger than expected. > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > jsr166-jdk9-integration/ > > Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is > hopefully intrinsified completely? > Good question. This optimization originated in a suggestion for jdk8, where there are no VarHandles. VarHandle.getAndSet does not know there are only two values for the int, so it is not obvious which one wins. I can imagine getAndSet being compiled to a weak cas loop. > > I like the single-CAS version too, but it probably warrants some > explanation. Suggestion: "Since there are only two boolean values, > single CAS is enough, because there are only two possibilities: a) CAS > succeeds: the actual value needed change, and therefore it was a > complement of new value; b) CAS fails: the actual value was exactly the > new value." > > I like the current terse comment. The natural explanation would be to construct a boolean truth table with all possible inputs and verify we get the right answer. But more trustworthy is the test, I think. > Any benchmarks backing up this optimization? > I measured a reduction in bytecode! Does that count? From mandy.chung at oracle.com Thu Aug 11 19:12:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Aug 2016 12:12:14 -0700 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> Message-ID: <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> > On Aug 11, 2016, at 2:29 AM, Daniel Fuchs wrote: > > On 10/08/16 17:21, Mandy Chung wrote: >>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >>> > >>> > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >> This looks pretty good. >> >> Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. > > We need to return KnownLevel because sometimes we need the > level object and sometimes the mirror. So either findByName(String name, boolean mirror) or two methods: findLevelByName and findMirroredLevelByName?? Or seriously consider to remove KnownLevel class by introducing a new Level subclass with final Level.getName, Level.getLocalizedName, Level.getResourceBundleName methods?? Mandy From lance.andersen at oracle.com Thu Aug 11 19:53:54 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 11 Aug 2016 15:53:54 -0400 Subject: RFR (JAXP) 8163535: javax/xml/jaxp/unittest/catalog/CatalogSupport2.java failed due to SocketTimeoutException In-Reply-To: <57ABAC25.2010609@oracle.com> References: <57ABAC25.2010609@oracle.com> Message-ID: <1B8C8637-E0F1-4CB9-98FE-2906670726BA@oracle.com> +1 Joe Best Lance > On Aug 10, 2016, at 6:35 PM, Joe Wang wrote: > > Hi, > > These tests shall accept any IOException. Please review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8163535 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8163535/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 aleksey.shipilev at gmail.com Thu Aug 11 20:08:23 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 11 Aug 2016 23:08:23 +0300 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: On 08/11/2016 09:59 PM, Martin Buchholz wrote: > On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev >> Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is >> hopefully intrinsified completely? > > Good question. This optimization originated in a suggestion for jdk8, > where there are no VarHandles. > VarHandle.getAndSet does not know there are only two values for the int, > so it is not obvious which one wins. I can imagine getAndSet being > compiled to a weak cas loop. getAndSet/getAndAdd have a nice rationale for x86: they compile to xchg/xadd, respectively. This is what I meant about "intrinsified completely". >> Any benchmarks backing up this optimization? > > I measured a reduction in bytecode! Does that count? I measured x86 instructions count, and you would not believe what it told me! http://cr.openjdk.java.net/~shade/8162805/BooleanGetAndSet.java Thanks, -Aleksey From michael.haupt at oracle.com Thu Aug 11 20:51:28 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 11 Aug 2016 13:51:28 -0700 Subject: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke In-Reply-To: <57ACBC1A.3090105@oracle.com> References: <57ACBC1A.3090105@oracle.com> Message-ID: Hi Claes, thumbs up - I'd appreciate if Aleksey could take a glance at the changes in the String concatenation logic though. Best, Michael > Am 11.08.2016 um 10:55 schrieb Claes Redestad : > > Hi, > > while further untangling the bootstrap of java.lang.invoke I found a number of trivial/minor/small contrivances, including: > > - calling of private methods and constants in parent classes generates and heavily exercise synthetic bridge methods; carefully making more of these package-private cleans the air > - use of MethodType.parameterList() and .subList() pull in extra classes in places I missed during JDK-8163370 analysis; preferring parameterType/parameterCount/Arrays.copyOf also reduces allocations > - removed some pointless bookkeeping and duplicate checks of constant placeholders in InvokerBytecodeGenerator > - since I was already changing around in StringConcatFactory I reworked some changes I made during JDK-8163370 that proved controversial > > Webrev: http://cr.openjdk.java.net/~redestad/8163878/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163878 > > All in all -45K executed bytecodes and 9 fewer loaded classes in my favored startup test. > > Thanks! > > /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From martinrb at google.com Thu Aug 11 20:56:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Aug 2016 13:56:57 -0700 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: Thanks Aleksey, for the usual convincing benchmark result. You win! I can imagine a machine that has a native cas instruction, but no native exchange instruction, but no one ever got fired for optimizing for x86. public final boolean getAndSet(boolean newValue) { return (int)VALUE.getAndSet(this, (newValue ? 1 : 0)) != 0; } On Thu, Aug 11, 2016 at 1:08 PM, Aleksey Shipilev < aleksey.shipilev at gmail.com> wrote: > On 08/11/2016 09:59 PM, Martin Buchholz wrote: > > On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev > >> Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is > >> hopefully intrinsified completely? > > > > Good question. This optimization originated in a suggestion for jdk8, > > where there are no VarHandles. > > VarHandle.getAndSet does not know there are only two values for the int, > > so it is not obvious which one wins. I can imagine getAndSet being > > compiled to a weak cas loop. > > getAndSet/getAndAdd have a nice rationale for x86: they compile to > xchg/xadd, respectively. This is what I meant about "intrinsified > completely". > > >> Any benchmarks backing up this optimization? > > > > I measured a reduction in bytecode! Does that count? > > I measured x86 instructions count, and you would not believe what it > told me! > http://cr.openjdk.java.net/~shade/8162805/BooleanGetAndSet.java > > Thanks, > -Aleksey > > From aleksey.shipilev at gmail.com Thu Aug 11 21:12:34 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 12 Aug 2016 00:12:34 +0300 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: <00703936-fa11-e7db-a9ff-82a9031c2314@gmail.com> On 08/11/2016 11:56 PM, Martin Buchholz wrote: > I can imagine a machine that has a native cas instruction, but no native > exchange instruction, but no one ever got fired for optimizing for x86. ...which would be less of an issue once we switch to proper-boolean VarHandles, not the int-simulation. This way, implementations may choose how to implement boolean getAndSet. Probably in Unsafe, but that would still be lower and more reusable than in AtomicBoolean alone. > public final boolean getAndSet(boolean newValue) { > return (int)VALUE.getAndSet(this, (newValue ? 1 : 0)) != 0; > } Yup. Thanks, -Aleksey From aleksey.shipilev at gmail.com Thu Aug 11 21:48:24 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 12 Aug 2016 00:48:24 +0300 Subject: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke In-Reply-To: References: <57ACBC1A.3090105@oracle.com> Message-ID: <05073853-6e2d-172f-fb4e-cdd5ed9b1e9e@gmail.com> On 08/11/2016 11:51 PM, Michael Haupt wrote: > thumbs up - I'd appreciate if Aleksey could take a glance at the changes in the String concatenation logic though. > > Best, > Michael > >> Am 11.08.2016 um 10:55 schrieb Claes Redestad : >> >> while further untangling the bootstrap of java.lang.invoke I found a number of trivial/minor/small contrivances, including: >> >> - calling of private methods and constants in parent classes generates and heavily exercise synthetic bridge methods; carefully making more of these package-private cleans the air >> - use of MethodType.parameterList() and .subList() pull in extra classes in places I missed during JDK-8163370 analysis; preferring parameterType/parameterCount/Arrays.copyOf also reduces allocations >> - removed some pointless bookkeeping and duplicate checks of constant placeholders in InvokerBytecodeGenerator >> - since I was already changing around in StringConcatFactory I reworked some changes I made during JDK-8163370 that proved controversial >> >> Webrev: http://cr.openjdk.java.net/~redestad/8163878/webrev.01/ *) StringConcatFactory changes look good. I should have used arrays from day one. (Also, my precious switches are back!) *) In LambdaForm.Name: @Stable only works on finals, right? 1411 @Stable short index; Thanks, -Aleksey From john.r.rose at oracle.com Thu Aug 11 22:22:24 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 11 Aug 2016 15:22:24 -0700 Subject: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke In-Reply-To: <05073853-6e2d-172f-fb4e-cdd5ed9b1e9e@gmail.com> References: <57ACBC1A.3090105@oracle.com> <05073853-6e2d-172f-fb4e-cdd5ed9b1e9e@gmail.com> Message-ID: <47F0DC7C-29C4-4E99-ACE8-8C9E05348666@oracle.com> @Stable works on non-final fields as well as array elements. ? John > On Aug 11, 2016, at 2:48 PM, Aleksey Shipilev wrote: > > Stable only works on finals, right? From martinrb at google.com Thu Aug 11 22:59:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Aug 2016 15:59:16 -0700 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: <00703936-fa11-e7db-a9ff-82a9031c2314@gmail.com> References: <00703936-fa11-e7db-a9ff-82a9031c2314@gmail.com> Message-ID: On Thu, Aug 11, 2016 at 2:12 PM, Aleksey Shipilev < aleksey.shipilev at gmail.com> wrote: > On 08/11/2016 11:56 PM, Martin Buchholz wrote: > > I can imagine a machine that has a native cas instruction, but no native > > exchange instruction, but no one ever got fired for optimizing for x86. > > ...which would be less of an issue once we switch to proper-boolean > VarHandles, not the int-simulation. This way, implementations may choose > how to implement boolean getAndSet. Probably in Unsafe, but that would > still be lower and more reusable than in AtomicBoolean alone. > I like the current int simulation, at least for AtomicBoolean. You'll never save space by switching to boolean, because of alignment, and you don't have to worry about machines without byte-sized instructions. But like I always say, "no one ever got fired for optimizing for x86"! From michael.haupt at oracle.com Fri Aug 12 00:27:03 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 11 Aug 2016 17:27:03 -0700 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API Message-ID: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8151179 Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/ The change addresses concerns about the JEP 274 API that were raised by the JCK team. One consequence is that the convenience wrappers for the generic loop combinator are now somewhat restrictive about the handles passed to them as arguments. They have to be created with the appropriate matching signatures. This minor inconvenience is easily overcome by utilising available API such as MethodHandles.constant(), .empty(), or .dropToMatch(). In case the full handle signature inference power is desired, the generic loop combinator, MethodHandles.loop(), still provides this. Most of the changes affect the API documentation, but the behavioural changes in some of the methods also reflect on the pertaining tests. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From claes.redestad at oracle.com Fri Aug 12 12:55:05 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 12 Aug 2016 14:55:05 +0200 Subject: RFR: 8163946: java/lang/String/concat/WithSecurityManager.java fails after 8163878 Message-ID: <57ADC729.5080701@oracle.com> Hi, changing to use GetPropertyAction in MethodHandleImpl unexpectedly caused a nasty bootstrap issue. Moving the MAX_ARITY constant to MethodHandleStatics avoids the issue and might be sensible to do regardless. bug: https://bugs.openjdk.java.net/browse/JDK-8163946 webrev: http://cr.openjdk.java.net/~redestad/8163946/webrev.01/ Thanks! /Claes From michael.haupt at oracle.com Fri Aug 12 15:17:13 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 12 Aug 2016 08:17:13 -0700 Subject: RFR: 8163946: java/lang/String/concat/WithSecurityManager.java fails after 8163878 In-Reply-To: <57ADC729.5080701@oracle.com> References: <57ADC729.5080701@oracle.com> Message-ID: <45E23202-B7D8-4A89-A34C-F6DE4D3C29DD@oracle.com> Hi Claes, thumbs up. Fix those tests. :-) Best, Michael > Am 12.08.2016 um 05:55 schrieb Claes Redestad : > > Hi, > > changing to use GetPropertyAction in MethodHandleImpl unexpectedly caused a nasty bootstrap issue. Moving the MAX_ARITY constant to MethodHandleStatics avoids the issue and might be sensible to do regardless. > > bug: https://bugs.openjdk.java.net/browse/JDK-8163946 > webrev: http://cr.openjdk.java.net/~redestad/8163946/webrev.01/ > > Thanks! > > /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From paul.sandoz at oracle.com Fri Aug 12 18:24:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 12 Aug 2016 11:24:24 -0700 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: Message-ID: <9E2A6A2E-A3C0-46A3-B518-D7FECD7913B2@oracle.com> > On 10 Aug 2016, at 18:34, Martin Buchholz wrote: > > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > Looks good. Paul. From martinrb at google.com Fri Aug 12 19:03:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 12 Aug 2016 12:03:16 -0700 Subject: RFR: jsr166 jdk9 integration wave 9 In-Reply-To: References: <00703936-fa11-e7db-a9ff-82a9031c2314@gmail.com> Message-ID: Another way of looking at it: Machines like the types "int" and "double". Use of float instead of double in an API is almost always a mistake, except to save space for arrays of values. Similarly, it's never worth optimizing a boolean or byte value to actually take up less than 4 bytes, except when storing them in arrays. We don't currently have AtomicBooleanArray (AtomicBitSet?) or AtomicByteArray, although we've gotten to the point where we _could_ have them. On Thu, Aug 11, 2016 at 3:59 PM, Martin Buchholz wrote: > > > On Thu, Aug 11, 2016 at 2:12 PM, Aleksey Shipilev < > aleksey.shipilev at gmail.com> wrote: > >> On 08/11/2016 11:56 PM, Martin Buchholz wrote: >> > I can imagine a machine that has a native cas instruction, but no native >> > exchange instruction, but no one ever got fired for optimizing for x86. >> >> ...which would be less of an issue once we switch to proper-boolean >> VarHandles, not the int-simulation. This way, implementations may choose >> how to implement boolean getAndSet. Probably in Unsafe, but that would >> still be lower and more reusable than in AtomicBoolean alone. >> > > I like the current int simulation, at least for AtomicBoolean. You'll > never save space by switching to boolean, because of alignment, and you > don't have to worry about machines without byte-sized instructions. But > like I always say, "no one ever got fired for optimizing for x86"! > From aleksey.shipilev at gmail.com Fri Aug 12 19:53:24 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 12 Aug 2016 22:53:24 +0300 Subject: RFR: 8163946: java/lang/String/concat/WithSecurityManager.java fails after 8163878 In-Reply-To: <57ADC729.5080701@oracle.com> References: <57ADC729.5080701@oracle.com> Message-ID: <8a720afa-b058-6c51-c456-8b2ebdcbb139@gmail.com> On 08/12/2016 03:55 PM, Claes Redestad wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8163946 > webrev: http://cr.openjdk.java.net/~redestad/8163946/webrev.01/ +1. Welcome to our world (of pain). Please run java/lang/String tests next time anything changes in StringConcatFactory? Thanks, -Aleksey From ramanand.patil at oracle.com Fri Aug 12 19:56:12 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 12 Aug 2016 12:56:12 -0700 (PDT) Subject: RFR: 8161016: Strange behavior of URLConnection with proxy In-Reply-To: <471c04ca-510b-da6b-3245-84475da47e79@gmail.com> References: <7f985cb6-480e-497f-aa8f-55598b81df96@default> <471c04ca-510b-da6b-3245-84475da47e79@gmail.com> Message-ID: Hi Aleksey, Thank you for your review. In the exception handler block: when last proxy fails, it was using a DIRECT connection, but in the fixed version it was just a re-try once with the last proxy before failing the connection. Considering your points I think the alternate approach of not re-trying and just failing after the last proxy is good. I have updated the code slightly which does the same as you suggested. And also updated the test case to use one more dummy proxy in MyProxySelector class. Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.01/ Regards, Ramanand. -----Original Message----- From: Aleksey Shipilev [mailto:aleksey.shipilev at gmail.com] Sent: Thursday, August 11, 2016 10:10 PM To: Ramanand Patil; OpenJDK Network Dev list Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR: 8161016: Strange behavior of URLConnection with proxy On 08/11/2016 05:17 PM, Ramanand Patil wrote: > Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.00/ > > Fix: Instead of falling back to direct connection when last proxy > fails to open connection, re-try once with the last proxy. An > alternate solution can also be- don't try to open any connection when > all set proxies fails to open a connection. I wonder if the code should traverse the last proxy within the loop, not trying to special-case it in the exception handler -- otherwise we would miss logging, exceptions, and ProxySelector notifications coming from the last proxy? E.g. instead of: 1116 } catch (IOException ioex) { 1117 if (p != Proxy.NO_PROXY) { 1118 sel.connectFailed(uri, p.address(), ioex); 1119 if (!it.hasNext()) { 1120 // re-try once with the last Proxy 1121 http = getNewHttpClient(url, p, connectTimeout, false); 1122 http.setReadTimeout(readTimeout); 1123 break; 1124 } 1125 } else { 1126 throw ioex; 1127 } 1128 continue; 1129 } ...do: } catch (IOException ioex) { if (p == Proxy.NO_PROXY) { throw ioex; } sel.connectFailed(uri, p.address(), ioex); if (it.hasNext()) { continue; // try the next Proxy } else { throw ioex; // that was the last Proxy, time to fail } } Thanks, -Aleksey From aleksey.shipilev at gmail.com Fri Aug 12 20:46:52 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 12 Aug 2016 23:46:52 +0300 Subject: RFR: 8161016: Strange behavior of URLConnection with proxy In-Reply-To: References: <7f985cb6-480e-497f-aa8f-55598b81df96@default> <471c04ca-510b-da6b-3245-84475da47e79@gmail.com> Message-ID: <6090798a-e890-9453-fecf-cb82fbefe4c0@gmail.com> On 08/12/2016 10:56 PM, Ramanand Patil wrote: > Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.01/ I think my version (below) is a little more straightforward, but no pressure. Your version is okay too, and does the minimal change. Thumbs up. Thanks, -Aleksey > } catch (IOException ioex) { > if (p == Proxy.NO_PROXY) { > throw ioex; > } > sel.connectFailed(uri, p.address(), ioex); > if (it.hasNext()) { > continue; // try the next Proxy > } else { > throw ioex; // that was the last Proxy, time to fail > } > } > > Thanks, > -Aleksey > From mandy.chung at oracle.com Fri Aug 12 23:55:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Aug 2016 16:55:02 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> Message-ID: <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> > On Aug 8, 2016, at 6:25 PM, Kim Barrett wrote: > > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ This looks very good. Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? Grammar question: "there are no more references? "If there aren't any pending {@link Reference}s" - This is the case with zero pending reference, shouldn?t it use ?is? such that: "there us no more reference? "If there isn't any pending {@link Reference}? Please update the synposis of JDK-8156500 to make it clear what this fix is (it?s nothing related to JDI). Maybe something like ?Move the pending reference list to VM? Mandy From peter.levart at gmail.com Sat Aug 13 08:20:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 13 Aug 2016 10:20:32 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> Message-ID: Hi Mandy, On 08/13/2016 01:55 AM, Mandy Chung wrote: >> On Aug 8, 2016, at 6:25 PM, Kim Barrett wrote: >> >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ > This looks very good. > > Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. > > waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? I think the split is intentional. It's a clever way to avoid an otherwise inevitable race that could otherwise cause DBB allocating thread to fail with OOME prematurely. waitForReferencePendingList() is invoked out of synchronized block so that it does not prevent the progress of thread(s) invoking waitForReferenceProcessing(), while getAndClearReferencePendingList is non-blocking and is invoked inside the synchronized block that also sets a boolean flag. Code in waitForReferenceProcessing() checks both the non-emptiness of reference pending list and the boolean flag while holding the lock. The following sequence of actions (as used in NIO Bits): System.gc(); Reference.waitForReferenceProcessing(); ...therefore either: - completes immediately after System.gc() returns without discovering any pending Reference, returning false; or - completes after System.gc() discovers at least one pending Reference and ReferenceHandler thread processes at least one Cleaner, returning true; or enqueues all pending Reference(s), returning false. When waitForReferenceProcessing() returns false consecutively even after a series of exponentially increasing pauses, the DBB allocating thread(s) can be sure they have exhausted all options to allocate the direct buffer and must fail with OOME. I have a feeling that these pauses are now unnecessary. Will try to check with some experiments... Regards, Peter > Grammar question: > > "there are no more references? > "If there aren't any pending {@link Reference}s" > > - This is the case with zero pending reference, shouldn?t it use ?is? such that: > > "there us no more reference? > "If there isn't any pending {@link Reference}? > > Please update the synposis of JDK-8156500 to make it clear what this fix is (it?s nothing related to JDI). Maybe something like ?Move the pending reference list to VM? > > Mandy From mandy.chung at oracle.com Sat Aug 13 20:07:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 13 Aug 2016 13:07:29 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> Message-ID: > On Aug 13, 2016, at 1:20 AM, Peter Levart wrote: > > Hi Mandy, > > On 08/13/2016 01:55 AM, Mandy Chung wrote: >>> On Aug 8, 2016, at 6:25 PM, Kim Barrett >>> wrote: >>> >>> full: >>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >>> >>> >>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >> This looks very good. >> >> Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. >> >> waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? >> > > I think the split is intentional. It's a clever way to avoid an otherwise inevitable race that could otherwise cause DBB allocating thread to fail with OOME prematurely. > Ah I see. I initially read that pendingList doesn?t need to be set within the synchronized block with processPendingActive flag but such race could cause DBB to fail with OOME, as you clarified. Then I suggest waitForReferencePendingList (and its JVM function) be renamed to: boolean awaitReferencePendingList(); a blocking version of "boolean hasReferencePendingList()?. Minor difference but I think it?s little clearer. waitForReferenceProcessing - I?d like the javadoc to include more details or @implNote for example: This method returns true to indicate that some pending references have been enqueued. If there are cleaners, cleaning actions are queued to be invoked e.g. DirectByteBuffer may be deallocated. This would help the readers to understand what this method is intended to do. Mandy > waitForReferencePendingList() is invoked out of synchronized block so that it does not prevent the progress of thread(s) invoking waitForReferenceProcessing(), while getAndClearReferencePendingList is non-blocking and is invoked inside the synchronized block that also sets a boolean flag. Code in waitForReferenceProcessing() checks both the non-emptiness of reference pending list and the boolean flag while holding the lock. > > The following sequence of actions (as used in NIO Bits): > > System.gc(); > Reference.waitForReferenceProcessing(); > > ...therefore either: > > - completes immediately after System.gc() returns without discovering any pending Reference, returning false; or > - completes after System.gc() discovers at least one pending Reference and ReferenceHandler thread processes at least one Cleaner, returning true; or enqueues all pending Reference(s), returning false. > > When waitForReferenceProcessing() returns false consecutively even after a series of exponentially increasing pauses, the DBB allocating thread(s) can be sure they have exhausted all options to allocate the direct buffer and must fail with OOME. > > I have a feeling that these pauses are now unnecessary. Will try to check with some experiments... > > Regards, Peter > >> Grammar question: >> >> "there are no more references? >> "If there aren't any pending {@link Reference}s" >> >> - This is the case with zero pending reference, shouldn?t it use ?is? such that: >> >> "there us no more reference? >> "If there isn't any pending {@link Reference}? >> >> Please update the synposis of JDK-8156500 to make it clear what this fix is (it?s nothing related to JDI). Maybe something like ?Move the pending reference list to VM? >> >> Mandy >> > From cs at schulte.it Sun Aug 14 01:49:30 2016 From: cs at schulte.it (Christian Schulte) Date: Sun, 14 Aug 2016 03:49:30 +0200 Subject: Executors enhancement In-Reply-To: <57aa0d10.10a81c0a.cf6f6.776f@mx.google.com> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> <57AA06C3.1040702@schulte.it> <57aa0d10.10a81c0a.cf6f6.776f@mx.google.com> Message-ID: <57AFCE2A.1050600@schulte.it> Am 08/09/16 um 19:04 schrieb ecki at zusammenkunft.net: > So it is a good idea to find a good shared default, but an API quite > seldomly can isolate itself and the users about those aspects. So always > allow to provide an alternate Executor. This also helps with thread > naming, thread context, interceptors and error handlers. That way? /** * Gets the {@code ExecutorService} used to run tasks in parallel. *

* The {@code ExecutorService} used to run tasks in parallel is an optional entity. If no such service is * provided by an application, no parallelization is performed. Configuration or lifecycle management of that * {@code ExecutorService} is the responsibility of the application. *

* * @return The {@code ExecutorService} used to run tasks in parallel, or {@code null}. * * @since 1.10 */ public final ExecutorService getExecutorService() { return this.executorService; } /** * Sets the {@code ExecutorService} to be used to run tasks in parallel. * * @param value The {@code ExecutorService} to be used to run tasks in parallel, or {@code null}, to not make use * of any parallelization. * * @since 1.10 */ public final void setExecutorService( final ExecutorService value ) { this.executorService = value; } Regards, -- Christian From ecki at zusammenkunft.net Sun Aug 14 02:21:17 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 14 Aug 2016 04:21:17 +0200 Subject: Executors enhancement In-Reply-To: <57AFCE2A.1050600@schulte.it> References: <57A7BB55.2040003@schulte.it> <57A7C145.40901@oracle.com> <8b5ddb2f-b1ff-3be3-8c4b-116e6cd82dc0@oracle.com> <57AA06C3.1040702@schulte.it> <57aa0d10.10a81c0a.cf6f6.776f@mx.google.com> <57AFCE2A.1050600@schulte.it> Message-ID: <20160814042117.00001ae6.ecki@zusammenkunft.net> Hello, yes, an ExecutorService or Executor or ForkJoinPool depending on the minimum requirements you have. As a default you can eithter use ForJoinPool.commonPool() or Executors.newSingleThreadExecutor() or a DirectExecutor() if you dont want to handle the null case special. BTW: little nit, I would add the long explanation what the ES is used for tho the setter not the getter. Gruss Bernd Am Sun, 14 Aug 2016 03:49:30 +0200 schrieb Christian Schulte : > Am 08/09/16 um 19:04 schrieb ecki at zusammenkunft.net: > > So it is a good idea to find a good shared default, but an API quite > > seldomly can isolate itself and the users about those aspects. So > > always allow to provide an alternate Executor. This also helps with > > thread naming, thread context, interceptors and error handlers. > > That way? > > > /** > * Gets the {@code ExecutorService} used to run tasks in parallel. > *

> * The {@code ExecutorService} used to run tasks in parallel is an > optional entity. If no such service is > * provided by an application, no parallelization is performed. > Configuration or lifecycle management of that > * {@code ExecutorService} is the responsibility of the > application. > *

> * > * @return The {@code ExecutorService} used to run tasks in > parallel, or {@code null}. > * > * @since 1.10 > */ > public final ExecutorService getExecutorService() > { > return this.executorService; > } > > /** > * Sets the {@code ExecutorService} to be used to run tasks in > parallel. * > * @param value The {@code ExecutorService} to be used to run > tasks in parallel, or {@code null}, to not make use > * of any parallelization. > * > * @since 1.10 > */ > public final void setExecutorService( final ExecutorService value > ) { > this.executorService = value; > } > > Regards, From kim.barrett at oracle.com Mon Aug 15 03:15:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 14 Aug 2016 23:15:26 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> Message-ID: <0D58CB68-DE1E-4174-BD99-C1CFFD67C0BB@oracle.com> > On Aug 13, 2016, at 4:20 AM, Peter Levart wrote: > > Hi Mandy, > > On 08/13/2016 01:55 AM, Mandy Chung wrote: >>> On Aug 8, 2016, at 6:25 PM, Kim Barrett >>> wrote: >>> >>> full: >>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >>> >>> >>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >> This looks very good. >> >> Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. >> >> waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? >> > > I think the split is intentional. It's a clever way to avoid an otherwise inevitable race that could otherwise cause DBB allocating thread to fail with OOME prematurely. > > waitForReferencePendingList() is invoked out of synchronized block so that it does not prevent the progress of thread(s) invoking waitForReferenceProcessing(), while getAndClearReferencePendingList is non-blocking and is invoked inside the synchronized block that also sets a boolean flag. Code in waitForReferenceProcessing() checks both the non-emptiness of reference pending list and the boolean flag while holding the lock. > > The following sequence of actions (as used in NIO Bits): > > System.gc(); > Reference.waitForReferenceProcessing(); > > ...therefore either: > > - completes immediately after System.gc() returns without discovering any pending Reference, returning false; or > - completes after System.gc() discovers at least one pending Reference and ReferenceHandler thread processes at least one Cleaner, returning true; or enqueues all pending Reference(s), returning false. > > When waitForReferenceProcessing() returns false consecutively even after a series of exponentially increasing pauses, the DBB allocating thread(s) can be sure they have exhausted all options to allocate the direct buffer and must fail with OOME. Thanks for answering Mandy?s questions for me. That all looks right. > I have a feeling that these pauses are now unnecessary. Will try to check with some experiments? I found that the DirectBufferAllocTest will sometimes fail if the pauses are taken out. I think what?s going on is that the multiple threads are competing for resources, and some threads in that test lose out if all of them are waiting and wake up at the same time. The exponentially increasing back-off scatters the threads enough for that to become very unlikely, though with sufficiently bad luck? But I think the current implementation could also fail that test with similarly bad luck. It just requires *very* bad luck, so we?re not seeing it as a problem. And that test is a pretty extreme stress test. > > Regards, Peter > >> Grammar question: >> >> "there are no more references? >> "If there aren't any pending {@link Reference}s" >> >> - This is the case with zero pending reference, shouldn?t it use ?is? such that: >> >> "there us no more reference? >> "If there isn't any pending {@link Reference}? >> >> Please update the synposis of JDK-8156500 to make it clear what this fix is (it?s nothing related to JDI). Maybe something like ?Move the pending reference list to VM? >> >> Mandy From huaming.li at oracle.com Mon Aug 15 08:12:47 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 15 Aug 2016 16:12:47 +0800 Subject: RFR of JDK9 8162519: Remove ParallelPrefix.java from ProblemList.txt Message-ID: <2941f4c3-3839-8c45-674f-6e70d3f45930@oracle.com> There are 2 issues related to test/java/util/Arrays/ParallelPrefix.java, 1. JDK-8080165, which is marked as samebinary-highfrequency. Based on below information, I think this bug should have been resolved, although I don't know which change set resolve the issue, 1. the last failure happened more than one year before; 2. run 3 loops concurrently, in every loop run ParallelPrefix 1000 times sequentially, PrefixBug(Paul's reproducible code above) is run in below mode on jdk9-b128: java -server -XX:LoopUnrollLimit=0 -XX:TieredStopAtLevel=4 PrefixBug java -server -XX:LoopUnrollLimit=0 PrefixBug java -server PrefixBug 3. issue easily reproduced by build/run "javac/java PrefixBug" on jdk9-b64. 2. JDK-8085982, which is not reproduced. So, I think ParallelPrefix.java should be removed from ProblemList.txt bug: https://bugs.openjdk.java.net/browse/JDK-8162519 webrev: http://cr.openjdk.java.net/~mli/8162519/webrev.00/ Thank you -Hamlin From scolebourne at joda.org Mon Aug 15 10:30:15 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 15 Aug 2016 11:30:15 +0100 Subject: NIO Path enhancements? In-Reply-To: References: Message-ID: Any thoughts on this? Stephen On 8 August 2016 at 18:29, Stephen Colebourne wrote: > I've been using the java.nio.file.Path API in the last few days and > have found it a little tricky to use. I'd like to understand if the > following ideas were ever considered (to consider whether an issue > should be raised). > > Currently, developers create a Path instance and it contains various > methods for managing the path, plus a few that actually access the > filing system. However, for most filing system operations, developers > have to use the static methods on Files. This feels very non-intuitive > and hard to discover. Current code: > > Path path = Paths.get("/my/path/to/file.txt"); > if (Files.exists(path)) { > boolean dir = Files.isDirectory(path); > ... > } > > Almost all methods on Files simply obtain the FileSystemProvider from > the FileSystem and invoke methods on that. Why not add a new class > PathOperations that binds the Path to the static methods? > > Path path = Paths.get("/my/path/to/file.txt"); > if (path.operations().exists()) { > boolean dir = path.operations().isDirectory(); > ... > } > > I can't see any reason why this wouldn't work, but perhaps I'm missing > something obvious. (All methods on Files would need to be replicated > on PathOperations, and maybe Files could be deprecated if the > deprecation tools improve.) > > > Separately, it is a little tricky grasping the ZIP file system, and > that it needs to be opened and closed separately. Could we see a new > method to indicate if a given path/file can be expanded to another > FileSystem? > > if (path.operations().isExpandableToFileSystem()) { > try (FileSystem fs = path.operations().expand()) { > // work with ZIP or similar > } > } > > This would be a lot more discoverable with appropriate docs. > > BTW, this also relates to Jigsaw as the new JFS provider may make > expandable paths more widely used. > > Stephen From michael.haupt at oracle.com Mon Aug 15 15:21:47 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 15 Aug 2016 17:21:47 +0200 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> Message-ID: <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> ... anyone, please? :-) Thanks, Michael > Am 12.08.2016 um 02:27 schrieb Michael Haupt : > > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8151179 > Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/ > > The change addresses concerns about the JEP 274 API that were raised by the JCK team. One consequence is that the convenience wrappers for the generic loop combinator are now somewhat restrictive about the handles passed to them as arguments. They have to be created with the appropriate matching signatures. This minor inconvenience is easily overcome by utilising available API such as MethodHandles.constant(), .empty(), or .dropToMatch(). In case the full handle signature inference power is desired, the generic loop combinator, MethodHandles.loop(), still provides this. > > Most of the changes affect the API documentation, but the behavioural changes in some of the methods also reflect on the pertaining tests. > > Thanks, > > Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Mon Aug 15 17:15:53 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Aug 2016 18:15:53 +0100 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> Message-ID: <57B1F8C9.7010901@redhat.com> Hi, On 27/07/16 12:47, Paul Sandoz wrote: > I made an embarrassing mistake in the fix for > > https://bugs.openjdk.java.net/browse/JDK-8151163 > All Buffer implementations should leverage Unsafe unaligned accessors > > The offset calculation for Unsafe access was incorrect, it?s easy to > get confused because for heap buffers the offset is relative to the > array, and for direct buffers the address (which can update for > slices/duplicates). Disturbingly all existing tests were passing > both for core and hotspot when i pushed to hs. > > As a penance i wrote a combinatorial test for buffer views to > navigate the twisty maze of heap/direct, aligned/unaligned, > little/big endian for accessing binary data and views from the > source buffer. > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162458-byte-buffer-view-offset-access-incorrect/webrev/ has anyone looked at this yet? I've just got back from my travels. Andrew. From aleksej.efimov at oracle.com Mon Aug 15 17:38:54 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 15 Aug 2016 20:38:54 +0300 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions Message-ID: Hi, Please, help to review the fix for memory leak [1] in com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused by usage of static final exceptions. This problem was already fixed in Apache Xerces project [2] and I would like to backport it to JDK9 Xerces implementation. Webrev with the changes: http://cr.openjdk.java.net/~aefimov/8146961/9/00 The Tomcat reproducer attached to the bug report fails without the fix and passes with the fix. The JPRT and JCK testing shows no jaxp tests failures with the proposed fix. With Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8146961 [2] https://issues.apache.org/jira/browse/XERCESJ-1667 From aleksey.shipilev at gmail.com Mon Aug 15 17:40:47 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Mon, 15 Aug 2016 20:40:47 +0300 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <57B1F8C9.7010901@redhat.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> <57B1F8C9.7010901@redhat.com> Message-ID: On 08/15/2016 08:15 PM, Andrew Haley wrote: > has anyone looked at this yet? I've just got back from my travels. I think it was reviewed and committed, as "HG Updater" comments say: https://bugs.openjdk.java.net/browse/JDK-8162458 Thanks, -Aleksey From aleksey.shipilev at gmail.com Mon Aug 15 17:47:12 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Mon, 15 Aug 2016 20:47:12 +0300 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: References: Message-ID: On 08/15/2016 08:38 PM, Aleks Efimov wrote: > This problem was already fixed in Apache Xerces project [2] and I > would like to backport it to JDK9 Xerces implementation. Webrev with > the changes: http://cr.openjdk.java.net/~aefimov/8146961/9/00 Ouch. Looks good. Thanks, -Aleksey From aph at redhat.com Mon Aug 15 17:59:40 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Aug 2016 18:59:40 +0100 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> <57B1F8C9.7010901@redhat.com> Message-ID: <57B2030C.2040600@redhat.com> On 15/08/16 18:40, Aleksey Shipilev wrote: > On 08/15/2016 08:15 PM, Andrew Haley wrote: >> has anyone looked at this yet? I've just got back from my travels. > > I think it was reviewed and committed, as "HG Updater" comments say: > https://bugs.openjdk.java.net/browse/JDK-8162458 Hmm, okay. I didn't see a reply to the email. It's in hs but not hs-comp. Do you have any idea why hs is used and not hs-comp, or vice versa? I'd love to know which one I'm supposed to use for development. Andrew. From huizhe.wang at oracle.com Mon Aug 15 18:09:42 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 15 Aug 2016 11:09:42 -0700 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: References: Message-ID: <57B20566.7040004@oracle.com> Hi Aleksej, I suggest we get rid of the static abort. If RuntimeException happens, check where it happens. The first use case looks suspicious as it just returns if it's an instance of RE. For the 2nd case in DOM error report, let's throw a RuntimeException with the specified error message if error happens, and there's no handler or the handler failed to handle it. (would be better than an empty RE) Best, Joe On 8/15/16, 10:38 AM, Aleks Efimov wrote: > Hi, > > Please, help to review the fix for memory leak [1] in > com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused by > usage of static final exceptions. > This problem was already fixed in Apache Xerces project [2] and I > would like to backport it to JDK9 Xerces implementation. > Webrev with the changes: > http://cr.openjdk.java.net/~aefimov/8146961/9/00 > > The Tomcat reproducer attached to the bug report fails without the fix > and passes with the fix. > The JPRT and JCK testing shows no jaxp tests failures with the > proposed fix. > > With Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8146961 > [2] https://issues.apache.org/jira/browse/XERCESJ-1667 > From aleksey.shipilev at gmail.com Mon Aug 15 18:16:17 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Mon, 15 Aug 2016 21:16:17 +0300 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <57B2030C.2040600@redhat.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> <57B1F8C9.7010901@redhat.com> <57B2030C.2040600@redhat.com> Message-ID: On 08/15/2016 08:59 PM, Andrew Haley wrote: > On 15/08/16 18:40, Aleksey Shipilev wrote: >> On 08/15/2016 08:15 PM, Andrew Haley wrote: >>> has anyone looked at this yet? I've just got back from my travels. >> >> I think it was reviewed and committed, as "HG Updater" comments say: >> https://bugs.openjdk.java.net/browse/JDK-8162458 > > Hmm, okay. I didn't see a reply to the email. > > It's in hs but not hs-comp. Do you have any idea why hs is used and > not hs-comp, or vice versa? I'd love to know which one I'm supposed > to use for development. Paul said in original RFR: "I will push to hs since that is where JDK-8151163 and it has not been integrated into jdk9/dev." http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-July/042605.html This must be one of those cases where deviating from the usual integration paths just snowballs. Waiting for JDK-8151163 to sync down to hs-comp, pushing the patch there, and waiting for hs-comp to integrate back would leave hs broken for too long... Thanks, -Aleksey From claes.redestad at oracle.com Mon Aug 15 18:19:00 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 15 Aug 2016 20:19:00 +0200 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> Message-ID: <57B20794.7090702@oracle.com> On 2016-08-12 02:27, Michael Haupt wrote: > Dear all, > > please review this change. > Bug: https://bugs.openjdk.java.net/browse/JDK-8151179 > Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/ Looks good to me. /Claes > > The change addresses concerns about the JEP 274 API that were raised by the JCK team. One consequence is that the convenience wrappers for the generic loop combinator are now somewhat restrictive about the handles passed to them as arguments. They have to be created with the appropriate matching signatures. This minor inconvenience is easily overcome by utilising available API such as MethodHandles.constant(), .empty(), or .dropToMatch(). In case the full handle signature inference power is desired, the generic loop combinator, MethodHandles.loop(), still provides this. > > Most of the changes affect the API documentation, but the behavioural changes in some of the methods also reflect on the pertaining tests. > > Thanks, > > Michael > From huizhe.wang at oracle.com Mon Aug 15 19:08:45 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 15 Aug 2016 12:08:45 -0700 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: <57B20566.7040004@oracle.com> References: <57B20566.7040004@oracle.com> Message-ID: <57B2133D.3090801@oracle.com> Hi Aleksej, Note that DOM spec about error handling: If errors occur during the invocation of this method, such as an attempt to update a read-only node or a |Node.nodeName| contains an invalid character according to the XML version in use, errors or warnings (|DOMError.SEVERITY_ERROR| or |DOMError.SEVERITY_WARNING|) will be reported using the |DOMErrorHandler| object associated with the "error-handler " parameter. Note this method might also report fatal errors ( |DOMError.SEVERITY_FATAL_ERROR|) if an implementation cannot recover from an error. So in this case, it doesn't seem to be "processing aborted by the user" as noted where RE was caught. When a DOM error happens, e.g. not wellformed, if no errorHandler is registered, the process will abort without an error. It's possible to handle the case without throw&catch RE. Please investigate. Thanks, Joe On 8/15/16, 11:09 AM, Joe Wang wrote: > Hi Aleksej, > > I suggest we get rid of the static abort. If RuntimeException happens, > check where it happens. The first use case looks suspicious as it just > returns if it's an instance of RE. For the 2nd case in DOM error > report, let's throw a RuntimeException with the specified error > message if error happens, and there's no handler or the handler failed > to handle it. (would be better than an empty RE) > > Best, > Joe > > On 8/15/16, 10:38 AM, Aleks Efimov wrote: >> Hi, >> >> Please, help to review the fix for memory leak [1] in >> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused >> by usage of static final exceptions. >> This problem was already fixed in Apache Xerces project [2] and I >> would like to backport it to JDK9 Xerces implementation. >> Webrev with the changes: >> http://cr.openjdk.java.net/~aefimov/8146961/9/00 >> >> The Tomcat reproducer attached to the bug report fails without the >> fix and passes with the fix. >> The JPRT and JCK testing shows no jaxp tests failures with the >> proposed fix. >> >> With Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 >> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 >> From john.r.rose at oracle.com Mon Aug 15 23:39:41 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 15 Aug 2016 16:39:41 -0700 Subject: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API In-Reply-To: <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> References: <44A14FE2-F84F-4ABF-A47F-1F0675F1D7FA@oracle.com> <7C0D47C4-233E-40CA-BE87-82C0FD6378EE@oracle.com> Message-ID: <3FA2149A-C14D-466D-BF5E-2FCAF958F6D4@oracle.com> I'm working on this. The javadoc has some re-filling which creates lots of diffs of whitespace only, which makes things go a little slower. I am trying to like the cleaner, more restricted semantics for the utility methods, but they really do some harm to the use cases. The really notable change is the loss of defaulting behavior of the first parameter to iteratedLoop, which was List::iterator. That was intended to corresponding to the for-each syntax, and it is hard (and probably non-performant) to ask the user to rebuild a MH for Iterable::iterator at each use site for iteratedLoop. ? John On Aug 15, 2016, at 8:21 AM, Michael Haupt wrote: > > ... anyone, please? :-) From david.holmes at oracle.com Tue Aug 16 02:05:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Aug 2016 12:05:00 +1000 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <57B2030C.2040600@redhat.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> <57B1F8C9.7010901@redhat.com> <57B2030C.2040600@redhat.com> Message-ID: <6d716190-6b13-58a5-2ff3-ff7d2d10c9b2@oracle.com> Hi Andrew, On 16/08/2016 3:59 AM, Andrew Haley wrote: > On 15/08/16 18:40, Aleksey Shipilev wrote: >> On 08/15/2016 08:15 PM, Andrew Haley wrote: >>> has anyone looked at this yet? I've just got back from my travels. >> >> I think it was reviewed and committed, as "HG Updater" comments say: >> https://bugs.openjdk.java.net/browse/JDK-8162458 > > Hmm, okay. I didn't see a reply to the email. > > It's in hs but not hs-comp. Do you have any idea why hs is used and > not hs-comp, or vice versa? I'd love to know which one I'm supposed > to use for development. hs-comp is the team forest for the compiler team. If you are working primarily on hotspot compiler issues and want to integrate with latest work the compiler team is doing, and/or you have shared compiler changes, then you would push to hs-comp. All other hotspot changes (runtime, gc, serviceability) now go to the hs forest directly (hs-rt and hs-gc forests no longer operate). David > Andrew. > > From aph at redhat.com Tue Aug 16 08:37:48 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Aug 2016 09:37:48 +0100 Subject: RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access In-Reply-To: <6d716190-6b13-58a5-2ff3-ff7d2d10c9b2@oracle.com> References: <2F815E1E-1DA6-4010-9B39-5D7BBB2DF069@oracle.com> <57B1F8C9.7010901@redhat.com> <57B2030C.2040600@redhat.com> <6d716190-6b13-58a5-2ff3-ff7d2d10c9b2@oracle.com> Message-ID: <57B2D0DC.5080505@redhat.com> On 16/08/16 03:05, David Holmes wrote: > hs-comp is the team forest for the compiler team. If you are working > primarily on hotspot compiler issues and want to integrate with latest > work the compiler team is doing, and/or you have shared compiler > changes, then you would push to hs-comp. > > All other hotspot changes (runtime, gc, serviceability) now go to the hs > forest directly (hs-rt and hs-gc forests no longer operate). OK, I get it now. It's really hard to understand for people outside Oracle, but this is clear enough. Thanks, Andrew. From daniel.fuchs at oracle.com Tue Aug 16 10:42:15 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Aug 2016 11:42:15 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> Message-ID: <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Hi Mandy, I added an additional selector parameter to the find methods. This made it possible to return Optional instead of KnownLevel - and it does simply the parse() method. http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 best regards, -- daniel On 11/08/16 20:12, Mandy Chung wrote: > >> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs wrote: >> >> On 10/08/16 17:21, Mandy Chung wrote: >>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >>>>> >>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>> This looks pretty good. >>> >>> Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. >> >> We need to return KnownLevel because sometimes we need the >> level object and sometimes the mirror. > > So either findByName(String name, boolean mirror) or two methods: findLevelByName and findMirroredLevelByName?? > > Or seriously consider to remove KnownLevel class by introducing a new Level subclass with final Level.getName, Level.getLocalizedName, Level.getResourceBundleName methods?? > > Mandy > From peter.levart at gmail.com Tue Aug 16 12:05:14 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 16 Aug 2016 14:05:14 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Message-ID: <5ec555d2-68f7-52d5-9f6e-6fb1b965db5f@gmail.com> Hi Daniel, Passing Stream returning extractors to Stream::flatMap is one way of doing it. The other would be to make findByXXX methods return Optional and then use Optional::map method on the result to extract the needed property, so instead of: Optional level = findByName(name, KnownLevel::referent); You could simply make findByName return Optional and then: Optional level = findByName(name).map(Reference::get); Just plain null-when-absent-returning getters used with Optional::map would do. Regards, Peter On 08/16/2016 12:42 PM, Daniel Fuchs wrote: > Hi Mandy, > > I added an additional selector parameter to the find methods. > This made it possible to return Optional instead of > KnownLevel - and it does simply the parse() method. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 > > best regards, > > -- daniel > > On 11/08/16 20:12, Mandy Chung wrote: >> >>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>> wrote: >>> >>> On 10/08/16 17:21, Mandy Chung wrote: >>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>> wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>> This looks pretty good. >>>> >>>> Since KnownLevel is now a Reference, I suggest to change >>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>> return Optional instead such that the parse method >>>> implementaiton could be simplified. >>> >>> We need to return KnownLevel because sometimes we need the >>> level object and sometimes the mirror. >> >> So either findByName(String name, boolean mirror) or two methods: >> findLevelByName and findMirroredLevelByName?? >> >> Or seriously consider to remove KnownLevel class by introducing a new >> Level subclass with final Level.getName, Level.getLocalizedName, >> Level.getResourceBundleName methods?? >> >> Mandy >> > From daniel.fuchs at oracle.com Tue Aug 16 12:30:56 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Aug 2016 13:30:56 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <5ec555d2-68f7-52d5-9f6e-6fb1b965db5f@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <5ec555d2-68f7-52d5-9f6e-6fb1b965db5f@gmail.com> Message-ID: <94cc86f5-b653-435f-08f0-f16445d5570a@oracle.com> Hi Peter, On 16/08/16 13:05, Peter Levart wrote: > Hi Daniel, > > Passing Stream returning extractors to Stream::flatMap is one way > of doing it. The other would be to make findByXXX methods return > Optional and then use Optional::map method on the result to > extract the needed property, so instead of: > > Optional level = findByName(name, KnownLevel::referent); > > You could simply make findByName return Optional and then: > > Optional level = findByName(name).map(Reference::get); > > Just plain null-when-absent-returning getters used with Optional::map > would do. Well - not exactly because when looking for levelObject the KnownLevel could become stale after it's returned. What we want is loop until we find a levelObject which is not null (that's why the previous version had some while loops in Level.parse). But maybe I'm misunderstanding what you are saying? best regards, -- daniel > > > Regards, Peter > > On 08/16/2016 12:42 PM, Daniel Fuchs wrote: >> Hi Mandy, >> >> I added an additional selector parameter to the find methods. >> This made it possible to return Optional instead of >> KnownLevel - and it does simply the parse() method. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >> >> best regards, >> >> -- daniel >> >> On 11/08/16 20:12, Mandy Chung wrote: >>> >>>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>>> wrote: >>>> >>>> On 10/08/16 17:21, Mandy Chung wrote: >>>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>>> wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>>> This looks pretty good. >>>>> >>>>> Since KnownLevel is now a Reference, I suggest to change >>>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>>> return Optional instead such that the parse method >>>>> implementaiton could be simplified. >>>> >>>> We need to return KnownLevel because sometimes we need the >>>> level object and sometimes the mirror. >>> >>> So either findByName(String name, boolean mirror) or two methods: >>> findLevelByName and findMirroredLevelByName?? >>> >>> Or seriously consider to remove KnownLevel class by introducing a new >>> Level subclass with final Level.getName, Level.getLocalizedName, >>> Level.getResourceBundleName methods?? >>> >>> Mandy >>> >> > From peter.levart at gmail.com Tue Aug 16 12:52:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 16 Aug 2016 14:52:32 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <94cc86f5-b653-435f-08f0-f16445d5570a@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <5ec555d2-68f7-52d5-9f6e-6fb1b965db5f@gmail.com> <94cc86f5-b653-435f-08f0-f16445d5570a@oracle.com> Message-ID: On 08/16/2016 02:30 PM, Daniel Fuchs wrote: > Hi Peter, > > On 16/08/16 13:05, Peter Levart wrote: >> Hi Daniel, >> >> Passing Stream returning extractors to Stream::flatMap is one way >> of doing it. The other would be to make findByXXX methods return >> Optional and then use Optional::map method on the result to >> extract the needed property, so instead of: >> >> Optional level = findByName(name, KnownLevel::referent); >> >> You could simply make findByName return Optional and then: >> >> Optional level = findByName(name).map(Reference::get); >> >> Just plain null-when-absent-returning getters used with Optional::map >> would do. > > Well - not exactly because when looking for levelObject the KnownLevel > could become stale after it's returned. What we want is loop until > we find a levelObject which is not null (that's why the previous > version had some while loops in Level.parse). Ah, I see. Right. Of course, my bad. In that case, there is a possible race that could lead to exception here: 476 // add new Level. 477 Level levelObject = new Level(name, x); 478 return KnownLevel.findByValue(x, KnownLevel::referent).get(); ...between lines 477 and 478 and between lines 377 and 378, the newly constructed Level object could already get GC-ed and so findByValue could return an empty Optional. You should do something like: Level levelObject = new Level(name, x); Level result = KnownLevel.findByValue(x, KnownLevel::referent).get(); Reference.reachabilityFence(levelObject); return result; Regards, Peter > > But maybe I'm misunderstanding what you are saying? > > best regards, > > -- daniel > >> >> >> Regards, Peter >> >> On 08/16/2016 12:42 PM, Daniel Fuchs wrote: >>> Hi Mandy, >>> >>> I added an additional selector parameter to the find methods. >>> This made it possible to return Optional instead of >>> KnownLevel - and it does simply the parse() method. >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >>> >>> best regards, >>> >>> -- daniel >>> >>> On 11/08/16 20:12, Mandy Chung wrote: >>>> >>>>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>>>> wrote: >>>>> >>>>> On 10/08/16 17:21, Mandy Chung wrote: >>>>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>>>> wrote: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>>>> This looks pretty good. >>>>>> >>>>>> Since KnownLevel is now a Reference, I suggest to change >>>>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>>>> return Optional instead such that the parse method >>>>>> implementaiton could be simplified. >>>>> >>>>> We need to return KnownLevel because sometimes we need the >>>>> level object and sometimes the mirror. >>>> >>>> So either findByName(String name, boolean mirror) or two methods: >>>> findLevelByName and findMirroredLevelByName?? >>>> >>>> Or seriously consider to remove KnownLevel class by introducing a new >>>> Level subclass with final Level.getName, Level.getLocalizedName, >>>> Level.getResourceBundleName methods?? >>>> >>>> Mandy >>>> >>> >> > From ivan.gerasimov at oracle.com Tue Aug 16 12:53:00 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 16 Aug 2016 15:53:00 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code Message-ID: Hello! Here's a cleanup pass through the code in java.io package. Would you please help review? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ With kind regards, Ivan From peter.levart at gmail.com Tue Aug 16 12:59:56 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 16 Aug 2016 14:59:56 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Message-ID: <709e6273-bb64-6c4c-1460-5452637fc2bc@gmail.com> Hi Daniel, Another place that is not clear to me is the following (in old code): 585 // Returns a KnownLevel with the given localized name matching 586 // by calling the Level.getLocalizedLevelName() method (i.e. found 587 // from the resourceBundle associated with the Level object). 588 // This method does not call Level.getLocalizedName() that may 589 // be overridden in a subclass implementation 590 static synchronized KnownLevel findByLocalizedLevelName(String name) { 591 for (List levels : nameToLevels.values()) { 592 for (KnownLevel l : levels) { 593 String lname = l.levelObject.getLocalizedLevelName(); 594 if (name.equals(lname)) { 595 return l; 596 } 597 } 598 } 599 return null; 600 } In spite of claiming that "this method doesn't call Level.getLocalizedName() that may be overridden in subclass", it does just that. it calls the getLocalizedLevelName on the KnownLevel.levelObject, which is a user-constructed object. You changed the code into: 627 static synchronized Optional findByLocalizedLevelName(String name, 628 Function> selector) { 629 purge(); 630 return nameToLevels.values() 631 .stream() 632 .flatMap(List::stream) 633 .flatMap(selector) 634 .filter(lo -> name.equals(lo.getLocalizedLevelName())) 635 .findFirst(); 636 } Which calls getLocalizedName() on the Level object selected by the given selector. In line 385 you pass in the selector to select the mirroredLevel, but in line 487, you pass in the selector to select the referent. So which one is the right one? If you want to obey the comment it should always be the mirroredLevel which is checked against localized name, right? Regards, Peter On 08/16/2016 12:42 PM, Daniel Fuchs wrote: > Hi Mandy, > > I added an additional selector parameter to the find methods. > This made it possible to return Optional instead of > KnownLevel - and it does simply the parse() method. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 > > best regards, > > -- daniel > > On 11/08/16 20:12, Mandy Chung wrote: >> >>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>> wrote: >>> >>> On 10/08/16 17:21, Mandy Chung wrote: >>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>> wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>> This looks pretty good. >>>> >>>> Since KnownLevel is now a Reference, I suggest to change >>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>> return Optional instead such that the parse method >>>> implementaiton could be simplified. >>> >>> We need to return KnownLevel because sometimes we need the >>> level object and sometimes the mirror. >> >> So either findByName(String name, boolean mirror) or two methods: >> findLevelByName and findMirroredLevelByName?? >> >> Or seriously consider to remove KnownLevel class by introducing a new >> Level subclass with final Level.getName, Level.getLocalizedName, >> Level.getResourceBundleName methods?? >> >> Mandy >> > From aleksey.shipilev at gmail.com Tue Aug 16 13:08:37 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Tue, 16 Aug 2016 16:08:37 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: References: Message-ID: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> On 08/16/2016 03:53 PM, Ivan Gerasimov wrote: > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ Both ObjectInputStream and ObjectOutputStream can use auto-unboxing in these blocks? 1271 if (result.booleanValue()) { 1272 return; 1273 } ObjectStreamClass: I wonder if the entire getPackageName is replaceable with Class.getPackageName()? If so, ditch the method completely and use Class.getPackageName everywhere. This may complicate backporting to JDK 8 though. OutputStreamWriter: New code in append(CharSequence,int,int) unnecessarily calls toString on CharBuffers which are handled specially downstream in append(CharSequence). Thanks, -Aleksey From daniel.fuchs at oracle.com Tue Aug 16 13:14:11 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Aug 2016 14:14:11 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <5ec555d2-68f7-52d5-9f6e-6fb1b965db5f@gmail.com> <94cc86f5-b653-435f-08f0-f16445d5570a@oracle.com> Message-ID: <2be86d00-6f96-95d6-50b1-8a6646e74fec@oracle.com> Hi Peter, On 16/08/16 13:52, Peter Levart wrote: > Ah, I see. Right. Of course, my bad. > > In that case, there is a possible race that could lead to exception here: > > 476 // add new Level. > 477 Level levelObject = new Level(name, x); > 478 return KnownLevel.findByValue(x, > KnownLevel::referent).get(); > > ...between lines 477 and 478 and between lines 377 and 378, the newly > constructed Level object could already get GC-ed and so findByValue > could return an empty Optional. > > You should do something like: > > Level levelObject = new Level(name, x); > Level result = KnownLevel.findByValue(x, KnownLevel::referent).get(); > Reference.reachabilityFence(levelObject); > return result; That's what I did in the very first version of the patch, but Chris commented that this was unnecessary because when level.getClass() == Level.class then levelObject == mirroredLevel. Chris found that using Reference.reachabilityFence(levelObject) just added more mystery - so I removed the statement. best regards, -- daniel > > > Regards, Peter From daniel.fuchs at oracle.com Tue Aug 16 13:16:54 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Aug 2016 14:16:54 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <709e6273-bb64-6c4c-1460-5452637fc2bc@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <709e6273-bb64-6c4c-1460-5452637fc2bc@gmail.com> Message-ID: On 16/08/16 13:59, Peter Levart wrote: > Hi Daniel, > > Another place that is not clear to me is the following (in old code): > > 585 // Returns a KnownLevel with the given localized name matching > 586 // by calling the Level.getLocalizedLevelName() method (i.e. found > 587 // from the resourceBundle associated with the Level object). > 588 // This method does not call Level.getLocalizedName() that may > 589 // be overridden in a subclass implementation > 590 static synchronized KnownLevel findByLocalizedLevelName(String name) { > 591 for (List levels : nameToLevels.values()) { > 592 for (KnownLevel l : levels) { > 593 String lname = l.levelObject.getLocalizedLevelName(); > 594 if (name.equals(lname)) { > 595 return l; > 596 } > 597 } > 598 } > 599 return null; > 600 } > > In spite of claiming that "this method doesn't call > Level.getLocalizedName() that may be overridden in subclass", it does > just that. it calls the getLocalizedLevelName on the > KnownLevel.levelObject, which is a user-constructed object. You changed > the code into: > > 627 static synchronized Optional > findByLocalizedLevelName(String name, > 628 Function> selector) { > 629 purge(); > 630 return nameToLevels.values() > 631 .stream() > 632 .flatMap(List::stream) > 633 .flatMap(selector) > 634 .filter(lo -> > name.equals(lo.getLocalizedLevelName())) > 635 .findFirst(); > 636 } > > Which calls getLocalizedName() on the Level object selected by the given > selector. In line 385 you pass in the selector to select the > mirroredLevel, but in line 487, you pass in the selector to select the > referent. > > So which one is the right one? If you want to obey the comment it should > always be the mirroredLevel which is checked against localized name, right? Good point - I suspect the comment is out of date. Maybe Mandy will remember. I believe Level.parse is supposed to call levelObject.getLocalizedName() and Level.find is supposed to work with the referent. Let me check. best regards, -- daniel From peter.levart at gmail.com Tue Aug 16 13:33:35 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 16 Aug 2016 15:33:35 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <2be86d00-6f96-95d6-50b1-8a6646e74fec@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <5ec555d2-68f7-52d5-9f6e-6fb1b965db5f@gmail.com> <94cc86f5-b653-435f-08f0-f16445d5570a@oracle.com> <2be86d00-6f96-95d6-50b1-8a6646e74fec@oracle.com> Message-ID: <566c50da-946d-7fb2-7910-351e1f7529f0@gmail.com> On 08/16/2016 03:14 PM, Daniel Fuchs wrote: > Hi Peter, > > On 16/08/16 13:52, Peter Levart wrote: >> Ah, I see. Right. Of course, my bad. >> >> In that case, there is a possible race that could lead to exception >> here: >> >> 476 // add new Level. >> 477 Level levelObject = new Level(name, x); >> 478 return KnownLevel.findByValue(x, >> KnownLevel::referent).get(); >> >> ...between lines 477 and 478 and between lines 377 and 378, the newly >> constructed Level object could already get GC-ed and so findByValue >> could return an empty Optional. >> >> You should do something like: >> >> Level levelObject = new Level(name, x); >> Level result = KnownLevel.findByValue(x, KnownLevel::referent).get(); >> Reference.reachabilityFence(levelObject); >> return result; > > That's what I did in the very first version of the patch, > but Chris commented that this was unnecessary because when > level.getClass() == Level.class then levelObject == mirroredLevel. > Chris found that using Reference.reachabilityFence(levelObject) > just added more mystery - so I removed the statement. Oh, yes. I missed Chris' comment. Perhaps just add a comment about that for posterity? Regards, Peter > > best regards, > > -- daniel > >> >> >> Regards, Peter > From peter.levart at gmail.com Tue Aug 16 13:54:17 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 16 Aug 2016 15:54:17 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Message-ID: <76fbfdba-96b2-a8e2-0052-fb72d8830370@gmail.com> Hi Daniel, Now that you have various findByXXX methods return Optional, you could make methods that use them more Optional-API-powered. For example, findLevel could be written as a single expression: static Level findLevel(String name) { return KnownLevel .findByName(Objects.requireNonNull(name), KnownLevel::mirrored) .or(() -> { // Now, check if the given name is an integer. If so, // first look for a Level with the given value and then // if necessary create one. try { int x = Integer.parseInt(name); return KnownLevel .findByValue(x, KnownLevel::mirrored) .or(() -> { // add new Level new Level(name, x); return KnownLevel.findByValue(x, KnownLevel::mirrored); }); } catch (NumberFormatException ex) { // Not an integer. // Drop through. return Optional.empty(); } }) .or(() -> KnownLevel.findByLocalizedLevelName(name, KnownLevel::mirrored)) .orElse(null); } Same with parse: public static synchronized Level parse(String name) throws IllegalArgumentException { return KnownLevel // Look for a known Level with the given non-localized name. .findByName(Objects.requireNonNull(name), KnownLevel::referent) .or(() -> { // Now, check if the given name is an integer. If so, // first look for a Level with the given value and then // if necessary create one. try { int x = Integer.parseInt(name); return KnownLevel .findByValue(x, KnownLevel::referent) .or(() -> { // add new Level. new Level(name, x); return KnownLevel.findByValue(x, KnownLevel::referent); }); } catch (NumberFormatException ex) { // Not an integer. // Drop through. return Optional.empty(); } }) // Finally, look for a known level with the given localized name, // in the current default locale. // This is relatively expensive, but not excessively so. .or(() -> KnownLevel.findByLocalizedLevelName(name, KnownLevel::referent)) // OK, we've tried everything and failed .orElseThrow(() -> new IllegalArgumentException("Bad level \"" + name + "\"")); } Regards, Peter On 08/16/2016 12:42 PM, Daniel Fuchs wrote: > Hi Mandy, > > I added an additional selector parameter to the find methods. > This made it possible to return Optional instead of > KnownLevel - and it does simply the parse() method. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 > > best regards, > > -- daniel > > On 11/08/16 20:12, Mandy Chung wrote: >> >>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>> wrote: >>> >>> On 10/08/16 17:21, Mandy Chung wrote: >>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>> wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>> This looks pretty good. >>>> >>>> Since KnownLevel is now a Reference, I suggest to change >>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>> return Optional instead such that the parse method >>>> implementaiton could be simplified. >>> >>> We need to return KnownLevel because sometimes we need the >>> level object and sometimes the mirror. >> >> So either findByName(String name, boolean mirror) or two methods: >> findLevelByName and findMirroredLevelByName?? >> >> Or seriously consider to remove KnownLevel class by introducing a new >> Level subclass with final Level.getName, Level.getLocalizedName, >> Level.getResourceBundleName methods?? >> >> Mandy >> > From Roger.Riggs at Oracle.com Tue Aug 16 14:30:44 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 16 Aug 2016 10:30:44 -0400 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: References: Message-ID: <6e39d462-0ca6-755c-aaa3-3d7d2f30825d@Oracle.com> Hi Ivan, Look fine. Remember to use the enhancement process[1] to get approval for this enhancement. Roger [1] http://openjdk.java.net/projects/jdk9/fc-extension-process On 8/16/2016 8:53 AM, Ivan Gerasimov wrote: > Hello! > > Here's a cleanup pass through the code in java.io package. > > Would you please help review? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 > WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ > > With kind regards, > Ivan > From ivan.gerasimov at oracle.com Tue Aug 16 17:10:09 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 16 Aug 2016 20:10:09 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <6e39d462-0ca6-755c-aaa3-3d7d2f30825d@Oracle.com> References: <6e39d462-0ca6-755c-aaa3-3d7d2f30825d@Oracle.com> Message-ID: Thanks Roger for the review and the pointer! I'll follow the process. With kind regards, Ivan On 16.08.2016 17:30, Roger Riggs wrote: > Hi Ivan, > > Look fine. > > Remember to use the enhancement process[1] to get approval for this > enhancement. > > Roger > > [1] http://openjdk.java.net/projects/jdk9/fc-extension-process > > On 8/16/2016 8:53 AM, Ivan Gerasimov wrote: >> Hello! >> >> Here's a cleanup pass through the code in java.io package. >> >> Would you please help review? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ >> >> With kind regards, >> Ivan >> > > From ivan.gerasimov at oracle.com Tue Aug 16 17:20:01 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 16 Aug 2016 20:20:01 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> References: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> Message-ID: <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> Thank you Aleksey for your careful review! On 16.08.2016 16:08, Aleksey Shipilev wrote: > On 08/16/2016 03:53 PM, Ivan Gerasimov wrote: >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ > Both ObjectInputStream and ObjectOutputStream can use auto-unboxing in > these blocks? > > 1271 if (result.booleanValue()) { > 1272 return; > 1273 } Yes. I'll also invert the logic, as it reads better. > ObjectStreamClass: > > I wonder if the entire getPackageName is replaceable with > Class.getPackageName()? If so, ditch the method completely and use > Class.getPackageName everywhere. This may complicate backporting to JDK > 8 though. Unfortunately, Class.getPackageName() cannot handle arrays, so I'll leave it as is. > OutputStreamWriter: > > New code in append(CharSequence,int,int) unnecessarily calls toString on > CharBuffers which are handled specially downstream in append(CharSequence). Good catch, thanks! I'll replace the call to write(String) with append(CharSequence). This will make the code even shorter. Here is the updated webrev: http://cr.openjdk.java.net/~igerasim/8163517/01/webrev/ With kind regards, Ivan. From brent.christian at oracle.com Tue Aug 16 18:54:14 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 16 Aug 2016 11:54:14 -0700 Subject: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods Message-ID: <294f91f1-8425-7762-5679-96d6c065d908@oracle.com> Hi, Please review this change which does some cleanup around documenting conditions for throwing SecurityExceptions. It adds a missing @throws tag to Class.forName(String, boolean, ClassLoader), and consolidates specifics in the @throws tags of ClassLoader & Thread. Bug: https://bugs.openjdk.java.net/browse/JDK-7180225 Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/ Specdiff: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/specdiff/package-summary.html Thanks! -Brent From huizhe.wang at oracle.com Tue Aug 16 18:59:07 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 16 Aug 2016 11:59:07 -0700 Subject: RFR (JAXP) 6211561: XPath.evaluate(String, Object, QName) throws exception if context node is null Message-ID: <57B3627B.2040900@oracle.com> Hi, Please review a javadoc fix for XPath, and the same for XPathExpression. Error message is improved to be more relevant. Please ignore the Lic header for XPATHErrorResources.java, they will be handled in the future. JBS: https://bugs.openjdk.java.net/browse/JDK-6211561 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/6211561/webrev/ Thanks, Joe From paul.sandoz at oracle.com Tue Aug 16 19:48:03 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Aug 2016 12:48:03 -0700 Subject: RFR of JDK9 8162519: Remove ParallelPrefix.java from ProblemList.txt In-Reply-To: <2941f4c3-3839-8c45-674f-6e70d3f45930@oracle.com> References: <2941f4c3-3839-8c45-674f-6e70d3f45930@oracle.com> Message-ID: <97C9CFC4-F118-4701-80D9-D67F284E4CAF@oracle.com> > On 15 Aug 2016, at 01:12, Hamlin Li wrote: > > There are 2 issues related to test/java/util/Arrays/ParallelPrefix.java, > > 1. JDK-8080165, which is marked as samebinary-highfrequency. Based on below information, I think this bug should have been resolved, although I don't know which change set resolve the issue, > > 1. the last failure happened more than one year before; > 2. run 3 loops concurrently, in every loop run ParallelPrefix 1000 times sequentially, PrefixBug(Paul's reproducible code above) is run in below mode on jdk9-b128: > java -server -XX:LoopUnrollLimit=0 -XX:TieredStopAtLevel=4 PrefixBug > java -server -XX:LoopUnrollLimit=0 PrefixBug > java -server PrefixBug > 3. issue easily reproduced by build/run "javac/java PrefixBug" on jdk9-b64. > > 2. JDK-8085982, which is not reproduced. > > So, I think ParallelPrefix.java should be removed from ProblemList.txt > > bug: https://bugs.openjdk.java.net/browse/JDK-8162519 > webrev: http://cr.openjdk.java.net/~mli/8162519/webrev.00/ > +1 Let?s see if it resurfaces in our test infra. Paul. From lance.andersen at oracle.com Tue Aug 16 21:40:58 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 16 Aug 2016 17:40:58 -0400 Subject: RFR (JAXP) 6211561: XPath.evaluate(String, Object, QName) throws exception if context node is null In-Reply-To: <57B3627B.2040900@oracle.com> References: <57B3627B.2040900@oracle.com> Message-ID: <61069045-46BE-4A15-BC1D-B140AC271D1E@oracle.com> +1 > On Aug 16, 2016, at 2:59 PM, Joe Wang wrote: > > Hi, > > Please review a javadoc fix for XPath, and the same for XPathExpression. Error message is improved to be more relevant. > > Please ignore the Lic header for XPATHErrorResources.java, they will be handled in the future. > > JBS: https://bugs.openjdk.java.net/browse/JDK-6211561 > Webrev: http://cr.openjdk.java.net/~joehw/jdk9/6211561/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 paul.sandoz at oracle.com Tue Aug 16 22:00:25 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Aug 2016 15:00:25 -0700 Subject: Collectors.toSet() small performance improvement In-Reply-To: <51903419.20160809123105@gmail.com> References: <51903419.20160809123105@gmail.com> Message-ID: Hi Tagir, I like it. Please open an issue and i will sponsor the fix for you. Thanks, Paul. > On 8 Aug 2016, at 22:31, Tagir F. Valeev wrote: > > Hello! > > I'd like to propose a simple performance patch for Collectors.toSet(): > > --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 > +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 > @@ -295,7 +295,12 @@ > public static > Collector> toSet() { > return new CollectorImpl<>((Supplier>) HashSet::new, Set::add, > - (left, right) -> { left.addAll(right); return left; }, > + (left, right) -> { > + if (left.size() < right.size()) { > + right.addAll(left); return right; > + } > + left.addAll(right); return left; > + }, > CH_UNORDERED_ID); > } > > This will add the smaller set to the larger which may improve parallel > performance when subtasks produced uneven results. In normal case the > additional overhead is insignificant (additional HashSet size > comparison per each combine operation which usually performed > ~4*parallelism times). > > Here's simple JDK benchmark with results (Core-i7-4702MQ 4 HT cores, > Win7, JDK 9-ea+129 64bit) which confirms the speedup: > http://cr.openjdk.java.net/~tvaleev/patches/toSet/ > > When data is unevenly distributed, it's significantly faster: > > Original: > ToSet.toSetParallel 10000 true avgt 50 88,580 ? 0,874 us/op > ToSet.toSetParallel 100000 true avgt 50 676,243 ? 41,188 us/op > ToSet.toSetParallel 1000000 true avgt 50 9126,399 ? 83,260 us/op > Patched: > ToSet.toSetParallel 10000 true avgt 50 62,121 ? 1,207 us/op > ToSet.toSetParallel 100000 true avgt 50 556,968 ? 37,404 us/op > ToSet.toSetParallel 1000000 true avgt 50 6572,372 ? 183,466 us/op > > When data is evenly distributed, no statistically significant changes > observed: > > Original: > ToSet.toSetParallel 10000 false avgt 50 177,137 ? 5,941 us/op > ToSet.toSetParallel 100000 false avgt 50 2056,332 ? 87,433 us/op > ToSet.toSetParallel 1000000 false avgt 50 51864,198 ? 560,883 us/op > Patched: > ToSet.toSetParallel 10000 false avgt 50 172,606 ? 7,321 us/op > ToSet.toSetParallel 100000 false avgt 50 1922,478 ? 79,593 us/op > ToSet.toSetParallel 1000000 false avgt 50 52648,100 ? 621,526 us/op > > What do you think? Should I open an issue? > > With best regards, > Tagir Valeev. > From artem.smotrakov at oracle.com Tue Aug 16 23:11:32 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 16 Aug 2016 16:11:32 -0700 Subject: [9] RFR: 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads Message-ID: Hello, Please review the following patch for java/nio/file/WatchService/UpdateInterference.java test. The test creates a couple of daemon threads which have an infinite loop inside. When the test finishes, those daemon still keep running as long as jtreg use this instance of JVM to run other tests (the test doesn't run in othervm mode). The test also creates a WatchService which creates a "FileSystemWatchService" daemon thread. Then, the test doesn't close this WatchService, and as a result, this daemon thread keeps running as well. The test shouldn't leave daemon threads when it finishes. It may slow down further test execution. If other tests also leave daemon threads, it may cause intermittent test failures, see for example JDK-8160642 and JDK-8162757. The patch updates the test with the following: - threads are not daemons any more - "while" loops are not infinite - the test waits for threads to finish before closing a watch service to avoid ClosedWatchServiceException - the test closes a watch service in try-with-resources block - the test removes temporary files and directories in the end Bug: https://bugs.openjdk.java.net/browse/JDK-8164159 Webrev: http://cr.openjdk.java.net/~asmotrak/8164159/webrev.00/ Artem From paul.sandoz at oracle.com Tue Aug 16 23:50:00 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 16 Aug 2016 16:50:00 -0700 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <20A5AEB1-F4A9-4C0E-9F28-521D691FAB03@reini.net> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> <20A5AEB1-F4A9-4C0E-9F28-521D691FAB03@reini.net> Message-ID: <51D7CAA9-0267-4873-A746-F0670E303918@oracle.com> > On 8 Aug 2016, at 12:14, Patrick Reinhart wrote: > > >> Am 08.08.2016 um 18:55 schrieb Alan Bateman : >> >> On 08/08/2016 17:29, Patrick Reinhart wrote: >> >>> : >>> I tried to integrate your suggested changes here: >>> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.01 >>> >> I should have been clearer. A lazy implementation of resources/systemResources methods won't throw any exceptions, instead any I/O exceptions will be wrapped with an UncheckedIOException and then thrown from the method that caused the access to take place. There are several examples of this already. For the javadoc then this will be described in the method description rather than a @throws. >> >> -Alan > > I hope that this version is more likely that what you meant? > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.02 > Perhaps consider: The loading of resources will occur when the returned stream is evaluated. If the loading of resources results in an {@code IOException} then the I/O exception is wrapped in an {@link UncheckedIOException} that is then thrown. Instead of ? use {@code ? } Paul. From amaembo at gmail.com Wed Aug 17 03:08:37 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Wed, 17 Aug 2016 10:08:37 +0700 Subject: Collectors.toSet() small performance improvement In-Reply-To: References: <51903419.20160809123105@gmail.com> Message-ID: <1536588275.20160817100837@gmail.com> Hello, Paul! Thank you. Here's issue: https://bugs.openjdk.java.net/browse/JDK-8164189 And webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8164189/r1/ With best regards, Tagir Valeev. PS> Hi Tagir, PS> I like it. Please open an issue and i will sponsor the fix for you. PS> Thanks, PS> Paul. >> On 8 Aug 2016, at 22:31, Tagir F. Valeev wrote: >> >> Hello! >> >> I'd like to propose a simple performance patch for Collectors.toSet(): >> >> --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 >> +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 >> @@ -295,7 +295,12 @@ >> public static >> Collector> toSet() { >> return new CollectorImpl<>((Supplier>) HashSet::new, Set::add, >> - (left, right) -> { left.addAll(right); return left; }, >> + (left, right) -> { >> + if (left.size() < right.size()) { >> + right.addAll(left); return right; >> + } >> + left.addAll(right); return left; >> + }, >> CH_UNORDERED_ID); >> } >> >> This will add the smaller set to the larger which may improve parallel >> performance when subtasks produced uneven results. In normal case the >> additional overhead is insignificant (additional HashSet size >> comparison per each combine operation which usually performed >> ~4*parallelism times). >> >> Here's simple JDK benchmark with results (Core-i7-4702MQ 4 HT cores, >> Win7, JDK 9-ea+129 64bit) which confirms the speedup: >> http://cr.openjdk.java.net/~tvaleev/patches/toSet/ >> >> When data is unevenly distributed, it's significantly faster: >> >> Original: >> ToSet.toSetParallel 10000 true avgt 50 88,580 ? 0,874 us/op >> ToSet.toSetParallel 100000 true avgt 50 676,243 ? 41,188 us/op >> ToSet.toSetParallel 1000000 true avgt 50 9126,399 ? 83,260 us/op >> Patched: >> ToSet.toSetParallel 10000 true avgt 50 62,121 ? 1,207 us/op >> ToSet.toSetParallel 100000 true avgt 50 556,968 ? 37,404 us/op >> ToSet.toSetParallel 1000000 true avgt 50 6572,372 ? 183,466 us/op >> >> When data is evenly distributed, no statistically significant changes >> observed: >> >> Original: >> ToSet.toSetParallel 10000 false avgt 50 177,137 ? 5,941 us/op >> ToSet.toSetParallel 100000 false avgt 50 2056,332 ? 87,433 us/op >> ToSet.toSetParallel 1000000 false avgt 50 51864,198 ? 560,883 us/op >> Patched: >> ToSet.toSetParallel 10000 false avgt 50 172,606 ? 7,321 us/op >> ToSet.toSetParallel 100000 false avgt 50 1922,478 ? 79,593 us/op >> ToSet.toSetParallel 1000000 false avgt 50 52648,100 ? 621,526 us/op >> >> What do you think? Should I open an issue? >> >> With best regards, >> Tagir Valeev. >> From mandy.chung at oracle.com Wed Aug 17 03:33:19 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Aug 2016 22:33:19 -0500 Subject: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods In-Reply-To: <294f91f1-8425-7762-5679-96d6c065d908@oracle.com> References: <294f91f1-8425-7762-5679-96d6c065d908@oracle.com> Message-ID: <9A7FFCF3-FEA1-42BB-BDA9-325C46100EB4@oracle.com> > On Aug 16, 2016, at 1:54 PM, Brent Christian wrote: > > Hi, > > Please review this change which does some cleanup around documenting conditions for throwing SecurityExceptions. > > It adds a missing @throws tag to Class.forName(String, boolean, ClassLoader), and consolidates specifics in the @throws tags of ClassLoader & Thread. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7180225 > Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/ > Specdiff: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/specdiff/package-summary.html Looks fine. A typo in Thread.java ?(? should be ?{" 1520 * @return the context (@code ClassLoader} for this thread, or {@code null} Mandy From mandy.chung at oracle.com Wed Aug 17 04:05:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Aug 2016 23:05:32 -0500 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Message-ID: > On Aug 16, 2016, at 5:42 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I added an additional selector parameter to the find methods. > This made it possible to return Optional instead of > KnownLevel - and it does simply the parse() method. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 > This looks much better. I like the findByName method taking a function to select what to be returned. But the selector looks strange to map from a KnownLevel to a stream of Level. I think it should be Function> and the callsite can convert to Stream using Optional::stream. No need for me to see an updated webrev. thanks Mandy From daniel.fuchs at oracle.com Wed Aug 17 07:11:08 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Aug 2016 08:11:08 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Message-ID: <382248ff-2b47-bfeb-b714-c8d5b7759abf@oracle.com> Hi Mandy, On 17/08/16 05:05, Mandy Chung wrote: >> On Aug 16, 2016, at 5:42 AM, Daniel Fuchs wrote: >> > >> > Hi Mandy, >> > >> > I added an additional selector parameter to the find methods. >> > This made it possible to return Optional instead of >> > KnownLevel - and it does simply the parse() method. >> > >> > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >> > > This looks much better. I like the findByName method taking a function to select what to be returned. But the selector looks strange to map from a KnownLevel to a stream of Level. I think it should be Function> and the callsite can convert to Stream using Optional::stream. OK - I'll do that. > No need for me to see an updated webrev. > > thanks > Mandy > From patrick at reini.net Wed Aug 17 09:39:26 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 17 Aug 2016 11:39:26 +0200 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <51D7CAA9-0267-4873-A746-F0670E303918@oracle.com> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> <20A5AEB1-F4A9-4C0E-9F28-521D691FAB03@reini.net> <51D7CAA9-0267-4873-A746-F0670E303918@oracle.com> Message-ID: <87e055be-f577-4dd0-d54e-5cd9dbd06d6b@reini.net> On 17.08.2016 01:50, Paul Sandoz wrote: > On 8 Aug 2016, at 12:14, Patrick Reinhart wrote: >> Am 08.08.2016 um 18:55 schrieb Alan Bateman : >>> On 08/08/2016 17:29, Patrick Reinhart wrote: >>> >>>> : >>>> I tried to integrate your suggested changes here: >>>> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.01 >>>> >>> I should have been clearer. A lazy implementation of resources/systemResources methods won't throw any exceptions, instead any I/O exceptions will be wrapped with an UncheckedIOException and then thrown from the method that caused the access to take place. There are several examples of this already. For the javadoc then this will be described in the method description rather than a @throws. >>> >>> -Alan >> I hope that this version is more likely that what you meant? >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.02 >> > Perhaps consider: > > The loading of resources will occur when the returned stream is evaluated. If the loading of resources > results in an {@code IOException} then the I/O exception is wrapped in an {@link UncheckedIOException} > that is then thrown. > > Instead of ? use {@code ? } > > Paul. Hi Paul, Thanks for the input. I integrated that into the version here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.03 Patrick From daniel.fuchs at oracle.com Wed Aug 17 11:00:26 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Aug 2016 12:00:26 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <709e6273-bb64-6c4c-1460-5452637fc2bc@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <709e6273-bb64-6c4c-1460-5452637fc2bc@gmail.com> Message-ID: <836e9465-af03-b6df-8b5a-3de8d4848ef9@oracle.com> Hi Peter, Rereading the comment and looking at the code I see that the comment is actually right. There are two methods with similar names: Level.getLocalizedName() which can be overridden by subclasses and Level.getLocalizedLevelName() which cannot. By default Level.getLocalizedName() calls Level.getLocalizedLevelName(), and findByLocalizedLevelName() calls Level.getLocalizedLevelName() too, not the overridable Level.getLocalizedName(). best regards, -- daniel On 16/08/16 13:59, Peter Levart wrote: > Hi Daniel, > > Another place that is not clear to me is the following (in old code): > > 585 // Returns a KnownLevel with the given localized name matching > 586 // by calling the Level.getLocalizedLevelName() method (i.e. found > 587 // from the resourceBundle associated with the Level object). > 588 // This method does not call Level.getLocalizedName() that may > 589 // be overridden in a subclass implementation > 590 static synchronized KnownLevel findByLocalizedLevelName(String name) { > 591 for (List levels : nameToLevels.values()) { > 592 for (KnownLevel l : levels) { > 593 String lname = l.levelObject.getLocalizedLevelName(); > 594 if (name.equals(lname)) { > 595 return l; > 596 } > 597 } > 598 } > 599 return null; > 600 } > > In spite of claiming that "this method doesn't call > Level.getLocalizedName() that may be overridden in subclass", it does > just that. it calls the getLocalizedLevelName on the > KnownLevel.levelObject, which is a user-constructed object. You changed > the code into: > > 627 static synchronized Optional > findByLocalizedLevelName(String name, > 628 Function> selector) { > 629 purge(); > 630 return nameToLevels.values() > 631 .stream() > 632 .flatMap(List::stream) > 633 .flatMap(selector) > 634 .filter(lo -> > name.equals(lo.getLocalizedLevelName())) > 635 .findFirst(); > 636 } > > Which calls getLocalizedName() on the Level object selected by the given > selector. In line 385 you pass in the selector to select the > mirroredLevel, but in line 487, you pass in the selector to select the > referent. > > So which one is the right one? If you want to obey the comment it should > always be the mirroredLevel which is checked against localized name, right? > > Regards, Peter From daniel.fuchs at oracle.com Wed Aug 17 11:16:59 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Aug 2016 12:16:59 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <76fbfdba-96b2-a8e2-0052-fb72d8830370@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <76fbfdba-96b2-a8e2-0052-fb72d8830370@gmail.com> Message-ID: <17dd0573-b28e-206e-f09c-e6fe6817c111@oracle.com> Hi Peter, >> Now that you have various findByXXX methods return Optional, you >> could make methods that use them more Optional-API-powered. For example, >> findLevel could be written as a single expression: Right. But do you mind if I leave that for another day? I'm not too keen on multi-line code statements embedded in lambdas - but I feel like we did enough restructuring for this fix now ;-) From your other mail: > Oh, yes. I missed Chris' comment. Perhaps just add a comment about that for posterity? I added the following comment to stress out that a reachability fence is not needed (at the two places where it occurred): 479 // add new Level. 480 Level levelObject = new Level(name, x); 481 // There's no need to use a reachability fence here because 482 // KnownLevel keeps a strong reference on the level when 483 // level.getClass() == Level.class. 484 return KnownLevel.findByValue(x, KnownLevel::referent).get(); For the record here are the changes - including Mandy's suggestions. If there's no objection I will push them after testing has passed, since Mandy said she didn't require a new webrev. http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.03 best regards, -- daniel On 16/08/16 14:54, Peter Levart wrote: > Hi Daniel, > > Now that you have various findByXXX methods return Optional, you > could make methods that use them more Optional-API-powered. For example, > findLevel could be written as a single expression: > > static Level findLevel(String name) { > return KnownLevel > .findByName(Objects.requireNonNull(name), KnownLevel::mirrored) > .or(() -> { > // Now, check if the given name is an integer. If so, > // first look for a Level with the given value and then > // if necessary create one. > try { > int x = Integer.parseInt(name); > return KnownLevel > .findByValue(x, KnownLevel::mirrored) > .or(() -> { > // add new Level > new Level(name, x); > return KnownLevel.findByValue(x, > KnownLevel::mirrored); > }); > } catch (NumberFormatException ex) { > // Not an integer. > // Drop through. > return Optional.empty(); > } > }) > .or(() -> KnownLevel.findByLocalizedLevelName(name, > KnownLevel::mirrored)) > .orElse(null); > } > > > Same with parse: > > public static synchronized Level parse(String name) throws > IllegalArgumentException { > return KnownLevel > // Look for a known Level with the given non-localized name. > .findByName(Objects.requireNonNull(name), KnownLevel::referent) > .or(() -> { > // Now, check if the given name is an integer. If so, > // first look for a Level with the given value and then > // if necessary create one. > try { > int x = Integer.parseInt(name); > return KnownLevel > .findByValue(x, KnownLevel::referent) > .or(() -> { > // add new Level. > new Level(name, x); > return KnownLevel.findByValue(x, > KnownLevel::referent); > }); > } catch (NumberFormatException ex) { > // Not an integer. > // Drop through. > return Optional.empty(); > } > }) > // Finally, look for a known level with the given localized > name, > // in the current default locale. > // This is relatively expensive, but not excessively so. > .or(() -> KnownLevel.findByLocalizedLevelName(name, > KnownLevel::referent)) > // OK, we've tried everything and failed > .orElseThrow(() -> new IllegalArgumentException("Bad level > \"" + name + "\"")); > } > > > Regards, Peter > > > On 08/16/2016 12:42 PM, Daniel Fuchs wrote: >> Hi Mandy, >> >> I added an additional selector parameter to the find methods. >> This made it possible to return Optional instead of >> KnownLevel - and it does simply the parse() method. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >> >> best regards, >> >> -- daniel >> >> On 11/08/16 20:12, Mandy Chung wrote: >>> >>>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>>> wrote: >>>> >>>> On 10/08/16 17:21, Mandy Chung wrote: >>>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>>> wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>>> This looks pretty good. >>>>> >>>>> Since KnownLevel is now a Reference, I suggest to change >>>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>>> return Optional instead such that the parse method >>>>> implementaiton could be simplified. >>>> >>>> We need to return KnownLevel because sometimes we need the >>>> level object and sometimes the mirror. >>> >>> So either findByName(String name, boolean mirror) or two methods: >>> findLevelByName and findMirroredLevelByName?? >>> >>> Or seriously consider to remove KnownLevel class by introducing a new >>> Level subclass with final Level.getName, Level.getLocalizedName, >>> Level.getResourceBundleName methods?? >>> >>> Mandy >>> >> > From peter.levart at gmail.com Wed Aug 17 11:20:29 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 17 Aug 2016 13:20:29 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> Message-ID: <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> Hi Daniel, Thinking of this patch from the compatibility standpoint, aren't you afraid that someone might be using the following idiom: public class MyLevel extends java.util.logging.Level { static { new MyLevel("LEVEL1", 1); new MyLevel("LEVEL2", 2); ... } public static void init() {} private MyLevel(String name, int value) { super(name, value); } ... } ...and then use those levels in code like: MyLevel.init(); ... Level level = Level.parse("LEVEL1") ... With the proposed patch, this will not work any more as custom Level subclass instances will possibly be GCed before being "parsed" and retained. To prevent that from happening and still allow custom Level subclasses and their class loaders to be garbage-collectable, I recommend that you "pin" each constructed subclass instance to its ClassLoader with a strong reference. You could use a ClassLoaderValue for this purpose, like in the following addition to your patch (see KnownLevel.add): http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/ Regards, Peter On 08/16/2016 12:42 PM, Daniel Fuchs wrote: > Hi Mandy, > > I added an additional selector parameter to the find methods. > This made it possible to return Optional instead of > KnownLevel - and it does simply the parse() method. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 > > best regards, > > -- daniel > > On 11/08/16 20:12, Mandy Chung wrote: >> >>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>> wrote: >>> >>> On 10/08/16 17:21, Mandy Chung wrote: >>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>> wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>> This looks pretty good. >>>> >>>> Since KnownLevel is now a Reference, I suggest to change >>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>> return Optional instead such that the parse method >>>> implementaiton could be simplified. >>> >>> We need to return KnownLevel because sometimes we need the >>> level object and sometimes the mirror. >> >> So either findByName(String name, boolean mirror) or two methods: >> findLevelByName and findMirroredLevelByName?? >> >> Or seriously consider to remove KnownLevel class by introducing a new >> Level subclass with final Level.getName, Level.getLocalizedName, >> Level.getResourceBundleName methods?? >> >> Mandy >> > From peter.levart at gmail.com Wed Aug 17 11:35:07 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 17 Aug 2016 13:35:07 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <17dd0573-b28e-206e-f09c-e6fe6817c111@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <76fbfdba-96b2-a8e2-0052-fb72d8830370@gmail.com> <17dd0573-b28e-206e-f09c-e6fe6817c111@oracle.com> Message-ID: <0af001ae-975d-cca3-003a-1efb17fbebe4@gmail.com> On 08/17/2016 01:16 PM, Daniel Fuchs wrote: >>> Now that you have various findByXXX methods return Optional, you >>> could make methods that use them more Optional-API-powered. For >>> example, >>> findLevel could be written as a single expression: > > Right. But do you mind if I leave that for another day? > I'm not too keen on multi-line code statements embedded > in lambdas - but I feel like we did enough restructuring > for this fix now ;-) It's just that the functional style is actually more readable in this case. But never mind. It's just style. Regards, Peter From peter.levart at gmail.com Wed Aug 17 11:37:43 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 17 Aug 2016 13:37:43 +0200 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> Message-ID: <2c526605-57a9-1c51-6691-d0e9066dae62@gmail.com> On 08/17/2016 01:20 PM, Peter Levart wrote: > You could use a ClassLoaderValue for this purpose, like in the > following addition to your patch (see KnownLevel.add): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/ Note that the above also contains the functional-style findLevel and parse implementations which you would probably want to leave out... Regards, Peter From Alan.Bateman at oracle.com Wed Aug 17 11:39:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Aug 2016 12:39:12 +0100 Subject: RFE to re-purpose option --version: In-Reply-To: References: <36EDD6DA-1762-4BE5-A2CB-FF17C6CE30F7@oracle.com> <511A495B-0DC2-45C5-B2D7-7146BA3AC170@oracle.com> Message-ID: <08784bec-f1bf-6395-092c-1bbc7a4db51d@oracle.com> On 10/08/2016 23:46, Martin Buchholz wrote: > On Wed, Aug 10, 2016 at 11:52 AM, Paul Benedict > wrote: > >> Martin, what do you have in mind when saying it's "broken"? Functionally, >> everything is fine -- I can delete "release" locally without issue (so it >> appears) -- so I imagine there's humor here I am missing? :-) >> > The release file is a user interface. Removing it is just like removing > any other part of the product (e.g. bin/javap) that users may have built a > dependency on. It's broken, just not totally broken! Right, the `release` is a JDK-specific and supported interface. It has been there for several releases to allow tools inspect the image without needing to invoke `java -version`. Removing the release file seems misguided. Also something like `java --version:9.1` isn't going to work when the run-time image is for another OS/architecture, another use-case for the `release` file btw. -Alan From daniel.fuchs at oracle.com Wed Aug 17 12:53:56 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 17 Aug 2016 13:53:56 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> Message-ID: <8063bd74-07c8-4d85-2483-f56f35631f0a@oracle.com> Hi Peter, On 17/08/16 12:20, Peter Levart wrote: > Hi Daniel, > > Thinking of this patch from the compatibility standpoint, aren't you > afraid that someone might be using the following idiom: > > public class MyLevel extends java.util.logging.Level { > static { > new MyLevel("LEVEL1", 1); > new MyLevel("LEVEL2", 2); > ... > } > > public static void init() {} > > private MyLevel(String name, int value) { > super(name, value); > } > ... > } > > ...and then use those levels in code like: > > MyLevel.init(); > ... > Level level = Level.parse("LEVEL1") ... That's a possibility, and maybe that would deserve to be noted as a side effect of the fix in the release notes. I do not believe this is something we would want to actively support though: the usual idiom for custom level would rather be to define them as public final static constant, and use a direct reference in the code. Something like: public class MyLevel extends Level { public static final MyLevel LEVEL1 = new MyLevel("LEVEL1", 1); ... } Level level = MyLevel.LEVEL1; or even more simpler: public static class Levels { public static Level LEVEL1 = new Level("LEVEL1", 1) {}; ... } So maybe this is a risk we should take. Mandy, what do you think? The other alternative is not to fix the bug as it's been here for several releases ;-) -- daniel > > > With the proposed patch, this will not work any more as custom Level > subclass instances will possibly be GCed before being "parsed" and > retained. > > To prevent that from happening and still allow custom Level subclasses > and their class loaders to be garbage-collectable, I recommend that you > "pin" each constructed subclass instance to its ClassLoader with a > strong reference. You could use a ClassLoaderValue for this purpose, > like in the following addition to your patch (see KnownLevel.add): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/ > > Regards, Peter > > > On 08/16/2016 12:42 PM, Daniel Fuchs wrote: >> Hi Mandy, >> >> I added an additional selector parameter to the find methods. >> This made it possible to return Optional instead of >> KnownLevel - and it does simply the parse() method. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >> >> best regards, >> >> -- daniel >> >> On 11/08/16 20:12, Mandy Chung wrote: >>> >>>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs >>>> wrote: >>>> >>>> On 10/08/16 17:21, Mandy Chung wrote: >>>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs >>>>>> wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>>> This looks pretty good. >>>>> >>>>> Since KnownLevel is now a Reference, I suggest to change >>>>> KnownLevel::findByName, findByValue and findByLocalizedLevelName to >>>>> return Optional instead such that the parse method >>>>> implementaiton could be simplified. >>>> >>>> We need to return KnownLevel because sometimes we need the >>>> level object and sometimes the mirror. >>> >>> So either findByName(String name, boolean mirror) or two methods: >>> findLevelByName and findMirroredLevelByName?? >>> >>> Or seriously consider to remove KnownLevel class by introducing a new >>> Level subclass with final Level.getName, Level.getLocalizedName, >>> Level.getResourceBundleName methods?? >>> >>> Mandy >>> >> > From amaembo at gmail.com Wed Aug 17 13:01:05 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Wed, 17 Aug 2016 20:01:05 +0700 Subject: Exceptional behavior of parallel stream Message-ID: <1882659279.20160817200105@gmail.com> Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the caller as is), the behavior for parallel streams differs from one might expect. Consider the following test: String[] data = IntStream.range(0, 100).mapToObj(String::valueOf) .toArray(String[]::new); data[20] = "oops"; try { int sum = Arrays.stream(data).parallel().mapToInt(Integer::valueOf) .peek(System.out::println).sum(); System.out.println("Sum is "+sum); } catch (NumberFormatException e) { System.out.println("Non-number appeared!"); } This parses integers stored in string array and sums them outputting every number to stdout once it processed. As data set contains non-number, the stream obviously fails with NumberFormatException. The typical output looks like this: 62 63 12 31 87 ... 28 92 29 8 Non-number appeared! 9 30 So as you can see, the stream is not actually terminated when exception is thrown and caught: even after that some parallel tasks continue running, and you see more numbers printed after catch block is executed. I consider such behavior as confusing and unexpected. Given the fact that stream may produce side-effects (e.g. if terminal op is forEach) this might lead to unforeseen consequences in user programs as left-over parallel stream tasks may continue mutate shared state after main stream thread exceptionally returns the control to the caller. So I suggest that such behavior should be either fixed or explicitly documented. What do you think? With best regards, Tagir Valeev. From peter.levart at gmail.com Wed Aug 17 12:58:50 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 17 Aug 2016 14:58:50 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <0D58CB68-DE1E-4174-BD99-C1CFFD67C0BB@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <0D58CB68-DE1E-4174-BD99-C1CFFD67C0BB@oracle.com> Message-ID: <3bf45986-be56-5782-ee80-c3e66c1d5a2f@gmail.com> Hi Kim, On 08/15/2016 05:15 AM, Kim Barrett wrote: >> >I have a feeling that these pauses are now unnecessary. Will try to check with some experiments? > I found that the DirectBufferAllocTest will sometimes fail if the pauses are taken out. > I think what?s going on is that the multiple threads are competing for resources, and > some threads in that test lose out if all of them are waiting and wake up at the same > time. The exponentially increasing back-off scatters the threads enough for that to > become very unlikely, though with sufficiently bad luck? But I think the current > implementation could also fail that test with similarly bad luck. It just requires*very* > bad luck, so we?re not seeing it as a problem. And that test is a pretty extreme stress > test. > I get the same results when experimenting with this. Another option would be to enclose the whole logic of (retrying reservation while waiting for Reference processing progress followed by System.gc() and another round of reservation retries while waiting for Reference processing) into a synchronized block so that multiple reservation threads could not barge for reservations. This approach works and might even be triggering less System.gc() rounds, but it is not much better than current approach. Regards, Peter From aleksej.efimov at oracle.com Wed Aug 17 14:04:58 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 17 Aug 2016 17:04:58 +0300 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: <57B20566.7040004@oracle.com> References: <57B20566.7040004@oracle.com> Message-ID: <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> Hi Joe, Aleksey, Thank you for reviewing the initial fix. I followed the Joe's suggestion (thanks for that) and removed static 'abort' field completely, the functionality was replaced by throwing the exception of newly added type - AbortException. The new webrev with removed 'abort' can be found here: http://cr.openjdk.java.net/~aefimov/8146961/9/01 The Tomcat reproducer attached to the bug report fails without the fix and passes with the new version of the fix. The JPRT and JCK testing again shows no related jaxp tests failures. Best Regards, Aleksej On 15/08/16 21:09, Joe Wang wrote: > Hi Aleksej, > > I suggest we get rid of the static abort. If RuntimeException happens, > check where it happens. The first use case looks suspicious as it just > returns if it's an instance of RE. For the 2nd case in DOM error > report, let's throw a RuntimeException with the specified error > message if error happens, and there's no handler or the handler failed > to handle it. (would be better than an empty RE) > > Best, > Joe > > On 8/15/16, 10:38 AM, Aleks Efimov wrote: >> Hi, >> >> Please, help to review the fix for memory leak [1] in >> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused >> by usage of static final exceptions. >> This problem was already fixed in Apache Xerces project [2] and I >> would like to backport it to JDK9 Xerces implementation. >> Webrev with the changes: >> http://cr.openjdk.java.net/~aefimov/8146961/9/00 >> >> The Tomcat reproducer attached to the bug report fails without the >> fix and passes with the fix. >> The JPRT and JCK testing shows no jaxp tests failures with the >> proposed fix. >> >> With Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 >> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 >> From sean.mullan at oracle.com Wed Aug 17 14:14:48 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 17 Aug 2016 10:14:48 -0400 Subject: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods In-Reply-To: <294f91f1-8425-7762-5679-96d6c065d908@oracle.com> References: <294f91f1-8425-7762-5679-96d6c065d908@oracle.com> Message-ID: <39803a0f-5fc3-dfbc-ef30-2c49aab467be@oracle.com> Looks fine to me. --Sean On 08/16/2016 02:54 PM, Brent Christian wrote: > Hi, > > Please review this change which does some cleanup around documenting > conditions for throwing SecurityExceptions. > > It adds a missing @throws tag to Class.forName(String, boolean, > ClassLoader), and consolidates specifics in the @throws tags of > ClassLoader & Thread. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7180225 > Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/ > Specdiff: > http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/specdiff/package-summary.html > > > Thanks! > > -Brent From huizhe.wang at oracle.com Wed Aug 17 16:30:02 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 17 Aug 2016 09:30:02 -0700 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> References: <57B20566.7040004@oracle.com> <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> Message-ID: <57B4910A.3070707@oracle.com> Looks good, Aleksej. Thanks for coming up with a well-thought solution to get rid of the static RE field. Best, Joe On 8/17/16, 7:04 AM, Aleks Efimov wrote: > Hi Joe, Aleksey, > Thank you for reviewing the initial fix. > > I followed the Joe's suggestion (thanks for that) and removed static > 'abort' field completely, the functionality was replaced by throwing > the exception of newly added type - AbortException. The new webrev > with removed 'abort' can be found here: > http://cr.openjdk.java.net/~aefimov/8146961/9/01 > > The Tomcat reproducer attached to the bug report fails without the fix > and passes with the new version of the fix. > The JPRT and JCK testing again shows no related jaxp tests failures. > > Best Regards, > Aleksej > > > On 15/08/16 21:09, Joe Wang wrote: >> Hi Aleksej, >> >> I suggest we get rid of the static abort. If RuntimeException >> happens, check where it happens. The first use case looks suspicious >> as it just returns if it's an instance of RE. For the 2nd case in DOM >> error report, let's throw a RuntimeException with the specified error >> message if error happens, and there's no handler or the handler >> failed to handle it. (would be better than an empty RE) >> >> Best, >> Joe >> >> On 8/15/16, 10:38 AM, Aleks Efimov wrote: >>> Hi, >>> >>> Please, help to review the fix for memory leak [1] in >>> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused >>> by usage of static final exceptions. >>> This problem was already fixed in Apache Xerces project [2] and I >>> would like to backport it to JDK9 Xerces implementation. >>> Webrev with the changes: >>> http://cr.openjdk.java.net/~aefimov/8146961/9/00 >>> >>> The Tomcat reproducer attached to the bug report fails without the >>> fix and passes with the fix. >>> The JPRT and JCK testing shows no jaxp tests failures with the >>> proposed fix. >>> >>> With Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 >>> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 >>> > From brent.christian at oracle.com Wed Aug 17 18:35:05 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 17 Aug 2016 11:35:05 -0700 Subject: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods In-Reply-To: <9A7FFCF3-FEA1-42BB-BDA9-325C46100EB4@oracle.com> References: <294f91f1-8425-7762-5679-96d6c065d908@oracle.com> <9A7FFCF3-FEA1-42BB-BDA9-325C46100EB4@oracle.com> Message-ID: On 8/16/16 8:33 PM, Mandy Chung wrote: >> On Aug 16, 2016, at 1:54 PM, Brent Christian wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-7180225 >> Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/ >> Specdiff: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/specdiff/package-summary.html > > Looks fine. A typo in Thread.java ?(? should be ?{" > > 1520 * @return the context (@code ClassLoader} for this thread, or {@code null} Good catch - I'll fix it before pushing. Thank you for the reviews, Mandy and Sean. -Brent From paul.sandoz at oracle.com Wed Aug 17 20:02:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 17 Aug 2016 13:02:18 -0700 Subject: Collectors.toSet() small performance improvement In-Reply-To: <1536588275.20160817100837@gmail.com> References: <51903419.20160809123105@gmail.com> <1536588275.20160817100837@gmail.com> Message-ID: > On 16 Aug 2016, at 20:08, Tagir F. Valeev wrote: > > Hello, Paul! > > Thank you. Here's issue: > https://bugs.openjdk.java.net/browse/JDK-8164189 > And webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8164189/r1/ > Thanks will push today or tomorrow, Paul. > With best regards, > Tagir Valeev. > > PS> Hi Tagir, > > PS> I like it. Please open an issue and i will sponsor the fix for you. > > PS> Thanks, > PS> Paul. > >>> On 8 Aug 2016, at 22:31, Tagir F. Valeev wrote: >>> >>> Hello! >>> >>> I'd like to propose a simple performance patch for Collectors.toSet(): >>> >>> --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 >>> +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 >>> @@ -295,7 +295,12 @@ >>> public static >>> Collector> toSet() { >>> return new CollectorImpl<>((Supplier>) HashSet::new, Set::add, >>> - (left, right) -> { left.addAll(right); return left; }, >>> + (left, right) -> { >>> + if (left.size() < right.size()) { >>> + right.addAll(left); return right; >>> + } >>> + left.addAll(right); return left; >>> + }, >>> CH_UNORDERED_ID); >>> } >>> >>> This will add the smaller set to the larger which may improve parallel >>> performance when subtasks produced uneven results. In normal case the >>> additional overhead is insignificant (additional HashSet size >>> comparison per each combine operation which usually performed >>> ~4*parallelism times). >>> >>> Here's simple JDK benchmark with results (Core-i7-4702MQ 4 HT cores, >>> Win7, JDK 9-ea+129 64bit) which confirms the speedup: >>> http://cr.openjdk.java.net/~tvaleev/patches/toSet/ >>> >>> When data is unevenly distributed, it's significantly faster: >>> >>> Original: >>> ToSet.toSetParallel 10000 true avgt 50 88,580 ? 0,874 us/op >>> ToSet.toSetParallel 100000 true avgt 50 676,243 ? 41,188 us/op >>> ToSet.toSetParallel 1000000 true avgt 50 9126,399 ? 83,260 us/op >>> Patched: >>> ToSet.toSetParallel 10000 true avgt 50 62,121 ? 1,207 us/op >>> ToSet.toSetParallel 100000 true avgt 50 556,968 ? 37,404 us/op >>> ToSet.toSetParallel 1000000 true avgt 50 6572,372 ? 183,466 us/op >>> >>> When data is evenly distributed, no statistically significant changes >>> observed: >>> >>> Original: >>> ToSet.toSetParallel 10000 false avgt 50 177,137 ? 5,941 us/op >>> ToSet.toSetParallel 100000 false avgt 50 2056,332 ? 87,433 us/op >>> ToSet.toSetParallel 1000000 false avgt 50 51864,198 ? 560,883 us/op >>> Patched: >>> ToSet.toSetParallel 10000 false avgt 50 172,606 ? 7,321 us/op >>> ToSet.toSetParallel 100000 false avgt 50 1922,478 ? 79,593 us/op >>> ToSet.toSetParallel 1000000 false avgt 50 52648,100 ? 621,526 us/op >>> >>> What do you think? Should I open an issue? >>> >>> With best regards, >>> Tagir Valeev. >>> > From brent.christian at oracle.com Wed Aug 17 20:05:38 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 17 Aug 2016 13:05:38 -0700 Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect Message-ID: <57B4C392.4060001@oracle.com> Hi, Please review this StackWalker fix in hotspot for 8156073, "2-slot LiveStackFrame locals (long and double) are incorrect" Bug: https://bugs.openjdk.java.net/browse/JDK-8156073 Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/ The experimental LiveStackFrame[1] interface for StackWalker provides access to stack frames' local variables, returned in an Object[] from LiveStackFrame.getLocals(). Long and double primitives are returned using two array slots (similar to JVMS section 2.6.1 [2]). This works as indicated on 32-bit JDKs, but needs some fixing on 64-bit. AFAICT under 64-bit, StackValueCollection stores the entire long/double in the 2nd (64-bit) slot: jlong StackValueCollection::long_at(int slot) const { #ifdef _LP64 return at(slot+1)->get_int(); #else ... The first slot goes unused and contains 0, instead of holding half of the long value as stackwalker expects. So stackwalker needs to take care splitting the value between the two slots. The fix examines StackValueCollection::long_at(i), checks for an unexpected 0 value from StackValueCollection::int_at(i), and copies the needed 32-bits (depending on native byte ordering) into the first slot as needed. (The 2nd slot gets truncated to 32-bits in create_primitive_value_instance()). Here's the fix in action on linux_x64 with the updated LocalsAndOperands.java test. Slots 4+5 contain a long, 6+7 contain a double. Before the fix: ... local 3: himom type java.lang.String local 4: 0 type I <-- local 5: 65535 type I local 6: 0 type I <-- local 7: 1293080650 type I local 8: 0 type I After the fix: ... local 3: himom type java.lang.String local 4: 1023 type I <-- local 5: 65535 type I local 6: 1074340347 type I <-- local 7: 1293080650 type I local 8: 0 type I This change also fixes 8158879, "Add new test for verifying 2-slot locals in LiveStackFrame". Thanks to Fabio Tudone (fabio at paralleluniverse.co) for the test case. I only test unused ("dead") local variables with -Xint, because they are removed in compiled frames. An automated build & test run on all platforms looks good. It would be good to also do more testing of LiveStackFrame.getStack(), but right now I want to focus on getting this getLocals() fix in. Testing of LiveStackFrame.getStack() will happen in a follow-up issue (8163825). Thanks, -Brent 1. http://hg.openjdk.java.net/jdk9/hs/jdk/file/1efce54b06b7/src/java.base/share/classes/java/lang/LiveStackFrame.java 2. https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.6.1 From frederic.parain at oracle.com Wed Aug 17 21:28:49 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 17 Aug 2016 17:28:49 -0400 Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect In-Reply-To: <57B4C392.4060001@oracle.com> References: <57B4C392.4060001@oracle.com> Message-ID: Brent, hotspot/src/share/vm/prims/stackwalk.cpp: 230 if (!expressions && 231 values->at(i)->type() == T_INT && 232 values->int_at(i) == 0 && // empty first slot of long? 233 i+1 < values->size() && 234 values->at(i+1)->type() == T_INT) { How does this test make the difference between: 1 - a local variable of type long 2 - two consecutive local variables of type int with the value of the first one being zero (1) requires the fix, but (2) does not. Another question: is it guaranteed that an unused slot from a pair-slot is always zero? This is not written in the JVM spec, and I don't remember that the JVM zeroes unused slots. A last question: the fix tries to provide a view of the local variables that matches the JVM spec rather than the implementation, so if half of the long or double value is put in the first slot, why the second slot is not stripped to only store the other half? Regards, Fred On 08/17/2016 04:05 PM, Brent Christian wrote: > Hi, > > Please review this StackWalker fix in hotspot for 8156073, "2-slot > LiveStackFrame locals (long and double) are incorrect" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156073 > Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/ > > The experimental LiveStackFrame[1] interface for StackWalker provides > access to stack frames' local variables, returned in an Object[] from > LiveStackFrame.getLocals(). > > Long and double primitives are returned using two array slots (similar > to JVMS section 2.6.1 [2]). This works as indicated on 32-bit JDKs, but > needs some fixing on 64-bit. > > AFAICT under 64-bit, StackValueCollection stores the entire > long/double in the 2nd (64-bit) slot: > > jlong StackValueCollection::long_at(int slot) const { > #ifdef _LP64 > return at(slot+1)->get_int(); > #else > ... > > The first slot goes unused and contains 0, instead of holding half of > the long value as stackwalker expects. So stackwalker needs to take > care splitting the value between the two slots. > > The fix examines StackValueCollection::long_at(i), checks for an > unexpected 0 value from StackValueCollection::int_at(i), and copies > the needed 32-bits (depending on native byte ordering) into the first > slot as needed. (The 2nd slot gets truncated to 32-bits in > create_primitive_value_instance()). > > Here's the fix in action on linux_x64 with the updated > LocalsAndOperands.java test. Slots 4+5 contain a long, 6+7 contain a > double. > > Before the fix: > ... > local 3: himom type java.lang.String > local 4: 0 type I <-- > local 5: 65535 type I > local 6: 0 type I <-- > local 7: 1293080650 type I > local 8: 0 type I > > After the fix: > ... > local 3: himom type java.lang.String > local 4: 1023 type I <-- > local 5: 65535 type I > local 6: 1074340347 type I <-- > local 7: 1293080650 type I > local 8: 0 type I > > This change also fixes 8158879, "Add new test for verifying 2-slot > locals in LiveStackFrame". Thanks to Fabio Tudone > (fabio at paralleluniverse.co) for the test case. I only test unused > ("dead") local variables with -Xint, because they are removed in > compiled frames. > > An automated build & test run on all platforms looks good. > > It would be good to also do more testing of LiveStackFrame.getStack(), > but right now I want to focus on getting this getLocals() fix in. > Testing of LiveStackFrame.getStack() will happen in a follow-up issue > (8163825). > > Thanks, > -Brent > > 1. > http://hg.openjdk.java.net/jdk9/hs/jdk/file/1efce54b06b7/src/java.base/share/classes/java/lang/LiveStackFrame.java > > 2. > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.6.1 > From claes.redestad at oracle.com Wed Aug 17 21:33:22 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 17 Aug 2016 23:33:22 +0200 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle Message-ID: <57B4D822.9010507@oracle.com> Hi, please review this change which adds pre-generation of simple DelegatingMethodHandles corresponding to the DirectMethodHandles we already pre-generate during linking. webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ bug: https://bugs.openjdk.java.net/browse/JDK-8164044 This also includes some cleanup suggested by Vladimir during internal review, such as: - adding an enum to control this behavior, which allows removing the special version of LF.compileToBytecode introduced by JDK-8163369 - refactored resolution of pregenerated code to the InvokerBytecodeGenerator - removing reliance on the LF.debugName (which we have some loose ideas to remove from LF and tuck away in a map we only create and initialize when actually debugging). This patch removes 11 out of the 39 classes generated on first use of the StringConcatFactory in a simple test, amounting to a ~10ms speedup on my machine. Thanks! /Claes From paul.sandoz at oracle.com Thu Aug 18 00:03:47 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 17 Aug 2016 17:03:47 -0700 Subject: Fork/Join exceptional completion can return before all tasks have finished executing Re: Exceptional behavior of parallel stream In-Reply-To: <1882659279.20160817200105@gmail.com> References: <1882659279.20160817200105@gmail.com> Message-ID: Hi Tagir, Hmm? we certainly ensure that any short-circuiting computation will wait until all the computation is complete (tasks still running whose results will be thrown away have to complete before the terminal operation returns). In that sprit we should be consistent when exceptions are thrown. But we don?t currently do anything or say anything when a task exceptionally completes, which propagates exceptional completion status up through the computation tree, and when the root task is hit (whose status has the SIGNAL bit set) the caller thread will be notified. This happens independently of task completion via pending counts of CountedCompleter and rest of the computation continues on blissfully unaware. I need to think about this a little more. To support this we may need to track exceptional completion explicitly by propagating state through CountedCompleter completions. Paul. From christoph.langer at sap.com Thu Aug 18 05:47:59 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 18 Aug 2016 05:47:59 +0000 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: <57B4910A.3070707@oracle.com> References: <57B20566.7040004@oracle.com> <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> <57B4910A.3070707@oracle.com> Message-ID: +1, nice fix. > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 17. August 2016 18:30 > To: Aleks Efimov > Cc: core-libs-dev > Subject: Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static > final Exceptions > > Looks good, Aleksej. Thanks for coming up with a well-thought solution > to get rid of the static RE field. > > Best, > Joe > > On 8/17/16, 7:04 AM, Aleks Efimov wrote: > > Hi Joe, Aleksey, > > Thank you for reviewing the initial fix. > > > > I followed the Joe's suggestion (thanks for that) and removed static > > 'abort' field completely, the functionality was replaced by throwing > > the exception of newly added type - AbortException. The new webrev > > with removed 'abort' can be found here: > > http://cr.openjdk.java.net/~aefimov/8146961/9/01 > > > > The Tomcat reproducer attached to the bug report fails without the fix > > and passes with the new version of the fix. > > The JPRT and JCK testing again shows no related jaxp tests failures. > > > > Best Regards, > > Aleksej > > > > > > On 15/08/16 21:09, Joe Wang wrote: > >> Hi Aleksej, > >> > >> I suggest we get rid of the static abort. If RuntimeException > >> happens, check where it happens. The first use case looks suspicious > >> as it just returns if it's an instance of RE. For the 2nd case in DOM > >> error report, let's throw a RuntimeException with the specified error > >> message if error happens, and there's no handler or the handler > >> failed to handle it. (would be better than an empty RE) > >> > >> Best, > >> Joe > >> > >> On 8/15/16, 10:38 AM, Aleks Efimov wrote: > >>> Hi, > >>> > >>> Please, help to review the fix for memory leak [1] in > >>> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused > >>> by usage of static final exceptions. > >>> This problem was already fixed in Apache Xerces project [2] and I > >>> would like to backport it to JDK9 Xerces implementation. > >>> Webrev with the changes: > >>> http://cr.openjdk.java.net/~aefimov/8146961/9/00 > >>> > >>> The Tomcat reproducer attached to the bug report fails without the > >>> fix and passes with the fix. > >>> The JPRT and JCK testing shows no jaxp tests failures with the > >>> proposed fix. > >>> > >>> With Best Regards, > >>> Aleksej > >>> > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 > >>> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 > >>> > > From peter.levart at gmail.com Thu Aug 18 08:08:20 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 18 Aug 2016 10:08:20 +0200 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> References: <57B20566.7040004@oracle.com> <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> Message-ID: <1f2c79d4-e6ff-0f52-bff1-5637449db958@gmail.com> Hi Aleks, Looks OK, but if AbortException is never inspected for a stack trace, then it could be constructed without it. This is perhaps unnecessary if it is not on the hot path, but it is easy to just call the appropriate super constructor: public class AbortException extends RuntimeException { private static final long serialVersionUID = 2608302175475740417L; /** * Constructor AbortException */ public AbortException() { super(null, null, false, false); } } Regards, Peter On 08/17/2016 04:04 PM, Aleks Efimov wrote: > Hi Joe, Aleksey, > Thank you for reviewing the initial fix. > > I followed the Joe's suggestion (thanks for that) and removed static > 'abort' field completely, the functionality was replaced by throwing > the exception of newly added type - AbortException. The new webrev > with removed 'abort' can be found here: > http://cr.openjdk.java.net/~aefimov/8146961/9/01 > > The Tomcat reproducer attached to the bug report fails without the fix > and passes with the new version of the fix. > The JPRT and JCK testing again shows no related jaxp tests failures. > > Best Regards, > Aleksej > > > On 15/08/16 21:09, Joe Wang wrote: >> Hi Aleksej, >> >> I suggest we get rid of the static abort. If RuntimeException >> happens, check where it happens. The first use case looks suspicious >> as it just returns if it's an instance of RE. For the 2nd case in DOM >> error report, let's throw a RuntimeException with the specified error >> message if error happens, and there's no handler or the handler >> failed to handle it. (would be better than an empty RE) >> >> Best, >> Joe >> >> On 8/15/16, 10:38 AM, Aleks Efimov wrote: >>> Hi, >>> >>> Please, help to review the fix for memory leak [1] in >>> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused >>> by usage of static final exceptions. >>> This problem was already fixed in Apache Xerces project [2] and I >>> would like to backport it to JDK9 Xerces implementation. >>> Webrev with the changes: >>> http://cr.openjdk.java.net/~aefimov/8146961/9/00 >>> >>> The Tomcat reproducer attached to the bug report fails without the >>> fix and passes with the fix. >>> The JPRT and JCK testing shows no jaxp tests failures with the >>> proposed fix. >>> >>> With Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 >>> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 >>> > From aleksej.efimov at oracle.com Thu Aug 18 10:05:58 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 18 Aug 2016 13:05:58 +0300 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: <1f2c79d4-e6ff-0f52-bff1-5637449db958@gmail.com> References: <57B20566.7040004@oracle.com> <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> <1f2c79d4-e6ff-0f52-bff1-5637449db958@gmail.com> Message-ID: <84574228-818c-fbd3-fb86-4c8f78229939@oracle.com> Hi Peter, Thank you for review and suggestion to add super constructor call: will add it before pushing the changes. Best Regards, Aleksej On 18/08/16 11:08, Peter Levart wrote: > Hi Aleks, > > Looks OK, but if AbortException is never inspected for a stack trace, > then it could be constructed without it. This is perhaps unnecessary > if it is not on the hot path, but it is easy to just call the > appropriate super constructor: > > public class AbortException extends RuntimeException { > > private static final long serialVersionUID = > 2608302175475740417L; > > /** > * Constructor AbortException > */ > public AbortException() { super(null, null, false, false); } > } > > > Regards, Peter > > On 08/17/2016 04:04 PM, Aleks Efimov wrote: >> Hi Joe, Aleksey, >> Thank you for reviewing the initial fix. >> >> I followed the Joe's suggestion (thanks for that) and removed static >> 'abort' field completely, the functionality was replaced by throwing >> the exception of newly added type - AbortException. The new webrev >> with removed 'abort' can be found here: >> http://cr.openjdk.java.net/~aefimov/8146961/9/01 >> >> The Tomcat reproducer attached to the bug report fails without the >> fix and passes with the new version of the fix. >> The JPRT and JCK testing again shows no related jaxp tests failures. >> >> Best Regards, >> Aleksej >> >> >> On 15/08/16 21:09, Joe Wang wrote: >>> Hi Aleksej, >>> >>> I suggest we get rid of the static abort. If RuntimeException >>> happens, check where it happens. The first use case looks suspicious >>> as it just returns if it's an instance of RE. For the 2nd case in >>> DOM error report, let's throw a RuntimeException with the specified >>> error message if error happens, and there's no handler or the >>> handler failed to handle it. (would be better than an empty RE) >>> >>> Best, >>> Joe >>> >>> On 8/15/16, 10:38 AM, Aleks Efimov wrote: >>>> Hi, >>>> >>>> Please, help to review the fix for memory leak [1] in >>>> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused >>>> by usage of static final exceptions. >>>> This problem was already fixed in Apache Xerces project [2] and I >>>> would like to backport it to JDK9 Xerces implementation. >>>> Webrev with the changes: >>>> http://cr.openjdk.java.net/~aefimov/8146961/9/00 >>>> >>>> The Tomcat reproducer attached to the bug report fails without the >>>> fix and passes with the fix. >>>> The JPRT and JCK testing shows no jaxp tests failures with the >>>> proposed fix. >>>> >>>> With Best Regards, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 >>>> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 >>>> >> > From aleksej.efimov at oracle.com Thu Aug 18 10:13:12 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 18 Aug 2016 13:13:12 +0300 Subject: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions In-Reply-To: References: <57B20566.7040004@oracle.com> <03d1f5cd-c3c3-1901-58f3-21810b1b550a@oracle.com> <57B4910A.3070707@oracle.com> Message-ID: <45fbb710-d991-28b0-72f5-d6d9fee1f55e@oracle.com> Joe, Christoph, Thanks for your reviews! With Best Regards, Aleksej On 18/08/16 08:47, Langer, Christoph wrote: > +1, nice fix. > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Joe Wang >> Sent: Mittwoch, 17. August 2016 18:30 >> To: Aleks Efimov >> Cc: core-libs-dev >> Subject: Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static >> final Exceptions >> >> Looks good, Aleksej. Thanks for coming up with a well-thought solution >> to get rid of the static RE field. >> >> Best, >> Joe >> >> On 8/17/16, 7:04 AM, Aleks Efimov wrote: >>> Hi Joe, Aleksey, >>> Thank you for reviewing the initial fix. >>> >>> I followed the Joe's suggestion (thanks for that) and removed static >>> 'abort' field completely, the functionality was replaced by throwing >>> the exception of newly added type - AbortException. The new webrev >>> with removed 'abort' can be found here: >>> http://cr.openjdk.java.net/~aefimov/8146961/9/01 >>> >>> The Tomcat reproducer attached to the bug report fails without the fix >>> and passes with the new version of the fix. >>> The JPRT and JCK testing again shows no related jaxp tests failures. >>> >>> Best Regards, >>> Aleksej >>> >>> >>> On 15/08/16 21:09, Joe Wang wrote: >>>> Hi Aleksej, >>>> >>>> I suggest we get rid of the static abort. If RuntimeException >>>> happens, check where it happens. The first use case looks suspicious >>>> as it just returns if it's an instance of RE. For the 2nd case in DOM >>>> error report, let's throw a RuntimeException with the specified error >>>> message if error happens, and there's no handler or the handler >>>> failed to handle it. (would be better than an empty RE) >>>> >>>> Best, >>>> Joe >>>> >>>> On 8/15/16, 10:38 AM, Aleks Efimov wrote: >>>>> Hi, >>>>> >>>>> Please, help to review the fix for memory leak [1] in >>>>> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused >>>>> by usage of static final exceptions. >>>>> This problem was already fixed in Apache Xerces project [2] and I >>>>> would like to backport it to JDK9 Xerces implementation. >>>>> Webrev with the changes: >>>>> http://cr.openjdk.java.net/~aefimov/8146961/9/00 >>>>> >>>>> The Tomcat reproducer attached to the bug report fails without the >>>>> fix and passes with the fix. >>>>> The JPRT and JCK testing shows no jaxp tests failures with the >>>>> proposed fix. >>>>> >>>>> With Best Regards, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146961 >>>>> [2] https://issues.apache.org/jira/browse/XERCESJ-1667 >>>>> From dl at cs.oswego.edu Thu Aug 18 10:54:32 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 18 Aug 2016 06:54:32 -0400 Subject: Exceptional behavior of parallel stream In-Reply-To: <1882659279.20160817200105@gmail.com> References: <1882659279.20160817200105@gmail.com> Message-ID: <2d8c7f16-6104-d3fd-b387-eeb66b4853f2@cs.oswego.edu> On 08/17/2016 09:01 AM, Tagir F. Valeev wrote: > Hello! > > I found no information in Stream API documentation on how it behaves > in case if exception occurs during the stream processing. While it's > quite evident for sequential stream (stream processing is terminated > and exception is propagated to the caller as is), the behavior for > parallel streams differs from one might expect. Consider the following > test: In your example, you can witness the delayed termination of other threads upon exception in another because you add side-effecting operations (here, just printing). Avoiding all this would force sequential processing. But if the supplied functions follow the documented properties, it should not matter that parallel processing of some elements continues when another hits an exception. Which is why nothing is said about it. Similar effects occur in findAny and other methods. I don't see any benefit in trying to specify exactly what happens in these cases. -Doug > > String[] data = IntStream.range(0, 100).mapToObj(String::valueOf) > .toArray(String[]::new); > data[20] = "oops"; > try { > int sum = Arrays.stream(data).parallel().mapToInt(Integer::valueOf) > .peek(System.out::println).sum(); > System.out.println("Sum is "+sum); > } catch (NumberFormatException e) { > System.out.println("Non-number appeared!"); > } > > This parses integers stored in string array and sums them outputting > every number to stdout once it processed. As data set contains > non-number, the stream obviously fails with NumberFormatException. The > typical output looks like this: > > 62 > 63 > 12 > 31 > 87 > ... > 28 > 92 > 29 > 8 > Non-number appeared! > 9 > 30 > > So as you can see, the stream is not actually terminated when > exception is thrown and caught: even after that some parallel tasks > continue running, and you see more numbers printed after catch block > is executed. > > I consider such behavior as confusing and unexpected. Given the fact > that stream may produce side-effects (e.g. if terminal op is forEach) > this might lead to unforeseen consequences in user programs as > left-over parallel stream tasks may continue mutate shared state after > main stream thread exceptionally returns the control to the caller. > > So I suggest that such behavior should be either fixed or explicitly > documented. What do you think? > > With best regards, > Tagir Valeev. > > From amaembo at gmail.com Thu Aug 18 11:58:46 2016 From: amaembo at gmail.com (Tagir F. Valeev) Date: Thu, 18 Aug 2016 18:58:46 +0700 Subject: Exceptional behavior of parallel stream In-Reply-To: <2d8c7f16-6104-d3fd-b387-eeb66b4853f2@cs.oswego.edu> References: <1882659279.20160817200105@gmail.com> <2d8c7f16-6104-d3fd-b387-eeb66b4853f2@cs.oswego.edu> Message-ID: <185642988.20160818185846@gmail.com> Hello, Doug! Thank you for your response. DL> In your example, you can witness the delayed termination of other threads DL> upon exception in another because you add side-effecting operations DL> (here, just printing). Avoiding all this would force sequential processing. DL> But if the supplied functions follow the documented properties, DL> it should not matter that parallel processing of some elements continues DL> when another hits an exception. Which is why nothing is said about it. DL> Similar effects occur in findAny and other methods. I don't see any benefit DL> in trying to specify exactly what happens in these cases. Note that functions supplied to peek, forEach and forEachOrdered methods, according to the documentation are allowed to produce side-effect (otherwise these operations would be completely useless). Thus my example does not violate the documented way of using streams. While you may argue that the "peek" is intended for debugging use, it's still possible to show the same effect using forEach. Thus I don't agree that using Streams in documented way you cannot hit this problem. Of course using forEach is usually discouraged, but it's still legal API method. With best regards, Tagir Valeev. DL> -Doug >> >> String[] data = IntStream.range(0, 100).mapToObj(String::valueOf) >> .toArray(String[]::new); >> data[20] = "oops"; >> try { >> int sum = Arrays.stream(data).parallel().mapToInt(Integer::valueOf) >> .peek(System.out::println).sum(); >> System.out.println("Sum is "+sum); >> } catch (NumberFormatException e) { >> System.out.println("Non-number appeared!"); >> } >> >> This parses integers stored in string array and sums them outputting >> every number to stdout once it processed. As data set contains >> non-number, the stream obviously fails with NumberFormatException. The >> typical output looks like this: >> >> 62 >> 63 >> 12 >> 31 >> 87 >> ... >> 28 >> 92 >> 29 >> 8 >> Non-number appeared! >> 9 >> 30 >> >> So as you can see, the stream is not actually terminated when >> exception is thrown and caught: even after that some parallel tasks >> continue running, and you see more numbers printed after catch block >> is executed. >> >> I consider such behavior as confusing and unexpected. Given the fact >> that stream may produce side-effects (e.g. if terminal op is forEach) >> this might lead to unforeseen consequences in user programs as >> left-over parallel stream tasks may continue mutate shared state after >> main stream thread exceptionally returns the control to the caller. >> >> So I suggest that such behavior should be either fixed or explicitly >> documented. What do you think? >> >> With best regards, >> Tagir Valeev. >> >> From claes.redestad at oracle.com Thu Aug 18 12:25:50 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Aug 2016 14:25:50 +0200 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> References: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> Message-ID: <57B5A94E.7040808@oracle.com> On 2016-08-16 19:20, Ivan Gerasimov wrote: >> ObjectStreamClass: >> >> I wonder if the entire getPackageName is replaceable with >> Class.getPackageName()? If so, ditch the method completely and use >> Class.getPackageName everywhere. This may complicate backporting to JDK >> 8 though. > > Unfortunately, Class.getPackageName() cannot handle arrays, so I'll > leave it as is. There are a number of utility methods around that could be reused, e.g., jdk.internal.reflect.Reflection.isSameClassPackage handles both arrays and primitive types and could replace both packageEquals and getPackageName in ObjectStreamClass (which already use j.i.r.Reflection for other things). Making isSameClassPackage in Reflection public should be non-controversial, I hope. Thanks! /Claes From michael.haupt at oracle.com Thu Aug 18 13:55:17 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 18 Aug 2016 15:55:17 +0200 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: <57B4D822.9010507@oracle.com> References: <57B4D822.9010507@oracle.com> Message-ID: Hi Claes, thumbs up. Best, Michael > Am 17.08.2016 um 23:33 schrieb Claes Redestad : > > Hi, > > please review this change which adds pre-generation of simple DelegatingMethodHandles corresponding to the DirectMethodHandles we already pre-generate during linking. > > webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8164044 > > This also includes some cleanup suggested by Vladimir during internal review, such as: > > - adding an enum to control this behavior, which allows removing the special version of LF.compileToBytecode introduced by JDK-8163369 > - refactored resolution of pregenerated code to the InvokerBytecodeGenerator > - removing reliance on the LF.debugName (which we have some loose ideas to remove from LF and tuck away in a map we only create and initialize when actually debugging). > > This patch removes 11 out of the 39 classes generated on first use of the StringConcatFactory in a simple test, amounting to a ~10ms speedup on my machine. > > Thanks! > > /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aleksey.shipilev at gmail.com Thu Aug 18 14:06:08 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 18 Aug 2016 17:06:08 +0300 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: <57B4D822.9010507@oracle.com> References: <57B4D822.9010507@oracle.com> Message-ID: On 08/18/2016 12:33 AM, Claes Redestad wrote: > Hi, > > please review this change which adds pre-generation of simple > DelegatingMethodHandles corresponding to the DirectMethodHandles we > already pre-generate during linking. > > webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ *) This block: if (!dedupSet.contains(methodTypes[i])) { // do stuff dedupSet.add(methodTypes[i]); } Is replaceable by: if (dedupSet.add(methodTypes[i])) { // do stuff } *) Can save instantiation here, by moving ptypes into else branch: 333 Class[] ptypes = new Class[parameters.length()]; 334 if (ptypes.length == 0) { 335 return MethodType.methodType(rtype); 336 } else { 337 for (int i = 0; i < ptypes.length; i++) { 338 ptypes[i] = simpleType(parameters.charAt(i)); 339 } 340 return MethodType.methodType(rtype, ptypes); 341 } 342 } *) Many whitespaces from this switch: 195 switch (which) { 196 case LF_INVVIRTUAL: linkerName = "linkToVirtual"; kind = DIRECT_INVOKE_VIRTUAL; break; 197 case LF_INVSTATIC: linkerName = "linkToStatic"; kind = DIRECT_INVOKE_STATIC; break; 198 case LF_INVSTATIC_INIT:linkerName = "linkToStatic"; kind = DIRECT_INVOKE_STATIC_INIT; break; 199 case LF_INVSPECIAL: linkerName = "linkToSpecial"; kind = DIRECT_INVOKE_SPECIAL; break; 200 case LF_INVINTERFACE: linkerName = "linkToInterface"; kind = DIRECT_INVOKE_INTERFACE; break; 201 case LF_NEWINVSPECIAL: linkerName = "linkToSpecial"; kind = DIRECT_NEW_INVOKE_SPECIAL; break; 202 default: throw new InternalError("which="+which); ...ran away to this one: 154 private static Kind whichKind(int whichCache) { 155 switch(whichCache) { 156 case MethodTypeForm.LF_REBIND: return BOUND_REINVOKER; 157 case MethodTypeForm.LF_DELEGATE: return DELEGATE; 158 default: return REINVOKER; 159 } 160 } Thanks, -Aleksey From vladimir.x.ivanov at oracle.com Thu Aug 18 14:13:48 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Aug 2016 17:13:48 +0300 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: <57B4D822.9010507@oracle.com> References: <57B4D822.9010507@oracle.com> Message-ID: <1b507ff7-7833-84a7-75bb-3592e3d6a084@oracle.com> Good work! Reviewed. Best regards, Vladimir Ivanov PS: I wish LF.debugString completely went away, but let's keep it for future cleanup. On 8/18/16 12:33 AM, Claes Redestad wrote: > Hi, > > please review this change which adds pre-generation of simple > DelegatingMethodHandles corresponding to the DirectMethodHandles we > already pre-generate during linking. > > webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8164044 > > This also includes some cleanup suggested by Vladimir during internal > review, such as: > > - adding an enum to control this behavior, which allows removing the > special version of LF.compileToBytecode introduced by JDK-8163369 > - refactored resolution of pregenerated code to the > InvokerBytecodeGenerator > - removing reliance on the LF.debugName (which we have some loose ideas > to remove from LF and tuck away in a map we only create and initialize > when actually debugging). > > This patch removes 11 out of the 39 classes generated on first use of > the StringConcatFactory in a simple test, amounting to a ~10ms speedup > on my machine. > > Thanks! > > /Claes From aleksey.shipilev at gmail.com Thu Aug 18 14:19:25 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 18 Aug 2016 17:19:25 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> References: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> Message-ID: <5fe64c98-df62-b817-3b64-4d7138ea675c@gmail.com> On 08/16/2016 08:20 PM, Ivan Gerasimov wrote: > Here is the updated webrev: > http://cr.openjdk.java.net/~igerasim/8163517/01/webrev/ Looks good to me. -Aleksey From claes.redestad at oracle.com Thu Aug 18 14:13:26 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Aug 2016 16:13:26 +0200 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: <1b507ff7-7833-84a7-75bb-3592e3d6a084@oracle.com> References: <57B4D822.9010507@oracle.com> <1b507ff7-7833-84a7-75bb-3592e3d6a084@oracle.com> Message-ID: <57B5C286.40609@oracle.com> Michael, Vladimir, thanks for reviewing and suggesting improvements. Getting rid of LF.debugName seems like a rather straight-forward and worthwhile cleanup at this point. /Claes On 2016-08-18 16:13, Vladimir Ivanov wrote: > Good work! Reviewed. > > Best regards, > Vladimir Ivanov > > PS: I wish LF.debugString completely went away, but let's keep it for > future cleanup. > > On 8/18/16 12:33 AM, Claes Redestad wrote: >> Hi, >> >> please review this change which adds pre-generation of simple >> DelegatingMethodHandles corresponding to the DirectMethodHandles we >> already pre-generate during linking. >> >> webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8164044 >> >> This also includes some cleanup suggested by Vladimir during internal >> review, such as: >> >> - adding an enum to control this behavior, which allows removing the >> special version of LF.compileToBytecode introduced by JDK-8163369 >> - refactored resolution of pregenerated code to the >> InvokerBytecodeGenerator >> - removing reliance on the LF.debugName (which we have some loose ideas >> to remove from LF and tuck away in a map we only create and initialize >> when actually debugging). >> >> This patch removes 11 out of the 39 classes generated on first use of >> the StringConcatFactory in a simple test, amounting to a ~10ms speedup >> on my machine. >> >> Thanks! >> >> /Claes From yasuenag at gmail.com Thu Aug 18 14:21:05 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 18 Aug 2016 23:21:05 +0900 Subject: Error at jrt*.js Message-ID: <2f1409f3-15cb-8710-4f22-cc409f871cfe@gmail.com> Hi all, I tried to run jrtfsviewer.js and jrtls.js . But they did not work as below: ---------------- $ jjs -fx jrtfsviewer.js Exception in Application start method Exception in thread "main" java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(javafx.graphics at 9-ea/LauncherImpl.java:897) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(javafx.graphics at 9-ea/LauncherImpl.java:188) at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) Caused by: java.lang.NullPointerException at java.util.Objects.requireNonNull(java.base at 9-ea/Objects.java:221) at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(java.base at 9-ea/JrtFileSystemProvider.java:104) at java.nio.file.FileSystems.newFileSystem(java.base at 9-ea/FileSystems.java:342) at jdk.nashorn.internal.scripts.Script$Recompilation$22$3116$jrtfsviewer$cu1$restOf.getJrtFileSystem(jdk.scripting.nashorn.scripts/jrtfsviewer.js:103) at jdk.nashorn.internal.scripts.Script$Recompilation$17$3748A$jrtfsviewer.start(jdk.scripting.nashorn.scripts/jrtfsviewer.js:109) at jdk.nashorn.internal.scripts.Script$Recompilation$6$839A$\=fx\!bootstrap$cu1$restOf.start(jdk.scripting.nashorn.scripts/fx:bootstrap.js:57) at jdk.nashorn.javaadapters.javafx_application_Application.start(Unknown Source) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(javafx.graphics at 9-ea/LauncherImpl.java:843) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(javafx.graphics at 9-ea/PlatformImpl.java:452) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(javafx.graphics at 9-ea/PlatformImpl.java:421) at java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(javafx.graphics at 9-ea/PlatformImpl.java:420) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(javafx.graphics at 9-ea/InvokeLaterDispatcher.java:96) at com.sun.glass.ui.win.WinApplication._runLoop(javafx.graphics at 9-ea/Native Method) at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(javafx.graphics at 9-ea/WinApplication.java:189) ... 1 more ---------------- $ jjs jrtls.js jrtls.js:37:1 Expected an operand but found * */ ^ ---------------- These scripts are not in JDK. I guess they are used for checking JDK/JRE modules by JDK developers, and they are no longer used. So I'm not sure whether they should be fixed. I think they can be fixed as below: ---------------- diff -r b60dcba6b4f9 src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js --- a/src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js Tue Aug 16 09:57:50 2016 +0200 +++ b/src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js Wed Aug 18 20:41:25 2016 +0900 @@ -53,6 +53,7 @@ var Files = Java.type("java.nio.file.Files"); var System = Java.type("java.lang.System"); var URI = Java.type("java.net.URI"); +var Collections = Java.type("java.util.Collections"); // JavaFX classes used var StackPane = Java.type("javafx.scene.layout.StackPane"); @@ -100,7 +101,7 @@ print("did you miss specifying jrt-fs.jar with -cp option?"); usage(); } - return FileSystems.newFileSystem(uri, null, cls.classLoader); + return FileSystems.newFileSystem(uri, Collections.emptyMap(), cls.classLoader); } } diff -r b60dcba6b4f9 src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js --- a/src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js Tue Aug 16 09:57:50 2016 +0200 +++ b/src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js Wed Aug 18 20:41:25 2016 +0900 @@ -34,7 +34,6 @@ * but also compiled and delivered as part of the jrtfs.jar to support access * to the jimage file provided by the shipped JDK by tools running on JDK 8. */ - */ // classes used var Files = Java.type("java.nio.file.Files"); ---------------- If this fix should be merged, I'll file it to JBS and upload webrev. What do you think about it? Thanks, Yasumasa From sundararajan.athijegannathan at oracle.com Thu Aug 18 14:34:26 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 18 Aug 2016 20:04:26 +0530 Subject: Error at jrt*.js In-Reply-To: <2f1409f3-15cb-8710-4f22-cc409f871cfe@gmail.com> References: <2f1409f3-15cb-8710-4f22-cc409f871cfe@gmail.com> Message-ID: <0ea05394-4787-8f5c-8473-e24a66c65e8f@oracle.com> Yes, those scripts are meant for developers and not part of binary JDK bits. Please do file a bug and send webrev for review. -Sundar On 8/18/2016 7:51 PM, Yasumasa Suenaga wrote: > Hi all, > > I tried to run jrtfsviewer.js and jrtls.js . But they did not work as > below: > ---------------- > $ jjs -fx jrtfsviewer.js > Exception in Application start method > Exception in thread "main" java.lang.RuntimeException: Exception in > Application start method > at > com.sun.javafx.application.LauncherImpl.launchApplication1(javafx.graphics at 9-ea/LauncherImpl.java:897) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(javafx.graphics at 9-ea/LauncherImpl.java:188) > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > Caused by: java.lang.NullPointerException > at > java.util.Objects.requireNonNull(java.base at 9-ea/Objects.java:221) > at > jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(java.base at 9-ea/JrtFileSystemProvider.java:104) > at > java.nio.file.FileSystems.newFileSystem(java.base at 9-ea/FileSystems.java:342) > at > jdk.nashorn.internal.scripts.Script$Recompilation$22$3116$jrtfsviewer$cu1$restOf.getJrtFileSystem(jdk.scripting.nashorn.scripts/jrtfsviewer.js:103) > at > jdk.nashorn.internal.scripts.Script$Recompilation$17$3748A$jrtfsviewer.start(jdk.scripting.nashorn.scripts/jrtfsviewer.js:109) > at > jdk.nashorn.internal.scripts.Script$Recompilation$6$839A$\=fx\!bootstrap$cu1$restOf.start(jdk.scripting.nashorn.scripts/fx:bootstrap.js:57) > at > jdk.nashorn.javaadapters.javafx_application_Application.start(Unknown > Source) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(javafx.graphics at 9-ea/LauncherImpl.java:843) > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(javafx.graphics at 9-ea/PlatformImpl.java:452) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(javafx.graphics at 9-ea/PlatformImpl.java:421) > at > java.security.AccessController.doPrivileged(java.base at 9-ea/Native Method) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(javafx.graphics at 9-ea/PlatformImpl.java:420) > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(javafx.graphics at 9-ea/InvokeLaterDispatcher.java:96) > at > com.sun.glass.ui.win.WinApplication._runLoop(javafx.graphics at 9-ea/Native > Method) > at > com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(javafx.graphics at 9-ea/WinApplication.java:189) > ... 1 more > ---------------- > $ jjs jrtls.js > jrtls.js:37:1 Expected an operand but found * > */ > ^ > ---------------- > > These scripts are not in JDK. I guess they are used for checking > JDK/JRE modules by JDK developers, and they are no longer used. > So I'm not sure whether they should be fixed. > > I think they can be fixed as below: > ---------------- > diff -r b60dcba6b4f9 > src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js > --- a/src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js > Tue Aug 16 09:57:50 2016 +0200 > +++ b/src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js > Wed Aug 18 20:41:25 2016 +0900 > @@ -53,6 +53,7 @@ > var Files = Java.type("java.nio.file.Files"); > var System = Java.type("java.lang.System"); > var URI = Java.type("java.net.URI"); > +var Collections = Java.type("java.util.Collections"); > > // JavaFX classes used > var StackPane = Java.type("javafx.scene.layout.StackPane"); > @@ -100,7 +101,7 @@ > print("did you miss specifying jrt-fs.jar with -cp > option?"); > usage(); > } > - return FileSystems.newFileSystem(uri, null, cls.classLoader); > + return FileSystems.newFileSystem(uri, Collections.emptyMap(), > cls.classLoader); > } > } > > diff -r b60dcba6b4f9 > src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js > --- a/src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js Tue > Aug 16 09:57:50 2016 +0200 > +++ b/src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js Wed > Aug 18 20:41:25 2016 +0900 > @@ -34,7 +34,6 @@ > * but also compiled and delivered as part of the jrtfs.jar to > support access > * to the jimage file provided by the shipped JDK by tools running on > JDK 8. > */ > - */ > > // classes used > var Files = Java.type("java.nio.file.Files"); > ---------------- > > If this fix should be merged, I'll file it to JBS and upload webrev. > What do you think about it? > > > Thanks, > > Yasumasa > From claes.redestad at oracle.com Thu Aug 18 14:32:15 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Aug 2016 16:32:15 +0200 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: References: <57B4D822.9010507@oracle.com> Message-ID: <57B5C6EF.10601@oracle.com> On 2016-08-18 16:06, Aleksey Shipilev wrote: > On 08/18/2016 12:33 AM, Claes Redestad wrote: >> Hi, >> >> please review this change which adds pre-generation of simple >> DelegatingMethodHandles corresponding to the DirectMethodHandles we >> already pre-generate during linking. >> >> webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ > *) This block: > > if (!dedupSet.contains(methodTypes[i])) { > // do stuff > dedupSet.add(methodTypes[i]); > } > > Is replaceable by: > > if (dedupSet.add(methodTypes[i])) { > // do stuff > } Sure! > > *) Can save instantiation here, by moving ptypes into else branch: > > 333 Class[] ptypes = new Class[parameters.length()]; > 334 if (ptypes.length == 0) { > 335 return MethodType.methodType(rtype); > 336 } else { > 337 for (int i = 0; i < ptypes.length; i++) { > 338 ptypes[i] = simpleType(parameters.charAt(i)); > 339 } > 340 return MethodType.methodType(rtype, ptypes); > 341 } > 342 } Efficiency of code only called at link time isn't too important, but it also looks cleaner: fixed. > > *) Many whitespaces from this switch: > > 195 switch (which) { > 196 case LF_INVVIRTUAL: linkerName = "linkToVirtual"; kind > = DIRECT_INVOKE_VIRTUAL; break; > 197 case LF_INVSTATIC: linkerName = "linkToStatic"; kind > = DIRECT_INVOKE_STATIC; break; > 198 case LF_INVSTATIC_INIT:linkerName = "linkToStatic"; kind > = DIRECT_INVOKE_STATIC_INIT; break; > 199 case LF_INVSPECIAL: linkerName = "linkToSpecial"; kind > = DIRECT_INVOKE_SPECIAL; break; > 200 case LF_INVINTERFACE: linkerName = "linkToInterface"; kind > = DIRECT_INVOKE_INTERFACE; break; > 201 case LF_NEWINVSPECIAL: linkerName = "linkToSpecial"; kind > = DIRECT_NEW_INVOKE_SPECIAL; break; > 202 default: throw new InternalError("which="+which); > > ...ran away to this one: > > 154 private static Kind whichKind(int whichCache) { > 155 switch(whichCache) { > 156 case MethodTypeForm.LF_REBIND: return > BOUND_REINVOKER; > 157 case MethodTypeForm.LF_DELEGATE: return DELEGATE; > 158 default: return REINVOKER; > 159 } > 160 } I assume you want less whitespace? http://cr.openjdk.java.net/~redestad/8164044/webrev.03/ Thanks! /Claes > > Thanks, > -Aleksey > > From yasuenag at gmail.com Thu Aug 18 15:18:51 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 19 Aug 2016 00:18:51 +0900 Subject: RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work Message-ID: <89199d55-6e27-ff1d-fc03-16663fa67c46@gmail.com> Hi all, This review request is related to [1]. jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. However, these tool might be used by JDK developers. So I think we should fix this issue. I uploaded a webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8164326/webrev.00/ Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042995.html From xueming.shen at oracle.com Thu Aug 18 15:50:46 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 18 Aug 2016 08:50:46 -0700 Subject: RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work In-Reply-To: <89199d55-6e27-ff1d-fc03-16663fa67c46@gmail.com> References: <89199d55-6e27-ff1d-fc03-16663fa67c46@gmail.com> Message-ID: <53232878-e8a4-0a1c-4efa-e1d5e6193e35@oracle.com> +1 On 8/18/16 8:18 AM, Yasumasa Suenaga wrote: > Hi all, > > This review request is related to [1]. > > jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. > However, these tool might be used by JDK developers. So I think we > should fix this issue. > > I uploaded a webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8164326/webrev.00/ > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042995.html From sundararajan.athijegannathan at oracle.com Thu Aug 18 15:54:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 18 Aug 2016 21:24:04 +0530 Subject: RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work In-Reply-To: <89199d55-6e27-ff1d-fc03-16663fa67c46@gmail.com> References: <89199d55-6e27-ff1d-fc03-16663fa67c46@gmail.com> Message-ID: <0cb21b77-8221-91b4-817a-5fcd2714e674@oracle.com> +1 On 8/18/2016 8:48 PM, Yasumasa Suenaga wrote: > Hi all, > > This review request is related to [1]. > > jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. > However, these tool might be used by JDK developers. So I think we > should fix this issue. > > I uploaded a webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8164326/webrev.00/ > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042995.html From aleksey.shipilev at gmail.com Thu Aug 18 16:11:02 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 18 Aug 2016 19:11:02 +0300 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: <57B5C6EF.10601@oracle.com> References: <57B4D822.9010507@oracle.com> <57B5C6EF.10601@oracle.com> Message-ID: On 08/18/2016 05:32 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8164044/webrev.03/ Doing this twice now? + dedupSet.add(methodTypes[i]); Otherwise thumbs up. -Aleksey From claes.redestad at oracle.com Thu Aug 18 16:20:12 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Aug 2016 18:20:12 +0200 Subject: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle In-Reply-To: References: <57B4D822.9010507@oracle.com> <57B5C6EF.10601@oracle.com> Message-ID: <57B5E03C.1060904@oracle.com> On 2016-08-18 18:11, Aleksey Shipilev wrote: > On 08/18/2016 05:32 PM, Claes Redestad wrote: >> http://cr.openjdk.java.net/~redestad/8164044/webrev.03/ > Doing this twice now? > > + dedupSet.add(methodTypes[i]); Oops. Fixed and updated in-place. > > Otherwise thumbs up. Thanks! /Claes From ivan.gerasimov at oracle.com Thu Aug 18 16:53:39 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 18 Aug 2016 19:53:39 +0300 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input Message-ID: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> Hello everybody! The factory methods of ZoneOffset class demonstrate a minor inconsistency. Normally, invalid values of arguments are rejected (e.g. when minutes > 59), but the value of Integer.MIN_VALUE is allowed to be passed in. This is due to using Math.abs(), which cannot handle Integer.MIN_VALUE well. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8164366 WEBREV: http://cr.openjdk.java.net/~igerasim/8164366/00/webrev/ With kind regards, Ivan From lance.andersen at oracle.com Thu Aug 18 18:08:02 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 18 Aug 2016 14:08:02 -0400 Subject: RFR 8138661, Address DataSource javadoc typo Message-ID: <5B625F00-91FC-40F6-82E7-04982D4D74AF@oracle.com> Hi all, This is a trivial fix of a typo in DataSource --------------------------------- ljanders-mac:jdk ljanders$ hg diff diff -r 6f5da13861db src/java.sql/share/classes/javax/sql/DataSource.java --- a/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 16:27:15 2016 +0300 +++ b/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 14:05:10 2016 -0400 @@ -64,7 +64,7 @@ *

* A driver that is accessed via a {@code DataSource} object does not * register itself with the {@code DriverManager}. Rather, a - * {@code DataSource} object is retrieved though a lookup operation + * {@code DataSource} object is retrieved through a lookup operation * and then used to create a {@code Connection} object. With a basic * implementation, the connection obtained through a {@code DataSource} * object is identical to a connection obtained through the ljanders-mac:jdk ljanders$ --------------------------------- 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 scolebourne at joda.org Thu Aug 18 18:16:42 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 18 Aug 2016 19:16:42 +0100 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> Message-ID: Looks good Stephen On 18 August 2016 at 17:53, Ivan Gerasimov wrote: > Hello everybody! > > The factory methods of ZoneOffset class demonstrate a minor inconsistency. > Normally, invalid values of arguments are rejected (e.g. when minutes > 59), > but the value of Integer.MIN_VALUE is allowed to be passed in. > > This is due to using Math.abs(), which cannot handle Integer.MIN_VALUE well. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8164366 > WEBREV: http://cr.openjdk.java.net/~igerasim/8164366/00/webrev/ > > With kind regards, > Ivan > From naoto.sato at oracle.com Thu Aug 18 18:20:01 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 18 Aug 2016 11:20:01 -0700 Subject: RFR 8138661, Address DataSource javadoc typo In-Reply-To: <5B625F00-91FC-40F6-82E7-04982D4D74AF@oracle.com> References: <5B625F00-91FC-40F6-82E7-04982D4D74AF@oracle.com> Message-ID: Looks good, Lance. Naoto On 8/18/16 11:08 AM, Lance Andersen wrote: > Hi all, > > This is a trivial fix of a typo in DataSource > > --------------------------------- > > ljanders-mac:jdk ljanders$ hg diff > diff -r 6f5da13861db src/java.sql/share/classes/javax/sql/DataSource.java > --- a/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 16:27:15 2016 +0300 > +++ b/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 14:05:10 2016 -0400 > @@ -64,7 +64,7 @@ > *

> * A driver that is accessed via a {@code DataSource} object does not > * register itself with the {@code DriverManager}. Rather, a > - * {@code DataSource} object is retrieved though a lookup operation > + * {@code DataSource} object is retrieved through a lookup operation > * and then used to create a {@code Connection} object. With a basic > * implementation, the connection obtained through a {@code DataSource} > * object is identical to a connection obtained through the > ljanders-mac:jdk ljanders$ > > --------------------------------- > > 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 ivan.gerasimov at oracle.com Thu Aug 18 18:23:52 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 18 Aug 2016 21:23:52 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <57B5A94E.7040808@oracle.com> References: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> <57B5A94E.7040808@oracle.com> Message-ID: <97077097-53cd-66c2-f727-790dbc41bf71@oracle.com> Hi Claes! Thank you for looking into this. On 18.08.2016 15:25, Claes Redestad wrote: > On 2016-08-16 19:20, Ivan Gerasimov wrote: >>> ObjectStreamClass: >>> >>> I wonder if the entire getPackageName is replaceable with >>> Class.getPackageName()? If so, ditch the method completely and use >>> Class.getPackageName everywhere. This may complicate backporting to JDK >>> 8 though. >> >> Unfortunately, Class.getPackageName() cannot handle arrays, so I'll >> leave it as is. > > There are a number of utility methods around that could be reused, > e.g., jdk.internal.reflect.Reflection.isSameClassPackage handles both > arrays and > primitive types and could replace both packageEquals and > getPackageName in > ObjectStreamClass (which already use j.i.r.Reflection for other > things). Making > isSameClassPackage in Reflection public should be non-controversial, I > hope. > Yes, thanks for the pointer! That's right, there are several similar methods in different packages. I see that the third option is sun.invoke.util.VerifyAccess.isSamePackage / getPackageName, but it also has its nuances. I guess that keeping ObjectStreamClass.getPackageName() separated would be the simplest approach: it minimizes the chances of regression and doesn't make it harder to do future modifications to Reflection.isSameClassPackage, if it is ever needed. If there are no objections, I'd like to push the latest variant of the fix, which is at http://cr.openjdk.java.net/~igerasim/8163517/01/webrev/ With kind regards, Ivan From ivan.gerasimov at oracle.com Thu Aug 18 18:26:36 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 18 Aug 2016 21:26:36 +0300 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> Message-ID: Thank you Stephen for review! On 18.08.2016 21:16, Stephen Colebourne wrote: > Looks good > Stephen > > On 18 August 2016 at 17:53, Ivan Gerasimov wrote: >> Hello everybody! >> >> The factory methods of ZoneOffset class demonstrate a minor inconsistency. >> Normally, invalid values of arguments are rejected (e.g. when minutes > 59), >> but the value of Integer.MIN_VALUE is allowed to be passed in. >> >> This is due to using Math.abs(), which cannot handle Integer.MIN_VALUE well. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8164366 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8164366/00/webrev/ >> >> With kind regards, >> Ivan >> From claes.redestad at oracle.com Thu Aug 18 18:27:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Aug 2016 20:27:28 +0200 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <97077097-53cd-66c2-f727-790dbc41bf71@oracle.com> References: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> <57B5A94E.7040808@oracle.com> <97077097-53cd-66c2-f727-790dbc41bf71@oracle.com> Message-ID: <57B5FE10.60007@oracle.com> On 2016-08-18 20:23, Ivan Gerasimov wrote: > Hi Claes! > > Thank you for looking into this. > > > On 18.08.2016 15:25, Claes Redestad wrote: >> On 2016-08-16 19:20, Ivan Gerasimov wrote: >>>> ObjectStreamClass: >>>> >>>> I wonder if the entire getPackageName is replaceable with >>>> Class.getPackageName()? If so, ditch the method completely and use >>>> Class.getPackageName everywhere. This may complicate backporting to >>>> JDK >>>> 8 though. >>> >>> Unfortunately, Class.getPackageName() cannot handle arrays, so I'll >>> leave it as is. >> >> There are a number of utility methods around that could be reused, >> e.g., jdk.internal.reflect.Reflection.isSameClassPackage handles both >> arrays and >> primitive types and could replace both packageEquals and >> getPackageName in >> ObjectStreamClass (which already use j.i.r.Reflection for other >> things). Making >> isSameClassPackage in Reflection public should be non-controversial, >> I hope. >> > > Yes, thanks for the pointer! > That's right, there are several similar methods in different packages. > I see that the third option is > sun.invoke.util.VerifyAccess.isSamePackage / getPackageName, but it > also has its nuances. > > I guess that keeping ObjectStreamClass.getPackageName() separated > would be the simplest approach: it minimizes the chances of regression > and doesn't make it harder to do future modifications to > Reflection.isSameClassPackage, if it is ever needed. > > If there are no objections, I'd like to push the latest variant of the > fix, which is at > http://cr.openjdk.java.net/~igerasim/8163517/01/webrev/ Go ahead, I'm just musing about the opportunity to consolidate further, which is better kept as a follow-up anyhow. Rather than breaking into Reflection we should likely add an internally public API with a more well-defined contract, ensuring that it addresses arrays, primitives etc, and then Reflection, VerifyAccess and ObjectStream could consolidate their use to such a method. Thanks! /Claes From ivan.gerasimov at oracle.com Thu Aug 18 18:53:05 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 18 Aug 2016 21:53:05 +0300 Subject: [jdk9] RFR: 8163517: Various cleanup in java.io code In-Reply-To: <57B5FE10.60007@oracle.com> References: <299310cd-eea4-e4a6-14e7-f42c6043984f@gmail.com> <0f034aae-e2ab-b758-d63a-e3b16f31eca3@oracle.com> <57B5A94E.7040808@oracle.com> <97077097-53cd-66c2-f727-790dbc41bf71@oracle.com> <57B5FE10.60007@oracle.com> Message-ID: <0e1281a4-a537-f0e9-7a04-820cb2be5862@oracle.com> On 18.08.2016 21:27, Claes Redestad wrote: > Rather than breaking into Reflection we should likely add an > internally public API with a more well-defined contract, ensuring that > it addresses arrays, primitives etc, and then Reflection, VerifyAccess > and ObjectStream could consolidate their use to such a method. Yes, totally agree with this. From paul.sandoz at oracle.com Thu Aug 18 19:33:06 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 18 Aug 2016 12:33:06 -0700 Subject: Exceptional behavior of parallel stream In-Reply-To: <2d8c7f16-6104-d3fd-b387-eeb66b4853f2@cs.oswego.edu> References: <1882659279.20160817200105@gmail.com> <2d8c7f16-6104-d3fd-b387-eeb66b4853f2@cs.oswego.edu> Message-ID: <8DEC666E-E189-4756-98DF-AD1D7FA4332D@oracle.com> > On 18 Aug 2016, at 03:54, Doug Lea

wrote: > > On 08/17/2016 09:01 AM, Tagir F. Valeev wrote: >> Hello! >> >> I found no information in Stream API documentation on how it behaves >> in case if exception occurs during the stream processing. While it's >> quite evident for sequential stream (stream processing is terminated >> and exception is propagated to the caller as is), the behavior for >> parallel streams differs from one might expect. Consider the following >> test: > > In your example, you can witness the delayed termination of other threads > upon exception in another because you add side-effecting operations > (here, just printing). Avoiding all this would force sequential processing. > > But if the supplied functions follow the documented properties, > it should not matter that parallel processing of some elements continues > when another hits an exception. Which is why nothing is said about it. > Similar effects occur in findAny and other methods. I don't see any benefit > in trying to specify exactly what happens in these cases. > Short circuiting terminal operations such as findAny and findFirst will not return until the computation has ?quiesced?, so once a result has been found the result will not be returned until all executing f/j tasks have completed. We consciously decided to do that so as the common pool would not contain straggling tasks beyond evaluation of the pipeline. When an behavioural operation throws an exception the stream can return before all related f/j tasks have finished. I thought i had a good grasp of the CountedCompleter exception propagation behaviour vs. normal completion propagation behaviour, but i am not so sure now, since i cannot bias things to make the non-quiescent behaviour very obvious. I think it?s because the main non-worker thread tries to help out executing tasks before waiting. Here is another reproducer: try { int s = 1024 * 16; IntStream.range(0, s).parallel() .peek(e -> { if (e < s / 2) throw new RuntimeException(); BigInteger.probablePrime(256, ThreadLocalRandom.current()); }) .forEach(e -> System.out.println(Thread.currentThread().getId() + " " + e)); } catch (RuntimeException e) { System.out.println("FAILED: " + ForkJoinPool.commonPool().isQuiescent()); } Paul. From paul.sandoz at oracle.com Thu Aug 18 22:17:36 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 18 Aug 2016 15:17:36 -0700 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <87e055be-f577-4dd0-d54e-5cd9dbd06d6b@reini.net> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> <20A5AEB1-F4A9-4C0E-9F28-521D691FAB03@reini.net> <51D7CAA9-0267-4873-A746-F0670E303918@oracle.com> <87e055be-f577-4dd0-d54e-5cd9dbd06d6b@reini.net> Message-ID: <2B50E5EC-E382-4EEC-9105-51506C8AF477@oracle.com> > On 17 Aug 2016, at 02:39, Patrick Reinhart wrote: > > Hi Paul, > > Thanks for the input. I integrated that into the version here: > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.03 > Onward to the implementation! Paul. From steve.drach at oracle.com Thu Aug 18 23:36:23 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 18 Aug 2016 16:36:23 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file Message-ID: Hi, Please review this rather simple fix to JarFileSystem. issue: https://bugs.openjdk.java.net/browse/JDK-8164389 webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html Thanks, Steve From paul.sandoz at oracle.com Fri Aug 19 00:01:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 18 Aug 2016 17:01:04 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file In-Reply-To: References: Message-ID: > On 18 Aug 2016, at 16:36, Steve Drach wrote: > > Hi, > > Please review this rather simple fix to JarFileSystem. > > issue: https://bugs.openjdk.java.net/browse/JDK-8164389 > webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html > JarFileSystem ? 162 private void walk(IndexNode inode, Consumer process) { 163 if (inode == null) return; 164 if (inode.isDir()) 165 walk(inode.child, process); 166 else 167 process.accept(inode); 168 walk(inode.sibling, process); 169 } I would recommend using braces, even for single statement blocks. JFSTester ? You might wanna create a temporary jar file if possible, just in case the test somehow fails to clean things up. 80 public void TestWalk() throws IOException { Lower case for first letter. Paul. From steve.drach at oracle.com Fri Aug 19 00:15:22 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 18 Aug 2016 17:15:22 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file In-Reply-To: References: Message-ID: <45C83B95-9F8B-4BE9-B077-C2104DAE6437@oracle.com> > You might wanna create a temporary jar file if possible, just in case the test somehow fails to clean things up. Unsure how to do that, or perhaps I don?t understand your request. From paul.sandoz at oracle.com Fri Aug 19 00:35:43 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 18 Aug 2016 17:35:43 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file In-Reply-To: <45C83B95-9F8B-4BE9-B077-C2104DAE6437@oracle.com> References: <45C83B95-9F8B-4BE9-B077-C2104DAE6437@oracle.com> Message-ID: <4B30F2A2-8F6E-4899-B6AC-6845EE4C5ECE@oracle.com> > On 18 Aug 2016, at 17:15, Steve Drach wrote: > >> You might wanna create a temporary jar file if possible, just in case the test somehow fails to clean things up. > > Unsure how to do that, or perhaps I don?t understand your request. I believe it?s possible to create a temporary directory, see Files.createTempDirectory, and use that to place the test.jar, although it might be more awkward to clean up. Actually maybe it?s ok with regards to test execution if you can confirm the ?user.dir? is set up correctly with jtreg, i cannot recall. Paul. From steve.drach at oracle.com Fri Aug 19 00:55:56 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 18 Aug 2016 17:55:56 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file In-Reply-To: <4B30F2A2-8F6E-4899-B6AC-6845EE4C5ECE@oracle.com> References: <45C83B95-9F8B-4BE9-B077-C2104DAE6437@oracle.com> <4B30F2A2-8F6E-4899-B6AC-6845EE4C5ECE@oracle.com> Message-ID: >>> You might wanna create a temporary jar file if possible, just in case the test somehow fails to clean things up. >> >> Unsure how to do that, or perhaps I don?t understand your request. > > I believe it?s possible to create a temporary directory, see Files.createTempDirectory, and use that to place the test.jar, although it might be more awkward to clean up. > > Actually maybe it?s ok with regards to test execution if you can confirm the ?user.dir? is set up correctly with jtreg, i cannot recall. It?s usually JTwork/scratch. A lot of tests use user.dir. From steve.drach at oracle.com Fri Aug 19 01:02:07 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 18 Aug 2016 18:02:07 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file In-Reply-To: References: Message-ID: <7FF65A66-71A7-4602-ACC4-5E2E64B6CF24@oracle.com> I?ve updated the webrev to incorporate most of Paul?s suggestions. http://cr.openjdk.java.net/~sdrach/8164389/webrev.01/index.html > On Aug 18, 2016, at 5:01 PM, Paul Sandoz wrote: > > >> On 18 Aug 2016, at 16:36, Steve Drach wrote: >> >> Hi, >> >> Please review this rather simple fix to JarFileSystem. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8164389 >> webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html >> > > JarFileSystem > ? > > 162 private void walk(IndexNode inode, Consumer process) { > 163 if (inode == null) return; > 164 if (inode.isDir()) > 165 walk(inode.child, process); > 166 else > 167 process.accept(inode); > 168 walk(inode.sibling, process); > 169 } > > I would recommend using braces, even for single statement blocks. > > > JFSTester > ? > > You might wanna create a temporary jar file if possible, just in case the test somehow fails to clean things up. > > > 80 public void TestWalk() throws IOException { > > Lower case for first letter. > > Paul. From david.holmes at oracle.com Fri Aug 19 05:15:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Aug 2016 15:15:16 +1000 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? Message-ID: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> No I didn't send this to the wrong mailing list :) I need to test the jbyte version of Atomic::cmpxchg in the VM, but so far it doesn't seem to be the case that any library code will actually invoke it. At the top Java level there is no AtomicByte class. Unsafe defines compareAndSwapByte variants but implements them using compareAndSwapInt and isolating the byte of interest. VarHandles seems to have direct *SwapByte operations but I can't figure out what they map to - there are VM intrinsics but again I can't the actual implementation to see if it uses Atomic::cmpxchg(jbyte*). So can someone (Aleksey?, Paul? :) ) tell me if this code does get used, and if not what I need to change to make it get used. And then what tests exist to exercise this? Thanks, David From nadeesh.tv at oracle.com Fri Aug 19 05:40:39 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 19 Aug 2016 11:10:39 +0530 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> Message-ID: <57B69BD7.6040100@oracle.com> Hi Stephen/Ivan, Is not the the statement "Zone offset minutes and seconds must be negative because hours is negative" and the following doc definition contradicts ? 358 * @param minutes the time-zone offset in minutes, from 0 to ±59 359 * @param seconds the time-zone offset in seconds, from 0 to ±59 -- Thanks and Regards, Nadeesh TV On 8/18/2016 11:46 PM, Stephen Colebourne wrote: > Looks good > Stephen > > On 18 August 2016 at 17:53, Ivan Gerasimov wrote: >> Hello everybody! >> >> The factory methods of ZoneOffset class demonstrate a minor inconsistency. >> Normally, invalid values of arguments are rejected (e.g. when minutes > 59), >> but the value of Integer.MIN_VALUE is allowed to be passed in. >> >> This is due to using Math.abs(), which cannot handle Integer.MIN_VALUE well. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8164366 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8164366/00/webrev/ >> >> With kind regards, >> Ivan >> From nadeesh.tv at oracle.com Fri Aug 19 05:46:56 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 19 Aug 2016 11:16:56 +0530 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: <57B69BD7.6040100@oracle.com> References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> <57B69BD7.6040100@oracle.com> Message-ID: <57B69D50.9030401@oracle.com> Hi , Sorry , my bad. I misread 'plusmn'. -- Thanks and Regards, Nadeesh TV On 8/19/2016 11:10 AM, nadeesh tv wrote: > Hi Stephen/Ivan, > > Is not the the statement > > "Zone offset minutes and seconds must be negative because hours is > negative" > > and the following doc definition contradicts ? > > 358 * @param minutes the time-zone offset in minutes, from 0 to > ±59 > 359 * @param seconds the time-zone offset in seconds, from 0 to > ±59 > > -- Thanks and Regards, Nadeesh TV From nadeesh.tv at oracle.com Fri Aug 19 06:01:46 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Fri, 19 Aug 2016 11:31:46 +0530 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> Message-ID: <57B6A0CA.1030505@oracle.com> Hi Ivan, ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same issue. It' not throwing the expected DTE. May be you can correct this also as part of this. Please update the copyright year also. Rest looks good. -- Thanks and Regards, Nadeesh TV On 8/18/2016 10:23 PM, Ivan Gerasimov wrote: > Hello everybody! > > The factory methods of ZoneOffset class demonstrate a minor > inconsistency. > Normally, invalid values of arguments are rejected (e.g. when minutes > > 59), but the value of Integer.MIN_VALUE is allowed to be passed in. > > This is due to using Math.abs(), which cannot handle Integer.MIN_VALUE > well. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8164366 > WEBREV: http://cr.openjdk.java.net/~igerasim/8164366/00/webrev/ > > With kind regards, > Ivan > -- Thanks and Regards, Nadeesh TV From aleksey.shipilev at gmail.com Fri Aug 19 06:31:58 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 19 Aug 2016 09:31:58 +0300 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> Message-ID: On 08/19/2016 08:15 AM, David Holmes wrote: > I need to test the jbyte version of Atomic::cmpxchg in the VM, but so > far it doesn't seem to be the case that any library code will actually > invoke it. At the top Java level there is no AtomicByte class. Unsafe > defines compareAndSwapByte variants but implements them using > compareAndSwapInt and isolating the byte of interest. VarHandles seems > to have direct *SwapByte operations but I can't figure out what they map > to - there are VM intrinsics but again I can't the actual implementation > to see if it uses Atomic::cmpxchg(jbyte*). VarHandles byte CAS/CAE map to Unsafe. Therefore they will use the Java-ish compareAndExchangeByte from Unsafe, without touching Atomic::cmpxchg(jbyte). In retrospect, we did that before Atomic::cmpxchg(jbyte) was available. Now it might be cleaner to ditch Java version from Unsafe, and make native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} which would call relevant Atomic::cmpxchg-s. Then, regular jdk/test/java/lang/invoke/varhandles and hotspot/tests/compiler/unsafe tests would exercise that path, as they run in interpreter too. Thanks, -Aleksey From aleksey.shipilev at gmail.com Fri Aug 19 06:34:35 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 19 Aug 2016 09:34:35 +0300 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> Message-ID: On 08/19/2016 09:31 AM, Aleksey Shipilev wrote: > Now it might be cleaner to ditch Java version from Unsafe, and make > native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} > which would call relevant Atomic::cmpxchg-s. ...or not. There is no Atomic::cmpxchg(jshort), argh. Thanks, -Aleksey From david.holmes at oracle.com Fri Aug 19 07:13:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Aug 2016 17:13:43 +1000 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> Message-ID: <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> Hi Aleksey, On 19/08/2016 4:31 PM, Aleksey Shipilev wrote: > On 08/19/2016 08:15 AM, David Holmes wrote: >> I need to test the jbyte version of Atomic::cmpxchg in the VM, but so >> far it doesn't seem to be the case that any library code will actually >> invoke it. At the top Java level there is no AtomicByte class. Unsafe >> defines compareAndSwapByte variants but implements them using >> compareAndSwapInt and isolating the byte of interest. VarHandles seems >> to have direct *SwapByte operations but I can't figure out what they map >> to - there are VM intrinsics but again I can't the actual implementation >> to see if it uses Atomic::cmpxchg(jbyte*). > > VarHandles byte CAS/CAE map to Unsafe. Therefore they will use the > Java-ish compareAndExchangeByte from Unsafe, without touching > Atomic::cmpxchg(jbyte). > > In retrospect, we did that before Atomic::cmpxchg(jbyte) was available. We did? I thought the VM jbyte version was old, while the Unsafe version was new ?? Anyway ... > Now it might be cleaner to ditch Java version from Unsafe, and make > native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} > which would call relevant Atomic::cmpxchg-s. I tried commenting out the Java-ish version and defining one that would call Atomic::cmpxchg from unsafe.cpp in the VM. However something is complaining about the intrinisics - I removed the HotspotIntrinsicCandidate annotation as I don't want any intrinisics, but I get a build error: Compiler intrinsic is defined for method [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], but the method is not annotated with @HotSpotIntrinsicCandidate. Exiting. No idea where this is coming from or how I can disable it ?? Thanks, David > Then, regular jdk/test/java/lang/invoke/varhandles and > hotspot/tests/compiler/unsafe tests would exercise that path, as they > run in interpreter too. > > Thanks, > -Aleksey > From aleksey.shipilev at gmail.com Fri Aug 19 07:40:35 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 19 Aug 2016 10:40:35 +0300 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> Message-ID: On 08/19/2016 10:13 AM, David Holmes wrote: >> Now it might be cleaner to ditch Java version from Unsafe, and make >> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >> which would call relevant Atomic::cmpxchg-s. > > I tried commenting out the Java-ish version and defining one that would > call Atomic::cmpxchg from unsafe.cpp in the VM. However something is > complaining about the intrinisics - I removed the > HotspotIntrinsicCandidate annotation as I don't want any intrinisics, > but I get a build error: > > Compiler intrinsic is defined for method > [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], > but the method is not annotated with @HotSpotIntrinsicCandidate. Exiting. > > No idea where this is coming from or how I can disable it ?? @HotSpotIntrinsicCandidate marks Java methods that are declared in vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without modifying vmSymbols.hpp would blow up like that. Anyway, I think you have to leave @HSIC methods untouched, because C2 would intrinsify them directly. To cater for the unsafe.cpp slow path, do a separate method: @HotSpotIntrinsicCandidate public final byte compareAndExchangeByteVolatile(Object o, long offset, byte expected, byte x) { compareAndExchangeByte0(o, long, expected, x); } public final native byte compareAndExchangeByte0(...); ...and then do an entry point for it in unsafe.cpp. Thanks, -Aleksey From john.r.rose at oracle.com Fri Aug 19 07:44:41 2016 From: john.r.rose at oracle.com (John Rose) Date: Fri, 19 Aug 2016 00:44:41 -0700 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> Message-ID: <6D343B02-D019-435B-B125-B1626BB69604@oracle.com> On Aug 19, 2016, at 12:13 AM, David Holmes wrote: > > No idea where this is coming from or how I can disable it ?? This is controlled by CheckIntrinsics in the JVM, a diagnostic option always on. It avoids accidentally expanding Java methods without the author's consent. ? John From michael.haupt at oracle.com Fri Aug 19 07:55:15 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 19 Aug 2016 09:55:15 +0200 Subject: RFR(S): 8164102: MethodHandles.countedLoop/4 works incorrect for start/end = Integer.MAX_VALUE Message-ID: <4901341F-2F21-4440-8255-A494C8B334BA@oracle.com> Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8164102 Webrev: http://cr.openjdk.java.net/~mhaupt/8164102/webrev.00/ The countedLoop implementation would yield loops with wrong iteration counts if start and end values around the fringes of the int value space were chosen. The fix - passing the decremented counter value to the predicate as well as the body - is temporary, as a larger overhaul of the JEP 274 API is under way as part of the fix to JDK-8151179. Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From claes.redestad at oracle.com Fri Aug 19 08:02:38 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Aug 2016 10:02:38 +0200 Subject: RFR(S): 8164102: MethodHandles.countedLoop/4 works incorrect for start/end = Integer.MAX_VALUE In-Reply-To: <4901341F-2F21-4440-8255-A494C8B334BA@oracle.com> References: <4901341F-2F21-4440-8255-A494C8B334BA@oracle.com> Message-ID: <57B6BD1E.9080108@oracle.com> Looks good for now, thanks! /Claes On 2016-08-19 09:55, Michael Haupt wrote: > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8164102 > Webrev: http://cr.openjdk.java.net/~mhaupt/8164102/webrev.00/ > > The countedLoop implementation would yield loops with wrong iteration counts if start and end values around the fringes of the int value space were chosen. The fix - passing the decremented counter value to the predicate as well as the body - is temporary, as a larger overhaul of the JEP 274 API is under way as part of the fix to JDK-8151179. > > Thanks, > > Michael > From david.holmes at oracle.com Fri Aug 19 09:26:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Aug 2016 19:26:58 +1000 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> Message-ID: On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: > On 08/19/2016 10:13 AM, David Holmes wrote: >>> Now it might be cleaner to ditch Java version from Unsafe, and make >>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >>> which would call relevant Atomic::cmpxchg-s. >> >> I tried commenting out the Java-ish version and defining one that would >> call Atomic::cmpxchg from unsafe.cpp in the VM. However something is >> complaining about the intrinisics - I removed the >> HotspotIntrinsicCandidate annotation as I don't want any intrinisics, >> but I get a build error: >> >> Compiler intrinsic is defined for method >> [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], >> but the method is not annotated with @HotSpotIntrinsicCandidate. Exiting. >> >> No idea where this is coming from or how I can disable it ?? > > @HotSpotIntrinsicCandidate marks Java methods that are declared in > vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without > modifying vmSymbols.hpp would blow up like that. > > Anyway, I think you have to leave @HSIC methods untouched, because C2 > would intrinsify them directly. To cater for the unsafe.cpp slow path, > do a separate method: > > @HotSpotIntrinsicCandidate > public final byte compareAndExchangeByteVolatile(Object o, long offset, > byte expected, > byte x) { > compareAndExchangeByte0(o, long, expected, x); > } > > public final native byte compareAndExchangeByte0(...); > > ...and then do an entry point for it in unsafe.cpp. Okay that was the easy part. Now where do I find out the conditional compilation syntax for the X-VarHandle.java.template file? Thanks, David > Thanks, > -Aleksey > From aleksey.shipilev at gmail.com Fri Aug 19 09:37:01 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 19 Aug 2016 12:37:01 +0300 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> Message-ID: <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> On 08/19/2016 12:26 PM, David Holmes wrote: > On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >> On 08/19/2016 10:13 AM, David Holmes wrote: >>>> Now it might be cleaner to ditch Java version from Unsafe, and make >>>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >>>> which would call relevant Atomic::cmpxchg-s. >>> >>> I tried commenting out the Java-ish version and defining one that would >>> call Atomic::cmpxchg from unsafe.cpp in the VM. However something is >>> complaining about the intrinisics - I removed the >>> HotspotIntrinsicCandidate annotation as I don't want any intrinisics, >>> but I get a build error: >>> >>> Compiler intrinsic is defined for method >>> [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], >>> but the method is not annotated with @HotSpotIntrinsicCandidate. >>> Exiting. >>> >>> No idea where this is coming from or how I can disable it ?? >> >> @HotSpotIntrinsicCandidate marks Java methods that are declared in >> vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without >> modifying vmSymbols.hpp would blow up like that. >> >> Anyway, I think you have to leave @HSIC methods untouched, because C2 >> would intrinsify them directly. To cater for the unsafe.cpp slow path, >> do a separate method: >> >> @HotSpotIntrinsicCandidate >> public final byte compareAndExchangeByteVolatile(Object o, long >> offset, >> byte expected, >> byte x) { >> compareAndExchangeByte0(o, long, expected, x); >> } >> >> public final native byte compareAndExchangeByte0(...); >> >> ...and then do an entry point for it in unsafe.cpp. > > Okay that was the easy part. > > Now where do I find out the conditional compilation syntax for the > X-VarHandle.java.template file? The template itself is driven by Spp preprocessor, the same one used thorough JDK. It is called during build via ./jdk/make/gensrc/GensrcVarHandles.gmk. But why do you need to change VH templates? VH implementations call Unsafe, see: @ForceInline static $type$ compareAndExchange(FieldInstanceReadWrite handle, Object holder, $type$ expected, $type$ value) { return UNSAFE.compareAndExchange$Type$Volatile(Objects.requireNonNull(handle.receiverType.cast(holder)), handle.fieldOffset, {#if[Object]?handle.fieldType.cast(expected):expected}, {#if[Object]?handle.fieldType.cast(value):value}); } ...so once you do the Unsafe part above, everything should be linked together. The jtreg tests exercise VH byte ops, so you can run them. Thanks, -Aleksey From claes.redestad at oracle.com Fri Aug 19 10:08:06 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Aug 2016 12:08:06 +0200 Subject: RFR: 8164451: Generate all zero and identity forms at link time Message-ID: <57B6DA86.7030402@oracle.com> Hi, after the internal improvements in JDK-8164451, adding pre-generation of zero and identity forms turns out to be very trivial. Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8164451 This removes runtime generation of 2 classes from the test in JDK-8086045, leaving only 2 generated forms to deal with to get down to no(!) bytecode generation during java.lang.invoke bootstrap. Thanks! /Claes From aleksey.shipilev at gmail.com Fri Aug 19 10:18:50 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 19 Aug 2016 13:18:50 +0300 Subject: RFR: 8164451: Generate all zero and identity forms at link time In-Reply-To: <57B6DA86.7030402@oracle.com> References: <57B6DA86.7030402@oracle.com> Message-ID: <8179b7f2-ca33-5b15-5bce-ad6e5a316a00@gmail.com> On 08/19/2016 01:08 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/ Looks good. > This removes runtime generation of 2 classes from the test in > JDK-8086045, leaving only 2 generated forms to deal with to get down > to no(!) bytecode generation during java.lang.invoke bootstrap. (everybody dance now) Thanks, -Aleksey From michael.haupt at oracle.com Fri Aug 19 11:49:54 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Fri, 19 Aug 2016 13:49:54 +0200 Subject: RFR: 8164451: Generate all zero and identity forms at link time In-Reply-To: <57B6DA86.7030402@oracle.com> References: <57B6DA86.7030402@oracle.com> Message-ID: Hi Claes, thumbs up. Best, Michael > Am 19.08.2016 um 12:08 schrieb Claes Redestad : > > Hi, > > after the internal improvements in JDK-8164451, adding pre-generation of zero > and identity forms turns out to be very trivial. > > Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8164451 > > This removes runtime generation of 2 classes from the test in JDK-8086045, leaving > only 2 generated forms to deal with to get down to no(!) bytecode generation > during java.lang.invoke bootstrap. > > Thanks! > > /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From vladimir.x.ivanov at oracle.com Fri Aug 19 11:57:43 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 19 Aug 2016 14:57:43 +0300 Subject: RFR: 8164451: Generate all zero and identity forms at link time In-Reply-To: <57B6DA86.7030402@oracle.com> References: <57B6DA86.7030402@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 8/19/16 1:08 PM, Claes Redestad wrote: > Hi, > > after the internal improvements in JDK-8164451, adding pre-generation of > zero > and identity forms turns out to be very trivial. > > Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8164451 > > This removes runtime generation of 2 classes from the test in > JDK-8086045, leaving > only 2 generated forms to deal with to get down to no(!) bytecode > generation > during java.lang.invoke bootstrap. > > Thanks! > > /Claes From david.holmes at oracle.com Fri Aug 19 12:03:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Aug 2016 22:03:57 +1000 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> Message-ID: <97e94602-fc88-2469-48bd-2b878497370a@oracle.com> On 19/08/2016 7:37 PM, Aleksey Shipilev wrote: > On 08/19/2016 12:26 PM, David Holmes wrote: >> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >>> On 08/19/2016 10:13 AM, David Holmes wrote: >>>>> Now it might be cleaner to ditch Java version from Unsafe, and make >>>>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >>>>> which would call relevant Atomic::cmpxchg-s. >>>> >>>> I tried commenting out the Java-ish version and defining one that would >>>> call Atomic::cmpxchg from unsafe.cpp in the VM. However something is >>>> complaining about the intrinisics - I removed the >>>> HotspotIntrinsicCandidate annotation as I don't want any intrinisics, >>>> but I get a build error: >>>> >>>> Compiler intrinsic is defined for method >>>> [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], >>>> but the method is not annotated with @HotSpotIntrinsicCandidate. >>>> Exiting. >>>> >>>> No idea where this is coming from or how I can disable it ?? >>> >>> @HotSpotIntrinsicCandidate marks Java methods that are declared in >>> vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without >>> modifying vmSymbols.hpp would blow up like that. >>> >>> Anyway, I think you have to leave @HSIC methods untouched, because C2 >>> would intrinsify them directly. To cater for the unsafe.cpp slow path, >>> do a separate method: >>> >>> @HotSpotIntrinsicCandidate >>> public final byte compareAndExchangeByteVolatile(Object o, long >>> offset, >>> byte expected, >>> byte x) { >>> compareAndExchangeByte0(o, long, expected, x); >>> } >>> >>> public final native byte compareAndExchangeByte0(...); >>> >>> ...and then do an entry point for it in unsafe.cpp. >> >> Okay that was the easy part. >> >> Now where do I find out the conditional compilation syntax for the >> X-VarHandle.java.template file? > > The template itself is driven by Spp preprocessor, the same one used > thorough JDK. It is called during build via > ./jdk/make/gensrc/GensrcVarHandles.gmk. Yes but I don't know the syntax. > > But why do you need to change VH templates? VH implementations call > Unsafe, see: > > @ForceInline > static $type$ compareAndExchange(FieldInstanceReadWrite handle, > Object holder, $type$ expected, $type$ value) { > return > UNSAFE.compareAndExchange$Type$Volatile(Objects.requireNonNull(handle.receiverType.cast(holder)), > handle.fieldOffset, > > {#if[Object]?handle.fieldType.cast(expected):expected}, > > {#if[Object]?handle.fieldType.cast(value):value}); > } > > ...so once you do the Unsafe part above, everything should be linked > together. The jtreg tests exercise VH byte ops, so you can run them. I was only making a change to the Byte version so the template needs to be specialized for Byte to call CompareAndExchangeByte0. Thanks, David > Thanks, > -Aleksey > > From ivan.gerasimov at oracle.com Fri Aug 19 12:52:36 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Aug 2016 15:52:36 +0300 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: <57B6A0CA.1030505@oracle.com> References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> <57B6A0CA.1030505@oracle.com> Message-ID: <37a2c22e-a23a-ffea-9e0f-d103d672ce07@oracle.com> Thanks Nadeesh. It's a good catch! Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8164366/01/webrev/ I also slightly modified comareTo(), not because there was an error in it, but just to avoid thinking too much about possible overflow in subtraction (of course, there can be no overflow here, as totalSeconds is bounded.) Now we just need official blessing from the Reviewer. With kind regards, Ivan On 19.08.2016 9:01, nadeesh tv wrote: > Hi Ivan, > > ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same issue. > It' not throwing the expected DTE. > > May be you can correct this also as part of this. > > Please update the copyright year also. > > Rest looks good. > From aleksey.shipilev at gmail.com Fri Aug 19 13:29:16 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 19 Aug 2016 16:29:16 +0300 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <97e94602-fc88-2469-48bd-2b878497370a@oracle.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> <97e94602-fc88-2469-48bd-2b878497370a@oracle.com> Message-ID: <1f4fa71e-ebc0-e419-eb43-5369b54ac790@gmail.com> On 08/19/2016 03:03 PM, David Holmes wrote: > On 19/08/2016 7:37 PM, Aleksey Shipilev wrote: >> On 08/19/2016 12:26 PM, David Holmes wrote: >>> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >>>> On 08/19/2016 10:13 AM, David Holmes wrote: >>>>>> Now it might be cleaner to ditch Java version from Unsafe, and make >>>>>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >>>>>> which would call relevant Atomic::cmpxchg-s. >>>>> >>>>> I tried commenting out the Java-ish version and defining one that >>>>> would >>>>> call Atomic::cmpxchg from unsafe.cpp in the VM. However something is >>>>> complaining about the intrinisics - I removed the >>>>> HotspotIntrinsicCandidate annotation as I don't want any intrinisics, >>>>> but I get a build error: >>>>> >>>>> Compiler intrinsic is defined for method >>>>> [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], >>>>> but the method is not annotated with @HotSpotIntrinsicCandidate. >>>>> Exiting. >>>>> >>>>> No idea where this is coming from or how I can disable it ?? >>>> >>>> @HotSpotIntrinsicCandidate marks Java methods that are declared in >>>> vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without >>>> modifying vmSymbols.hpp would blow up like that. >>>> >>>> Anyway, I think you have to leave @HSIC methods untouched, because C2 >>>> would intrinsify them directly. To cater for the unsafe.cpp slow path, >>>> do a separate method: >>>> >>>> @HotSpotIntrinsicCandidate >>>> public final byte compareAndExchangeByteVolatile(Object o, long >>>> offset, >>>> byte expected, >>>> byte x) { >>>> compareAndExchangeByte0(o, long, expected, x); >>>> } >>>> >>>> public final native byte compareAndExchangeByte0(...); >>>> >>>> ...and then do an entry point for it in unsafe.cpp. >>> >>> Okay that was the easy part. >>> >>> Now where do I find out the conditional compilation syntax for the >>> X-VarHandle.java.template file? >> >> The template itself is driven by Spp preprocessor, the same one used >> thorough JDK. It is called during build via >> ./jdk/make/gensrc/GensrcVarHandles.gmk. > > Yes but I don't know the syntax. If you find Spp.java in the forest, there is a comment section about the syntax: ./jdk/make/src/classes/build/tools/spp/Spp.java >> But why do you need to change VH templates? VH implementations call >> Unsafe, see: >> >> @ForceInline >> static $type$ compareAndExchange(FieldInstanceReadWrite handle, >> Object holder, $type$ expected, $type$ value) { >> return >> UNSAFE.compareAndExchange$Type$Volatile(Objects.requireNonNull(handle.receiverType.cast(holder)), >> >> handle.fieldOffset, >> >> {#if[Object]?handle.fieldType.cast(expected):expected}, >> >> {#if[Object]?handle.fieldType.cast(value):value}); >> } >> >> ...so once you do the Unsafe part above, everything should be linked >> together. The jtreg tests exercise VH byte ops, so you can run them. > > I was only making a change to the Byte version so the template needs to > be specialized for Byte to call CompareAndExchangeByte0. I get that. But I still think X-VarHandle.template change is unnecessary. The code for byte CAS generated from X-VarHandle.template calls Unsafe.compareAnd{Swap,Exchange}*. Why can't you leave VH template alone, and call CompareAndExchangeByte0 from Unsafe.compareAndExchangeByteVolatile, like I suggested before? @HotSpotIntrinsicCandidate public final byte compareAndExchangeByteVolatile(Object o, long offset, byte expected, byte x) { compareAndExchangeByte0(o, long, expected, x); } public final native byte compareAndExchangeByte0(...); VH tests have a least one testing mode which does not intrinsify Unsafe methods, i.e. -Xint. compareAndExchangeByte0 path would be visited there. -Aleksey From scolebourne at joda.org Fri Aug 19 14:32:48 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 19 Aug 2016 15:32:48 +0100 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: <37a2c22e-a23a-ffea-9e0f-d103d672ce07@oracle.com> References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> <57B6A0CA.1030505@oracle.com> <37a2c22e-a23a-ffea-9e0f-d103d672ce07@oracle.com> Message-ID: I'm less comfortable with the compareTo change because it may make it slower and that may have knock on effects. I think a comment saying that both are bounded would be enough in compareTo() Stephen On 19 August 2016 at 13:52, Ivan Gerasimov wrote: > Thanks Nadeesh. It's a good catch! > > Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/8164366/01/webrev/ > > I also slightly modified comareTo(), not because there was an error in it, > but just to avoid thinking too much about possible overflow in subtraction > (of course, there can be no overflow here, as totalSeconds is bounded.) > > Now we just need official blessing from the Reviewer. > > With kind regards, > Ivan > > > > On 19.08.2016 9:01, nadeesh tv wrote: >> >> Hi Ivan, >> >> ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same issue. It' >> not throwing the expected DTE. >> >> May be you can correct this also as part of this. >> >> Please update the copyright year also. >> >> Rest looks good. >> > From ivan.gerasimov at oracle.com Fri Aug 19 14:59:54 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 Aug 2016 17:59:54 +0300 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> <57B6A0CA.1030505@oracle.com> <37a2c22e-a23a-ffea-9e0f-d103d672ce07@oracle.com> Message-ID: <069f552d-13b6-393f-d08f-c3fb3e24a8de@oracle.com> On 19.08.2016 17:32, Stephen Colebourne wrote: > I'm less comfortable with the compareTo change because it may make it > slower and that may have knock on effects. I think a comment saying > that both are bounded would be enough in compareTo() Okay. I reverted that change back then and added a comment. The webrev is updated: http://cr.openjdk.java.net/~igerasim/8164366/02/webrev/ With kind regards, Ivan > Stephen > > On 19 August 2016 at 13:52, Ivan Gerasimov wrote: >> Thanks Nadeesh. It's a good catch! >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8164366/01/webrev/ >> >> I also slightly modified comareTo(), not because there was an error in it, >> but just to avoid thinking too much about possible overflow in subtraction >> (of course, there can be no overflow here, as totalSeconds is bounded.) >> >> Now we just need official blessing from the Reviewer. >> >> With kind regards, >> Ivan >> >> >> >> On 19.08.2016 9:01, nadeesh tv wrote: >>> Hi Ivan, >>> >>> ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same issue. It' >>> not throwing the expected DTE. >>> >>> May be you can correct this also as part of this. >>> >>> Please update the copyright year also. >>> >>> Rest looks good. >>> From paul.sandoz at oracle.com Fri Aug 19 15:00:33 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 19 Aug 2016 08:00:33 -0700 Subject: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file In-Reply-To: References: <45C83B95-9F8B-4BE9-B077-C2104DAE6437@oracle.com> <4B30F2A2-8F6E-4899-B6AC-6845EE4C5ECE@oracle.com> Message-ID: <1E6FB2A6-B37E-40F6-B3D7-E31BCD95C99B@oracle.com> > On 18 Aug 2016, at 17:55, Steve Drach wrote: > >>>> You might wanna create a temporary jar file if possible, just in case the test somehow fails to clean things up. >>> >>> Unsure how to do that, or perhaps I don?t understand your request. >> >> I believe it?s possible to create a temporary directory, see Files.createTempDirectory, and use that to place the test.jar, although it might be more awkward to clean up. >> >> Actually maybe it?s ok with regards to test execution if you can confirm the ?user.dir? is set up correctly with jtreg, i cannot recall. > > It?s usually JTwork/scratch. A lot of tests use user.dir. Ok! Paul. From nipa at codefx.org Fri Aug 19 15:05:38 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Fri, 19 Aug 2016 17:05:38 +0200 Subject: Can't get Platform Logging to work Message-ID: Hi! I'm trying out JEP 264: Platform Logging API and Service but can't get it to work (or misunderstood something). My understanding is that the JVM should use the provided LoggerFinder to log its own messages. So when I start with "-verbose:gc" I expected the message "Using G1" to go through my logger implementation - but it doesn't. I've set up a demo project[1], in which I'm creating a modules `logger`, which provides `LoggerFinder`, and `app`, which holds the started application. I launch with: java -verbose:gc -mp out/mods -m org.codefx.demo.java9.app The messages I send from the app module go through my logger, so the service module gets picked up. But the G1 message doesn't. :( I noticed that the docs[2] say this: > First it finds any custom LoggerFinder provider using the ServiceLoader facility with the system class loader. Do I have to do anything differently to make my service available to the system class loader? On a tangent, I also wondered what would be the preferred way to log from inside my code. Should I use System::getLogger directly? Logger logger = System.getLogger("Application"); logger.log(Level.INFO, "Hello, World!"); so long ... Nicolai [1] https://github.com/CodeFX-org/demo-java-9/tree/master/src/org/codefx/demo/java9/api/platform_logging [2] http://download.java.net/java/jdk9/docs/api/java/lang/System.LoggerFinder.html -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From daniel.fuchs at oracle.com Fri Aug 19 15:16:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 19 Aug 2016 16:16:30 +0100 Subject: Can't get Platform Logging to work In-Reply-To: References: Message-ID: <993e792d-34fb-0d7e-b893-cb649e0da1c9@oracle.com> Hi Nicolai, Log messages emitted by the JVM are not emitted through the System.Logger API. JEP 264 is a pure Java API which aims at replacing the sun.util.logging.PlatformLogger implementation. I believe what you are looking for is JEP 158 Unified JVM Logging [1] best regards, -- daniel [1] http://openjdk.java.net/jeps/158 On 19/08/16 16:05, Nicolai Parlog wrote: > Hi! > > I'm trying out JEP 264: Platform Logging API and Service but can't get > it to work (or misunderstood something). > > My understanding is that the JVM should use the provided LoggerFinder to > log its own messages. So when I start with "-verbose:gc" I expected the > message "Using G1" to go through my logger implementation - but it doesn't. > > I've set up a demo project[1], in which I'm creating a modules `logger`, > which provides `LoggerFinder`, and `app`, which holds the started > application. I launch with: > > java -verbose:gc -mp out/mods -m org.codefx.demo.java9.app > > The messages I send from the app module go through my logger, so the > service module gets picked up. But the G1 message doesn't. :( I noticed > that the docs[2] say this: > >> First it finds any custom LoggerFinder provider using the > ServiceLoader facility with the system class loader. > > Do I have to do anything differently to make my service available to the > system class loader? > > On a tangent, I also wondered what would be the preferred way to log > from inside my code. Should I use System::getLogger directly? > > Logger logger = System.getLogger("Application"); > logger.log(Level.INFO, "Hello, World!"); > > so long ... Nicolai > > > [1] > https://github.com/CodeFX-org/demo-java-9/tree/master/src/org/codefx/demo/java9/api/platform_logging > [2] > http://download.java.net/java/jdk9/docs/api/java/lang/System.LoggerFinder.html > > > From nipa at codefx.org Fri Aug 19 15:21:33 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Fri, 19 Aug 2016 17:21:33 +0200 Subject: Can't get Platform Logging to work In-Reply-To: <993e792d-34fb-0d7e-b893-cb649e0da1c9@oracle.com> References: <993e792d-34fb-0d7e-b893-cb649e0da1c9@oracle.com> Message-ID: Hi Daniel, thanks for the quick reply. And you are of course right. Luckily I don't care about the specific G1 message. After setting everything up, I was looking for _anything_ that logs a message and that was the first thing I came up with. Forgot the "platform classes" in the first sentence. :( Any idea what else I could use that logs messages via the new API? so long ... Nicolai On 19.08.2016 17:16, Daniel Fuchs wrote: > Hi Nicolai, > > Log messages emitted by the JVM are not emitted through the > System.Logger API. JEP 264 is a pure Java API which aims at > replacing the sun.util.logging.PlatformLogger implementation. > > I believe what you are looking for is JEP 158 Unified JVM Logging > [1] > > best regards, > > -- daniel > > [1] http://openjdk.java.net/jeps/158 > > > On 19/08/16 16:05, Nicolai Parlog wrote: >> Hi! >> >> I'm trying out JEP 264: Platform Logging API and Service but >> can't get it to work (or misunderstood something). >> >> My understanding is that the JVM should use the provided >> LoggerFinder to log its own messages. So when I start with >> "-verbose:gc" I expected the message "Using G1" to go through my >> logger implementation - but it doesn't. >> >> I've set up a demo project[1], in which I'm creating a modules >> `logger`, which provides `LoggerFinder`, and `app`, which holds >> the started application. I launch with: >> >> java -verbose:gc -mp out/mods -m org.codefx.demo.java9.app >> >> The messages I send from the app module go through my logger, so >> the service module gets picked up. But the G1 message doesn't. :( >> I noticed that the docs[2] say this: >> >>> First it finds any custom LoggerFinder provider using the >> ServiceLoader facility with the system class loader. >> >> Do I have to do anything differently to make my service available >> to the system class loader? >> >> On a tangent, I also wondered what would be the preferred way to >> log from inside my code. Should I use System::getLogger >> directly? >> >> Logger logger = System.getLogger("Application"); >> logger.log(Level.INFO, "Hello, World!"); >> >> so long ... Nicolai >> >> >> [1] >> https://github.com/CodeFX-org/demo-java-9/tree/master/src/org/codefx/ demo/java9/api/platform_logging >> >> >> [2] >> http://download.java.net/java/jdk9/docs/api/java/lang/System.LoggerFi nder.html >> >> >> >> > >> -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From daniel.fuchs at oracle.com Fri Aug 19 15:25:40 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 19 Aug 2016 16:25:40 +0100 Subject: Can't get Platform Logging to work In-Reply-To: References: Message-ID: <63aef387-9f0c-6d81-23b5-139266c6c9ef@oracle.com> Hi Nicolai, On 19/08/16 16:05, Nicolai Parlog wrote: > On a tangent, I also wondered what would be the preferred way to log > from inside my code. Should I use System::getLogger directly? > > Logger logger = System.getLogger("Application"); > logger.log(Level.INFO, "Hello, World!"); > > so long ... Nicolai > If you use System.Logger then your log messages will end up in whatever logging backend has been plugged in through the system's LoggerFinder provider, without having to declare any dependencies on that specific backend. However - if you're writing an application and have selected a specific logging API for it (say - SLF4J or Log4J) then you should preferably use the logging facade provided by those APIs. best regards, -- daniel From daniel.fuchs at oracle.com Fri Aug 19 15:34:55 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 19 Aug 2016 16:34:55 +0100 Subject: Can't get Platform Logging to work In-Reply-To: References: <993e792d-34fb-0d7e-b893-cb649e0da1c9@oracle.com> Message-ID: <05e99455-8183-fb4a-960a-eeb200279f67@oracle.com> Hi Nicolai, On 19/08/16 16:21, Nicolai Parlog wrote: > Hi Daniel, > > thanks for the quick reply. And you are of course right. > > Luckily I don't care about the specific G1 message. After setting > everything up, I was looking for _anything_ that logs a message and that > was the first thing I came up with. Forgot the "platform classes" in the > first sentence. :( > > Any idea what else I could use that logs messages via the new API? At the moment, anything that logs through sun.util.logging.PlatformLogger will end up logging through your LoggerFinder. At the moment, only a small set of jdk libraries/modules are using System.Logger (mainly java.base and java.destkop I believe), and at this time mostly through the legacy sun.util.logging.PlatformLogger API. I hope that going forward more and more jdk libraries will start using / migrate towards the new API, but we're not there yet. best regards, -- daniel From nipa at codefx.org Fri Aug 19 15:37:16 2016 From: nipa at codefx.org (Nicolai Parlog) Date: Fri, 19 Aug 2016 17:37:16 +0200 Subject: Private interface methods Message-ID: Hi! I was very surprised how the syntax for private interface method turned out. (I want to apologize in advance if this has been discussed before. I searched but didn't find anything. And I know it's a bike shed - still...) I was going into a long explanation of what I thought were the reasons behind defining the syntax at it currently stands and that they were all very understandable. Then I would explain why I think the current design is still awkward. I soon realized that most people on the list will have had those thought long before me. So I cut them out and come straight to the point: The way the two axes[1] public / private and abstract / has-impl turned out is pretty erratic: interface FooBar { // public foo(); // public has-impl bar() { ... } // private has-impl foobar() { ... } foo(); default foo() { ... } private foobar() { ... } } If private abstract methods were ever added (Does this even make sense? Would be nice to have a private channel between interface and implementation.) the confusion would be complete. Now, if `default` were optional as well... :) so long ... Nicolai [1] https://thumbs.dreamstime.com/x/two-axes-15577060.jpg -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From claes.redestad at oracle.com Fri Aug 19 15:52:55 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Aug 2016 17:52:55 +0200 Subject: RFR: 8164485: Zero forms not properly generated Message-ID: <57B72B57.7040403@oracle.com> Hi, the generation of zero forms in JDK-8164451 was incorrect, since we currently don't deal with constant placeholders in forms generated by the jlink plugin. While the zero constants might be something we can special-case, for now I have to back out the pre-generation of the zero forms. webrev: http://cr.openjdk.java.net/~redestad/8164485/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8164485 This was caught by existing but rather obscure tests. Thanks! /Claes From paul.sandoz at oracle.com Fri Aug 19 16:52:34 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 19 Aug 2016 09:52:34 -0700 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <1f4fa71e-ebc0-e419-eb43-5369b54ac790@gmail.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> <97e94602-fc88-2469-48bd-2b878497370a@oracle.com> <1f4fa71e-ebc0-e419-eb43-5369b54ac790@gmail.com> Message-ID: <60D46BDF-549D-4634-A0FD-9C5321AEDA0A@oracle.com> I agree with Alexey it should be possible to do this under the covers of existing Unsafe methods. Paul. > On 19 Aug 2016, at 06:29, Aleksey Shipilev wrote: > > On 08/19/2016 03:03 PM, David Holmes wrote: >> On 19/08/2016 7:37 PM, Aleksey Shipilev wrote: >>> On 08/19/2016 12:26 PM, David Holmes wrote: >>>> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >>>>> On 08/19/2016 10:13 AM, David Holmes wrote: >>>>>>> Now it might be cleaner to ditch Java version from Unsafe, and make >>>>>>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >>>>>>> which would call relevant Atomic::cmpxchg-s. >>>>>> >>>>>> I tried commenting out the Java-ish version and defining one that >>>>>> would >>>>>> call Atomic::cmpxchg from unsafe.cpp in the VM. However something is >>>>>> complaining about the intrinisics - I removed the >>>>>> HotspotIntrinsicCandidate annotation as I don't want any intrinisics, >>>>>> but I get a build error: >>>>>> >>>>>> Compiler intrinsic is defined for method >>>>>> [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], >>>>>> but the method is not annotated with @HotSpotIntrinsicCandidate. >>>>>> Exiting. >>>>>> >>>>>> No idea where this is coming from or how I can disable it ?? >>>>> >>>>> @HotSpotIntrinsicCandidate marks Java methods that are declared in >>>>> vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without >>>>> modifying vmSymbols.hpp would blow up like that. >>>>> >>>>> Anyway, I think you have to leave @HSIC methods untouched, because C2 >>>>> would intrinsify them directly. To cater for the unsafe.cpp slow path, >>>>> do a separate method: >>>>> >>>>> @HotSpotIntrinsicCandidate >>>>> public final byte compareAndExchangeByteVolatile(Object o, long >>>>> offset, >>>>> byte expected, >>>>> byte x) { >>>>> compareAndExchangeByte0(o, long, expected, x); >>>>> } >>>>> >>>>> public final native byte compareAndExchangeByte0(...); >>>>> >>>>> ...and then do an entry point for it in unsafe.cpp. >>>> >>>> Okay that was the easy part. >>>> >>>> Now where do I find out the conditional compilation syntax for the >>>> X-VarHandle.java.template file? >>> >>> The template itself is driven by Spp preprocessor, the same one used >>> thorough JDK. It is called during build via >>> ./jdk/make/gensrc/GensrcVarHandles.gmk. >> >> Yes but I don't know the syntax. > > If you find Spp.java in the forest, there is a comment section about the > syntax: > ./jdk/make/src/classes/build/tools/spp/Spp.java > > >>> But why do you need to change VH templates? VH implementations call >>> Unsafe, see: >>> >>> @ForceInline >>> static $type$ compareAndExchange(FieldInstanceReadWrite handle, >>> Object holder, $type$ expected, $type$ value) { >>> return >>> UNSAFE.compareAndExchange$Type$Volatile(Objects.requireNonNull(handle.receiverType.cast(holder)), >>> >>> handle.fieldOffset, >>> >>> {#if[Object]?handle.fieldType.cast(expected):expected}, >>> >>> {#if[Object]?handle.fieldType.cast(value):value}); >>> } >>> >>> ...so once you do the Unsafe part above, everything should be linked >>> together. The jtreg tests exercise VH byte ops, so you can run them. >> >> I was only making a change to the Byte version so the template needs to >> be specialized for Byte to call CompareAndExchangeByte0. > > I get that. > > But I still think X-VarHandle.template change is unnecessary. The code > for byte CAS generated from X-VarHandle.template calls > Unsafe.compareAnd{Swap,Exchange}*. Why can't you leave VH template > alone, and call CompareAndExchangeByte0 from > Unsafe.compareAndExchangeByteVolatile, like I suggested before? > > @HotSpotIntrinsicCandidate > public final byte compareAndExchangeByteVolatile(Object o, > long offset, > byte expected, > byte x) { > compareAndExchangeByte0(o, long, expected, x); > } > > public final native byte compareAndExchangeByte0(...); > > VH tests have a least one testing mode which does not intrinsify Unsafe > methods, i.e. -Xint. compareAndExchangeByte0 path would be visited there. > > -Aleksey From paul.sandoz at oracle.com Fri Aug 19 16:56:41 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 19 Aug 2016 09:56:41 -0700 Subject: RFR: 8164485: Zero forms not properly generated In-Reply-To: <57B72B57.7040403@oracle.com> References: <57B72B57.7040403@oracle.com> Message-ID: <94969DE9-4D88-41F7-884F-60AB1E920881@oracle.com> > On 19 Aug 2016, at 08:52, Claes Redestad wrote: > > Hi, > > the generation of zero forms in JDK-8164451 was incorrect, since we currently don't deal with constant placeholders in forms generated by the jlink plugin. While the zero constants might be something we can special-case, for now I have to back out the pre-generation of the zero forms. > > webrev: http://cr.openjdk.java.net/~redestad/8164485/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8164485 > +1 Paul. > This was caught by existing but rather obscure tests. > > Thanks! > > /Claes From martinrb at google.com Fri Aug 19 19:18:06 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Aug 2016 12:18:06 -0700 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <60D46BDF-549D-4634-A0FD-9C5321AEDA0A@oracle.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> <97e94602-fc88-2469-48bd-2b878497370a@oracle.com> <1f4fa71e-ebc0-e419-eb43-5369b54ac790@gmail.com> <60D46BDF-549D-4634-A0FD-9C5321AEDA0A@oracle.com> Message-ID: FYI I don't think java.util.concurrent has any plans for sub-int-sized atomics. We would use it if we added an AtomicByteArray, but that probably won't happen (users can just use VarHandle directly!) From david.holmes at oracle.com Fri Aug 19 21:50:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 20 Aug 2016 07:50:13 +1000 Subject: Testing hotspot's Atomic::cmpxchg(jbyte*) ? In-Reply-To: <1f4fa71e-ebc0-e419-eb43-5369b54ac790@gmail.com> References: <5cc28126-7d3c-a998-ae09-a83b1c11c522@oracle.com> <9ffaf3ce-eb61-dc71-8477-8b14f6ed52e3@oracle.com> <53de8c1a-8d6c-b332-c80b-ddb5dda59791@gmail.com> <97e94602-fc88-2469-48bd-2b878497370a@oracle.com> <1f4fa71e-ebc0-e419-eb43-5369b54ac790@gmail.com> Message-ID: <39330829-5783-7945-5a84-5657d911deeb@oracle.com> On 19/08/2016 11:29 PM, Aleksey Shipilev wrote: > On 08/19/2016 03:03 PM, David Holmes wrote: >> On 19/08/2016 7:37 PM, Aleksey Shipilev wrote: >>> On 08/19/2016 12:26 PM, David Holmes wrote: >>>> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote: >>>>> On 08/19/2016 10:13 AM, David Holmes wrote: >>>>>>> Now it might be cleaner to ditch Java version from Unsafe, and make >>>>>>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} >>>>>>> which would call relevant Atomic::cmpxchg-s. >>>>>> >>>>>> I tried commenting out the Java-ish version and defining one that >>>>>> would >>>>>> call Atomic::cmpxchg from unsafe.cpp in the VM. However something is >>>>>> complaining about the intrinisics - I removed the >>>>>> HotspotIntrinsicCandidate annotation as I don't want any intrinisics, >>>>>> but I get a build error: >>>>>> >>>>>> Compiler intrinsic is defined for method >>>>>> [jdk.internal.misc.Unsafe.compareAndSwapByte(Ljava/lang/Object;JBB)Z], >>>>>> but the method is not annotated with @HotSpotIntrinsicCandidate. >>>>>> Exiting. >>>>>> >>>>>> No idea where this is coming from or how I can disable it ?? >>>>> >>>>> @HotSpotIntrinsicCandidate marks Java methods that are declared in >>>>> vmSymbols.hpp, and the VM code checks it. So, removing @HSIC without >>>>> modifying vmSymbols.hpp would blow up like that. >>>>> >>>>> Anyway, I think you have to leave @HSIC methods untouched, because C2 >>>>> would intrinsify them directly. To cater for the unsafe.cpp slow path, >>>>> do a separate method: >>>>> >>>>> @HotSpotIntrinsicCandidate >>>>> public final byte compareAndExchangeByteVolatile(Object o, long >>>>> offset, >>>>> byte expected, >>>>> byte x) { >>>>> compareAndExchangeByte0(o, long, expected, x); >>>>> } >>>>> >>>>> public final native byte compareAndExchangeByte0(...); >>>>> >>>>> ...and then do an entry point for it in unsafe.cpp. >>>> >>>> Okay that was the easy part. >>>> >>>> Now where do I find out the conditional compilation syntax for the >>>> X-VarHandle.java.template file? >>> >>> The template itself is driven by Spp preprocessor, the same one used >>> thorough JDK. It is called during build via >>> ./jdk/make/gensrc/GensrcVarHandles.gmk. >> >> Yes but I don't know the syntax. > > If you find Spp.java in the forest, there is a comment section about the > syntax: > ./jdk/make/src/classes/build/tools/spp/Spp.java > > >>> But why do you need to change VH templates? VH implementations call >>> Unsafe, see: >>> >>> @ForceInline >>> static $type$ compareAndExchange(FieldInstanceReadWrite handle, >>> Object holder, $type$ expected, $type$ value) { >>> return >>> UNSAFE.compareAndExchange$Type$Volatile(Objects.requireNonNull(handle.receiverType.cast(holder)), >>> >>> handle.fieldOffset, >>> >>> {#if[Object]?handle.fieldType.cast(expected):expected}, >>> >>> {#if[Object]?handle.fieldType.cast(value):value}); >>> } >>> >>> ...so once you do the Unsafe part above, everything should be linked >>> together. The jtreg tests exercise VH byte ops, so you can run them. >> >> I was only making a change to the Byte version so the template needs to >> be specialized for Byte to call CompareAndExchangeByte0. > > I get that. > > But I still think X-VarHandle.template change is unnecessary. The code > for byte CAS generated from X-VarHandle.template calls > Unsafe.compareAnd{Swap,Exchange}*. Why can't you leave VH template > alone, and call CompareAndExchangeByte0 from > Unsafe.compareAndExchangeByteVolatile, like I suggested before? Ah I misunderstood. But even if I change this Java version, the intrinsic will do what it currently does, so this would only work -Xint mode. Anyway I'll figure something out on Monday. Thanks, David > @HotSpotIntrinsicCandidate > public final byte compareAndExchangeByteVolatile(Object o, > long offset, > byte expected, > byte x) { > compareAndExchangeByte0(o, long, expected, x); > } > > public final native byte compareAndExchangeByte0(...); > > VH tests have a least one testing mode which does not intrinsify Unsafe > methods, i.e. -Xint. compareAndExchangeByte0 path would be visited there. > > -Aleksey > > From kim.barrett at oracle.com Fri Aug 19 23:09:27 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Aug 2016 19:09:27 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> Message-ID: > On Aug 13, 2016, at 4:07 PM, Mandy Chung wrote: > > >> On Aug 13, 2016, at 1:20 AM, Peter Levart wrote: >> >> Hi Mandy, >> >> On 08/13/2016 01:55 AM, Mandy Chung wrote: >>>> On Aug 8, 2016, at 6:25 PM, Kim Barrett >>>> wrote: >>>> >>>> full: >>>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >>>> >>>> >>>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >>> This looks very good. >>> >>> Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. >>> >>> waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? >>> >> >> I think the split is intentional. It's a clever way to avoid an otherwise inevitable race that could otherwise cause DBB allocating thread to fail with OOME prematurely. >> > > Ah I see. I initially read that pendingList doesn?t need to be set within the synchronized block with processPendingActive flag but such race could cause DBB to fail with OOME, as you clarified. > > Then I suggest waitForReferencePendingList (and its JVM function) be renamed to: > boolean awaitReferencePendingList(); > > a blocking version of "boolean hasReferencePendingList()?. Minor difference but I think it?s little clearer. Regarding the name, e.g. "waitFor" vs "await", the meaning is the same. If there were a documented or defacto preference for "await" I would feel obliged to rename, but the JDK seems to use both forms in roughly comparable numbers. Regarding the signature and description, recall that waitForReferencePendingList() does not return a value, nor does it need to. So documenting it as a blocking version of hasReferencePendingList() isn't correct. > waitForReferenceProcessing - I?d like the javadoc to include more details or @implNote for example: > This method returns true to indicate that some pending references have been enqueued. If there are cleaners, cleaning actions are queued to be invoked e.g. DirectByteBuffer may be deallocated. > > This would help the readers to understand what this method is intended to do. I was intentionally a little vague in the description; I don't want to be promising too much, and having callers depend on behavior that we might want to change. In particular, it was intentional that there's no mention of Cleaner or any special behavior for them. For example, we might later decide we don't want the reference processing thread to incur the cost of notifying possible waiters and the associated synchronization, and instead let "waiters" return immediately when there is reference processing in progress, on the assumption that the reference processing thread makes rapid progress. In some respects that's probably more similar in effect to what the old code did. Also recall that this function is presently private, accessed by nio.Bits code via SharedSecrets (and via reflection by one test). It might be appropriate to change the access to this function or provide some similar non-private function in the future, at which point the javadoc and possibly the semantics and implementation will need to be carefully examined. From brent.christian at oracle.com Fri Aug 19 23:40:24 2016 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 19 Aug 2016 16:40:24 -0700 Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect In-Reply-To: References: <57B4C392.4060001@oracle.com> Message-ID: <57B798E8.4020509@oracle.com> Hi, Fred Thanks for having a look. Good questions... On 08/17/2016 02:28 PM, Frederic Parain wrote: > > hotspot/src/share/vm/prims/stackwalk.cpp: > 230 if (!expressions && > 231 values->at(i)->type() == T_INT && > 232 values->int_at(i) == 0 && // empty first slot of long? > 233 i+1 < values->size() && > 234 values->at(i+1)->type() == T_INT) { > > How does this test make the difference between: > 1 - a local variable of type long > 2 - two consecutive local variables of type int with the value > of the first one being zero > > (1) requires the fix, but (2) does not. That code just checks if we potentially have two consecutive T_INTs representing a long. The code that can tell the difference comes later: jlong nextVal = values->long_at(i) This grabs the full 64-bits (from slot i+1) for examination. The key difference in (2) is that the second slot can't have a value >32-bits. In (1), the second slot can contain a full 64-bit value. I would break it down further into: 1a: long with 1 or more of the most significant 32 bits set 1b: long with none of the most significant 32 bits set 1a is the only case that requires adjustment. StackWalker should return the same values for 1b and 2. > Another question: is it guaranteed that an unused slot from > a pair-slot is always zero? This is not written in the JVM spec, > and I don't remember that the JVM zeroes unused slots. Interesting. I've only seen zeros in my testing of locally-declared longs. (How does other VM code account for unused local slots?). Presuming an un-zeroed slot could contain anything, I can think of a couple problems that could occur (returning a mystery T_INT, clobbering a "real" int [1]). Having only seen 0s in unused slots, I still think my suggested code is about as good as we can do for this experimental StackWalker feature. > A last question: the fix tries to provide a view of the local > variables that matches the JVM spec rather than the implementation, > so if half of the long or double value is put in the first slot, > why the second slot is not stripped to only store the other half? Indeed. This truncation happens in the call to create_primitive_value_instance(): 161 case T_INT: 162 args.push_int(values->int_at(i)); StackValueCollection::int_at() truncates the value to a jint. So it's not strictly necessary for the 2nd slot to be stripped as part of this fix. Thanks, -Brent 1. If *any* T_INT could be an unused slot (not only those containing 0), and all we can look for are high-order bits set in the 2nd slot, I feel all bets are kind of off. A couple problems could occur: * For situation 1b (long w/o high bits set), the unused slot would remain untouched, and we would return a slot containing a mystery T_INT value. * In the case of a local int followed by a local long, if the long's first, unused slot happened to have high-order bits set, it would be interpreted as a 64-bit long value, and the preceding slot could have its (legitimate) value overwritten: slot 0: slot for real local int slot 1: unused slot containing garbage w/ upper bits set slot 2: 2nd slot of a long, containing the long value > On 08/17/2016 04:05 PM, Brent Christian wrote: >> Hi, >> >> Please review this StackWalker fix in hotspot for 8156073, "2-slot >> LiveStackFrame locals (long and double) are incorrect" >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073 >> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/ >> >> The experimental LiveStackFrame[1] interface for StackWalker provides >> access to stack frames' local variables, returned in an Object[] from >> LiveStackFrame.getLocals(). >> >> Long and double primitives are returned using two array slots (similar >> to JVMS section 2.6.1 [2]). This works as indicated on 32-bit JDKs, but >> needs some fixing on 64-bit. >> >> AFAICT under 64-bit, StackValueCollection stores the entire >> long/double in the 2nd (64-bit) slot: >> >> jlong StackValueCollection::long_at(int slot) const { >> #ifdef _LP64 >> return at(slot+1)->get_int(); >> #else >> ... >> >> The first slot goes unused and contains 0, instead of holding half of >> the long value as stackwalker expects. So stackwalker needs to take >> care splitting the value between the two slots. >> >> The fix examines StackValueCollection::long_at(i), checks for an >> unexpected 0 value from StackValueCollection::int_at(i), and copies >> the needed 32-bits (depending on native byte ordering) into the first >> slot as needed. (The 2nd slot gets truncated to 32-bits in >> create_primitive_value_instance()). >> >> Here's the fix in action on linux_x64 with the updated >> LocalsAndOperands.java test. Slots 4+5 contain a long, 6+7 contain a >> double. >> >> Before the fix: >> ... >> local 3: himom type java.lang.String >> local 4: 0 type I <-- >> local 5: 65535 type I >> local 6: 0 type I <-- >> local 7: 1293080650 type I >> local 8: 0 type I >> >> After the fix: >> ... >> local 3: himom type java.lang.String >> local 4: 1023 type I <-- >> local 5: 65535 type I >> local 6: 1074340347 type I <-- >> local 7: 1293080650 type I >> local 8: 0 type I >> >> This change also fixes 8158879, "Add new test for verifying 2-slot >> locals in LiveStackFrame". Thanks to Fabio Tudone >> (fabio at paralleluniverse.co) for the test case. I only test unused >> ("dead") local variables with -Xint, because they are removed in >> compiled frames. >> >> An automated build & test run on all platforms looks good. >> >> It would be good to also do more testing of LiveStackFrame.getStack(), >> but right now I want to focus on getting this getLocals() fix in. >> Testing of LiveStackFrame.getStack() will happen in a follow-up issue >> (8163825). >> >> Thanks, >> -Brent >> >> 1. >> http://hg.openjdk.java.net/jdk9/hs/jdk/file/1efce54b06b7/src/java.base/share/classes/java/lang/LiveStackFrame.java >> >> >> 2. >> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.6.1 >> From mandy.chung at oracle.com Fri Aug 19 23:54:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 19 Aug 2016 16:54:30 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> Message-ID: > On Aug 19, 2016, at 4:09 PM, Kim Barrett wrote: > >> On Aug 13, 2016, at 4:07 PM, Mandy Chung wrote: >> >> >>> On Aug 13, 2016, at 1:20 AM, Peter Levart wrote: >>> >>> Hi Mandy, >>> >>> On 08/13/2016 01:55 AM, Mandy Chung wrote: >>>>> On Aug 8, 2016, at 6:25 PM, Kim Barrett >>>>> wrote: >>>>> >>>>> full: >>>>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >>>> This looks very good. >>>> >>>> Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. >>>> >>>> waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? >>>> >>> >>> I think the split is intentional. It's a clever way to avoid an otherwise inevitable race that could otherwise cause DBB allocating thread to fail with OOME prematurely. >>> >> >> Ah I see. I initially read that pendingList doesn?t need to be set within the synchronized block with processPendingActive flag but such race could cause DBB to fail with OOME, as you clarified. >> >> Then I suggest waitForReferencePendingList (and its JVM function) be renamed to: >> boolean awaitReferencePendingList(); >> >> a blocking version of "boolean hasReferencePendingList()?. Minor difference but I think it?s little clearer. > > Regarding the name, e.g. "waitFor" vs "await", the meaning is the > same. If there were a documented or defacto preference for "await" I > would feel obliged to rename, but the JDK seems to use both forms in > roughly comparable numbers. > > Regarding the signature and description, recall that > waitForReferencePendingList() does not return a value, nor does it > need to. So documenting it as a blocking version of > hasReferencePendingList() isn't correct. It?s not a suggestion to write ?a blocking version of ?? in the javadoc (just my brief way to make my comment that clears my reading of the interfaces) If there were multiple reference handling threads, each would want to wait until there are pending references but only one thread could grab the pending list. Having it to return a boolean would be useful to me and up to the callers to decide whether it wants to check the return value (it doesn?t need to get the pending list if it returns false) If waitForReferencePendingList returns a boolean, awaitReferencePendingList reads consistent with ?hasReferencePendingList? (one word verb). > >> waitForReferenceProcessing - I?d like the javadoc to include more details or @implNote for example: >> This method returns true to indicate that some pending references have been enqueued. If there are cleaners, cleaning actions are queued to be invoked e.g. DirectByteBuffer may be deallocated. >> >> This would help the readers to understand what this method is intended to do. > > I was intentionally a little vague in the description; I don't want to > be promising too much, and having callers depend on behavior that we > might want to change. In particular, it was intentional that there's > no mention of Cleaner or any special behavior for them. > > For example, we might later decide we don't want the reference > processing thread to incur the cost of notifying possible waiters and > the associated synchronization, and instead let "waiters" return > immediately when there is reference processing in progress, on the > assumption that the reference processing thread makes rapid progress. > In some respects that's probably more similar in effect to what the > old code did. > > Also recall that this function is presently private, accessed by > nio.Bits code via SharedSecrets (and via reflection by one test). It > might be appropriate to change the access to this function or provide > some similar non-private function in the future, at which point the > javadoc and possibly the semantics and implementation will need to be > carefully examined. This is private API that is subject to change or remove any time. I won?t worry the javadoc here will give a false impression of its supportedness. I think this deserves reasonable level of detailed implementation notes. It will help the readers to understand what this does rather than reading the code (both this class and the callsites) carefully with multiple mutators in mind. Mandy From kim.barrett at oracle.com Sat Aug 20 00:30:17 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 19 Aug 2016 20:30:17 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> Message-ID: <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> > On Aug 19, 2016, at 7:54 PM, Mandy Chung wrote: > > >> On Aug 19, 2016, at 4:09 PM, Kim Barrett wrote: >> >>> On Aug 13, 2016, at 4:07 PM, Mandy Chung wrote: >>> >>> >>>> On Aug 13, 2016, at 1:20 AM, Peter Levart wrote: >>>> >>>> Hi Mandy, >>>> >>>> On 08/13/2016 01:55 AM, Mandy Chung wrote: >>>>>> On Aug 8, 2016, at 6:25 PM, Kim Barrett >>>>>> wrote: >>>>>> >>>>>> full: >>>>>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/ >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >>>>> This looks very good. >>>>> >>>>> Have you considered having JVM_WaitForReferencePendingList method to return the pending list? i.e. make it a blocking version of getAndClearReferencePendingList rather than two operations. >>>>> >>>>> waitForReferenceProcessing is really wait for pending reference(s) enqueued (additionally cleaner gets invoked). What do you think to rename this method to ?waitForPendingReferencesEnqueued?? >>>>> >>>> >>>> I think the split is intentional. It's a clever way to avoid an otherwise inevitable race that could otherwise cause DBB allocating thread to fail with OOME prematurely. >>>> >>> >>> Ah I see. I initially read that pendingList doesn?t need to be set within the synchronized block with processPendingActive flag but such race could cause DBB to fail with OOME, as you clarified. >>> >>> Then I suggest waitForReferencePendingList (and its JVM function) be renamed to: >>> boolean awaitReferencePendingList(); >>> >>> a blocking version of "boolean hasReferencePendingList()?. Minor difference but I think it?s little clearer. >> >> Regarding the name, e.g. "waitFor" vs "await", the meaning is the >> same. If there were a documented or defacto preference for "await" I >> would feel obliged to rename, but the JDK seems to use both forms in >> roughly comparable numbers. >> >> Regarding the signature and description, recall that >> waitForReferencePendingList() does not return a value, nor does it >> need to. So documenting it as a blocking version of >> hasReferencePendingList() isn't correct. > > It?s not a suggestion to write ?a blocking version of ?? in the javadoc (just my brief way to make my comment that clears my reading of the interfaces) > > If there were multiple reference handling threads, each would want to wait until there are pending references but only one thread could grab the pending list. Having it to return a boolean would be useful to me and up to the callers to decide whether it wants to check the return value (it doesn?t need to get the pending list if it returns false) But we don't have multiple reference processing [handling] threads, nor does the proposed design want such. waitForReferencePendingList() is an implementation detail that exists for the exclusive use of the single reference processing thread, to allow it to wait outside the synchronization block where it gets the pending list. The notion of a plurality of callers makes no sense for this function. Maybe I'm not understanding what you are suggesting? It seems like you are talking about some unknown to me design that is different from what I've proposed, and suggesting names and signatures based on that alternative design. > If waitForReferencePendingList returns a boolean, awaitReferencePendingList reads consistent with ?hasReferencePendingList? (one word verb). > >> >>> waitForReferenceProcessing - I?d like the javadoc to include more details or @implNote for example: >>> This method returns true to indicate that some pending references have been enqueued. If there are cleaners, cleaning actions are queued to be invoked e.g. DirectByteBuffer may be deallocated. >>> >>> This would help the readers to understand what this method is intended to do. >> >> I was intentionally a little vague in the description; I don't want to >> be promising too much, and having callers depend on behavior that we >> might want to change. In particular, it was intentional that there's >> no mention of Cleaner or any special behavior for them. >> >> For example, we might later decide we don't want the reference >> processing thread to incur the cost of notifying possible waiters and >> the associated synchronization, and instead let "waiters" return >> immediately when there is reference processing in progress, on the >> assumption that the reference processing thread makes rapid progress. >> In some respects that's probably more similar in effect to what the >> old code did. >> >> Also recall that this function is presently private, accessed by >> nio.Bits code via SharedSecrets (and via reflection by one test). It >> might be appropriate to change the access to this function or provide >> some similar non-private function in the future, at which point the >> javadoc and possibly the semantics and implementation will need to be >> carefully examined. > > This is private API that is subject to change or remove any time. I won?t worry the javadoc here will give a false impression of its supportedness. > > I think this deserves reasonable level of detailed implementation notes. It will help the readers to understand what this does rather than reading the code (both this class and the callsites) carefully with multiple mutators in mind. > > Mandy From Alan.Bateman at oracle.com Sat Aug 20 15:21:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Aug 2016 16:21:41 +0100 Subject: RFR(XXS): 8164520 - java/lang/ProcessHandle/Basic.java is missing @library tag In-Reply-To: <094601d1fae4$76106b10$62314130$@oracle.com> References: <094601d1fae4$76106b10$62314130$@oracle.com> Message-ID: <88c64ed0-6349-9c39-58cb-24f539eec09f@oracle.com> On 20/08/2016 14:12, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes a mistake made in JDK-8157957, > the @library tag was supposed to be changed to /test/lib but instead got > lost somewhere on the way. > > > > Verified the change locally. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8164520/webrev.00/ > Looks okay but curious why we aren't seeing this in jdk9/dev. -Alan. From christian.tornqvist at oracle.com Sat Aug 20 16:37:02 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Sat, 20 Aug 2016 12:37:02 -0400 Subject: RFR(XXS): 8164520 - java/lang/ProcessHandle/Basic.java is missing @library tag In-Reply-To: <88c64ed0-6349-9c39-58cb-24f539eec09f@oracle.com> References: <094601d1fae4$76106b10$62314130$@oracle.com> <88c64ed0-6349-9c39-58cb-24f539eec09f@oracle.com> Message-ID: <097d01d1fb01$14bbdc10$3e339430$@oracle.com> Hi Alan, The change that broke this was pushed to jdk9/hs yesterday, this will fix it before we integrate with jdk9/dev. Thanks, Christian -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Saturday, August 20, 2016 11:22 AM To: Christian Tornqvist ; core-libs-dev at openjdk.java.net Subject: Re: RFR(XXS): 8164520 - java/lang/ProcessHandle/Basic.java is missing @library tag On 20/08/2016 14:12, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes a mistake made in > JDK-8157957, the @library tag was supposed to be changed to /test/lib > but instead got lost somewhere on the way. > > > > Verified the change locally. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8164520/webrev.00/ > Looks okay but curious why we aren't seeing this in jdk9/dev. -Alan. From joe.darcy at oracle.com Sat Aug 20 18:55:12 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 20 Aug 2016 11:55:12 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec Message-ID: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Hello, Please review the doc-only patch below to address JDK-8164524: Correct inconsistencies in floating-point abs spec In brief, Martin noted in JDK-8164199 that a close reading of the specification of the Math and StrictMath floating-point abs methods reveals some inconsistencies in the text of the specification versus the operational semantics of the sample code in term of NaN handling. To resolve this, the sample code is slightly modified and demoted to informative rather than normative text. The core of the edit is changing Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) to Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) that is the "raw" floating-point => integral conversion rather than the "cooked" one which has tighter behavioral requirements around different NaN values, analogous changes for the double cases. (I don't think the request to mandate particular NaN behavior in JDK-8164199 is warranted; see the comments in that bug for a longer discussion.) Thanks, -Joe Since the float and double abs methods appears both in java.lang.Math and java.lang.StrictMath, the same edits are made multiple times. diff -r 9287101b5f49 src/java.base/share/classes/java/lang/Math.java --- a/src/java.base/share/classes/java/lang/Math.java Tue Aug 09 07:50:26 2016 -0700 +++ b/src/java.base/share/classes/java/lang/Math.java Sat Aug 20 11:47:22 2016 -0700 @@ -1370,8 +1370,12 @@ * result is positive zero. *
  • If the argument is infinite, the result is positive infinity. *
  • If the argument is NaN, the result is NaN. - * In other words, the result is the same as the value of the expression: - *

    {@code Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a))} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code float} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit:
    + * {@code Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a))} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. @@ -1389,8 +1393,12 @@ * is positive zero. *

  • If the argument is infinite, the result is positive infinity. *
  • If the argument is NaN, the result is NaN. - * In other words, the result is the same as the value of the expression: - *

    {@code Double.longBitsToDouble((Double.doubleToLongBits(a)<<1)>>>1)} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code double} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit:
    + * {@code Double.longBitsToDouble((Double.doubleToRawLongBits(a)<<1)>>>1)} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. diff -r 9287101b5f49 src/java.base/share/classes/java/lang/StrictMath.java --- a/src/java.base/share/classes/java/lang/StrictMath.java Tue Aug 09 07:50:26 2016 -0700 +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sat Aug 20 11:47:22 2016 -0700 @@ -1070,8 +1070,12 @@ * result is positive zero. *

  • If the argument is infinite, the result is positive infinity. *
  • If the argument is NaN, the result is NaN. - * In other words, the result is the same as the value of the expression: - *

    {@code Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a))} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code float} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit:
    + * {@code Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a))} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. @@ -1089,8 +1093,12 @@ * is positive zero. *

  • If the argument is infinite, the result is positive infinity. *
  • If the argument is NaN, the result is NaN. - * In other words, the result is the same as the value of the expression: - *

    {@code Double.longBitsToDouble((Double.doubleToLongBits(a)<<1)>>>1)} + * + * @apiNote As implied by the above, one valid implementation of + * this method is given by the expression below which computes a + * {@code double} with the same exponent and significand as the + * argument but with a guaranteed positive sign bit:
    + * {@code Double.longBitsToDouble((Double.doubleToRawLongBits(a)<<1)>>>1)} * * @param a the argument whose absolute value is to be determined * @return the absolute value of the argument. From martinrb at google.com Sat Aug 20 19:32:49 2016 From: martinrb at google.com (Martin Buchholz) Date: Sat, 20 Aug 2016 12:32:49 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: Thanks, Joe. This looks like progress. Feel free to ignore quibbles. Quibble: "guaranteed" may be true in practice, but longBitsToDouble is technically permitted to reset the sign bit back to 1 if the hardware is hostile. Because of this, I would simply remove the word "guaranteed". Should the non-intrinsified java bodies of abs be updated to match the updated spec? It would promote consistency between spec and interpreter and jit, so I would say yes, but this change is complete without any code updates. Quibble: I would use (the equivalent) ~(1 << 31) & for the float case and ~(1L << 63) & for the double case On Sat, Aug 20, 2016 at 11:55 AM, joe darcy wrote: > Hello, > > Please review the doc-only patch below to address > > JDK-8164524: Correct inconsistencies in floating-point abs spec > > In brief, Martin noted in JDK-8164199 that a close reading of the > specification of the Math and StrictMath floating-point abs methods reveals > some inconsistencies in the text of the specification versus the > operational semantics of the sample code in term of NaN handling. > > To resolve this, the sample code is slightly modified and demoted to > informative rather than normative text. > > The core of the edit is changing > > Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) > > to > > Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) > > that is the "raw" floating-point => integral conversion rather than the > "cooked" one which has tighter behavioral requirements around different NaN > values, analogous changes for the double cases. > > (I don't think the request to mandate particular NaN behavior in > JDK-8164199 is warranted; see the comments in that bug for a longer > discussion.) > > Thanks, > > -Joe > > Since the float and double abs methods appears both in java.lang.Math and > java.lang.StrictMath, the same edits are made multiple times. > > diff -r 9287101b5f49 src/java.base/share/classes/java/lang/Math.java > --- a/src/java.base/share/classes/java/lang/Math.java Tue Aug 09 > 07:50:26 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/Math.java Sat Aug 20 > 11:47:22 2016 -0700 > @@ -1370,8 +1370,12 @@ > * result is positive zero. > *

  • If the argument is infinite, the result is positive infinity. > *
  • If the argument is NaN, the result is NaN. > - * In other words, the result is the same as the value of the > expression: > - *

    {@code Float.intBitsToFloat(0x7fffffff & > Float.floatToIntBits(a))} > + * > + * @apiNote As implied by the above, one valid implementation of > + * this method is given by the expression below which computes a > + * {@code float} with the same exponent and significand as the > + * argument but with a guaranteed positive sign bit:
    > + * {@code Float.intBitsToFloat(0x7fffffff & > Float.floatToRawIntBits(a))} > * > * @param a the argument whose absolute value is to be determined > * @return the absolute value of the argument. > @@ -1389,8 +1393,12 @@ > * is positive zero. > *

  • If the argument is infinite, the result is positive infinity. > *
  • If the argument is NaN, the result is NaN. > - * In other words, the result is the same as the value of the > expression: > - *

    {@code Double.longBitsToDouble((Doubl > e.doubleToLongBits(a)<<1)>>>1)} > + * > + * @apiNote As implied by the above, one valid implementation of > + * this method is given by the expression below which computes a > + * {@code double} with the same exponent and significand as the > + * argument but with a guaranteed positive sign bit:
    > + * {@code Double.longBitsToDouble((Doubl > e.doubleToRawLongBits(a)<<1)>>>1)} > * > * @param a the argument whose absolute value is to be determined > * @return the absolute value of the argument. > diff -r 9287101b5f49 src/java.base/share/classes/java/lang/StrictMath.java > --- a/src/java.base/share/classes/java/lang/StrictMath.java Tue Aug 09 > 07:50:26 2016 -0700 > +++ b/src/java.base/share/classes/java/lang/StrictMath.java Sat Aug 20 > 11:47:22 2016 -0700 > @@ -1070,8 +1070,12 @@ > * result is positive zero. > *

  • If the argument is infinite, the result is positive infinity. > *
  • If the argument is NaN, the result is NaN. > - * In other words, the result is the same as the value of the > expression: > - *

    {@code Float.intBitsToFloat(0x7fffffff & > Float.floatToIntBits(a))} > + * > + * @apiNote As implied by the above, one valid implementation of > + * this method is given by the expression below which computes a > + * {@code float} with the same exponent and significand as the > + * argument but with a guaranteed positive sign bit:
    > + * {@code Float.intBitsToFloat(0x7fffffff & > Float.floatToRawIntBits(a))} > * > * @param a the argument whose absolute value is to be determined > * @return the absolute value of the argument. > @@ -1089,8 +1093,12 @@ > * is positive zero. > *

  • If the argument is infinite, the result is positive infinity. > *
  • If the argument is NaN, the result is NaN. > - * In other words, the result is the same as the value of the > expression: > - *

    {@code Double.longBitsToDouble((Doubl > e.doubleToLongBits(a)<<1)>>>1)} > + * > + * @apiNote As implied by the above, one valid implementation of > + * this method is given by the expression below which computes a > + * {@code double} with the same exponent and significand as the > + * argument but with a guaranteed positive sign bit:
    > + * {@code Double.longBitsToDouble((Doubl > e.doubleToRawLongBits(a)<<1)>>>1)} > * > * @param a the argument whose absolute value is to be determined > * @return the absolute value of the argument. > > From mandy.chung at oracle.com Sat Aug 20 20:17:50 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 20 Aug 2016 13:17:50 -0700 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> Message-ID: <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> It is a good observation. Pinning on a class loader is a good solution. On the other hand, the Level API isn?t well designed for customization (so does LogManager or Logger) that should be re-examined at some point in the future (which is one cause of the current complicated implementation). I think typical pattern would hold a strong reference to the custom level instances for the application/library use and so this compatibility risk may be relatively low. IMO, in the current state of logging API, it?s the subclass?s reponsibility to ensure the custom level instances are not garbage collected, like loggers (where LogManager::getLogger may return null if a logger is GC?ed). I think the right thing to do is to define a proper API for customization as a long-term solution. As for this issue, I don?t have a strong opinion in both approaches (using ClassLoaderValue vs Daniel?s current fix). Peter - in any case, as we have identified several usages for it, I suggest to file a separate bug to move ClassLoaderValue to a jdk.internal.xxx package. jdk.internal.loader may be a better home for it. Mandy > On Aug 17, 2016, at 4:20 AM, Peter Levart wrote: > > Hi Daniel, > > Thinking of this patch from the compatibility standpoint, aren't you afraid that someone might be using the following idiom: > > public class MyLevel extends java.util.logging.Level { > static { > new MyLevel("LEVEL1", 1); > new MyLevel("LEVEL2", 2); > ... > } > > public static void init() {} > > private MyLevel(String name, int value) { > super(name, value); > } > ... > } > > ...and then use those levels in code like: > > MyLevel.init(); > ... > Level level = Level.parse("LEVEL1") ... > > > With the proposed patch, this will not work any more as custom Level subclass instances will possibly be GCed before being "parsed" and retained. > > To prevent that from happening and still allow custom Level subclasses and their class loaders to be garbage-collectable, I recommend that you "pin" each constructed subclass instance to its ClassLoader with a strong reference. You could use a ClassLoaderValue for this purpose, like in the following addition to your patch (see KnownLevel.add): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/ > > Regards, Peter > > > On 08/16/2016 12:42 PM, Daniel Fuchs wrote: >> Hi Mandy, >> >> I added an additional selector parameter to the find methods. >> This made it possible to return Optional instead of >> KnownLevel - and it does simply the parse() method. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >> >> best regards, >> >> -- daniel >> >> On 11/08/16 20:12, Mandy Chung wrote: >>> >>>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs wrote: >>>> >>>> On 10/08/16 17:21, Mandy Chung wrote: >>>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>>> This looks pretty good. >>>>> >>>>> Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. >>>> >>>> We need to return KnownLevel because sometimes we need the >>>> level object and sometimes the mirror. >>> >>> So either findByName(String name, boolean mirror) or two methods: findLevelByName and findMirroredLevelByName?? >>> >>> Or seriously consider to remove KnownLevel class by introducing a new Level subclass with final Level.getName, Level.getLocalizedName, Level.getResourceBundleName methods?? >>> >>> Mandy >>> >> > From martinrb at google.com Sat Aug 20 22:16:14 2016 From: martinrb at google.com (Martin Buchholz) Date: Sat, 20 Aug 2016 15:16:14 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: On Sat, Aug 20, 2016 at 12:32 PM, Martin Buchholz wrote: > > Quibble: "guaranteed" may be true in practice, but longBitsToDouble is > technically permitted to reset the sign bit back to 1 if the hardware is > hostile. Because of this, I would simply remove the word "guaranteed". > After reading IEEE 754 2008 6.2.1. , I now believe signalling NaNs have to use the significand bits; the sign bit is free to use; and so I retract my quibble, and am happy with the word "guaranteed". From joe.darcy at oracle.com Sat Aug 20 23:10:00 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 20 Aug 2016 16:10:00 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: On 8/20/2016 3:16 PM, Martin Buchholz wrote: > > > On Sat, Aug 20, 2016 at 12:32 PM, Martin Buchholz > wrote: > > > Quibble: "guaranteed" may be true in practice, > but longBitsToDouble is technically permitted to reset the sign > bit back to 1 if the hardware is hostile. Because of this, I would > simply remove the word "guaranteed". > > > After reading IEEE 754 2008 6.2.1. , I now believe signalling NaNs > have to use the significand bits; the sign bit is free to use; and so > I retract my quibble, and am happy with the word "guaranteed". Right; the sign bit of a NaN has very little meaning. The hardware guys like to be able to do things like for a floating-point multiply "sign bit of output = XOR of sign bits of inputs" without having to do inconvenient NaN checks :-) The NaN payload for retrospective diagnostics is all in the significand. Cheers, -Joe From hboehm at google.com Sat Aug 20 23:40:43 2016 From: hboehm at google.com (Hans Boehm) Date: Sat, 20 Aug 2016 16:40:43 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: The new specification presumably does not guarantee that Float.floatToRawIntBits(Math.abs(x)) == Float.floatToRawIntBits(Math.abs(x)) when x is a NaN, instead leaving that to quality of implementation. Intended? I'm OK with either answer. Just asking to confirm. On Sat, Aug 20, 2016 at 4:10 PM, joe darcy wrote: > On 8/20/2016 3:16 PM, Martin Buchholz wrote: > >> >> >> On Sat, Aug 20, 2016 at 12:32 PM, Martin Buchholz > > wrote: >> >> >> Quibble: "guaranteed" may be true in practice, >> but longBitsToDouble is technically permitted to reset the sign >> bit back to 1 if the hardware is hostile. Because of this, I would >> simply remove the word "guaranteed". >> >> >> After reading IEEE 754 2008 6.2.1. , I now believe signalling NaNs have >> to use the significand bits; the sign bit is free to use; and so I retract >> my quibble, and am happy with the word "guaranteed". >> > > Right; the sign bit of a NaN has very little meaning. The hardware guys > like to be able to do things like for a floating-point multiply "sign bit > of output = XOR of sign bits of inputs" without having to do inconvenient > NaN checks :-) The NaN payload for retrospective diagnostics is all in the > significand. > > Cheers, > > -Joe > > From joe.darcy at oracle.com Sun Aug 21 01:24:44 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 20 Aug 2016 18:24:44 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: <8919199d-8863-2ae1-202c-ff65fd318681@oracle.com> Hello, On 8/20/2016 4:40 PM, Hans Boehm wrote: > The new specification presumably does not guarantee that > > Float.floatToRawIntBits(Math.abs(x)) == > Float.floatToRawIntBits(Math.abs(x)) > > when x is a NaN, instead leaving that to quality of implementation. > Intended? The normative specification says if the argument to abs is a NaN, the result is a NaN; no guarantees are made about the bits of the NaN. Therefore, the identity above is not guaranteed to be true for NaN value of x, but would likely usually return true in practice for a given platform implementation. (One way it could fail to be true is if one Math.abs was replaced by an intrinsic and the other one was not and the intrinsic and the non-intrinsic implementation had different NaN handling.) HTH, -Joe > > I'm OK with either answer. Just asking to confirm. > > On Sat, Aug 20, 2016 at 4:10 PM, joe darcy > wrote: > > On 8/20/2016 3:16 PM, Martin Buchholz wrote: > > > > On Sat, Aug 20, 2016 at 12:32 PM, Martin Buchholz > > >> wrote: > > > Quibble: "guaranteed" may be true in practice, > but longBitsToDouble is technically permitted to reset the > sign > bit back to 1 if the hardware is hostile. Because of this, > I would > simply remove the word "guaranteed". > > > After reading IEEE 754 2008 6.2.1 . , > I now believe signalling NaNs have to use the significand > bits; the sign bit is free to use; and so I retract my > quibble, and am happy with the word "guaranteed". > > > Right; the sign bit of a NaN has very little meaning. The hardware > guys like to be able to do things like for a floating-point > multiply "sign bit of output = XOR of sign bits of inputs" without > having to do inconvenient NaN checks :-) The NaN payload for > retrospective diagnostics is all in the significand. > > Cheers, > > -Joe > > From claes.redestad at oracle.com Sun Aug 21 09:59:43 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 21 Aug 2016 11:59:43 +0200 Subject: RFR: 8164525: Re-examine zero form link time pre-generation Message-ID: <57B97B8F.4000201@oracle.com> Hi, the previous attempt to pre-generate zero LambdaForms[1] failed due to the current implementation surprisingly emitting placeholder constants to link to the associated identity function (which we can't properly handle when pre-generating forms) rather than simply emitting the corresponding bytecode directly (iconst_0, etc). It turns out the setup of Zero and Identity functions aren't being made intrinsic, which appears to be an oversight. Fixing this allows for more optimal bytecode[1]. While this fix could have positive performance implications in general, it also makes the startup optimization from JDK-8164451 re-apply without issue (no test failures running RBT --test jdk/test/:tier1). Bug: https://bugs.openjdk.java.net/browse/JDK-8164525 Webrev: http://cr.openjdk.java.net/~redestad/8164525/webrev.01/ Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8164451 [2] Before: static java.lang.Object zero_000_L(java.lang.Object); descriptor: (Ljava/lang/Object;)Ljava/lang/Object; flags: ACC_STATIC Code: stack=2, locals=1, args_size=1 0: ldc #14 // String CONSTANT_PLACEHOLDER_1 <<(Object)Object : identity_000_L=Lambda(a0:L,a1:L)=>{a1:L}\n& Class=SimpleMethodHandle>> 2: checkcast #16 // class java/lang/invoke/MethodHandle 5: aconst_null 6: invokevirtual #19 // Method java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object; 9: areturn RuntimeVisibleAnnotations: 0: #8() 1: #9() 2: #10() After: static java.lang.Object zero_L(java.lang.Object); descriptor: (Ljava/lang/Object;)Ljava/lang/Object; flags: ACC_STATIC Code: stack=1, locals=1, args_size=1 0: aconst_null 1: areturn RuntimeVisibleAnnotations: 0: #8() 1: #9() 2: #10() From forax at univ-mlv.fr Sun Aug 21 11:35:26 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 21 Aug 2016 13:35:26 +0200 (CEST) Subject: RFR: 8164525: Re-examine zero form link time pre-generation In-Reply-To: <57B97B8F.4000201@oracle.com> References: <57B97B8F.4000201@oracle.com> Message-ID: <254965155.584163.1471779326342.JavaMail.zimbra@u-pem.fr> Hi Claes, it seems you have not generated the webrev from the right patch set, what the purpose of debugCompilation in LambdaForm ? cheers, R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev Libs" > Envoy?: Dimanche 21 Ao?t 2016 11:59:43 > Objet: RFR: 8164525: Re-examine zero form link time pre-generation > Hi, > > the previous attempt to pre-generate zero LambdaForms[1] failed > due to the current implementation surprisingly emitting placeholder > constants to link to the associated identity function (which we can't > properly handle when pre-generating forms) rather than simply emitting > the corresponding bytecode directly (iconst_0, etc). > > It turns out the setup of Zero and Identity functions aren't being made > intrinsic, which appears to be an oversight. Fixing this allows for more > optimal bytecode[1]. > > While this fix could have positive performance implications in general, > it also makes the startup optimization from JDK-8164451 re-apply > without issue (no test failures running RBT --test jdk/test/:tier1). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164525 > Webrev: http://cr.openjdk.java.net/~redestad/8164525/webrev.01/ > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8164451 > [2] Before: > > static java.lang.Object zero_000_L(java.lang.Object); > descriptor: (Ljava/lang/Object;)Ljava/lang/Object; > flags: ACC_STATIC > Code: > stack=2, locals=1, args_size=1 > 0: ldc #14 // String > CONSTANT_PLACEHOLDER_1 <<(Object)Object : > identity_000_L=Lambda(a0:L,a1:L)=>{a1:L}\n& Class=SimpleMethodHandle>> > 2: checkcast #16 // class > java/lang/invoke/MethodHandle > 5: aconst_null > 6: invokevirtual #19 // Method > java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object; > 9: areturn > RuntimeVisibleAnnotations: > 0: #8() > 1: #9() > 2: #10() > > After: > > static java.lang.Object zero_L(java.lang.Object); > descriptor: (Ljava/lang/Object;)Ljava/lang/Object; > flags: ACC_STATIC > Code: > stack=1, locals=1, args_size=1 > 0: aconst_null > 1: areturn > RuntimeVisibleAnnotations: > 0: #8() > 1: #9() > 2: #10() From claes.redestad at oracle.com Sun Aug 21 13:09:11 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 21 Aug 2016 15:09:11 +0200 Subject: RFR: 8164525: Re-examine zero form link time pre-generation In-Reply-To: <254965155.584163.1471779326342.JavaMail.zimbra@u-pem.fr> References: <57B97B8F.4000201@oracle.com> <254965155.584163.1471779326342.JavaMail.zimbra@u-pem.fr> Message-ID: <57B9A7F7.5080802@oracle.com> Hi R?mi, On 2016-08-21 13:35, Remi Forax wrote: > Hi Claes, > it seems you have not generated the webrev from the right patch set, > > what the purpose of debugCompilation in LambdaForm ? oops, a leftover from debugging the issue I'm sure. Removed and updated in place. The rest should be as intended. Thanks! /Claes > > cheers, > R?mi > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "core-libs-dev Libs" >> Envoy?: Dimanche 21 Ao?t 2016 11:59:43 >> Objet: RFR: 8164525: Re-examine zero form link time pre-generation > >> Hi, >> >> the previous attempt to pre-generate zero LambdaForms[1] failed >> due to the current implementation surprisingly emitting placeholder >> constants to link to the associated identity function (which we can't >> properly handle when pre-generating forms) rather than simply emitting >> the corresponding bytecode directly (iconst_0, etc). >> >> It turns out the setup of Zero and Identity functions aren't being made >> intrinsic, which appears to be an oversight. Fixing this allows for more >> optimal bytecode[1]. >> >> While this fix could have positive performance implications in general, >> it also makes the startup optimization from JDK-8164451 re-apply >> without issue (no test failures running RBT --test jdk/test/:tier1). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164525 >> Webrev: http://cr.openjdk.java.net/~redestad/8164525/webrev.01/ >> >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8164451 >> [2] Before: >> >> static java.lang.Object zero_000_L(java.lang.Object); >> descriptor: (Ljava/lang/Object;)Ljava/lang/Object; >> flags: ACC_STATIC >> Code: >> stack=2, locals=1, args_size=1 >> 0: ldc #14 // String >> CONSTANT_PLACEHOLDER_1 <<(Object)Object : >> identity_000_L=Lambda(a0:L,a1:L)=>{a1:L}\n& Class=SimpleMethodHandle>> >> 2: checkcast #16 // class >> java/lang/invoke/MethodHandle >> 5: aconst_null >> 6: invokevirtual #19 // Method >> java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object; >> 9: areturn >> RuntimeVisibleAnnotations: >> 0: #8() >> 1: #9() >> 2: #10() >> >> After: >> >> static java.lang.Object zero_L(java.lang.Object); >> descriptor: (Ljava/lang/Object;)Ljava/lang/Object; >> flags: ACC_STATIC >> Code: >> stack=1, locals=1, args_size=1 >> 0: aconst_null >> 1: areturn >> RuntimeVisibleAnnotations: >> 0: #8() >> 1: #9() >> 2: #10() From vladimir.x.ivanov at oracle.com Mon Aug 22 10:12:55 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Aug 2016 13:12:55 +0300 Subject: RFR: 8164525: Re-examine zero form link time pre-generation In-Reply-To: <57B97B8F.4000201@oracle.com> References: <57B97B8F.4000201@oracle.com> Message-ID: Reviewed. Best regards, Vladimir Ivanov On 8/21/16 12:59 PM, Claes Redestad wrote: > Hi, > > the previous attempt to pre-generate zero LambdaForms[1] failed > due to the current implementation surprisingly emitting placeholder > constants to link to the associated identity function (which we can't > properly handle when pre-generating forms) rather than simply emitting > the corresponding bytecode directly (iconst_0, etc). > > It turns out the setup of Zero and Identity functions aren't being made > intrinsic, which appears to be an oversight. Fixing this allows for more > optimal bytecode[1]. > > While this fix could have positive performance implications in general, > it also makes the startup optimization from JDK-8164451 re-apply > without issue (no test failures running RBT --test jdk/test/:tier1). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164525 > Webrev: http://cr.openjdk.java.net/~redestad/8164525/webrev.01/ > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8164451 > [2] Before: > > static java.lang.Object zero_000_L(java.lang.Object); > descriptor: (Ljava/lang/Object;)Ljava/lang/Object; > flags: ACC_STATIC > Code: > stack=2, locals=1, args_size=1 > 0: ldc #14 // String > CONSTANT_PLACEHOLDER_1 <<(Object)Object : > identity_000_L=Lambda(a0:L,a1:L)=>{a1:L}\n& Class=SimpleMethodHandle>> > 2: checkcast #16 // class > java/lang/invoke/MethodHandle > 5: aconst_null > 6: invokevirtual #19 // Method > java/lang/invoke/MethodHandle.invokeBasic:(Ljava/lang/Object;)Ljava/lang/Object; > > 9: areturn > RuntimeVisibleAnnotations: > 0: #8() > 1: #9() > 2: #10() > > After: > > static java.lang.Object zero_L(java.lang.Object); > descriptor: (Ljava/lang/Object;)Ljava/lang/Object; > flags: ACC_STATIC > Code: > stack=1, locals=1, args_size=1 > 0: aconst_null > 1: areturn > RuntimeVisibleAnnotations: > 0: #8() > 1: #9() > 2: #10() From peter.levart at gmail.com Mon Aug 22 10:15:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 22 Aug 2016 12:15:05 +0200 Subject: RFR: JDK-8164547: Make java.lang.reflect.ClassLoaderValue public for internal use Message-ID: Hi, Several potential internal usages of currently package-private java.lang.reflect.ClassLoaderValue have been identified. Here is a proposal to move it to jdk.internal.loader package and make it public... Task: https://bugs.openjdk.java.net/browse/JDK-8164547 Webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoaderValue.public/webrev.01/ Regards, Peter From aleksey.shipilev at gmail.com Mon Aug 22 10:22:29 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Mon, 22 Aug 2016 13:22:29 +0300 Subject: RFR: JDK-8164547: Make java.lang.reflect.ClassLoaderValue public for internal use In-Reply-To: References: Message-ID: <47454704-7748-b63e-6644-05d01387b2db@gmail.com> On 08/22/2016 01:15 PM, Peter Levart wrote: > Webrev: > http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoaderValue.public/webrev.01/ Looks good to me. AFAIU, making the classes public under the non-exported jdk.internal.loader package is fine. Thanks, -Aleksey From Alan.Bateman at oracle.com Mon Aug 22 10:27:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Aug 2016 11:27:10 +0100 Subject: RFR: JDK-8164547: Make java.lang.reflect.ClassLoaderValue public for internal use In-Reply-To: References: Message-ID: On 22/08/2016 11:15, Peter Levart wrote: > Hi, > > Several potential internal usages of currently package-private > java.lang.reflect.ClassLoaderValue have been identified. Here is a > proposal to move it to jdk.internal.loader package and make it public... > > Task: https://bugs.openjdk.java.net/browse/JDK-8164547 > Webrev: > http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoaderValue.public/webrev.01/ jdk.internal.loader looks right, the change looks good to me. -Alan From peter.levart at gmail.com Mon Aug 22 11:40:23 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 22 Aug 2016 13:40:23 +0200 Subject: RFR: JDK-8164547: Make java.lang.reflect.ClassLoaderValue public for internal use In-Reply-To: References: Message-ID: Hi Aleksey, Alan, Thanks for reviewing. Pushed. Regards, Peter On 08/22/2016 12:27 PM, Alan Bateman wrote: > > > On 22/08/2016 11:15, Peter Levart wrote: >> Hi, >> >> Several potential internal usages of currently package-private >> java.lang.reflect.ClassLoaderValue have been identified. Here is a >> proposal to move it to jdk.internal.loader package and make it public... >> >> Task: https://bugs.openjdk.java.net/browse/JDK-8164547 >> Webrev: >> http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoaderValue.public/webrev.01/ > jdk.internal.loader looks right, the change looks good to me. > > -Alan From sean.coffey at oracle.com Mon Aug 22 15:16:26 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 Aug 2016 16:16:26 +0100 Subject: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input In-Reply-To: <069f552d-13b6-393f-d08f-c3fb3e24a8de@oracle.com> References: <6b23e1bf-2aea-016b-f903-b2271b768618@oracle.com> <57B6A0CA.1030505@oracle.com> <37a2c22e-a23a-ffea-9e0f-d103d672ce07@oracle.com> <069f552d-13b6-393f-d08f-c3fb3e24a8de@oracle.com> Message-ID: <57BB174A.5040502@oracle.com> Looks fine Ivan. Reviewed. Regards, Sean. On 19/08/16 15:59, Ivan Gerasimov wrote: > On 19.08.2016 17:32, Stephen Colebourne wrote: >> I'm less comfortable with the compareTo change because it may make it >> slower and that may have knock on effects. I think a comment saying >> that both are bounded would be enough in compareTo() > > Okay. I reverted that change back then and added a comment. > The webrev is updated: > http://cr.openjdk.java.net/~igerasim/8164366/02/webrev/ > > With kind regards, > Ivan > >> Stephen >> >> On 19 August 2016 at 13:52, Ivan Gerasimov >> wrote: >>> Thanks Nadeesh. It's a good catch! >>> >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/8164366/01/webrev/ >>> >>> I also slightly modified comareTo(), not because there was an error >>> in it, >>> but just to avoid thinking too much about possible overflow in >>> subtraction >>> (of course, there can be no overflow here, as totalSeconds is bounded.) >>> >>> Now we just need official blessing from the Reviewer. >>> >>> With kind regards, >>> Ivan >>> >>> >>> >>> On 19.08.2016 9:01, nadeesh tv wrote: >>>> Hi Ivan, >>>> >>>> ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same >>>> issue. It' >>>> not throwing the expected DTE. >>>> >>>> May be you can correct this also as part of this. >>>> >>>> Please update the copyright year also. >>>> >>>> Rest looks good. >>>> > From brian.burkhalter at oracle.com Mon Aug 22 18:41:55 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Aug 2016 11:41:55 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: Hi Joe, This doc-only patch appears reasonable to me. Approved. Brian On Aug 20, 2016, at 11:55 AM, joe darcy wrote: > Please review the doc-only patch below to address > > JDK-8164524: Correct inconsistencies in floating-point abs spec > > In brief, Martin noted in JDK-8164199 that a close reading of the specification of the Math and StrictMath floating-point abs methods reveals some inconsistencies in the text of the specification versus the operational semantics of the sample code in term of NaN handling. > > To resolve this, the sample code is slightly modified and demoted to informative rather than normative text. > > The core of the edit is changing > > Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) > > to > > Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) > > that is the "raw" floating-point => integral conversion rather than the "cooked" one which has tighter behavioral requirements around different NaN values, analogous changes for the double cases. From joe.darcy at oracle.com Mon Aug 22 20:47:56 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 22 Aug 2016 13:47:56 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> Message-ID: <57BB64FC.2050204@oracle.com> Hello, I plan to push with a slightly different wording. Rather than ... but with a guaranteed positive sign bit: using ...but with a guaranteed zero sign bit of a positive value: I think the latter is clearer. Thanks, -Joe On 8/22/2016 11:41 AM, Brian Burkhalter wrote: > Hi Joe, > > This doc-only patch appears reasonable to me. Approved. > > Brian > > On Aug 20, 2016, at 11:55 AM, joe darcy > wrote: > >> Please review the doc-only patch below to address >> >> JDK-8164524: Correct inconsistencies in floating-point abs spec >> >> In brief, Martin noted in JDK-8164199 that a close reading of the >> specification of the Math and StrictMath floating-point abs methods >> reveals some inconsistencies in the text of the specification versus >> the operational semantics of the sample code in term of NaN handling. >> >> To resolve this, the sample code is slightly modified and demoted to >> informative rather than normative text. >> >> The core of the edit is changing >> >> Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) >> >> to >> >> Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) >> >> that is the "raw" floating-point => integral conversion rather than >> the "cooked" one which has tighter behavioral requirements around >> different NaN values, analogous changes for the double cases. > From hboehm at google.com Mon Aug 22 21:44:44 2016 From: hboehm at google.com (Hans Boehm) Date: Mon, 22 Aug 2016 14:44:44 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: <57BB64FC.2050204@oracle.com> References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> <57BB64FC.2050204@oracle.com> Message-ID: The new version seems less clear to me. Could it be misread as only applying if the value is positive? s/of/indicating a/ ? On Mon, Aug 22, 2016 at 1:47 PM, Joseph D. Darcy wrote: > Hello, > > I plan to push with a slightly different wording. Rather than > > ... but with a guaranteed positive sign bit: > > using > > ...but with a guaranteed zero sign bit of a positive value: > > I think the latter is clearer. > > Thanks, > > -Joe > > On 8/22/2016 11:41 AM, Brian Burkhalter wrote: > >> Hi Joe, >> >> This doc-only patch appears reasonable to me. Approved. >> >> Brian >> >> On Aug 20, 2016, at 11:55 AM, joe darcy > joe.darcy at oracle.com>> wrote: >> >> Please review the doc-only patch below to address >>> >>> JDK-8164524: Correct inconsistencies in floating-point abs spec >>> >>> In brief, Martin noted in JDK-8164199 that a close reading of the >>> specification of the Math and StrictMath floating-point abs methods reveals >>> some inconsistencies in the text of the specification versus the >>> operational semantics of the sample code in term of NaN handling. >>> >>> To resolve this, the sample code is slightly modified and demoted to >>> informative rather than normative text. >>> >>> The core of the edit is changing >>> >>> Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) >>> >>> to >>> >>> Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) >>> >>> that is the "raw" floating-point => integral conversion rather than the >>> "cooked" one which has tighter behavioral requirements around different NaN >>> values, analogous changes for the double cases. >>> >> >> > From brian.burkhalter at oracle.com Mon Aug 22 22:24:54 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Aug 2016 15:24:54 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> <57BB64FC.2050204@oracle.com> Message-ID: <44ACB07C-9105-40A6-B24D-5CFE096C2D41@oracle.com> I think that sounds good. Brian On Aug 22, 2016, at 2:44 PM, Hans Boehm wrote: > The new version seems less clear to me. Could it be misread as only applying if the value is positive? s/of/indicating a/ ? > > > On Mon, Aug 22, 2016 at 1:47 PM, Joseph D. Darcy wrote: > Hello, > > I plan to push with a slightly different wording. Rather than > > ... but with a guaranteed positive sign bit: > > using > > ...but with a guaranteed zero sign bit of a positive value: > > I think the latter is clearer. > > Thanks, > > -Joe > > On 8/22/2016 11:41 AM, Brian Burkhalter wrote: > Hi Joe, > > This doc-only patch appears reasonable to me. Approved. > > Brian > > On Aug 20, 2016, at 11:55 AM, joe darcy > wrote: > > Please review the doc-only patch below to address > > JDK-8164524: Correct inconsistencies in floating-point abs spec > > In brief, Martin noted in JDK-8164199 that a close reading of the specification of the Math and StrictMath floating-point abs methods reveals some inconsistencies in the text of the specification versus the operational semantics of the sample code in term of NaN handling. > > To resolve this, the sample code is slightly modified and demoted to informative rather than normative text. > > The core of the edit is changing > > Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) > > to > > Float.intBitsToFloat(0x7fffffff & Float.floatToRawIntBits(a)) > > that is the "raw" floating-point => integral conversion rather than the "cooked" one which has tighter behavioral requirements around different NaN values, analogous changes for the double cases. From steve.drach at oracle.com Mon Aug 22 23:18:42 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 22 Aug 2016 16:18:42 -0700 Subject: 8164585: JarFile::isMultiRelease does not return true in all cases where it should return true Message-ID: <9B08561C-5FEA-45F8-BDB2-A64222975B67@oracle.com> Hi, Please review this simple change to JarFile issue: https://bugs.openjdk.java.net/browse/JDK-8164585 webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/ Thanks, Steve From joe.darcy at oracle.com Tue Aug 23 00:22:41 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 22 Aug 2016 17:22:41 -0700 Subject: JDK 9 RFR of JDK-8164524: Correct inconsistencies in floating-point abs spec In-Reply-To: <44ACB07C-9105-40A6-B24D-5CFE096C2D41@oracle.com> References: <8f2bd54c-46f4-4075-ceda-8d6b68dfd236@oracle.com> <57BB64FC.2050204@oracle.com> <44ACB07C-9105-40A6-B24D-5CFE096C2D41@oracle.com> Message-ID: <57BB9751.8050305@oracle.com> Pushed with suggested wording change; thanks, -Joe On 8/22/2016 3:24 PM, Brian Burkhalter wrote: > I think that sounds good. > > Brian > > On Aug 22, 2016, at 2:44 PM, Hans Boehm > wrote: > >> The new version seems less clear to me. Could it be misread as only >> applying if the value is positive? s/of/indicating a/ ? >> >> >> On Mon, Aug 22, 2016 at 1:47 PM, Joseph D. Darcy> >wrote: >> >> Hello, >> >> I plan to push with a slightly different wording. Rather than >> >> ... but with a guaranteed positive sign bit: >> >> using >> >> ...but with a guaranteed zero sign bit of a positive value: >> >> I think the latter is clearer. >> >> Thanks, >> >> -Joe >> >> On 8/22/2016 11:41 AM, Brian Burkhalter wrote: >> >> Hi Joe, >> >> This doc-only patch appears reasonable to me. Approved. >> >> Brian >> >> On Aug 20, 2016, at 11:55 AM, joe darcy > > >> wrote: >> >> Please review the doc-only patch below to address >> >> JDK-8164524: Correct inconsistencies in floating-point >> abs spec >> >> In brief, Martin noted in JDK-8164199 that a close >> reading of the specification of the Math and StrictMath >> floating-point abs methods reveals some inconsistencies >> in the text of the specification versus the operational >> semantics of the sample code in term of NaN handling. >> >> To resolve this, the sample code is slightly modified and >> demoted to informative rather than normative text. >> >> The core of the edit is changing >> >> Float.intBitsToFloat(0x7fffffff & Float.floatToIntBits(a)) >> >> to >> >> Float.intBitsToFloat(0x7fffffff & >> Float.floatToRawIntBits(a)) >> >> that is the "raw" floating-point => integral conversion >> rather than the "cooked" one which has tighter behavioral >> requirements around different NaN values, analogous >> changes for the double cases. >> > From alexandre.iline at oracle.com Tue Aug 23 00:32:54 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 22 Aug 2016 17:32:54 -0700 Subject: RFR: 8148859 Fix module dependences for java/time tests Message-ID: <457222DB-AF4A-46C8-A310-872CE9AB4BD1@oracle.com> Hi. Please review a quick fix for the java/time test module dependencies. http://cr.openjdk.java.net/~shurailine/8148859/webrev.00/ It is using new syntax added in JTReg, which allows to only build certain classes from a test library for TestNG tests: https://bugs.openjdk.java.net/browse/CODETOOLS-7901667 Shura From mandy.chung at oracle.com Tue Aug 23 04:30:21 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Aug 2016 21:30:21 -0700 Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect In-Reply-To: <57B4C392.4060001@oracle.com> References: <57B4C392.4060001@oracle.com> Message-ID: <4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com> Hi Brent, > On Aug 17, 2016, at 1:05 PM, Brent Christian wrote: > > Hi, > > Please review this StackWalker fix in hotspot for 8156073, "2-slot LiveStackFrame locals (long and double) are incorrect" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156073 > Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/ This looks a good stop-gap fix that will allow further experiments of using LiveStackFrame. The new test has long lines that should be wrapped. > On 08/17/2016 02:28 PM, Frederic Parain wrote: >> Another question: is it guaranteed that an unused slot from >> a pair-slot is always zero? This is not written in the JVM spec, >> and I don't remember that the JVM zeroes unused slots. > > Interesting. I've only seen zeros in my testing of locally-declared longs. (How does other VM code account for unused local slots?). > We need to follow up this issue to understand what the interpreter and compiler do for this unused slot and whether it?s always zero out. We should file JBS issue to follow it up separately. Mandy From huaming.li at oracle.com Tue Aug 23 08:55:46 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 23 Aug 2016 16:55:46 +0800 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java Message-ID: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. "Additionally, the bulk operations addAll, removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically. For example, an iterator operating concurrently with an addAll operation might view only some of the added elements." It should be modified as some thing like below: "Additionally, the bulk operations removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically." bug: https://bugs.openjdk.java.net/browse/JDK-8164623 webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ Thank you -Hamlin From claes.redestad at oracle.com Tue Aug 23 08:57:30 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 23 Aug 2016 10:57:30 +0200 Subject: RFR: 8164483: Generate field lambda forms at link time Message-ID: <57BC0FFA.5030608@oracle.com> Hi, this patch adds link-time generation of the simplest field lambda forms. This avoid generating these forms during bootstrapping, which is commonly done early on in even the simplest startup tests. To make this work, injecting Unsafe as a constant replacement had to be replaced with a getter function, resulting in a few more bytecodes to do the same thing, but which after inlining should turn into equivalent code; performance testing indicate this change is performance neutral. Bug: https://bugs.openjdk.java.net/browse/JDK-8164483 Webrev: http://cr.openjdk.java.net/~redestad/8164483/webrev.01/ Together with JDK-8164569 (which I've tested together with this) this removes all class generation from runtime in the tests associated with JDK-8086045 Thanks! /Claes From claes.redestad at oracle.com Tue Aug 23 08:57:34 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 23 Aug 2016 10:57:34 +0200 Subject: RFR: 8164569: Generate non-customized invoker forms at link time Message-ID: <57BC0FFE.7020006@oracle.com> Hi, this patch adds configurable link-time generation of the invoker forms. Some such forms is commonly used early on in even the simplest startup tests, and an unbounded number of invoker forms can be generated in more complex cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8164569 Webrev: http://cr.openjdk.java.net/~redestad/8164569/webrev.01/ Together with JDK-8164483 (which I've tested together with this) this removes all class generation from runtime in the tests associated with JDK-8086045 I'd also note that the default setting in this patch is rather arbitrary: although it removes a handful of invokers in a number of tests, it's admittedly complicated to detect which ones are needed (same goes for already implemented options to select Direct-/DelegatingMethodHandles and BoundMethodHandle$Species_*). The plan is to implement JDK-8163371 in such a way that running a application with a tracing flag enabled will produce a file to use as the sole input to --generate-jli-classes. Thanks! /Claes From david.holmes at oracle.com Tue Aug 23 09:10:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Aug 2016 19:10:49 +1000 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: > > Below doc is not correct, because for ConcurrentLinkedDeque and > ConcurrentLinkedQueue, addAll is a atomic operation. No it is not! There is no bug here. Are you perhaps confusing thread-safe with atomic? David ----- > "Additionally, the bulk operations addAll, removeAll, retainAll, > containsAll, equals, and toArray are not guaranteed to be performed > atomically. For example, an iterator operating concurrently with an > addAll operation might view only some of the added elements." > It should be modified as some thing like below: > "Additionally, the bulk operations removeAll, retainAll, containsAll, > equals, and toArray are not guaranteed to be performed atomically." > > bug: https://bugs.openjdk.java.net/browse/JDK-8164623 > webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ > > Thank you > -Hamlin > From huaming.li at oracle.com Tue Aug 23 12:53:03 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 23 Aug 2016 20:53:03 +0800 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: On 2016/8/23 17:10, David Holmes wrote: > Hi Hamlin, > > On 23/08/2016 6:55 PM, Hamlin Li wrote: >> >> Below doc is not correct, because for ConcurrentLinkedDeque and >> ConcurrentLinkedQueue, addAll is a atomic operation. > > No it is not! There is no bug here. Are you perhaps confusing > thread-safe with atomic? Hi David, Thank you for review. Please let me clarify. Although "public boolean addAll(Collection c)" is not protected by any lock or monitor, the implementation in both ConcurrentLinked*eque.java still "Atomically append the chain at the tail of this collection", so I still think addAll is a atomic method. Even though it's not called atomic at this situation, the statement "For example, an iterator operating concurrently with an addAll operation might view only some of the added elements." is wrong, because either all objects in Collection c are viewed by iterator, or none of objects in Collection c are viewed by iterator. Thank you -Hamlin > > David > ----- > >> "Additionally, the bulk operations addAll, removeAll, retainAll, >> containsAll, equals, and toArray are not guaranteed to be performed >> atomically. For example, an iterator operating concurrently with an >> addAll operation might view only some of the added elements." >> It should be modified as some thing like below: >> "Additionally, the bulk operations removeAll, retainAll, containsAll, >> equals, and toArray are not guaranteed to be performed atomically." >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8164623 >> webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ >> >> Thank you >> -Hamlin >> From Alan.Bateman at oracle.com Tue Aug 23 14:34:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Aug 2016 15:34:19 +0100 Subject: 8164585: JarFile::isMultiRelease does not return true in all cases where it should return true In-Reply-To: <9B08561C-5FEA-45F8-BDB2-A64222975B67@oracle.com> References: <9B08561C-5FEA-45F8-BDB2-A64222975B67@oracle.com> Message-ID: <7bbdbeaf-cd7f-50f7-6360-db2aafc58e48@oracle.com> On 23/08/2016 00:18, Steve Drach wrote: > Hi, > > Please review this simple change to JarFile > > issue: https://bugs.openjdk.java.net/browse/JDK-8164585 > webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/ > > This looks right to me. -Alan From Alan.Bateman at oracle.com Tue Aug 23 14:35:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Aug 2016 15:35:53 +0100 Subject: RFR: 8148859 Fix module dependences for java/time tests In-Reply-To: <457222DB-AF4A-46C8-A310-872CE9AB4BD1@oracle.com> References: <457222DB-AF4A-46C8-A310-872CE9AB4BD1@oracle.com> Message-ID: On 23/08/2016 01:32, Alexandre (Shura) Iline wrote: > Hi. > > Please review a quick fix for the java/time test module dependencies. > http://cr.openjdk.java.net/~shurailine/8148859/webrev.00/ > > It is using new syntax added in JTReg, which allows to only build certain classes from a test library for TestNG tests: > https://bugs.openjdk.java.net/browse/CODETOOLS-7901667 This looks okay except don't you need jtreg 4.2 b04 to promote first? -Alan From martinrb at google.com Tue Aug 23 16:17:51 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 23 Aug 2016 09:17:51 -0700 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: I didn't see this thread before updating the bug. I think this is Not a Bug, because """The current atomic addAll is a tradeoff; it's efficient, but at the cost of potential loss of concurrency if the other collection is slow. It's reasonable for a subclass to override addAll to add elements eagerly and non-atomically.""" OTOH it would be reasonable to document the atomicity of the implementation in CLD and CLQ as @implNote. On Tue, Aug 23, 2016 at 5:53 AM, Hamlin Li wrote: > > On 2016/8/23 17:10, David Holmes wrote: > >> Hi Hamlin, >> >> On 23/08/2016 6:55 PM, Hamlin Li wrote: >> >>> >>> Below doc is not correct, because for ConcurrentLinkedDeque and >>> ConcurrentLinkedQueue, addAll is a atomic operation. >>> >> >> No it is not! There is no bug here. Are you perhaps confusing thread-safe >> with atomic? >> > Hi David, > > Thank you for review. Please let me clarify. > Although "public boolean addAll(Collection c)" is not > protected by any lock or monitor, the implementation in both > ConcurrentLinked*eque.java still "Atomically append the chain at the tail > of this collection", so I still think addAll is a atomic method. Even > though it's not called atomic at this situation, the statement "For > example, an iterator operating concurrently with an addAll operation might > view only some of the added elements." is wrong, because either all objects > in Collection c are viewed by iterator, or none of objects in Collection c > are viewed by iterator. > > Thank you > -Hamlin > > >> David >> ----- >> >> "Additionally, the bulk operations addAll, removeAll, retainAll, >>> containsAll, equals, and toArray are not guaranteed to be performed >>> atomically. For example, an iterator operating concurrently with an >>> addAll operation might view only some of the added elements." >>> It should be modified as some thing like below: >>> "Additionally, the bulk operations removeAll, retainAll, containsAll, >>> equals, and toArray are not guaranteed to be performed atomically." >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8164623 >>> webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ >>> >>> Thank you >>> -Hamlin >>> >>> > From huizhe.wang at oracle.com Tue Aug 23 16:53:04 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 23 Aug 2016 09:53:04 -0700 Subject: RFR 8157797: SAX Parser throws incorrect error on invalid xml Message-ID: <57BC7F70.1040700@oracle.com> Hi, Please review a quick fix for an incorrect error that should never have been thrown. JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/webrev/ Thanks, Joe From paul.sandoz at oracle.com Tue Aug 23 16:56:51 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 23 Aug 2016 09:56:51 -0700 Subject: 8164585: JarFile::isMultiRelease does not return true in all cases where it should return true In-Reply-To: <9B08561C-5FEA-45F8-BDB2-A64222975B67@oracle.com> References: <9B08561C-5FEA-45F8-BDB2-A64222975B67@oracle.com> Message-ID: <22C8BBA0-067F-49C8-BD45-FC8EFF6BD168@oracle.com> > On 22 Aug 2016, at 16:18, Steve Drach wrote: > > Hi, > > Please review this simple change to JarFile > > issue: https://bugs.openjdk.java.net/browse/JDK-8164585 > webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/ > +1 Paul. From alexandre.iline at oracle.com Tue Aug 23 17:39:45 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 23 Aug 2016 10:39:45 -0700 Subject: RFR: 8148859 Fix module dependences for java/time tests In-Reply-To: References: <457222DB-AF4A-46C8-A310-872CE9AB4BD1@oracle.com> Message-ID: > On Aug 23, 2016, at 7:35 AM, Alan Bateman wrote: > > On 23/08/2016 01:32, Alexandre (Shura) Iline wrote: > >> Hi. >> >> Please review a quick fix for the java/time test module dependencies. >> http://cr.openjdk.java.net/~shurailine/8148859/webrev.00/ >> >> It is using new syntax added in JTReg, which allows to only build certain classes from a test library for TestNG tests: >> https://bugs.openjdk.java.net/browse/CODETOOLS-7901667 > This looks okay except don't you need jtreg 4.2 b04 to promote first? You would need a newer version of JTReg for the new property to be taken into account. With the current JTReg version the tests would work just as they did before - with compiling all classes in the library. Shura > > -Alan > From patrick at reini.net Tue Aug 23 18:38:45 2016 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 23 Aug 2016 20:38:45 +0200 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <2B50E5EC-E382-4EEC-9105-51506C8AF477@oracle.com> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> <0ea87b60-1a21-d6d4-eb7e-38a9dddf1c52@oracle.com> <20A5AEB1-F4A9-4C0E-9F28-521D691FAB03@reini.net> <51D7CAA9-0267-4873-A746-F0670E303918@oracle.com> <87e055be-f577-4dd0-d54e-5cd9dbd06d6b@reini.net> <2B50E5EC-E382-4EEC-9105-51506C8AF477@oracle.com> Message-ID: <05589738-12c5-64ba-eea0-1f6dd7fbca24@reini.net> On 19.08.2016 00:17, Paul Sandoz wrote: > > Onward to the implementation! > > Paul. I did not manage it to get the OpenJDK to compile stressfully under my Fedora Linux as in the past now. Anyhow here a sample implementation, that I will integrate into the existing ClassLoader and the according Test, when we are all happy (or I get the compilation up and running again): http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ImplementationProposal.00 - Patrick From claes.redestad at oracle.com Tue Aug 23 18:49:12 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 23 Aug 2016 20:49:12 +0200 Subject: RFR: 8164669: Lazier initialization of java.time Message-ID: <57BC9AA8.6080903@oracle.com> Hi, this tiny cleanup reduces number of loaded classes from a minimal test touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding pulling in regex and some internal Calendar-related classes. Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ Thanks! /Claes From lance.andersen at oracle.com Tue Aug 23 19:34:35 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 23 Aug 2016 15:34:35 -0400 Subject: RFR 8157797: SAX Parser throws incorrect error on invalid xml In-Reply-To: <57BC7F70.1040700@oracle.com> References: <57BC7F70.1040700@oracle.com> Message-ID: <77EBAC58-28F5-4E89-80CE-010F43E4A656@oracle.com> Looks fine Joe. > On Aug 23, 2016, at 12:53 PM, Joe Wang wrote: > > Hi, > > Please review a quick fix for an incorrect error that should never have been thrown. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 > > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/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 huizhe.wang at oracle.com Tue Aug 23 20:34:16 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 23 Aug 2016 13:34:16 -0700 Subject: RFR 8157797: SAX Parser throws incorrect error on invalid xml In-Reply-To: <77EBAC58-28F5-4E89-80CE-010F43E4A656@oracle.com> References: <57BC7F70.1040700@oracle.com> <77EBAC58-28F5-4E89-80CE-010F43E4A656@oracle.com> Message-ID: <57BCB348.9080905@oracle.com> Thanks Lance! Joe On 8/23/16, 12:34 PM, Lance Andersen wrote: > Looks fine Joe. > >> On Aug 23, 2016, at 12:53 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a quick fix for an incorrect error that should never >> have been thrown. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 >> >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/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 scolebourne at joda.org Tue Aug 23 20:52:56 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 23 Aug 2016 21:52:56 +0100 Subject: RFR: 8164669: Lazier initialization of java.time In-Reply-To: <57BC9AA8.6080903@oracle.com> References: <57BC9AA8.6080903@oracle.com> Message-ID: This looks fine to me. I suspect that we could hand write a parser to avoid the regex, but this probably suffices. Stephen On 23 August 2016 at 19:49, Claes Redestad wrote: > Hi, > > this tiny cleanup reduces number of loaded classes from a minimal test > touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding > pulling in regex and some internal Calendar-related classes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 > Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ > > Thanks! > > /Claes From kim.barrett at oracle.com Tue Aug 23 21:09:58 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 23 Aug 2016 17:09:58 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> Message-ID: <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> Mandy asked for some additional comments to make life easier for future readers. I've also stopped pretending the description for waitForReferenceProcessing is javadoc, since this function is private and only accessible via SharedSecrets or reflection that avoids access control. Changes only in the jdk tree: New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ Unchanged hotspot webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ From mandy.chung at oracle.com Tue Aug 23 21:31:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 23 Aug 2016 14:31:26 -0700 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> Message-ID: > On Aug 23, 2016, at 2:09 PM, Kim Barrett wrote: > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ > > Unchanged hotspot webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ +1 I agree with Kim offline to keep the current proposed methods as the interface can be revised in the future when needed. FYI. I updated the description of JDK-8156500 to: Move Reference pending list into VM to prevent deadlocks This will make it clear what this changeset is about. Mandy From claes.redestad at oracle.com Tue Aug 23 21:52:49 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 23 Aug 2016 23:52:49 +0200 Subject: RFR: 8164669: Lazier initialization of java.time In-Reply-To: References: <57BC9AA8.6080903@oracle.com> Message-ID: <57BCC5B1.7010704@oracle.com> On 2016-08-23 22:52, Stephen Colebourne wrote: > This looks fine to me. Thanks for the review! > I suspect that we could hand write a parser to > avoid the regex, but this probably suffices. > Stephen Right, this is admittedly a bit of a hack. Maybe it would be possible to carefully use/extend DateTimeFormatter to deal with Durations and Periods? /Claes > > On 23 August 2016 at 19:49, Claes Redestad wrote: >> Hi, >> >> this tiny cleanup reduces number of loaded classes from a minimal test >> touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding >> pulling in regex and some internal Calendar-related classes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 >> Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ >> >> Thanks! >> >> /Claes From scolebourne at joda.org Tue Aug 23 21:54:37 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 23 Aug 2016 22:54:37 +0100 Subject: RFR: 8164669: Lazier initialization of java.time In-Reply-To: <57BCC5B1.7010704@oracle.com> References: <57BC9AA8.6080903@oracle.com> <57BCC5B1.7010704@oracle.com> Message-ID: Really, we should add a TemporalAmountFormatter to the JDK, but its a bigger piece of work and quite tricky. Stephen On 23 August 2016 at 22:52, Claes Redestad wrote: > > > On 2016-08-23 22:52, Stephen Colebourne wrote: >> >> This looks fine to me. > > > Thanks for the review! > >> I suspect that we could hand write a parser to >> avoid the regex, but this probably suffices. >> Stephen > > > Right, this is admittedly a bit of a hack. Maybe it would be possible > to carefully use/extend DateTimeFormatter to deal with Durations and > Periods? > > /Claes > > >> >> On 23 August 2016 at 19:49, Claes Redestad >> wrote: >>> >>> Hi, >>> >>> this tiny cleanup reduces number of loaded classes from a minimal test >>> touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding >>> pulling in regex and some internal Calendar-related classes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 >>> Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ >>> >>> Thanks! >>> >>> /Claes From paul.sandoz at oracle.com Tue Aug 23 21:59:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 23 Aug 2016 14:59:42 -0700 Subject: Exceptional behavior of parallel stream In-Reply-To: <1882659279.20160817200105@gmail.com> References: <1882659279.20160817200105@gmail.com> Message-ID: <298448B6-78BB-42E2-94E6-26092C08646C@oracle.com> Hi Tagir, After some discussion with Doug i logged an issue: https://bugs.openjdk.java.net/browse/JDK-8164690 but as of yet undecided whether we should do anything about it at the level of ForkJoinTask or specific to Stream (or even ConcurrentHashMap bulk ops). We could mention, as an implementation detail (@implNote), on Stream and CHM about the current behaviour. I am reluctant to specify normatively. Paul. > On 17 Aug 2016, at 06:01, Tagir F. Valeev wrote: > > Hello! > > I found no information in Stream API documentation on how it behaves > in case if exception occurs during the stream processing. While it's > quite evident for sequential stream (stream processing is terminated > and exception is propagated to the caller as is), the behavior for > parallel streams differs from one might expect. Consider the following > test: > > String[] data = IntStream.range(0, 100).mapToObj(String::valueOf) > .toArray(String[]::new); > data[20] = "oops"; > try { > int sum = Arrays.stream(data).parallel().mapToInt(Integer::valueOf) > .peek(System.out::println).sum(); > System.out.println("Sum is "+sum); > } catch (NumberFormatException e) { > System.out.println("Non-number appeared!"); > } > > This parses integers stored in string array and sums them outputting > every number to stdout once it processed. As data set contains > non-number, the stream obviously fails with NumberFormatException. The > typical output looks like this: > > 62 > 63 > 12 > 31 > 87 > ... > 28 > 92 > 29 > 8 > Non-number appeared! > 9 > 30 > > So as you can see, the stream is not actually terminated when > exception is thrown and caught: even after that some parallel tasks > continue running, and you see more numbers printed after catch block > is executed. > > I consider such behavior as confusing and unexpected. Given the fact > that stream may produce side-effects (e.g. if terminal op is forEach) > this might lead to unforeseen consequences in user programs as > left-over parallel stream tasks may continue mutate shared state after > main stream thread exceptionally returns the control to the caller. > > So I suggest that such behavior should be either fixed or explicitly > documented. What do you think? > > With best regards, > Tagir Valeev. > From paul.sandoz at oracle.com Tue Aug 23 22:10:26 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 23 Aug 2016 15:10:26 -0700 Subject: RFR 8160971 Re-enable VarHandle tests quarantined by JDK-8160690 Message-ID: <06BAD5E1-5EE7-4C44-A16B-33B3C7FAE475@oracle.com> Hi, Please review an update to test/ProblemList.txt remove some VarHandle tests now that JDK-8160690 has been fixed. I will push to jdk9/dev unless HotSpot team members have a preference for me to push to hs-comp where the fix for JDK-8160690 was pushed. Paul. diff -r 5612c35465f3 test/ProblemList.txt --- a/test/ProblemList.txt Tue Aug 23 10:51:17 2016 -0700 +++ b/test/ProblemList.txt Tue Aug 23 15:07:22 2016 -0700 @@ -124,10 +124,6 @@ # jdk_lang java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java 8160690 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java 8160690 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java 8160690 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java 8160690 generic-all From edharned at gmail.com Tue Aug 23 22:20:10 2016 From: edharned at gmail.com (Edward Harned) Date: Tue, 23 Aug 2016 18:20:10 -0400 Subject: Exceptional behavior of parallel stream In-Reply-To: <298448B6-78BB-42E2-94E6-26092C08646C@oracle.com> References: <1882659279.20160817200105@gmail.com> <298448B6-78BB-42E2-94E6-26092C08646C@oracle.com> Message-ID: An enhancement issue is nice, but what can you really do? The reason the framework cannot handle exceptions in related threads is because the framework doesn?t have a central thread management facility. It spits out threads like the Executor Service it inherits without regard for controlling those threads. I gave Doug Lea a Data Parallel engine that properly managed threads back in 2010. He ignored it. Here is a link to the updated project since I?m using some code from that project below. http://sourceforge.net/projects/tymeacdse The management concept is that every request gets a Request Object. This way the request can be timed, cancelled, inquired about, etc. and work threads can know about exceptions in other work threads. com.tymeac.dse.base.WorkThread::syncRequest RequestItem local_request = getReq(); // When backing out (there was a problem somewhere else) if (local_request.isBackout()) { // decrement number of forked tasks and // when number remaining is none // say is complete with no completion object (failure) if (local_request.decrementPendingWork() == 0) local_request.setCompleted(null); return; } Having an API that creates unmanaged threads is acceptable; really, what else could a general purpose API do? Having a service, that controls all parallel processing in JavaSE, that creates un-managed threads is not acceptable. Ed On Tue, Aug 23, 2016 at 5:59 PM, Paul Sandoz wrote: > Hi Tagir, > > After some discussion with Doug i logged an issue: > > https://bugs.openjdk.java.net/browse/JDK-8164690 < > https://bugs.openjdk.java.net/browse/JDK-8164690> > > but as of yet undecided whether we should do anything about it at the > level of ForkJoinTask or specific to Stream (or even ConcurrentHashMap bulk > ops). > > We could mention, as an implementation detail (@implNote), on Stream and > CHM about the current behaviour. I am reluctant to specify normatively. > > Paul. > > > On 17 Aug 2016, at 06:01, Tagir F. Valeev wrote: > > > > Hello! > > > > I found no information in Stream API documentation on how it behaves > > in case if exception occurs during the stream processing. While it's > > quite evident for sequential stream (stream processing is terminated > > and exception is propagated to the caller as is), the behavior for > > parallel streams differs from one might expect. Consider the following > > test: > > > > String[] data = IntStream.range(0, 100).mapToObj(String::valueOf) > > .toArray(String[]::new); > > data[20] = "oops"; > > try { > > int sum = Arrays.stream(data).parallel().mapToInt(Integer::valueOf) > > .peek(System.out::println).sum(); > > System.out.println("Sum is "+sum); > > } catch (NumberFormatException e) { > > System.out.println("Non-number appeared!"); > > } > > > > This parses integers stored in string array and sums them outputting > > every number to stdout once it processed. As data set contains > > non-number, the stream obviously fails with NumberFormatException. The > > typical output looks like this: > > > > 62 > > 63 > > 12 > > 31 > > 87 > > ... > > 28 > > 92 > > 29 > > 8 > > Non-number appeared! > > 9 > > 30 > > > > So as you can see, the stream is not actually terminated when > > exception is thrown and caught: even after that some parallel tasks > > continue running, and you see more numbers printed after catch block > > is executed. > > > > I consider such behavior as confusing and unexpected. Given the fact > > that stream may produce side-effects (e.g. if terminal op is forEach) > > this might lead to unforeseen consequences in user programs as > > left-over parallel stream tasks may continue mutate shared state after > > main stream thread exceptionally returns the control to the caller. > > > > So I suggest that such behavior should be either fixed or explicitly > > documented. What do you think? > > > > With best regards, > > Tagir Valeev. > > > > From vladimir.x.ivanov at oracle.com Tue Aug 23 22:33:29 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Aug 2016 01:33:29 +0300 Subject: RFR 8160971 Re-enable VarHandle tests quarantined by JDK-8160690 In-Reply-To: <06BAD5E1-5EE7-4C44-A16B-33B3C7FAE475@oracle.com> References: <06BAD5E1-5EE7-4C44-A16B-33B3C7FAE475@oracle.com> Message-ID: Looks good. I'm fine with pushing it directly to jdk9/dev. Best regards, Vladimir Ivanov On 8/24/16 1:10 AM, Paul Sandoz wrote: > Hi, > > Please review an update to test/ProblemList.txt remove some VarHandle tests now that JDK-8160690 has been fixed. > > I will push to jdk9/dev unless HotSpot team members have a preference for me to push to hs-comp where the fix for JDK-8160690 was pushed. > > Paul. > > diff -r 5612c35465f3 test/ProblemList.txt > --- a/test/ProblemList.txt Tue Aug 23 10:51:17 2016 -0700 > +++ b/test/ProblemList.txt Tue Aug 23 15:07:22 2016 -0700 > @@ -124,10 +124,6 @@ > # jdk_lang > > java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all > -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java 8160690 generic-all > -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java 8160690 generic-all > -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java 8160690 generic-all > -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java 8160690 generic-all > From kim.barrett at oracle.com Tue Aug 23 22:56:48 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 23 Aug 2016 18:56:48 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> Message-ID: <4B517CD0-40AE-4633-ADF9-A65AF6292EFC@oracle.com> > On Aug 23, 2016, at 5:31 PM, Mandy Chung wrote: > > >> On Aug 23, 2016, at 2:09 PM, Kim Barrett wrote: >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ >> >> Unchanged hotspot webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ > > +1 > > I agree with Kim offline to keep the current proposed methods as the interface can be revised in the future when needed. > > FYI. I updated the description of JDK-8156500 to: > Move Reference pending list into VM to prevent deadlocks > > This will make it clear what this changeset is about. > > Mandy Thanks. From huaming.li at oracle.com Wed Aug 24 01:18:29 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 24 Aug 2016 09:18:29 +0800 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: <8f94a157-c6ca-73bc-44ba-df2e036b96fb@oracle.com> Hi Martin, Thank you for clarifying and taking the bug. -Hamlin On 2016/8/24 0:17, Martin Buchholz wrote: > I didn't see this thread before updating the bug. > > I think this is Not a Bug, because """The current atomic addAll is a > tradeoff; it's efficient, but at the cost of potential loss of > concurrency if the other collection is slow. It's reasonable for a > subclass to override addAll to add elements eagerly and non-atomically.""" > > OTOH it would be reasonable to document the atomicity of the > implementation in CLD and CLQ as @implNote. > > On Tue, Aug 23, 2016 at 5:53 AM, Hamlin Li > wrote: > > > On 2016/8/23 17:10, David Holmes wrote: > > Hi Hamlin, > > On 23/08/2016 6:55 PM, Hamlin Li wrote: > > > Below doc is not correct, because for > ConcurrentLinkedDeque and > ConcurrentLinkedQueue, addAll is a atomic operation. > > > No it is not! There is no bug here. Are you perhaps confusing > thread-safe with atomic? > > Hi David, > > Thank you for review. Please let me clarify. > Although "public boolean addAll(Collection c)" is not > protected by any lock or monitor, the implementation in both > ConcurrentLinked*eque.java still "Atomically append the chain at > the tail of this collection", so I still think addAll is a atomic > method. Even though it's not called atomic at this situation, the > statement "For example, an iterator operating concurrently with an > addAll operation might view only some of the added elements." is > wrong, because either all objects in Collection c are viewed by > iterator, or none of objects in Collection c are viewed by iterator. > > Thank you > -Hamlin > > > David > ----- > > "Additionally, the bulk operations addAll, removeAll, > retainAll, > containsAll, equals, and toArray are not guaranteed to be > performed > atomically. For example, an iterator operating > concurrently with an > addAll operation might view only some of the added elements." > It should be modified as some thing like below: > "Additionally, the bulk operations removeAll, retainAll, > containsAll, > equals, and toArray are not guaranteed to be performed > atomically." > > bug: https://bugs.openjdk.java.net/browse/JDK-8164623 > > webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ > > > Thank you > -Hamlin > > > From david.holmes at oracle.com Wed Aug 24 01:22:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Aug 2016 11:22:46 +1000 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: <46351129-90ea-943a-a5dd-14d01ac9872b@oracle.com> Hi Hamlin, On 23/08/2016 10:53 PM, Hamlin Li wrote: > > On 2016/8/23 17:10, David Holmes wrote: >> Hi Hamlin, >> >> On 23/08/2016 6:55 PM, Hamlin Li wrote: >>> >>> Below doc is not correct, because for ConcurrentLinkedDeque and >>> ConcurrentLinkedQueue, addAll is a atomic operation. >> >> No it is not! There is no bug here. Are you perhaps confusing >> thread-safe with atomic? > Hi David, > > Thank you for review. Please let me clarify. > Although "public boolean addAll(Collection c)" is not > protected by any lock or monitor, the implementation in both > ConcurrentLinked*eque.java still "Atomically append the chain at the > tail of this collection", so I still think addAll is a atomic method. Yes you are correct, my apologies. But as Martin states this is an implementation artifact not something that the specification wants to be guaranteeing. Thanks, David > Even though it's not called atomic at this situation, the statement "For > example, an iterator operating concurrently with an addAll operation > might view only some of the added elements." is wrong, because either > all objects in Collection c are viewed by iterator, or none of objects > in Collection c are viewed by iterator. > > Thank you > -Hamlin >> >> David >> ----- >> >>> "Additionally, the bulk operations addAll, removeAll, retainAll, >>> containsAll, equals, and toArray are not guaranteed to be performed >>> atomically. For example, an iterator operating concurrently with an >>> addAll operation might view only some of the added elements." >>> It should be modified as some thing like below: >>> "Additionally, the bulk operations removeAll, retainAll, containsAll, >>> equals, and toArray are not guaranteed to be performed atomically." >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8164623 >>> webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ >>> >>> Thank you >>> -Hamlin >>> > From huaming.li at oracle.com Wed Aug 24 02:04:33 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 24 Aug 2016 10:04:33 +0800 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: <46351129-90ea-943a-a5dd-14d01ac9872b@oracle.com> References: <46351129-90ea-943a-a5dd-14d01ac9872b@oracle.com> Message-ID: <1d37b070-7c3e-137b-f2e8-f32fa1b6c4f5@oracle.com> On 2016/8/24 9:22, David Holmes wrote: > Hi Hamlin, > > On 23/08/2016 10:53 PM, Hamlin Li wrote: >> >> On 2016/8/23 17:10, David Holmes wrote: >>> Hi Hamlin, >>> >>> On 23/08/2016 6:55 PM, Hamlin Li wrote: >>>> >>>> Below doc is not correct, because for ConcurrentLinkedDeque and >>>> ConcurrentLinkedQueue, addAll is a atomic operation. >>> >>> No it is not! There is no bug here. Are you perhaps confusing >>> thread-safe with atomic? >> Hi David, >> >> Thank you for review. Please let me clarify. >> Although "public boolean addAll(Collection c)" is not >> protected by any lock or monitor, the implementation in both >> ConcurrentLinked*eque.java still "Atomically append the chain at the >> tail of this collection", so I still think addAll is a atomic method. > > Yes you are correct, my apologies. Hi David, It's OK :-) I should have made it more clear in code review request. > But as Martin states this is an implementation artifact not something > that the specification wants to be guaranteeing. Yes, I think Martin's suggestion is more reasonable. Thank you both! -Hamlin > > Thanks, > David > >> Even though it's not called atomic at this situation, the statement "For >> example, an iterator operating concurrently with an addAll operation >> might view only some of the added elements." is wrong, because either >> all objects in Collection c are viewed by iterator, or none of objects >> in Collection c are viewed by iterator. >> >> Thank you >> -Hamlin >>> >>> David >>> ----- >>> >>>> "Additionally, the bulk operations addAll, removeAll, retainAll, >>>> containsAll, equals, and toArray are not guaranteed to be performed >>>> atomically. For example, an iterator operating concurrently with an >>>> addAll operation might view only some of the added elements." >>>> It should be modified as some thing like below: >>>> "Additionally, the bulk operations removeAll, retainAll, containsAll, >>>> equals, and toArray are not guaranteed to be performed atomically." >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8164623 >>>> webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ >>>> >>>> Thank you >>>> -Hamlin >>>> >> From martinrb at google.com Wed Aug 24 03:02:50 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 23 Aug 2016 20:02:50 -0700 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz wrote: > I didn't see this thread before updating the bug. > > I think this is Not a Bug, because """The current atomic addAll is a > tradeoff; it's efficient, but at the cost of potential loss of concurrency > if the other collection is slow. It's reasonable for a subclass to override > addAll to add elements eagerly and non-atomically.""" > > OTOH it would be reasonable to document the atomicity of the > implementation in CLD and CLQ as @implNote. > Right now I'm even back-pedaling on that. Unless there's an important use case where atomicity of addAll matters, it's not worth the confusion to document that some particular implementation is atomic. The aim of that code was efficiency, not atomicity. In fact, choosing some batch size and adding in chunks, I/O buffer style, may be a better choice. From huaming.li at oracle.com Wed Aug 24 03:39:50 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 24 Aug 2016 11:39:50 +0800 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: On 2016/8/24 11:02, Martin Buchholz wrote: > > > On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz > wrote: > > I didn't see this thread before updating the bug. > > I think this is Not a Bug, because """The current atomic addAll is > a tradeoff; it's efficient, but at the cost of potential loss of > concurrency if the other collection is slow. It's reasonable for a > subclass to override addAll to add elements eagerly and > non-atomically.""" > > OTOH it would be reasonable to document the atomicity of the > implementation in CLD and CLQ as @implNote. > > > Right now I'm even back-pedaling on that. Unless there's an important > use case where atomicity of addAll matters, it's not worth the > confusion to document that some particular implementation is atomic. > The aim of that code was efficiency, not atomicity. In fact, choosing > some batch size and adding in chunks, I/O buffer style, may be a > better choice. Hi Martin, Yes, you're right. But currently, "For example, an iterator operating concurrently with an addAll operation might view only some of the added elements." is a wrong statement for ConcurrentLinkedDeque and ConcurrentLinkedQueue, so maybe we could just remove just this sentence for now. Thank you -Hamlin From david.holmes at oracle.com Wed Aug 24 04:53:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Aug 2016 14:53:41 +1000 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: References: Message-ID: <5efb7f8f-3561-1a4c-c80d-7f7080e9ce27@oracle.com> On 24/08/2016 1:39 PM, Hamlin Li wrote: > > On 2016/8/24 11:02, Martin Buchholz wrote: >> >> >> On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz > > wrote: >> >> I didn't see this thread before updating the bug. >> >> I think this is Not a Bug, because """The current atomic addAll is >> a tradeoff; it's efficient, but at the cost of potential loss of >> concurrency if the other collection is slow. It's reasonable for a >> subclass to override addAll to add elements eagerly and >> non-atomically.""" >> >> OTOH it would be reasonable to document the atomicity of the >> implementation in CLD and CLQ as @implNote. >> >> >> Right now I'm even back-pedaling on that. Unless there's an important >> use case where atomicity of addAll matters, it's not worth the >> confusion to document that some particular implementation is atomic. >> The aim of that code was efficiency, not atomicity. In fact, choosing >> some batch size and adding in chunks, I/O buffer style, may be a >> better choice. > Hi Martin, > > Yes, you're right. > But currently, "For example, an iterator operating concurrently with an > addAll operation might view only some of the added elements." is a wrong > statement for ConcurrentLinkedDeque and ConcurrentLinkedQueue, so maybe > we could just remove just this sentence for now. It is only an example and it says "might". If we change the implementation tomorrow we wouldn't want to have to update the spec to add the example back. It is really non-normative text but we don't want any users of these classes to rely on any atomicity property. David > Thank you > -Hamlin From huaming.li at oracle.com Wed Aug 24 06:09:23 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 24 Aug 2016 14:09:23 +0800 Subject: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java In-Reply-To: <5efb7f8f-3561-1a4c-c80d-7f7080e9ce27@oracle.com> References: <5efb7f8f-3561-1a4c-c80d-7f7080e9ce27@oracle.com> Message-ID: <0fd243c0-a077-0c2b-0d5d-87ae5faf214e@oracle.com> On 2016/8/24 12:53, David Holmes wrote: > On 24/08/2016 1:39 PM, Hamlin Li wrote: >> >> On 2016/8/24 11:02, Martin Buchholz wrote: >>> >>> >>> On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz >> > wrote: >>> >>> I didn't see this thread before updating the bug. >>> >>> I think this is Not a Bug, because """The current atomic addAll is >>> a tradeoff; it's efficient, but at the cost of potential loss of >>> concurrency if the other collection is slow. It's reasonable for a >>> subclass to override addAll to add elements eagerly and >>> non-atomically.""" >>> >>> OTOH it would be reasonable to document the atomicity of the >>> implementation in CLD and CLQ as @implNote. >>> >>> >>> Right now I'm even back-pedaling on that. Unless there's an important >>> use case where atomicity of addAll matters, it's not worth the >>> confusion to document that some particular implementation is atomic. >>> The aim of that code was efficiency, not atomicity. In fact, choosing >>> some batch size and adding in chunks, I/O buffer style, may be a >>> better choice. >> Hi Martin, >> >> Yes, you're right. >> But currently, "For example, an iterator operating concurrently with an >> addAll operation might view only some of the added elements." is a wrong >> statement for ConcurrentLinkedDeque and ConcurrentLinkedQueue, so maybe >> we could just remove just this sentence for now. > > It is only an example and it says "might". If we change the > implementation tomorrow we wouldn't want to have to update the spec to > add the example back. It is really non-normative text but we don't > want any users of these classes to rely on any atomicity property. Hi David, Got your point. Thank you -Hamlin > > David > >> Thank you >> -Hamlin From per.liden at oracle.com Wed Aug 24 07:50:37 2016 From: per.liden at oracle.com (Per Liden) Date: Wed, 24 Aug 2016 09:50:37 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> Message-ID: Still looks good. cheers, Per On 2016-08-23 23:09, Kim Barrett wrote: > Mandy asked for some additional comments to make life easier for > future readers. I've also stopped pretending the description for > waitForReferenceProcessing is javadoc, since this function is private > and only accessible via SharedSecrets or reflection that avoids access > control. > > Changes only in the jdk tree: > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ > > Unchanged hotspot webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ > > From claes.redestad at oracle.com Wed Aug 24 09:59:03 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Aug 2016 11:59:03 +0200 Subject: RFR: 8164669: Lazier initialization of java.time In-Reply-To: References: <57BC9AA8.6080903@oracle.com> <57BCC5B1.7010704@oracle.com> Message-ID: <57BD6FE7.4010508@oracle.com> Agreed, seems like something to consider for a future release. Thanks! /Claes PS. I still need a OpenJDK Reviewer before I can push this one On 2016-08-23 23:54, Stephen Colebourne wrote: > Really, we should add a TemporalAmountFormatter to the JDK, but its a > bigger piece of work and quite tricky. > Stephen > > On 23 August 2016 at 22:52, Claes Redestad wrote: >> >> >> On 2016-08-23 22:52, Stephen Colebourne wrote: >>> >>> This looks fine to me. >> >> >> Thanks for the review! >> >>> I suspect that we could hand write a parser to >>> avoid the regex, but this probably suffices. >>> Stephen >> >> >> Right, this is admittedly a bit of a hack. Maybe it would be possible >> to carefully use/extend DateTimeFormatter to deal with Durations and >> Periods? >> >> /Claes >> >> >>> >>> On 23 August 2016 at 19:49, Claes Redestad >>> wrote: >>>> >>>> Hi, >>>> >>>> this tiny cleanup reduces number of loaded classes from a minimal test >>>> touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding >>>> pulling in regex and some internal Calendar-related classes. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 >>>> Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ >>>> >>>> Thanks! >>>> >>>> /Claes From chris.hegarty at oracle.com Wed Aug 24 10:11:08 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 24 Aug 2016 11:11:08 +0100 Subject: RFR: 8164669: Lazier initialization of java.time In-Reply-To: References: <57BC9AA8.6080903@oracle.com> Message-ID: <9d4994d5-50d2-88fd-547c-f35451e19d2e@oracle.com> +1. -Chris. On 23/08/16 21:52, Stephen Colebourne wrote: > This looks fine to me. I suspect that we could hand write a parser to > avoid the regex, but this probably suffices. > Stephen > > On 23 August 2016 at 19:49, Claes Redestad wrote: >> Hi, >> >> this tiny cleanup reduces number of loaded classes from a minimal test >> touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding >> pulling in regex and some internal Calendar-related classes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 >> Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ >> >> Thanks! >> >> /Claes From Alan.Bateman at oracle.com Wed Aug 24 10:13:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Aug 2016 11:13:20 +0100 Subject: RFR: 8164669: Lazier initialization of java.time In-Reply-To: <57BD6FE7.4010508@oracle.com> References: <57BC9AA8.6080903@oracle.com> <57BCC5B1.7010704@oracle.com> <57BD6FE7.4010508@oracle.com> Message-ID: On 24/08/2016 10:59, Claes Redestad wrote: > Agreed, seems like something to consider for a future release. > > Thanks! > > /Claes > > PS. I still need a OpenJDK Reviewer before I can push this one Looks okay, I guess I would name it Holder or something like that rather than "Lazy" but that is a minor point. -Alan From vladimir.x.ivanov at oracle.com Wed Aug 24 10:32:42 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Aug 2016 13:32:42 +0300 Subject: RFR: 8164569: Generate non-customized invoker forms at link time In-Reply-To: <57BC0FFE.7020006@oracle.com> References: <57BC0FFE.7020006@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 8/23/16 11:57 AM, Claes Redestad wrote: > Hi, > > this patch adds configurable link-time generation of the invoker forms. > Some such forms is commonly used early on in even the simplest startup > tests, and an unbounded number of invoker forms can be generated in more > complex cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164569 > Webrev: http://cr.openjdk.java.net/~redestad/8164569/webrev.01/ > > Together with JDK-8164483 (which I've tested together with this) this > removes all class generation from runtime in the tests associated with > JDK-8086045 > > I'd also note that the default setting in this patch is rather > arbitrary: although it removes a handful of invokers in a number of > tests, it's admittedly complicated to detect which ones are needed (same > goes for already implemented options to select > Direct-/DelegatingMethodHandles and BoundMethodHandle$Species_*). The > plan is to implement JDK-8163371 in such a way that running a > application with a tracing flag enabled will produce a file to use as > the sole input to --generate-jli-classes. > > Thanks! > > /Claes From vladimir.x.ivanov at oracle.com Wed Aug 24 11:02:18 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Aug 2016 14:02:18 +0300 Subject: RFR: 8164483: Generate field lambda forms at link time In-Reply-To: <57BC0FFA.5030608@oracle.com> References: <57BC0FFA.5030608@oracle.com> Message-ID: <87ed3f0e-9e79-6458-d504-b6c15629ffe8@oracle.com> src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java + @ForceInline + /*non-public*/ static Unsafe unsafe() { + return UNSAFE; + } + + NF_unsafe = new NamedFunction(DirectMethodHandle.class + .getDeclaredMethod("unsafe")) No need for an accessor method. InvokerBytecodeGenerator already supports static field getters/setters [1]. You have to provide proper NamedFunction for MethodHandleStatics.UNSAFE. Regarding LambdaForm.Kind, IMO field accessors push enum approach to the limit. Let's think about better ways to represent LF shape in a structured manner, but I'm fine with keeping it for future cleanup. Overall, looks good. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/496a116876a3/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java#l931 On 8/23/16 11:57 AM, Claes Redestad wrote: > Hi, > > this patch adds link-time generation of the simplest field lambda forms. > This avoid generating these forms during bootstrapping, which is > commonly done early on in even the simplest startup tests. > > To make this work, injecting Unsafe as a constant replacement had to be > replaced with a getter function, resulting in a few more bytecodes to do > the same thing, but which after inlining should turn into equivalent > code; performance testing indicate this change is performance neutral. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164483 > Webrev: http://cr.openjdk.java.net/~redestad/8164483/webrev.01/ > > Together with JDK-8164569 (which I've tested together with this) this > removes all class generation from runtime in the tests associated with > JDK-8086045 > > Thanks! > > /Claes From claes.redestad at oracle.com Wed Aug 24 13:04:57 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Aug 2016 15:04:57 +0200 Subject: RFR: 8164483: Generate field lambda forms at link time In-Reply-To: <87ed3f0e-9e79-6458-d504-b6c15629ffe8@oracle.com> References: <57BC0FFA.5030608@oracle.com> <87ed3f0e-9e79-6458-d504-b6c15629ffe8@oracle.com> Message-ID: <57BD9B79.60601@oracle.com> On 2016-08-24 13:02, Vladimir Ivanov wrote: > src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java > > + @ForceInline > + /*non-public*/ static Unsafe unsafe() { > + return UNSAFE; > + } > + > > + NF_unsafe = new NamedFunction(DirectMethodHandle.class > + .getDeclaredMethod("unsafe")) > > No need for an accessor method. InvokerBytecodeGenerator already > supports static field getters/setters [1]. You have to provide proper > NamedFunction for MethodHandleStatics.UNSAFE. Like so: http://cr.openjdk.java.net/~redestad/8164483/webrev.02/ > > Regarding LambdaForm.Kind, IMO field accessors push enum approach to the > limit. Let's think about better ways to represent LF shape in a > structured manner, but I'm fine with keeping it for future cleanup. Agreed, this is begging for a better abstraction/structure. Thanks! /Claes > > Overall, looks good. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/496a116876a3/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java#l931 > > > On 8/23/16 11:57 AM, Claes Redestad wrote: >> Hi, >> >> this patch adds link-time generation of the simplest field lambda forms. >> This avoid generating these forms during bootstrapping, which is >> commonly done early on in even the simplest startup tests. >> >> To make this work, injecting Unsafe as a constant replacement had to be >> replaced with a getter function, resulting in a few more bytecodes to do >> the same thing, but which after inlining should turn into equivalent >> code; performance testing indicate this change is performance neutral. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164483 >> Webrev: http://cr.openjdk.java.net/~redestad/8164483/webrev.01/ >> >> Together with JDK-8164569 (which I've tested together with this) this >> removes all class generation from runtime in the tests associated with >> JDK-8086045 >> >> Thanks! >> >> /Claes From vladimir.x.ivanov at oracle.com Wed Aug 24 13:27:39 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 24 Aug 2016 16:27:39 +0300 Subject: RFR: 8164483: Generate field lambda forms at link time In-Reply-To: <57BD9B79.60601@oracle.com> References: <57BC0FFA.5030608@oracle.com> <87ed3f0e-9e79-6458-d504-b6c15629ffe8@oracle.com> <57BD9B79.60601@oracle.com> Message-ID: > http://cr.openjdk.java.net/~redestad/8164483/webrev.02/ Looks good. Best regards, Vladimir Ivanov >> >> Regarding LambdaForm.Kind, IMO field accessors push enum approach to the >> limit. Let's think about better ways to represent LF shape in a >> structured manner, but I'm fine with keeping it for future cleanup. > > Agreed, this is begging for a better abstraction/structure. > > Thanks! > > /Claes > >> >> Overall, looks good. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/496a116876a3/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java#l931 >> >> >> >> On 8/23/16 11:57 AM, Claes Redestad wrote: >>> Hi, >>> >>> this patch adds link-time generation of the simplest field lambda forms. >>> This avoid generating these forms during bootstrapping, which is >>> commonly done early on in even the simplest startup tests. >>> >>> To make this work, injecting Unsafe as a constant replacement had to be >>> replaced with a getter function, resulting in a few more bytecodes to do >>> the same thing, but which after inlining should turn into equivalent >>> code; performance testing indicate this change is performance neutral. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164483 >>> Webrev: http://cr.openjdk.java.net/~redestad/8164483/webrev.01/ >>> >>> Together with JDK-8164569 (which I've tested together with this) this >>> removes all class generation from runtime in the tests associated with >>> JDK-8086045 >>> >>> Thanks! >>> >>> /Claes From kim.barrett at oracle.com Wed Aug 24 13:52:19 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Aug 2016 09:52:19 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> Message-ID: <688217F0-DE77-423F-885E-48D7A2ED115E@oracle.com> > On Aug 24, 2016, at 3:50 AM, Per Liden wrote: > > Still looks good. > > cheers, > Per Thanks. > > On 2016-08-23 23:09, Kim Barrett wrote: >> Mandy asked for some additional comments to make life easier for >> future readers. I've also stopped pretending the description for >> waitForReferenceProcessing is javadoc, since this function is private >> and only accessible via SharedSecrets or reflection that avoids access >> control. >> >> Changes only in the jdk tree: >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ >> >> Unchanged hotspot webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ From srinivas.dama at oracle.com Wed Aug 24 14:28:57 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 24 Aug 2016 07:28:57 -0700 (PDT) Subject: RFR:8163793: jlink has typo in copy-files plugin help text example Message-ID: <37bbf55f-8eb4-4e1f-8b97-2842aae97db7@default> Hi, This patch fixes very small typo error. Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163793 Regards, Srinivas From sundararajan.athijegannathan at oracle.com Wed Aug 24 14:32:18 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 24 Aug 2016 20:02:18 +0530 Subject: RFR:8163793: jlink has typo in copy-files plugin help text example In-Reply-To: <37bbf55f-8eb4-4e1f-8b97-2842aae97db7@default> References: <37bbf55f-8eb4-4e1f-8b97-2842aae97db7@default> Message-ID: <4936a4f2-69c0-a6c4-75d2-16eb3846f358@oracle.com> +1 On 8/24/2016 7:58 PM, Srinivas Dama wrote: > Hi, > > This patch fixes very small typo error. > > Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163793 > > > Regards, > Srinivas From claes.redestad at oracle.com Wed Aug 24 14:40:32 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Aug 2016 16:40:32 +0200 Subject: RFR:8163793: jlink has typo in copy-files plugin help text example In-Reply-To: <37bbf55f-8eb4-4e1f-8b97-2842aae97db7@default> References: <37bbf55f-8eb4-4e1f-8b97-2842aae97db7@default> Message-ID: <57BDB1E0.8000304@oracle.com> +1 On 2016-08-24 16:28, Srinivas Dama wrote: > Hi, > > This patch fixes very small typo error. > > Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163793 > > > Regards, > Srinivas > From paul.sandoz at oracle.com Wed Aug 24 15:45:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 24 Aug 2016 08:45:32 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet In-Reply-To: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> References: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> Message-ID: <71132A36-9DD6-45E2-A988-29C6F652E8ED@oracle.com> Hi, Gentle reminder. Paul. > On 10 Aug 2016, at 17:03, Paul Sandoz wrote: > > Hi > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/ > > This is a refactoring to produce a consistent naming scheme for the VarHandle Read Modify Write (RMW) methods. The unqualified methods default to volatile access. > > (And i hope this is the last modifying to the API signatures) > > This touches 166 classes that use or refer to the weak plain/volatile methods. > > The plan is to follow up deprecating (*not* for removal) the weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add weakCompareAndSetPlain methods. Analysis via grepcode shows very little usages of the Atomic*.weakCompareAndSet methods. > > A further plan is to rename the Unsafe methods s/Swap/Set, add Plain qualifier etc. > > Paul. From claes.redestad at oracle.com Wed Aug 24 16:48:56 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Aug 2016 18:48:56 +0200 Subject: RFR: 8164739: Remove computation of predefined interpreter forms Message-ID: <57BDCFF8.8080203@oracle.com> Hi, LambdaForm predefines a number of forms for the benefit of the LF and NF interpreters, which doesn't appear useful at all at this point. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164739 Webrev: http://cr.openjdk.java.net/~redestad/8164739/webrev.01/ Testing: all java/lang/invoke tests with various values for -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD to run with and without LF interpretation. Removing this code improves on previous work to improve indy bootstrap to the point where the indy bootstrap happens in a few milliseconds, only loads 21 extra classes. On full program execution there's no discernible time difference between the regular and the MH variant. Thanks! /Claes From john.r.rose at oracle.com Wed Aug 24 17:07:25 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Aug 2016 10:07:25 -0700 Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect In-Reply-To: <4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com> References: <57B4C392.4060001@oracle.com> <4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com> Message-ID: <4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com> On Aug 22, 2016, at 9:30 PM, Mandy Chung wrote: > > We need to follow up this issue to understand what the interpreter and compiler do for this unused slot and whether it?s always zero out. These slot pairs are a curse, in the same league as endian-ness. Suppose a 64-bit long x lives in L[0] and L[1]. Now suppose that the interpreter (as well it might) has adjacent 32-bit words for those locals. There are four reasonable conventions for apportioning the bits of x into L[0:1]. Call HI(x) the arithmetically high part of x, and LO(x) the other part. Also, call FST(x) the lower-addressed 32-bit component of x, when stored in memory, and SND(x) the other part. Depending on your machine's endian-ness, HI=FST or HI=SND (little-endian, x86). For portable code there are obviously four ways to pack L[0:1]. I've personally seen them all, sometimes as hard-to-find VM bugs. We're just getting started, though. Now let the interpreter generously allocate 64 bits to each local. The above four cases are still possible, but now we have 4 32-bit storage units to play with. That makes (if you do the math) 4x3=12 more theoretically possible ways to store the bits of x into the 128 bits of L[0:1]. I've not seen all 12, but there are several variations that HotSpot has used over time. Confused yet? There's more: All current HotSpot implementations grow the stack downward, which means that the address of L[0] is *higher* than L[1]. This means that the pair of storage units for L[0:1] can be viewed as a memory buffer, but the bits of L[1] come at a lower address. (Once we had a tagged-stack interpreter in which there were extra tag words between the words of L[0] and L[1], for extra fun. We got tired of that.) There's one more annoyance: The memory block located at L[0:1] must be at least 64 bits wide, but it need not be 64-bit aligned, if the size of a local slot is 32 bits. So on machines that cannot perform unaligned 64-bit access, the interpreter needs to load and store 64-bit values as 32-bit halves. But we can put that aside for now; that's a separable cost borne by 32-bit RISCs. How do we simplify this? For one thing, view all reference to HI and LO with extreme suspicion. That goes for misleadingly simple terms like "the low half of x". On Intel everybody knows that's also FST (the first memory word of x), and nods in agreement, and then when you port to SPARC (that was my job) the nods turn into glassy-eyed stares. Next, don't trust L[0] and L[1] to work like array elements. Although the bytecode interpreter refers directly to L[0] and indirectly to L[1], when storing 'x', realize that you don't know exactly how those guys are laid out in memory. The interpreter will make some local decision to avoid the obvious-in-retrospect bug of storing 64-bits to L[0] on a 32-bit machine. The decision might be to form the address of L[1] and treat *that* as the base address of a memory block. The more subtle and principled thing to do would be to form the address of the *end* of L[0] and treat that as the *end* address of a memory block. The two approaches are equivalent on 32-bit machine, but on a 64-bit machine one puts the payload only in L[1] and one only in L[0]. Meanwhile, the JIT, with its free-wheeling approach to storage allocation, will probably try its best to ignore and forget stupid L[1], allocating a right-sized register or stack slot for L[0]. Thus interpreter and JIT can have independent internal conventions for how they assign storage units to L[0:1] and how they use those units to store a 64-bit value. Those independent schemes have to be reconciled along mode change paths: C2I and I2C adapters, deoptimization, and on-stack replacement (= reoptimization). The vframe_hp code does this. A strong global convention would be best, such as always using L[0] and always storing all of x in L[0] if it fits, else SND(x) in L[0] and FST(x) in L[1]. I'm not sure (and I doubt) that we are actually that clean. Any reasonable high-level API for dealing with this stuff will do like the JIT does, and pretend that, whatever the size of L[0] is physically, it contains the whole value assigned to it, without any need to inspect L[1]. That's the best policy for virtualizing stack frames, because it aligns with the plain meaning of bytecodes like "lload0", which don't mention L[1]. The role of L[1] is to provide "slop space" for internal storage in a tiny interpreter; it has no external role. The convention used in HotSpot and the JVM verifier is to assign a special type to L[1], "Top" which means "do not look at me; I contain no bits". A virtualized API which produces a view on such an L[1] needs to return some default value (if pressed), and to indicate that the slot has no payload. HTH ? John P.S. If all goes well with Valhalla, we will probably get rid of slot pairs altogether in a future version of the JVM bytecodes. They spoil generics over longs and doubles. The 32-bit implementations of JVM interpreters will have to do extra work, such as have 64-bit slot sizes for methods that work with longs or doubles, but it's worth it. From martinrb at google.com Wed Aug 24 19:37:51 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 24 Aug 2016 12:37:51 -0700 Subject: RFR: 8163353: NPE in ConcurrentHashMap.removeAll() Message-ID: Let's get in the fix for regression 8163353 quickly: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ https://bugs.openjdk.java.net/browse/JDK-8163353 From claes.redestad at oracle.com Wed Aug 24 19:41:08 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 24 Aug 2016 21:41:08 +0200 Subject: RFR: 8163353: NPE in ConcurrentHashMap.removeAll() In-Reply-To: References: Message-ID: <57BDF854.4000401@oracle.com> +1 /Claes On 2016-08-24 21:37, Martin Buchholz wrote: > Let's get in the fix for regression 8163353 quickly: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ > https://bugs.openjdk.java.net/browse/JDK-8163353 > From Alan.Bateman at oracle.com Wed Aug 24 19:44:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Aug 2016 20:44:07 +0100 Subject: RFR: 8163353: NPE in ConcurrentHashMap.removeAll() In-Reply-To: References: Message-ID: <196620fa-ec52-f68c-0f36-565760c15236@oracle.com> On 24/08/2016 20:37, Martin Buchholz wrote: > Let's get in the fix for regression 8163353 quickly: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ > https://bugs.openjdk.java.net/browse/JDK-8163353 Looks good, I think a couple of people have run into this in the last build or so. -Alan From paul.sandoz at oracle.com Wed Aug 24 20:06:20 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 24 Aug 2016 13:06:20 -0700 Subject: RFR: 8163353: NPE in ConcurrentHashMap.removeAll() In-Reply-To: References: Message-ID: > On 24 Aug 2016, at 12:37, Martin Buchholz wrote: > > Let's get in the fix for regression 8163353 quickly: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ > https://bugs.openjdk.java.net/browse/JDK-8163353 +1 Paul. From martinrb at google.com Wed Aug 24 20:11:40 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 24 Aug 2016 13:11:40 -0700 Subject: RFR: 8163353: NPE in ConcurrentHashMap.removeAll() In-Reply-To: References: Message-ID: Thanks all! Pushed. On Wed, Aug 24, 2016 at 1:06 PM, Paul Sandoz wrote: > > > On 24 Aug 2016, at 12:37, Martin Buchholz wrote: > > > > Let's get in the fix for regression 8163353 quickly: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ > > https://bugs.openjdk.java.net/browse/JDK-8163353 > > +1 > > Paul. > From martinrb at google.com Wed Aug 24 21:17:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 24 Aug 2016 14:17:16 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet In-Reply-To: <71132A36-9DD6-45E2-A988-29C6F652E8ED@oracle.com> References: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> <71132A36-9DD6-45E2-A988-29C6F652E8ED@oracle.com> Message-ID: Hi Paul, Thanks for doing this. Probably your IDE is fixing import statements. We'd prefer having that not happen for j.u.c. but we can live with it. Of course, keeping all the variants in sync is errorprone. Below is one case where what you're testing and what your assertions say are out of sync. In such cases I've found it better to simply do: assertTrue(success); assertEquals(x, 1.0d); which is more maintainable. In case of a failure the ever helpful stack trace will let us know what went wrong. @@ -749,9 +749,9 @@ for (int c = 0; c < WEAK_ATTEMPTS && !success; c++) { success = vh.weakCompareAndSetRelease(2.0d, 1.0d); } - assertEquals(success, true, "weakCompareAndSetVolatile double"); + assertEquals(success, true, "weakCompareAndSet double"); double x = (double) vh.get(); - assertEquals(x, 1.0d, "weakCompareAndSetVolatile double"); + assertEquals(x, 1.0d, "weakCompareAndSet double"); } // Compare set and get On Wed, Aug 24, 2016 at 8:45 AM, Paul Sandoz wrote: > Hi, > > Gentle reminder. > > Paul. > > > On 10 Aug 2016, at 17:03, Paul Sandoz wrote: > > > > Hi > > > > Please review: > > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename- > weakCompareAndSetVolatile/webrev/ psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/> > > > > This is a refactoring to produce a consistent naming scheme for the > VarHandle Read Modify Write (RMW) methods. The unqualified methods default > to volatile access. > > > > (And i hope this is the last modifying to the API signatures) > > > > This touches 166 classes that use or refer to the weak plain/volatile > methods. > > > > The plan is to follow up deprecating (*not* for removal) the > weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add > weakCompareAndSetPlain methods. Analysis via grepcode shows very little > usages of the Atomic*.weakCompareAndSet methods. > > > > A further plan is to rename the Unsafe methods s/Swap/Set, add Plain > qualifier etc. > > > > Paul. > > From martinrb at google.com Wed Aug 24 21:23:01 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 24 Aug 2016 14:23:01 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet In-Reply-To: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> References: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> Message-ID: On Wed, Aug 10, 2016 at 5:03 PM, Paul Sandoz wrote: > > This touches 166 classes that use or refer to the weak plain/volatile > methods. > Feel free to commit these. They will eventually break jsr166 CVS but we'll deal with it. From paul.sandoz at oracle.com Wed Aug 24 21:29:51 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 24 Aug 2016 14:29:51 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet In-Reply-To: References: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> <71132A36-9DD6-45E2-A988-29C6F652E8ED@oracle.com> Message-ID: > On 24 Aug 2016, at 14:17, Martin Buchholz wrote: > > Hi Paul, > > Thanks for doing this. > > Probably your IDE is fixing import statements. We'd prefer having that not happen for j.u.c. but we can live with it. > Ah, i will update so as not to perturb that. > Of course, keeping all the variants in sync is errorprone. Below is one case where what you're testing and what your assertions say are out of sync. In such cases I've found it better to simply do: > > assertTrue(success); > assertEquals(x, 1.0d); > > which is more maintainable. In case of a failure the ever helpful stack trace will let us know what went wrong. > Ooops, i will fix that. We have found it useful to output method to more quickly identify what is failing. It?s usually not a lot of work because the source is modified in the test templates, but you are correct in saying it is not so easy to maintain. Thanks for the review. ? It just so happens i am blocked on a x86 byte CAS fix in HotSpot making it?s way into jdk9/dev and on the order of patches in my queue (i could rebase, but that is more work). So it may be a week or two before i commit. Paul. > @@ -749,9 +749,9 @@ > for (int c = 0; c < WEAK_ATTEMPTS && !success; c++) { > success = vh.weakCompareAndSetRelease(2.0d, 1.0d); > } > - assertEquals(success, true, "weakCompareAndSetVolatile double"); > + assertEquals(success, true, "weakCompareAndSet double"); > double x = (double) vh.get(); > - assertEquals(x, 1.0d, "weakCompareAndSetVolatile double"); > + assertEquals(x, 1.0d, "weakCompareAndSet double"); > } > > // Compare set and get > > > On Wed, Aug 24, 2016 at 8:45 AM, Paul Sandoz > wrote: > Hi, > > Gentle reminder. > > Paul. > > > On 10 Aug 2016, at 17:03, Paul Sandoz > wrote: > > > > Hi > > > > Please review: > > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/ > > > > > This is a refactoring to produce a consistent naming scheme for the VarHandle Read Modify Write (RMW) methods. The unqualified methods default to volatile access. > > > > (And i hope this is the last modifying to the API signatures) > > > > This touches 166 classes that use or refer to the weak plain/volatile methods. > > > > The plan is to follow up deprecating (*not* for removal) the weakCompareAndSet methods on j.u.concurrent.atomic.* classes and add weakCompareAndSetPlain methods. Analysis via grepcode shows very little usages of the Atomic*.weakCompareAndSet methods. > > > > A further plan is to rename the Unsafe methods s/Swap/Set, add Plain qualifier etc. > > > > Paul. > > From martinrb at google.com Wed Aug 24 22:48:48 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 24 Aug 2016 15:48:48 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet In-Reply-To: References: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> <71132A36-9DD6-45E2-A988-29C6F652E8ED@oracle.com> Message-ID: Below it seems like weakCompareAndSetVolatile is susceptible to spurious failure as much as other weak cas variants and so should have the same kind of retry loop. { boolean success = false; for (int c = 0; c < WEAK_ATTEMPTS && !success; c++) { success = vh.weakCompareAndSetRelease(array, i, VALUE_1, VALUE_2); } assertEquals(success, true, "weakCompareAndSetRelease $type$"); $type$ x = ($type$) vh.get(array, i); assertEquals(x, VALUE_2, "weakCompareAndSetRelease $type$"); } { boolean r = vh.weakCompareAndSetVolatile(array, i, VALUE_2, VALUE_1); assertEquals(r, true, "weakCompareAndSetVolatile $type$"); $type$ x = ($type$) vh.get(array, i); assertEquals(x, VALUE_1, "weakCompareAndSetVolatile $type$ value"); } From paul.sandoz at oracle.com Wed Aug 24 23:01:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 24 Aug 2016 16:01:56 -0700 Subject: j.l.invoke and the wrapping of exceptions Message-ID: <10703727-709D-4546-B24C-EF2F6A7F4B37@oracle.com> Hi, Recent discussion on the wrapping of exceptions (any Throwable) in LinkageError be it for invokedynamic and BootstrapMethodError (a spec issue) or for signature polymorphic linkage (an implementation detail AFAICT) resulted in a more detailed look at the exception handling in the j.l.invoke code. To partially fix signature polymorphic linkage i have made some small modifications [1] but i found i need to dig deeper as there are many other cases where Throwable is wrapped, specifically with the calls to MethodHandleStatic.newInternalError: /*non-public*/ static InternalError newInternalError(Throwable cause) { return new InternalError(cause); } There is also MethodHandleStatic.uncaughtException /** Propagate unchecked exceptions and errors, but wrap anything checked and throw that instead. */ /*non-public*/ static Error uncaughtException(Throwable ex) { if (ex instanceof Error) throw (Error) ex; if (ex instanceof RuntimeException) throw (RuntimeException) ex; throw newInternalError("uncaught exception", ex); } There may be cases where these are interchangeable, it?s subtle, and i would be away of replacing calls to newInternalError with uncaughtException. I propose the following: 1) change newInternalError(String message, Throwable cause) to newInternalError(String message, Exception cause) We want to be clear that the cause is an Exception, since this method will always return InternalError with a message. 2) replace newInternalError(Throwable cause) with errorOrNewInternalError(Throwable ex) /*non-public*/ static Error errorOrNewInternalError(Throwable ex) { if (ex instanceof Error) return (Error) ex; return newInternalError("uncaught exception", ex); } In all cases existing Errors will never be wrapped. 3) It?s tempting to rename uncaughtException with uncheckedOrNewInternalError. Paul. [1] diff -r 248159c6e61a src/java.base/share/classes/java/lang/invoke/LambdaForm.java --- a/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Wed Aug 24 11:23:58 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Wed Aug 24 15:31:29 2016 -0700 @@ -41,7 +41,6 @@ import static java.lang.invoke.LambdaForm.BasicType.*; import static java.lang.invoke.MethodHandleNatives.Constants.REF_invokeStatic; import static java.lang.invoke.MethodHandleStatics.*; -import java.util.Objects; /** * The symbolic, non-executable form of a method handle's invocation semantics. @@ -856,7 +855,7 @@ System.out.println("LambdaForm compilation failed: " + this); bge.printStackTrace(System.out); } - } catch (Error | Exception e) { + } catch (Exception e) { throw newInternalError(this.toString(), e); } } diff -r 248159c6e61a src/java.base/share/classes/java/lang/invoke/MethodHandle.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Wed Aug 24 11:23:58 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Wed Aug 24 15:31:29 2016 -0700 @@ -957,7 +957,7 @@ if (!fail) return needType; // elicit an error: this.asType(needType); - throw newInternalError("should not return", null); + throw newInternalError("should not return"); } private void spreadArrayChecks(Class arrayType, int arrayLength) { diff -r 248159c6e61a src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Wed Aug 24 11:23:58 2016 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Wed Aug 24 15:31:29 2016 -0700 @@ -380,8 +380,11 @@ } } } catch (Throwable ex) { - if (ex instanceof LinkageError) - throw (LinkageError) ex; + // Pass through all instances of Error, thus ensuring errors such as + // ThreadDeath, StackOverflowException, OutOfMemoryException etc. + // are not wrapped + if (ex instanceof Error) + throw (Error) ex; else throw new LinkageError(ex.getMessage(), ex); From paul.sandoz at oracle.com Wed Aug 24 23:12:31 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 24 Aug 2016 16:12:31 -0700 Subject: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet In-Reply-To: References: <8095E155-79CC-4788-9209-DE3FF249BE32@oracle.com> <71132A36-9DD6-45E2-A988-29C6F652E8ED@oracle.com> Message-ID: <80BCCD8A-307E-433C-A248-AA76DCB191EC@oracle.com> > On 24 Aug 2016, at 15:48, Martin Buchholz wrote: > > Below it seems like weakCompareAndSetVolatile is susceptible to spurious failure as much as other weak cas variants and so should have the same kind of retry loop. > > { > boolean success = false; > for (int c = 0; c < WEAK_ATTEMPTS && !success; c++) { > success = vh.weakCompareAndSetRelease(array, i, VALUE_1, VALUE_2); > } > assertEquals(success, true, "weakCompareAndSetRelease $type$"); > $type$ x = ($type$) vh.get(array, i); > assertEquals(x, VALUE_2, "weakCompareAndSetRelease $type$"); > } > > { > boolean r = vh.weakCompareAndSetVolatile(array, i, VALUE_2, VALUE_1); > assertEquals(r, true, "weakCompareAndSetVolatile $type$"); > $type$ x = ($type$) vh.get(array, i); > assertEquals(x, VALUE_1, "weakCompareAndSetVolatile $type$ value"); > } Thanks, i will update, Paul. From david.holmes at oracle.com Thu Aug 25 01:26:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Aug 2016 11:26:19 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> Message-ID: <20bd401f-24d7-ff5e-9154-7222b65c398b@oracle.com> Hi Kim, Sorry this fell off the radar ... On 24/08/2016 7:09 AM, Kim Barrett wrote: > Mandy asked for some additional comments to make life easier for > future readers. I've also stopped pretending the description for > waitForReferenceProcessing is javadoc, since this function is private > and only accessible via SharedSecrets or reflection that avoids access > control. > > Changes only in the jdk tree: > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ Just to be clear, in waitForReferenceProcessing() you are okay with returning true on spurious wakeup? > Unchanged hotspot webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ No further comments from me. Thanks, David From mandy.chung at oracle.com Thu Aug 25 02:17:23 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Aug 2016 19:17:23 -0700 Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect In-Reply-To: <4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com> References: <57B4C392.4060001@oracle.com> <4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com> <4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com> Message-ID: <06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com> John, This is useful, thanks. Probably more questions will follow after doing more homework. Mandy > On Aug 24, 2016, at 10:07 AM, John Rose wrote: > > On Aug 22, 2016, at 9:30 PM, Mandy Chung wrote: >> >> We need to follow up this issue to understand what the interpreter and compiler do for this unused slot and whether it?s always zero out. > > These slot pairs are a curse, in the same league as endian-ness. > > Suppose a 64-bit long x lives in L[0] and L[1]. Now suppose > that the interpreter (as well it might) has adjacent 32-bit words > for those locals. There are four reasonable conventions for > apportioning the bits of x into L[0:1]. Call HI(x) the arithmetically > high part of x, and LO(x) the other part. Also, call FST(x) the > lower-addressed 32-bit component of x, when stored in memory, > and SND(x) the other part. Depending on your machine's > endian-ness, HI=FST or HI=SND (little-endian, x86). > For portable code there are obviously four ways to pack L[0:1]. > I've personally seen them all, sometimes as hard-to-find VM bugs. > > We're just getting started, though. Now let the interpreter generously > allocate 64 bits to each local. The above four cases are still possible, > but now we have 4 32-bit storage units to play with. That makes > (if you do the math) 4x3=12 more theoretically possible ways to > store the bits of x into the 128 bits of L[0:1]. I've not seen all 12, > but there are several variations that HotSpot has used over time. > > Confused yet? There's more: All current HotSpot implementations > grow the stack downward, which means that the address of L[0] > is *higher* than L[1]. This means that the pair of storage units > for L[0:1] can be viewed as a memory buffer, but the bits of L[1] > come at a lower address. (Once we had a tagged-stack interpreter > in which there were extra tag words between the words of L[0] > and L[1], for extra fun. We got tired of that.) > > There's one more annoyance: The memory block located at L[0:1] > must be at least 64 bits wide, but it need not be 64-bit aligned, > if the size of a local slot is 32 bits. So on machines that cannot > perform unaligned 64-bit access, the interpreter needs to load > and store 64-bit values as 32-bit halves. But we can put that > aside for now; that's a separable cost borne by 32-bit RISCs. > > How do we simplify this? For one thing, view all reference > to HI and LO with extreme suspicion. That goes for misleadingly > simple terms like "the low half of x". On Intel everybody > knows that's also FST (the first memory word of x), and > nods in agreement, and then when you port to SPARC > (that was my job) the nods turn into glassy-eyed stares. > > Next, don't trust L[0] and L[1] to work like array elements. > Although the bytecode interpreter refers directly to L[0] > and indirectly to L[1], when storing 'x', realize that you > don't know exactly how those guys are laid out in memory. > The interpreter will make some local decision to avoid > the obvious-in-retrospect bug of storing 64-bits to L[0] > on a 32-bit machine. The decision might be to form the > address of L[1] and treat *that* as the base address of > a memory block. The more subtle and principled thing > to do would be to form the address of the *end* of L[0] > and treat that as the *end* address of a memory block. > The two approaches are equivalent on 32-bit machine, > but on a 64-bit machine one puts the payload only > in L[1] and one only in L[0]. > > Meanwhile, the JIT, with its free-wheeling approach > to storage allocation, will probably try its best to ignore > and forget stupid L[1], allocating a right-sized register > or stack slot for L[0]. > > Thus interpreter and JIT can have independent internal > conventions for how they assign storage units to L[0:1] and > how they use those units to store a 64-bit value. Those > independent schemes have to be reconciled along mode > change paths: C2I and I2C adapters, deoptimization, and > on-stack replacement (= reoptimization). > > The vframe_hp code does this. A strong global convention > would be best, such as always using L[0] and always storing > all of x in L[0] if it fits, else SND(x) in L[0] and FST(x) in L[1]. > I'm not sure (and I doubt) that we are actually that clean. > > Any reasonable high-level API for dealing with this stuff > will do like the JIT does, and pretend that, whatever the > size of L[0] is physically, it contains the whole value assigned > to it, without any need to inspect L[1]. That's the best policy > for virtualizing stack frames, because it aligns with the > plain meaning of bytecodes like "lload0", which don't mention > L[1]. The role of L[1] is to provide "slop space" for internal > storage in a tiny interpreter; it has no external role. The > convention used in HotSpot and the JVM verifier is to > assign a special type to L[1], "Top" which means "do not > look at me; I contain no bits". A virtualized API which > produces a view on such an L[1] needs to return some > default value (if pressed), and to indicate that the slot > has no payload. > > HTH > > ? John > > P.S. If all goes well with Valhalla, we will probably get > rid of slot pairs altogether in a future version of the JVM > bytecodes. They spoil generics over longs and doubles. > The 32-bit implementations of JVM interpreters will have > to do extra work, such as have 64-bit slot sizes for methods > that work with longs or doubles, but it's worth it. > From weijun.wang at oracle.com Thu Aug 25 03:55:10 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Aug 2016 11:55:10 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission Message-ID: Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginning of JDK, FilePermission canonicalizes the input path and use the result in implies() and equals(). This has been a big performance hurt and leads to confusing results when symlinks are involved. The code change above removes the canonicalization. This means FilePermission on "/the/current/working/directory/x" no longer implies that on "x". Since this might bring quite some compatibility risk, the code change includes some tweaks in permission checking to make sure an app is still able to read "x" when the FilePermission granted is on "/the/current/working/directory/x". However, we still hope the policy to be updated to be consistent of how a file is actually accessed. No tweak is devoted to make granting "/this/is/a/symlink" to imply reading of "/the/actual/target/file", because we think it should not. This is quite a big behavior change. If it breaks your app/lib, or does not work with your customized security manager or policy implementation, please let us know. Feel free to provide any feedback. Finally, a new system property "jdk.filepermission.canonicalize" is introduced and it can be "true", "false", or "compat". The out-of-box default is "compat", which means no canonicalization with check tweaks. Thanks Max From kim.barrett at oracle.com Thu Aug 25 05:54:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 25 Aug 2016 01:54:40 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <20bd401f-24d7-ff5e-9154-7222b65c398b@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <5e294ee2-15dc-beba-8a6b-d6239bfac9e4@oracle.com> <13E6ED4A-40F6-49B0-A05C-11DFF328601C@oracle.com> <27B31235-82E7-437C-AD59-4E7B8B345ACF@oracle.com> <60E204E0-CD9E-4830-B40C-DF4D47FB5192@oracle.com> <1264A156-E185-4D0E-BEAB-DF9716D95ACD@oracle.com> <20bd401f-24d7-ff5e-9154-7222b65c398b@oracle.com> Message-ID: <61D3A7F8-F739-4E68-A838-B574A97D1995@oracle.com> > On Aug 24, 2016, at 9:26 PM, David Holmes wrote: > > Hi Kim, > > Sorry this fell off the radar ? That?s okay. There was a long gap while I was working on other things. > On 24/08/2016 7:09 AM, Kim Barrett wrote: >> Mandy asked for some additional comments to make life easier for >> future readers. I've also stopped pretending the description for >> waitForReferenceProcessing is javadoc, since this function is private >> and only accessible via SharedSecrets or reflection that avoids access >> control. >> >> Changes only in the jdk tree: >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ > > Just to be clear, in waitForReferenceProcessing() you are okay with returning true on spurious wakeup? Yes. >> Unchanged hotspot webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04.inc/ > > No further comments from me. > > Thanks, > David From david.simms at oracle.com Thu Aug 25 10:05:22 2016 From: david.simms at oracle.com (David Simms) Date: Thu, 25 Aug 2016 12:05:22 +0200 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> Message-ID: <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> Updated the webrev here: http://cr.openjdk.java.net/~dsimms/8164086/webrev1/ core-libs & Kumar: java launcher: are you okay with the CHECK_EXCEPTION_PRINT macro, or would you rather it was silent (i.e. CHECK_EXCEPTION_RETURN) ? In-line... On 23/08/16 14:16, David Holmes wrote: > Hi David > > On 23/08/2016 8:24 PM, David Simms wrote: >> >> Reply in-line... >> >> On 19/08/16 14:29, David Holmes wrote: >>> Hi David, >>> >>> >>> The changes in the native wrapper seem okay though I'm not an expert >>> on the machine specific encodings. >>> >>> I'm a little surprised there are not more things that need changing >>> though. Does the JIT use those wrappers too? >> >> Yeah they do, I double checked Nils from compiler group. I also tested >> with -Xcomp, test failed without sharedRuntime fix. The test execution >> time was over 10 seconds, so I removed it from the jtreg test itself >> (hard-coded ProcessTools.executeTestJVM()) since it is part of >> "hotspot_fast_runtime". >> >>> Can we transition from Java to VM to native and then back - and if so >>> might we need to clear the pending exception check? (I'm not sure if >>> from in the VM a native call could actually be a JNI call, or will >>> only be a direct native call?). >> >> At first I thought JavaCallWrapper needs it, following all the places we >> manipulate the thread's active handle block (besides manual push/pop). >> But then call helper just ends up calling the native wrapper, which >> takes care of it. Not a direct native call. So I left it, as-is. > > That's not the case I was thinking of. We have ThreadToNativeFromVM > and then we do native stuff - if any of that were JNI-based (perhaps > it is not) then we would enable the check but not disable it again > when returning from VM to Java. > Got you now: Java->VM->Native i.e. VM code using JNI may miss an exception check. So I check the call hierarchy from "ThreadToNativeFromVM" and found whitebox.cpp had a few spots where checks were missing, added them in now. There's an extra comment stating ThreadToNativeFromVM is expected to be "well behaved" (i.e. check for exceptions), which it is with the whitebox.cpp fixes, so we don't require any extra code or overhead in VM->Java transitions. As far as maintaining "well behaved" JNI code, we do static code checking with "Parfait" as part of testing, and there are a few other related bugs that already exist to address these issues. >>> >>> Did you intend to leave in the changes to >>> jdk/src/java.base/share/native/libjli/java.c? It looks like debug/test >>> code to me. >> >> The launcher produces warnings (Java method invokes) that break the >> jtreg test, so yeah, thought it was best to check and print them. Some >> of the existing code checks and silently returns, I followed the same >> pattern where that pattern was in place. > > This needs to be looked at closer then and reviewed by the launcher > folk (ie Kumar). CC:ed core-libs & Kumar. Thanks for pointing that out. > >>> >>> The test I'm finding a bit hard to follow but don't you need to check >>> for pending exceptions here: >>> >>> 29 static jmethodID get_method_id(JNIEnv *env, jclass clz, jstring >>> jname, jstring jsig) { >>> 30 jmethodID mid; >>> 31 const char *name, *sig; >>> 32 name = (*env)->GetStringUTFChars(env, jname, NULL); >>> 33 sig = (*env)->GetStringUTFChars(env, jsig, NULL); >>> 34 mid = (*env)->GetMethodID(env, clz, name, sig); >>> >>> to avoid triggering the warning? >>> >> Those methods don't require an explicit check since there return values >> denote an error condition. >> >> Whilst Java invoke return values are user defined, so they do need >> it >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#asynchronous_exceptions). >> >> Technically array stores need to check for AIOOBE, but given most >> code handles index/bounds checks, it seemed way too pedantic >> (commented in jniCheck.cpp:176). > > Not following. GetStringUTFChars can post OOME so we would enable the > check-flag if that happens on the first call above, then the second > call would be made with the exception pending and trigger the warning. So as we mentioned off-list, yes this test code should also follow spec, updated. Thanks for looking at this, David /David Simms From vladimir.x.ivanov at oracle.com Thu Aug 25 10:30:52 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Aug 2016 13:30:52 +0300 Subject: RFR: 8164739: Remove computation of predefined interpreter forms In-Reply-To: <57BDCFF8.8080203@oracle.com> References: <57BDCFF8.8080203@oracle.com> Message-ID: <27528f02-5fee-1103-08ce-4e366cd8f3de@oracle.com> Looks good. Best regards, Vladimir Ivanov On 8/24/16 7:48 PM, Claes Redestad wrote: > Hi, > > LambdaForm predefines a number of forms for the benefit of the LF and > NF interpreters, which doesn't appear useful at all at this point. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8164739 > Webrev: http://cr.openjdk.java.net/~redestad/8164739/webrev.01/ > > Testing: all java/lang/invoke tests with various values for > -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD to run with and > without LF interpretation. > > Removing this code improves on previous work to improve indy > bootstrap to the point where the indy bootstrap happens in a few > milliseconds, only loads 21 extra classes. On full program execution > there's no discernible time difference between the regular and the > MH variant. > > Thanks! > > /Claes From claes.redestad at oracle.com Thu Aug 25 11:38:04 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 25 Aug 2016 13:38:04 +0200 Subject: RFR: 8164739: Remove computation of predefined interpreter forms In-Reply-To: <27528f02-5fee-1103-08ce-4e366cd8f3de@oracle.com> References: <57BDCFF8.8080203@oracle.com> <27528f02-5fee-1103-08ce-4e366cd8f3de@oracle.com> Message-ID: <57BED89C.1080907@oracle.com> On 2016-08-25 12:30, Vladimir Ivanov wrote: > Looks good. Thanks! Pushed. /Claes > > Best regards, > Vladimir Ivanov > > On 8/24/16 7:48 PM, Claes Redestad wrote: >> Hi, >> >> LambdaForm predefines a number of forms for the benefit of the LF and >> NF interpreters, which doesn't appear useful at all at this point. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8164739 >> Webrev: http://cr.openjdk.java.net/~redestad/8164739/webrev.01/ >> >> Testing: all java/lang/invoke tests with various values for >> -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD to run with and >> without LF interpretation. >> >> Removing this code improves on previous work to improve indy >> bootstrap to the point where the indy bootstrap happens in a few >> milliseconds, only loads 21 extra classes. On full program execution >> there's no discernible time difference between the regular and the >> MH variant. >> >> Thanks! >> >> /Claes From aleksej.efimov at oracle.com Thu Aug 25 12:33:32 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 25 Aug 2016 15:33:32 +0300 Subject: RFR (JAXB): 8159240: XSOM parser incorrectly processes type names with whitespaces Message-ID: <8ceba21b-dd0c-6caf-1f3d-f4c3811929a0@oracle.com> Hello, Please, help to review the JDK9 changes in JAXB XSOM parser that solves issue [0] with incorrectly collapsed namespaces within schema types names definitions/usages: http://cr.openjdk.java.net/~aefimov/8159240/9/00/ Problem description: The XMLSchema defines that whitespaces should be collapsed for type names and different attribute values that can contain type names. Examples are: - 'name' attribute value for 'xsd:simpleType', 'xsd:complexType', 'xsd:attribute' - 'type' attribute value for 'xsd:attribute' - 'base' attribute value for 'xsd:restriction' Almost all type values for such attributes are inherited from NCName or QName schema types. Both types are defined with whiteSpace restriction set to "collapse" [1]. The XSOM parser state machine was reversed engineered and all NCName and QName typed values are now collapsed to match the schema definitions. New regression test was executed alongside to JTREG and JCK tests - no failures. With Best Regards, Aleksej [0] https://bugs.openjdk.java.net/browse/JDK-8159240 [1] https://www.w3.org/2001/XMLSchema.xsd [2] XSOM parser page: https://xsom.java.net/ From john.r.rose at oracle.com Thu Aug 25 20:36:50 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 25 Aug 2016 13:36:50 -0700 Subject: RFR: 8164739: Remove computation of predefined interpreter forms In-Reply-To: <57BED89C.1080907@oracle.com> References: <57BDCFF8.8080203@oracle.com> <27528f02-5fee-1103-08ce-4e366cd8f3de@oracle.com> <57BED89C.1080907@oracle.com> Message-ID: <21EA4C01-75FF-473D-9C7D-E62E4C7AEAB0@oracle.com> CDE (Code Deletion Engineering) at its finest! On Aug 25, 2016, at 4:38 AM, Claes Redestad wrote: > On 2016-08-25 12:30, Vladimir Ivanov wrote: >> Looks good. > > Thanks! Pushed. > > /Claes > >> >> Best regards, >> Vladimir Ivanov From paul.sandoz at oracle.com Thu Aug 25 20:48:10 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 25 Aug 2016 13:48:10 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain Message-ID: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164814--atomics-weakCompareAndSet-deprecate/webrev/ This patch deprecates weakCompareAndSet and adds a new method weakCompareAndSetPlain. The intent is to avoid confusion over the memory effects of such methods, since other read-modify-write methods, with unqualified names, have volatile memory effects. I just modified atomic classes that have already been updated for Java 9 [*]. Paul. [*] atomic classes not updated: AtomicIntegerFieldUpdater AtomicLongFieldUpdater AtomicMarkableReference AtomicReferenceFieldUpdater AtomicStampedReference From steve.drach at oracle.com Thu Aug 25 23:30:31 2016 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 25 Aug 2016 16:30:31 -0700 Subject: RFR 8163798: Add a versionedStream method to JarFile Message-ID: Hi, Please review this changeset that adds a versionedStream method to JarFile. webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8163798 Thanks Steve From david.holmes at oracle.com Fri Aug 26 00:27:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Aug 2016 10:27:31 +1000 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> Message-ID: <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> Hi David, I'm missing some pieces of this puzzle I'm afraid. On 25/08/2016 8:05 PM, David Simms wrote: > > Updated the webrev here: > http://cr.openjdk.java.net/~dsimms/8164086/webrev1/ hotspot/src/share/vm/prims/whitebox.cpp First I'm not sure that Whitebox isn't a special case here that could be handled in the WB_START/END macros - see below. More generally you state below that the transition from native back to the VM doesn't have to do anything with the pending_exception_check flag because well behaved native code in that context will explicitly check for exceptions, and so the pending-exception-check will already be disabled before returning to Java. First, if that is the case then we should assert that it is so in the native->VM return transition. Second though, it doesn't seem to be the case in Whitebox because the CHECK_JNI_EXCEPTION_ macro simply calls HAS_PENDING_EXCEPTION and so won't touch the pending-exception-check flag. ?? It was a good pick up that some whitebox code was using values that might be NULL because an exception had occurred. There are a couple of changes that are unnecessary though: 1235 result = env->NewObjectArray(5, clazz, NULL); 1236 CHECK_JNI_EXCEPTION_(env, NULL); 1237 if (result == NULL) { 1238 return result; 1239 } (and similarly at 1322) result will be NULL iff there is a pending exception; and vice-versa. So the existing check for NULL suffices for correctness. If you want to check exceptions for the side-effect of clearing the pending-exception-check flag then lines 1237-1239 can be deleted. However I would suggest that if you truly do want to clear the pending-exception-check flag then the place to do it is the WB_END macro. That allows allows exception checks at the end of methods, eg: 1261 env->SetObjectArrayElement(result, 4, entry_point); 1262 CHECK_JNI_EXCEPTION_(env, NULL); 1263 1264 return result; to be elided. --- hotspot/src/share/vm/runtime/thread.hpp ! // which function name. Returning to a Java frame should implicitly clear the ! // need for, this is done for Native->Java transitions. Seems to be some text missing after "need for". --- For the tests we no longer use bug numbers as part of the test names. Looks like some recent tests slipped by unfortunately. :( You should be able to get rid of the: * @modules java.base/jdk.internal.misc with Christian's just pushed changes to ProcessTools to isolate the Unsafe dependency. > core-libs & Kumar: java launcher: are you okay with the > CHECK_EXCEPTION_PRINT macro, or would you rather it was silent (i.e. > CHECK_EXCEPTION_RETURN) ? I'm not seeing the point of this logic. Any exceptions that remain pending when the main thread detaches from the VM will be reported by the uncaught-exception handling logic. The checks you put in are in most cases immediately before a return so there is no need to check for a pending exception and do an earlier return. And in one case you would bypass tracing logic by doing an early return. I had assumed this was just some debugging code you had left in by mistake. Thanks, David H. ------- > In-line... > > > On 23/08/16 14:16, David Holmes wrote: >> Hi David >> >> On 23/08/2016 8:24 PM, David Simms wrote: >>> >>> Reply in-line... >>> >>> On 19/08/16 14:29, David Holmes wrote: >>>> Hi David, >>>> >>>> >>>> The changes in the native wrapper seem okay though I'm not an expert >>>> on the machine specific encodings. >>>> >>>> I'm a little surprised there are not more things that need changing >>>> though. Does the JIT use those wrappers too? >>> >>> Yeah they do, I double checked Nils from compiler group. I also tested >>> with -Xcomp, test failed without sharedRuntime fix. The test execution >>> time was over 10 seconds, so I removed it from the jtreg test itself >>> (hard-coded ProcessTools.executeTestJVM()) since it is part of >>> "hotspot_fast_runtime". >>> >>>> Can we transition from Java to VM to native and then back - and if so >>>> might we need to clear the pending exception check? (I'm not sure if >>>> from in the VM a native call could actually be a JNI call, or will >>>> only be a direct native call?). >>> >>> At first I thought JavaCallWrapper needs it, following all the places we >>> manipulate the thread's active handle block (besides manual push/pop). >>> But then call helper just ends up calling the native wrapper, which >>> takes care of it. Not a direct native call. So I left it, as-is. >> >> That's not the case I was thinking of. We have ThreadToNativeFromVM >> and then we do native stuff - if any of that were JNI-based (perhaps >> it is not) then we would enable the check but not disable it again >> when returning from VM to Java. >> > > > Got you now: Java->VM->Native i.e. VM code using JNI may miss an > exception check. So I check the call hierarchy from > "ThreadToNativeFromVM" and found whitebox.cpp had a few spots where > checks were missing, added them in now. > > There's an extra comment stating ThreadToNativeFromVM is expected to be > "well behaved" (i.e. check for exceptions), which it is with the > whitebox.cpp fixes, so we don't require any extra code or overhead in > VM->Java transitions. As far as maintaining "well behaved" JNI code, we > do static code checking with "Parfait" as part of testing, and there are > a few other related bugs that already exist to address these issues. > >>>> >>>> Did you intend to leave in the changes to >>>> jdk/src/java.base/share/native/libjli/java.c? It looks like debug/test >>>> code to me. >>> >>> The launcher produces warnings (Java method invokes) that break the >>> jtreg test, so yeah, thought it was best to check and print them. Some >>> of the existing code checks and silently returns, I followed the same >>> pattern where that pattern was in place. >> >> This needs to be looked at closer then and reviewed by the launcher >> folk (ie Kumar). > > CC:ed core-libs & Kumar. Thanks for pointing that out. > >> >>>> >>>> The test I'm finding a bit hard to follow but don't you need to check >>>> for pending exceptions here: >>>> >>>> 29 static jmethodID get_method_id(JNIEnv *env, jclass clz, jstring >>>> jname, jstring jsig) { >>>> 30 jmethodID mid; >>>> 31 const char *name, *sig; >>>> 32 name = (*env)->GetStringUTFChars(env, jname, NULL); >>>> 33 sig = (*env)->GetStringUTFChars(env, jsig, NULL); >>>> 34 mid = (*env)->GetMethodID(env, clz, name, sig); >>>> >>>> to avoid triggering the warning? >>>> >>> Those methods don't require an explicit check since there return values >>> denote an error condition. >>> >>> Whilst Java invoke return values are user defined, so they do need >>> it >>> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html#asynchronous_exceptions). >>> >>> >>> Technically array stores need to check for AIOOBE, but given most >>> code handles index/bounds checks, it seemed way too pedantic >>> (commented in jniCheck.cpp:176). >> >> Not following. GetStringUTFChars can post OOME so we would enable the >> check-flag if that happens on the first call above, then the second >> call would be made with the exception pending and trigger the warning. > > So as we mentioned off-list, yes this test code should also follow spec, > updated. > > Thanks for looking at this, David > /David Simms > From amaembo at gmail.com Fri Aug 26 05:16:46 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 26 Aug 2016 08:16:46 +0300 Subject: RFR 8163798: Add a versionedStream method to JarFile In-Reply-To: References: Message-ID: Hello! Small nitpick: versionsMap.keySet().forEach(v -> { Stream names = versionsMap.get(v).stream().map(nm -> nm.name); if (v == versionMajor) { // add all entries of the version we are interested in finalNames.addAll(names.collect(Collectors.toSet())); } else { // add resource entries found in lower versioned directories finalNames.addAll(names.filter(nm -> nm.endsWith(".class") ? false : true) .collect(Collectors.toSet())); } }); I suggest to replace with versionsMap.forEach((v, list) -> { Stream names = list.stream().map(nm -> nm.name); if (v != versionMajor) { names = names.filter(nm -> !nm.endsWith(".class")); } names.forEach(finalNames::add); }); This is cleaner and somewhat faster to use Map.forEach as you don't need to lookup every map entry. Also I don't see why "nm -> nm.endsWith(".class") ? false : true" could be better than "nm -> !nm.endsWith(".class")". Probably a matter of style though. Finally there's no need to collect into intermediate set just to add this set into finalNames. Instead you can drain the stream directly to finalNames via forEach. Probably it should be explicitly noted in spec that the resulting stream is unordered (or at least may be unordered) as it's created from the Set. With best regards, Tagir Valeev On Fri, Aug 26, 2016 at 2:30 AM, Steve Drach wrote: > Hi, > > Please review this changeset that adds a versionedStream method to JarFile. > > webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ < > http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/> > issue: https://bugs.openjdk.java.net/browse/JDK-8163798 < > https://bugs.openjdk.java.net/browse/JDK-8163798> > > Thanks > Steve > > > From andrej.golovnin at gmail.com Fri Aug 26 06:05:37 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 26 Aug 2016 08:05:37 +0200 Subject: RFR 8163798: Add a versionedStream method to JarFile In-Reply-To: References: Message-ID: Hi Steve, in the line 597 Map> versionsMap = stream() I miss space after the comma. In the line 626 return finalNames.stream().map(nm -> getJarEntry(nm)); You can use a method reference instead of lambda: 626 return finalNames.stream().map(this::getJarEntry); And if you add a method #getName() to the Name class, then you can use method references in the lines 604 and 614 too. +1 to Tagir's suggestions. Best regards, Andrej Golovnin From peter.levart at gmail.com Fri Aug 26 08:45:48 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 26 Aug 2016 10:45:48 +0200 Subject: RFR 8163798: Add a versionedStream method to JarFile In-Reply-To: References: Message-ID: Hi Steve, Here are my observations. I haven't followed the development of multi-release jar files very closely, so I might be missing some quirks, but I speak here from the knowledge I get from the javadocs... Javadoc for the new method mentions public and non-public classes: "@{code JarEntries} * containing non-public classes in the * versioned directory that corresponds to the version returned by * {@link JarFile#getVersion()} are included in the stream because they are * typically accessed by the public classes." Why? The logic of multi-release jar files is indifferent towards the access attributes of class files. It never parses the class file to interpret the access attributes of the containing class. The class-level javadoc of JarFile does mention "public classes", but I view this just as a recommendation how they should be constructed. The logic of multi-release jar files is indifferent towards the types of resources contained in the jar entries too, as far as I can see. Your logic in versionedStream() is not. The proposed new method is the only place in JarFile and ZipFile where the check for ".class" suffix of the entry name is performed. Why this special treatement of class files? I also don't understand why the versioned stream should contain the untranslated base versioned directories. For example, the following entries for the v10 stream in the test: "META-INF/versions/9/" "META-INF/versions/10/" All other resources and sub-directories in the META-INF/versions/XX/... directories are "normalized" (meaning that the versioned prefix is stripped from the names in the returned entries). Normalizing above directories would translate them to "root" directory, which is never included as an entry of a normal jar or zip file. So I think they could simply be skipped in the resulting versioned stream. Couldn't they? Considering all of the above, I think versionedStream() method could be much simpler. For example, something like the following: public Stream versionedStream() { return !isMultiRelease() ? stream() : stream() .flatMap(je -> { String name = je.getName(); if (name.startsWith(META_INF_VERSIONS)) { // versioned entry if (name.length() > META_INF_VERSIONS.length()) { // potentially real entry String vStr = name.substring(META_INF_VERSIONS.length()); int offset = vStr.indexOf('/'); int version = 0; if (offset >= 0) try { version = Integer.parseInt(vStr.substring(0, offset)); } catch (NumberFormatException e) { /* ignore */ } if (version <= 0) { throw new RuntimeException( "Can't obtain version from multi-release jar entry: " + name); } return (version <= versionMajor && vStr.length() > offset + 1) // normalized name of real entry ? Stream.of(vStr.substring(offset + 1)) // version > versionMajor or // META-INF/versions// dir - ignored : Stream.empty(); } else { // META-INF/versions/ dir - ignored return Stream.empty(); } } else { // base entry return Stream.of(name); } }) .distinct() .map(this::getJarEntry); } What do you think? Regards, Peter On 08/26/2016 07:16 AM, Tagir Valeev wrote: > Hello! > > Small nitpick: > > versionsMap.keySet().forEach(v -> { > Stream names = versionsMap.get(v).stream().map(nm -> nm.name); > if (v == versionMajor) { > // add all entries of the version we are interested in > finalNames.addAll(names.collect(Collectors.toSet())); > } else { > // add resource entries found in lower versioned directories > finalNames.addAll(names.filter(nm -> nm.endsWith(".class") ? false > : true) > .collect(Collectors.toSet())); > } > }); > > I suggest to replace with > > versionsMap.forEach((v, list) -> { > Stream names = list.stream().map(nm -> nm.name); > if (v != versionMajor) { > names = names.filter(nm -> !nm.endsWith(".class")); > } > names.forEach(finalNames::add); > }); > > This is cleaner and somewhat faster to use Map.forEach as you don't need to > lookup every map entry. > > Also I don't see why "nm -> nm.endsWith(".class") ? false : true" could be > better than > "nm -> !nm.endsWith(".class")". Probably a matter of style though. > > Finally there's no need to collect into intermediate set just to add this > set into finalNames. > Instead you can drain the stream directly to finalNames via forEach. > > Probably it should be explicitly noted in spec that the resulting stream is > unordered (or at least may > be unordered) as it's created from the Set. > > With best regards, > Tagir Valeev > > On Fri, Aug 26, 2016 at 2:30 AM, Steve Drach wrote: > >> Hi, >> >> Please review this changeset that adds a versionedStream method to JarFile. >> >> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ < >> http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/> >> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 < >> https://bugs.openjdk.java.net/browse/JDK-8163798> >> >> Thanks >> Steve >> >> >> From david.simms at oracle.com Fri Aug 26 11:55:48 2016 From: david.simms at oracle.com (David Simms) Date: Fri, 26 Aug 2016 13:55:48 +0200 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> Message-ID: <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> Hi David, Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev2/ On 26/08/16 02:27, David Holmes wrote: > Hi David, > > I'm missing some pieces of this puzzle I'm afraid. > > On 25/08/2016 8:05 PM, David Simms wrote: >> >> Updated the webrev here: >> http://cr.openjdk.java.net/~dsimms/8164086/webrev1/ > > hotspot/src/share/vm/prims/whitebox.cpp > > First I'm not sure that Whitebox isn't a special case here that could > be handled in the WB_START/END macros - see below. > > More generally you state below that the transition from native back to > the VM doesn't have to do anything with the pending_exception_check > flag because well behaved native code in that context will explicitly > check for exceptions, and so the pending-exception-check will already > be disabled before returning to Java. First, if that is the case then > we should assert that it is so in the native->VM return transition. Agreed, inserted assert. > > Second though, it doesn't seem to be the case in Whitebox because the > CHECK_JNI_EXCEPTION_ macro simply calls HAS_PENDING_EXCEPTION and so > won't touch the pending-exception-check flag. ?? Doh, you are correct...I mistook this for the CHECK_JNI_EXCEPTION macro in "java.c" which does perform check... > > It was a good pick up that some whitebox code was using values that > might be NULL because an exception had occurred. There are a couple of > changes that are unnecessary though: > > 1235 result = env->NewObjectArray(5, clazz, NULL); > 1236 CHECK_JNI_EXCEPTION_(env, NULL); > 1237 if (result == NULL) { > 1238 return result; > 1239 } > > (and similarly at 1322) > > result will be NULL iff there is a pending exception; and vice-versa. > So the existing check for NULL suffices for correctness. If you want > to check exceptions for the side-effect of clearing the > pending-exception-check flag then lines 1237-1239 can be deleted. > However I would suggest that if you truly do want to clear the > pending-exception-check flag then the place to do it is the WB_END > macro. That allows allows exception checks at the end of methods, eg: > > 1261 env->SetObjectArrayElement(result, 4, entry_point); > 1262 CHECK_JNI_EXCEPTION_(env, NULL); > 1263 > 1264 return result; > > to be elided. > Agreed, introduce StackObj with appropriate destructor, removed the checks above. > --- > > hotspot/src/share/vm/runtime/thread.hpp > > ! // which function name. Returning to a Java frame should > implicitly clear the > ! // need for, this is done for Native->Java transitions. > > Seems to be some text missing after "need for". Thanks for seeing that, fixed. > > --- > > For the tests we no longer use bug numbers as part of the test names. > Looks like some recent tests slipped by unfortunately. :( > Moved to "test/runtime/jni/checked" > You should be able to get rid of the: > > * @modules java.base/jdk.internal.misc > > with Christian's just pushed changes to ProcessTools to isolate the > Unsafe dependency. > Done >> core-libs & Kumar: java launcher: are you okay with the >> CHECK_EXCEPTION_PRINT macro, or would you rather it was silent (i.e. >> CHECK_EXCEPTION_RETURN) ? > > I'm not seeing the point of this logic. Any exceptions that remain > pending when the main thread detaches from the VM will be reported by > the uncaught-exception handling logic. The checks you put in are in > most cases immediately before a return so there is no need to check > for a pending exception and do an earlier return. And in one case you > would bypass tracing logic by doing an early return. Removed all the extra checks, add JNI exception check to within the existing CHECK_NULL0 macro (make more sense there). > > I had assumed this was just some debugging code you had left in by > mistake. The method invocations needed to find main class needs to check for the test to pass. Cheers /David From Alan.Bateman at oracle.com Fri Aug 26 12:50:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Aug 2016 13:50:55 +0100 Subject: RFR 8163798: Add a versionedStream method to JarFile In-Reply-To: References: Message-ID: <2e0d20dd-82e9-fbe2-ad00-43f2a97bb6bf@oracle.com> On 26/08/2016 00:30, Steve Drach wrote: > Hi, > > Please review this changeset that adds a versionedStream method to JarFile. > > webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ > issue: https://bugs.openjdk.java.net/browse/JDK-8163798 > I see Peter and others are commenting on the implementation so I'll focus on the javadoc for now. In general then I think the javadoc will need a bit of work as I don't think it's clear to the reader what is returned. It might help to include a few simple examples to show what elements will be in the stream. One example might be where the runtime version is 10 and there are resources in the base and versions/9 sections. Also assume I've got resources in versions/10/** that are not in other sections then it would be useful to quickly understand if they are included are not. Terminology-wise then I'm not sure if "accessible" should be used, the reason is that it will be confused with other types of access, particularly access control or even security permissions. The javadoc also mentions non-public classes and being accessed by public classes. I know what you mean but the javadoc shouldn't be concerned with that. Clearly the API should be the same on all versions but that is something for the introducing in the class description rather than this method. Also with modular JARs then you may have public types in non-exported packages. I might even have public types in non-exported packages in versioned sections that don't override anything in the base section. Another point to include in the javadoc is to make it clear that the method behaves the same as stream() then the JAR file is not a multi-release JAR. A minor comment is that there are at least 4 x @{code ...}, it should be {@code ...}. -Alan. From claes.redestad at oracle.com Fri Aug 26 13:26:32 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 26 Aug 2016 15:26:32 +0200 Subject: RFR: 8163371: Enable tracing which JLI classes can be pre-generated Message-ID: <57C04388.20305@oracle.com> Hi, please review this change which adds a means to trace what LFs and BMH classes we try to resolve at runtime (and whether we failed or succeeded), along with an update to the --generate-jli-classes plugin to take as it's input a file containing the output of such tracing. Bug: https://bugs.openjdk.java.net/browse/JDK-8163371 Webrev: http://cr.openjdk.java.net/~redestad/8163371/webrev.01/ I picked a random use case to test/verify the implementation in a minimal nashorn script, bin/jjs exit.js[1]. 1. On my local JDK image this loads 2359 classes. 2. On a jlink image with --generate-jli-classes=@empty to disable the default pre-generation, 2450 classes are loaded 3. On a jlink image built with the output of a tracing run[2], 2114 classes are loaded Also, inspecting the output shows that a total of 42 BoundMethodHandle$Species_* classes were pregenerated in case number 3, compared to 37 in the default case and 0 on the image with no pregeneration, meaning we avoid generating a total of 378 classes at runtime. As a follow up I plan to add tests and explore the benefits of adding a way to generate and use a relevant list of jli classes in the build (adding to the existing CDS classlist generation mechanism seems appropriate). Thanks! /Claes [1] exit.js: exit(); [2] bin/jjs -J-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true exit.js > trace.out bin/jlink ... --generate-jli-classes=@trace.out From vladimir.x.ivanov at oracle.com Fri Aug 26 13:40:36 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Aug 2016 16:40:36 +0300 Subject: RFR: 8163371: Enable tracing which JLI classes can be pre-generated In-Reply-To: <57C04388.20305@oracle.com> References: <57C04388.20305@oracle.com> Message-ID: <614ec111-53ec-0050-f5da-4febac848ca6@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 8/26/16 4:26 PM, Claes Redestad wrote: > Hi, > > please review this change which adds a means to trace what > LFs and BMH classes we try to resolve at runtime (and whether > we failed or succeeded), along with an update to the > --generate-jli-classes plugin to take as it's input a file containing > the output of such tracing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163371 > Webrev: http://cr.openjdk.java.net/~redestad/8163371/webrev.01/ > > I picked a random use case to test/verify the implementation in > a minimal nashorn script, bin/jjs exit.js[1]. > > 1. On my local JDK image this loads 2359 classes. > 2. On a jlink image with --generate-jli-classes=@empty to > disable the default pre-generation, 2450 classes are loaded > 3. On a jlink image built with the output of a tracing run[2], > 2114 classes are loaded > > Also, inspecting the output shows that a total of 42 > BoundMethodHandle$Species_* classes were pregenerated in case > number 3, compared to 37 in the default case and 0 on the image > with no pregeneration, meaning we avoid generating a total of 378 > classes at runtime. > > As a follow up I plan to add tests and explore the benefits of > adding a way to generate and use a relevant list of jli classes in the > build (adding to the existing CDS classlist generation mechanism > seems appropriate). > > Thanks! > > /Claes > > [1] > exit.js: > exit(); > > [2] > bin/jjs -J-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true exit.js > > trace.out > bin/jlink ... --generate-jli-classes=@trace.out From claes.redestad at oracle.com Fri Aug 26 13:41:30 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 26 Aug 2016 15:41:30 +0200 Subject: RFR: 8163371: Enable tracing which JLI classes can be pre-generated In-Reply-To: <614ec111-53ec-0050-f5da-4febac848ca6@oracle.com> References: <57C04388.20305@oracle.com> <614ec111-53ec-0050-f5da-4febac848ca6@oracle.com> Message-ID: <57C0470A.2030604@oracle.com> On 2016-08-26 15:40, Vladimir Ivanov wrote: > Reviewed. Thanks for reviewing! /Claes > > Best regards, > Vladimir Ivanov > > On 8/26/16 4:26 PM, Claes Redestad wrote: >> Hi, >> >> please review this change which adds a means to trace what >> LFs and BMH classes we try to resolve at runtime (and whether >> we failed or succeeded), along with an update to the >> --generate-jli-classes plugin to take as it's input a file containing >> the output of such tracing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163371 >> Webrev: http://cr.openjdk.java.net/~redestad/8163371/webrev.01/ >> >> I picked a random use case to test/verify the implementation in >> a minimal nashorn script, bin/jjs exit.js[1]. >> >> 1. On my local JDK image this loads 2359 classes. >> 2. On a jlink image with --generate-jli-classes=@empty to >> disable the default pre-generation, 2450 classes are loaded >> 3. On a jlink image built with the output of a tracing run[2], >> 2114 classes are loaded >> >> Also, inspecting the output shows that a total of 42 >> BoundMethodHandle$Species_* classes were pregenerated in case >> number 3, compared to 37 in the default case and 0 on the image >> with no pregeneration, meaning we avoid generating a total of 378 >> classes at runtime. >> >> As a follow up I plan to add tests and explore the benefits of >> adding a way to generate and use a relevant list of jli classes in the >> build (adding to the existing CDS classlist generation mechanism >> seems appropriate). >> >> Thanks! >> >> /Claes >> >> [1] >> exit.js: >> exit(); >> >> [2] >> bin/jjs -J-Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true exit.js > >> trace.out >> bin/jlink ... --generate-jli-classes=@trace.out From alexandre.iline at oracle.com Fri Aug 26 14:59:57 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 26 Aug 2016 07:59:57 -0700 Subject: RFR: 8164859 Fix module dependences in java/text tests Message-ID: Hi. Please review this simple fix: http://cr.openjdk.java.net/~shurailine/8164859/webrev.00/ This fix is only adding @modules with either java.desktop or jdk.localedata to number of tests - no other changes. Shura From claes.redestad at oracle.com Fri Aug 26 16:07:36 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 26 Aug 2016 18:07:36 +0200 Subject: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ Message-ID: <57C06947.7060304@oracle.com> Hi, JDK-8163371 forgot about the associated test. Changed it as necessary as some of the options are no longer implemented as of the latest changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ Thanks! /Claes From vladimir.x.ivanov at oracle.com Fri Aug 26 16:14:05 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Aug 2016 19:14:05 +0300 Subject: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ In-Reply-To: <57C06947.7060304@oracle.com> References: <57C06947.7060304@oracle.com> Message-ID: Reviewed. Best regards, Vladimir Ivanov On 8/26/16 7:07 PM, Claes Redestad wrote: > Hi, > > JDK-8163371 forgot about the associated test. Changed it as necessary as > some of the options are no longer implemented as of the latest changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 > Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ > > Thanks! > > /Claes From sundararajan.athijegannathan at oracle.com Fri Aug 26 16:09:35 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 26 Aug 2016 21:39:35 +0530 Subject: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ In-Reply-To: <57C06947.7060304@oracle.com> References: <57C06947.7060304@oracle.com> Message-ID: <9725b8cf-a94c-d3b2-ddfc-ab58c7ab9098@oracle.com> +1 -Sundar On 8/26/2016 9:37 PM, Claes Redestad wrote: > Hi, > > JDK-8163371 forgot about the associated test. Changed it as necessary > as some of the options are no longer implemented as of the latest > changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 > Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Aug 26 16:09:32 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 26 Aug 2016 18:09:32 +0200 Subject: RFR: 8164866: tools/jlink/plugins/GenerateJLIClassesPluginTest.java can't compile after JDK-8163371 In-Reply-To: <57C06947.7060304@oracle.com> References: <57C06947.7060304@oracle.com> Message-ID: <57C069BC.30809@oracle.com> On 2016-08-26 18:07, Claes Redestad wrote: > Hi, > > JDK-8163371 forgot about the associated test. Changed it as necessary > as some of the options are no longer implemented as of the latest > changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 > Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ > > Thanks! > > /Claes From claes.redestad at oracle.com Fri Aug 26 16:11:12 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 26 Aug 2016 18:11:12 +0200 Subject: RFR: 8164866: tools/jlink/plugins/GenerateJLIClassesPluginTest.java can't compile after JDK-8163371 In-Reply-To: <57C069BC.30809@oracle.com> References: <57C06947.7060304@oracle.com> <57C069BC.30809@oracle.com> Message-ID: <57C06A20.4040103@oracle.com> Thanks Sundar and Vladimir for reviewing quicker than I was able to correct myself! :-) /Claes On 2016-08-26 18:09, Claes Redestad wrote: > > > On 2016-08-26 18:07, Claes Redestad wrote: >> Hi, >> >> JDK-8163371 forgot about the associated test. Changed it as necessary >> as some of the options are no longer implemented as of the latest >> changes: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 >> Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ >> >> Thanks! >> >> /Claes > From xueming.shen at oracle.com Fri Aug 26 16:48:04 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 26 Aug 2016 09:48:04 -0700 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code Message-ID: <57C072C4.9000108@oracle.com> Hi, This is a aged rfe from Paul's code review comments for the old code. base. The implementation has been changed lots since. Some has gone, some has been updated accordingly. Just went through the list and here is the change set for some minor issues still present. issue: https://bugs.openjdk.java.net/browse/JDK-8066577 webrev: http://cr.openjdk.java.net/~sherman/8066577/webrev Thanks, Sherman From huizhe.wang at oracle.com Fri Aug 26 17:06:35 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Aug 2016 10:06:35 -0700 Subject: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver Message-ID: <57C0771B.8000307@oracle.com> Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces. New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException. Existing tests: mainly replaced CatalogUriResolver with CatalogResolver. JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/ Thanks, Joe From naoto.sato at oracle.com Fri Aug 26 17:07:22 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 26 Aug 2016 10:07:22 -0700 Subject: RFR: 8164859 Fix module dependences in java/text tests In-Reply-To: References: Message-ID: <83cab5c8-6dd2-8f37-96f1-b421ab869987@oracle.com> Looks good to me. Naoto On 8/26/16 7:59 AM, Alexandre (Shura) Iline wrote: > Hi. > > Please review this simple fix: > http://cr.openjdk.java.net/~shurailine/8164859/webrev.00/ > > This fix is only adding @modules with either java.desktop or jdk.localedata to number of tests - no other changes. > > Shura > > From paul.sandoz at oracle.com Fri Aug 26 17:54:37 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 26 Aug 2016 10:54:37 -0700 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <57C072C4.9000108@oracle.com> References: <57C072C4.9000108@oracle.com> Message-ID: > On 26 Aug 2016, at 09:48, Xueming Shen wrote: > > Hi, > > This is a aged rfe from Paul's code review comments for the old code. base. The > implementation has been changed lots since. Some has gone, some has been updated > accordingly. Just went through the list and here is the change set for some minor issues > still present. > > issue: https://bugs.openjdk.java.net/browse/JDK-8066577 > webrev: http://cr.openjdk.java.net/~sherman/8066577/webrev > +1 Paul. From daniel.fuchs at oracle.com Fri Aug 26 19:01:52 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 26 Aug 2016 20:01:52 +0100 Subject: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver In-Reply-To: <57C0771B.8000307@oracle.com> References: <57C0771B.8000307@oracle.com> Message-ID: <4d180720-5aa9-76fc-b420-5fc4b280ca88@oracle.com> Hi Joe, Looks good to me! -- daniel On 26/08/16 18:06, Joe Wang wrote: > Hi, > > Please review a consolidation of resolver support to CatalogResolver. > The purpose is to simplify the interface and usage scenarios so that the > one CatalogResolver is usable for all JDK XML processors. As with the > existing resolver interfaces, the change makes it no distinction between > system identifiers and URIs, which would make it easier for users to > create catalogs (without worrying about when and why to use what type of > catalog entries). The implementation is almost identical for all JDK XML > resolver interfaces. > > New tests: added to CatalogTest.java to cover URIResolver (Transform), > XMLResolver (StAX) and LSResourceResolver (Validation). > new CatalogSupport5.java is added to cover error > handling. When there is no match found, a processor shall return with > the specified checked exception rather than CatalogException. > > Existing tests: mainly replaced CatalogUriResolver with CatalogResolver. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/ > > Thanks, > Joe From steve.drach at oracle.com Fri Aug 26 19:27:21 2016 From: steve.drach at oracle.com (Steve Drach) Date: Fri, 26 Aug 2016 12:27:21 -0700 Subject: Fwd: RFR 8163798: Add a versionedStream method to JarFile References: Message-ID: <96416182-D5EC-43BA-936E-85BA6E3CFBC5@oracle.com> Sorry, forget to Cc core-libs on my response to Peter?s questions > Begin forwarded message: > > From: Steve Drach > Subject: Re: RFR 8163798: Add a versionedStream method to JarFile > Date: August 26, 2016 at 9:44:39 AM PDT > To: Peter Levart > > Hi Peter, > >> Javadoc for the new method mentions public and non-public classes: >> >> "@{code JarEntries} >> * containing non-public classes in the >> * versioned directory that corresponds to the version returned by >> * {@link JarFile#getVersion()} are included in the stream because they are >> * typically accessed by the public classes." >> >> Why? > > The public ?interface? for a multi-release jar is the set of public or protected classes in the base (or root) section of the jar. By definition, no new (i.e. without a corresponding base class) public or protected classes can be contained in a versioned directory. Versioned directories can contain new package-private classes. In practice these package-private classes are dependencies for the public/protected classes in > in the same versioned directory. > >> The logic of multi-release jar files is indifferent towards the access attributes of class files. It never parses the class file to interpret the access attributes of the containing class. > > I know. I thought about doing that but rejected it as too heavyweight and just decided to use the heuristic that real class files have the suffix ?.class? and that if there was not a corresponding base class, then the class has to be package-private according to the ?rules? of multi-release jar files. The jar tool enforces these rules by actually parsing the class files. > >> The class-level javadoc of JarFile does mention "public classes", but I view this just as a recommendation how they should be constructed. >> >> The logic of multi-release jar files is indifferent towards the types of resources contained in the jar entries too, as far as I can see. Your logic in versionedStream() is not. The proposed new method is the only place in JarFile and ZipFile where the check for ".class" suffix of the entry name is performed. Why this special treatement of class files? > > I hope the explanation above is sufficient. The versionedStream looks at the jar file in an inverted or backwards way. In the usual case, a > multi-release jar file entry is obtained by JarFile.getJarEntry(base-entry-name). In this case if the jar file was opened for version 10, we?d not be able to see or get package-private classes in the version 9 directory. Oh, one thing I should mention, Mr. Jar?s can be sparsely populated in the versioned directories, So if a version 10 public class was not in the version 10 directory, but was in the version 9 directory, then the version 9 one would be returned. > >> I also don't understand why the versioned stream should contain the untranslated base versioned directories. For example, the following entries for the v10 stream in the test: >> >> "META-INF/versions/9/" >> "META-INF/versions/10/? > > I just did it because they are returned by JarFile::stream. I?m ambivalent about it, so I wanted to see the comments if any. > >> >> All other resources and sub-directories in the META-INF/versions/XX/... directories are "normalized" (meaning that the versioned prefix is stripped from the names in the returned entries). Normalizing above directories would translate them to "root" directory, which is never included as an entry of a normal jar or zip file. So I think they could simply be skipped in the resulting versioned stream. Couldn't they? > > Yes. > >> >> Considering all of the above, I think versionedStream() method could be much simpler. For example, something like the following: >> >> >> public Stream versionedStream() { >> return >> !isMultiRelease() >> ? stream() >> : stream() >> .flatMap(je -> { >> String name = je.getName(); >> if (name.startsWith(META_INF_VERSIONS)) { >> // versioned entry >> if (name.length() > META_INF_VERSIONS.length()) { >> // potentially real entry >> String vStr = name.substring(META_INF_VERSIONS.length()); >> int offset = vStr.indexOf('/'); >> int version = 0; >> if (offset >= 0) try { >> version = Integer.parseInt(vStr.substring(0, offset)); >> } catch (NumberFormatException e) { /* ignore */ } >> if (version <= 0) { >> throw new RuntimeException( >> "Can't obtain version from multi-release jar entry: " >> + name); >> } >> return (version <= versionMajor && vStr.length() > offset + 1) >> // normalized name of real entry >> ? Stream.of(vStr.substring(offset + 1)) >> // version > versionMajor or >> // META-INF/versions// dir - ignored >> : Stream.empty(); >> } else { >> // META-INF/versions/ dir - ignored >> return Stream.empty(); >> } >> } else { // base entry >> return Stream.of(name); >> } >> }) >> .distinct() >> .map(this::getJarEntry); >> } >> >> >> What do you think? > > It?s certainly more sophisticated than the way I did it. If we could constrain the getJarEntry only to base names we might be able to handle the package-private classes too. I need to think about it a bit. > > Steve > >> >> Regards, Peter >> >> >> On 08/26/2016 07:16 AM, Tagir Valeev wrote: >>> Hello! >>> >>> Small nitpick: >>> >>> versionsMap.keySet().forEach(v -> { >>> Stream names = versionsMap.get(v).stream().map(nm -> nm.name); >>> if (v == versionMajor) { >>> // add all entries of the version we are interested in >>> finalNames.addAll(names.collect(Collectors.toSet())); >>> } else { >>> // add resource entries found in lower versioned directories >>> finalNames.addAll(names.filter(nm -> nm.endsWith(".class") ? false >>> : true) >>> .collect(Collectors.toSet())); >>> } >>> }); >>> >>> I suggest to replace with >>> >>> versionsMap.forEach((v, list) -> { >>> Stream names = list.stream().map(nm -> nm.name); >>> if (v != versionMajor) { >>> names = names.filter(nm -> !nm.endsWith(".class")); >>> } >>> names.forEach(finalNames::add); >>> }); >>> >>> This is cleaner and somewhat faster to use Map.forEach as you don't need to >>> lookup every map entry. >>> >>> Also I don't see why "nm -> nm.endsWith(".class") ? false : true" could be >>> better than >>> "nm -> !nm.endsWith(".class")". Probably a matter of style though. >>> >>> Finally there's no need to collect into intermediate set just to add this >>> set into finalNames. >>> Instead you can drain the stream directly to finalNames via forEach. >>> >>> Probably it should be explicitly noted in spec that the resulting stream is >>> unordered (or at least may >>> be unordered) as it's created from the Set. >>> >>> With best regards, >>> Tagir Valeev >>> >>> On Fri, Aug 26, 2016 at 2:30 AM, Steve Drach wrote: >>> >>>> Hi, >>>> >>>> Please review this changeset that adds a versionedStream method to JarFile. >>>> >>>> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ < >>>> http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/> >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 < >>>> https://bugs.openjdk.java.net/browse/JDK-8163798> >>>> >>>> Thanks >>>> Steve >>>> >>>> >>>> >> > From huizhe.wang at oracle.com Fri Aug 26 19:37:31 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Aug 2016 12:37:31 -0700 Subject: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver In-Reply-To: <4d180720-5aa9-76fc-b420-5fc4b280ca88@oracle.com> References: <57C0771B.8000307@oracle.com> <4d180720-5aa9-76fc-b420-5fc4b280ca88@oracle.com> Message-ID: <57C09A7B.1050204@oracle.com> Thanks Daniel! Best, Joe On 8/26/16, 12:01 PM, Daniel Fuchs wrote: > Hi Joe, > > Looks good to me! > > -- daniel > > On 26/08/16 18:06, Joe Wang wrote: >> Hi, >> >> Please review a consolidation of resolver support to CatalogResolver. >> The purpose is to simplify the interface and usage scenarios so that the >> one CatalogResolver is usable for all JDK XML processors. As with the >> existing resolver interfaces, the change makes it no distinction between >> system identifiers and URIs, which would make it easier for users to >> create catalogs (without worrying about when and why to use what type of >> catalog entries). The implementation is almost identical for all JDK XML >> resolver interfaces. >> >> New tests: added to CatalogTest.java to cover URIResolver (Transform), >> XMLResolver (StAX) and LSResourceResolver (Validation). >> new CatalogSupport5.java is added to cover error >> handling. When there is no match found, a processor shall return with >> the specified checked exception rather than CatalogException. >> >> Existing tests: mainly replaced CatalogUriResolver with CatalogResolver. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/ >> >> Thanks, >> Joe > From lance.andersen at oracle.com Fri Aug 26 19:41:38 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 26 Aug 2016 15:41:38 -0400 Subject: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver In-Reply-To: <57C0771B.8000307@oracle.com> References: <57C0771B.8000307@oracle.com> Message-ID: <74E9B1B5-2B4B-493E-95EA-2E6BE900ADC8@oracle.com> +1 > On Aug 26, 2016, at 1:06 PM, Joe Wang wrote: > > Hi, > > Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces. > > New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). > new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException. > > Existing tests: mainly replaced CatalogUriResolver with CatalogResolver. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/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 huizhe.wang at oracle.com Fri Aug 26 19:58:44 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Aug 2016 12:58:44 -0700 Subject: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver In-Reply-To: <74E9B1B5-2B4B-493E-95EA-2E6BE900ADC8@oracle.com> References: <57C0771B.8000307@oracle.com> <74E9B1B5-2B4B-493E-95EA-2E6BE900ADC8@oracle.com> Message-ID: <57C09F74.50407@oracle.com> Thanks Lance! Best, Joe On 8/26/16, 12:41 PM, Lance Andersen wrote: > +1 >> On Aug 26, 2016, at 1:06 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a consolidation of resolver support to CatalogResolver. >> The purpose is to simplify the interface and usage scenarios so that >> the one CatalogResolver is usable for all JDK XML processors. As with >> the existing resolver interfaces, the change makes it no distinction >> between system identifiers and URIs, which would make it easier for >> users to create catalogs (without worrying about when and why to use >> what type of catalog entries). The implementation is almost identical >> for all JDK XML resolver interfaces. >> >> New tests: added to CatalogTest.java to cover URIResolver >> (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). >> new CatalogSupport5.java is added to cover error >> handling. When there is no match found, a processor shall return with >> the specified checked exception rather than CatalogException. >> >> Existing tests: mainly replaced CatalogUriResolver with CatalogResolver. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/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 yingqi.lu at intel.com Fri Aug 26 22:31:14 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 26 Aug 2016 22:31:14 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> Dear All, This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to and from this file. File I/O is done directly to/from user-space buffers. Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more details. The advantage of this feature is to provide consistent and predictable IO throughput, bypassing the influence of Linux filesystem cache. It is useful for applications which already have their own caching layers, such as databases Apache HBase and Apache Cassandra. In addition, for applications like Apache Spark shuffle phase that have random file accesses and no access locality (read the file only once from a random location), this feature also helps performance by minimizing trashing the filesystem cache. The proposal adds 4 API methods to java/io/FileInputStream.java, java/io/OutputStream.java to enable the feature. In addition, it add O_DIRECT with two more modes "ro" (read-only and direct) and "rwo" (read-write and direct) to java/io/RandomAccessFile.java. public FileInputStream(String name, boolean direct) throws FileNotFoundException public FileInputStream(File file, boolean direct) throws FileNotFoundException public FileOutputStream(String name, boolean append, boolean direct) throws FileNotFoundException public FileOutputStream(File file, boolean append, boolean direct) throws FileNotFoundException Many database applications written in C/C++ such as MySQL and MongoDB have already used O_DIRECT for certain DB operations. Many Java based BigData applications such as Cassandra are already using it from third party library named JNA. (https://github.com/java-native-access/jna) Our internal version of Hadoop Distributed File System (HDFS) that has O_DIRECT enabled via JNI functions also show significant throughput improvements. We opened a JBS ticket at https://bugs.openjdk.java.net/browse/JDK-8164900 and the initial version of the JDK9 patch is available at http://cr.openjdk.java.net/~vdeshpande/8164900/webrev.00/. By using this patch, we saw good results up to 1.8x improvement on random read throughput on a micro workload named IOMeter with both SATA SSDs and Intel PCIeSSDs. The workload is available at https://github.com/persado/iometer/blob/master/src/main/java/com/persado/oss/iometer/IOMeter.java Please review the patch and let us know your feedback. Thanks, Yingqi Lu (Lucy) From paul.sandoz at oracle.com Fri Aug 26 23:13:27 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 26 Aug 2016 16:13:27 -0700 Subject: RFR 8164691 Stream specification clarifications for iterate and collect Message-ID: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Hi, Please review some minor tweaks to the stream specification: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691-stream-iterate-collect-spec-updates/webrev/index.html The first tweak is to clarify the iterate methods and HB edges between function calls, the functions could potentially be stateful, they will never be called concurrently due to the nature of the source, but may be called in different threads. The second tweak is to the three-arg collect method. The combiner of result containers neglected to state how result containers should be merged. Thanks, Paul. From stuart.marks at oracle.com Sat Aug 27 00:20:05 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 26 Aug 2016 17:20:05 -0700 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Message-ID: Hi Paul, Overall looks good. A couple minor wording comments. For the 3-arg collectors, the combiner arg is defined as * @param combiner an associative, * non-interfering, * stateless * function that accepts two partial result containers and * merges them, which must be compatible with the accumulator * function. The combiner function folds the elements in * result container that is the second argument into the * result container that is the first argument. I'd suggest replacing the last sentence with The combiner function must fold the elements from the second result container into the first result container. I think it's implicitly pretty clear that the first and second result containers are the first and second arguments to the combiner function. If you're ok with the "must fold" style, then maybe also update the accumulator arg spec * @param accumulator an associative, * non-interfering, * stateless * function that folds an element into a result container. from "that folds" to "that must fold". That way all three args use the "must" style wording. I think the same wording is present in all four Stream types. s'marks On 8/26/16 4:13 PM, Paul Sandoz wrote: > Hi, > > Please review some minor tweaks to the stream specification: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691-stream-iterate-collect-spec-updates/webrev/index.html > > The first tweak is to clarify the iterate methods and HB edges between function calls, the functions could potentially be stateful, they will never be called concurrently due to the nature of the source, but may be called in different threads. > > The second tweak is to the three-arg collect method. The combiner of result containers neglected to state how result containers should be merged. > > Thanks, > Paul. > From Alan.Bateman at oracle.com Sat Aug 27 07:43:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Aug 2016 08:43:48 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> Message-ID: On 26/08/2016 23:31, Lu, Yingqi wrote: > Dear All, > > This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to and from this file. File I/O is done directly to/from user-space buffers. Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more details. > > FIS/FOS/RAF doesn't seem the right place for this. Have you looked at using extended open options with FileChannel instead? -Alan From Alan.Bateman at oracle.com Sat Aug 27 07:53:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Aug 2016 08:53:46 +0100 Subject: Fwd: RFR 8163798: Add a versionedStream method to JarFile In-Reply-To: <96416182-D5EC-43BA-936E-85BA6E3CFBC5@oracle.com> References: <96416182-D5EC-43BA-936E-85BA6E3CFBC5@oracle.com> Message-ID: <9355c2f9-da68-6e1d-fd99-9a674d5d74a4@oracle.com> On 26/08/2016 20:27, Steve Drach wrote: > : >> The public ?interface? for a multi-release jar is the set of public or protected classes in the base (or root) section of the jar. By definition, no new (i.e. without a corresponding base class) public or protected classes can be contained in a versioned directory. Versioned directories can contain new package-private classes. In practice these package-private classes are dependencies for the public/protected classes in >> in the same versioned directory. The versioned section of a modular MR JAR may contain .class files corresponding to types that are not in exported packages. In that scenario then it doesn't matter if the types are public or not. In any case, the JarFile code shouldn't be concerned this, it can leave any checking to packaging time and the jar tool. -Alan. From Alan.Bateman at oracle.com Sat Aug 27 07:57:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Aug 2016 08:57:20 +0100 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <57C072C4.9000108@oracle.com> References: <57C072C4.9000108@oracle.com> Message-ID: <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> On 26/08/2016 17:48, Xueming Shen wrote: > Hi, > > This is a aged rfe from Paul's code review comments for the old code. > base. The > implementation has been changed lots since. Some has gone, some has > been updated > accordingly. Just went through the list and here is the change set for > some minor issues > still present. > > issue: https://bugs.openjdk.java.net/browse/JDK-8066577 > webrev: http://cr.openjdk.java.net/~sherman/8066577/webrev You might want to re-check the synchronization in JrtDirectoryStream, it looks the next/hasNext methods are synchronizing on the Iterator instance. -Alan. From paul.sandoz at oracle.com Sat Aug 27 14:40:53 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Sat, 27 Aug 2016 07:40:53 -0700 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> Message-ID: <1DD920BC-31C6-4843-8BED-65F4638A00BC@oracle.com> > On 27 Aug 2016, at 00:57, Alan Bateman wrote: > > On 26/08/2016 17:48, Xueming Shen wrote: > >> Hi, >> >> This is a aged rfe from Paul's code review comments for the old code. base. The >> implementation has been changed lots since. Some has gone, some has been updated >> accordingly. Just went through the list and here is the change set for some minor issues >> still present. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8066577 >> webrev: http://cr.openjdk.java.net/~sherman/8066577/webrev > You might want to re-check the synchronization in JrtDirectoryStream, it looks the next/hasNext methods are synchronizing on the Iterator instance. > Yes, i missed that. The Iterator will need to synchronize on its enclosing instance. Paul. From yingqi.lu at intel.com Sat Aug 27 16:00:38 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sat, 27 Aug 2016 16:00:38 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com>, Message-ID: The workload we have uses fis/fos/raf, that is why we started here following the example of other file open flags. We can surely look into filechannel extended open options to see if it fits better there. Thanks, Lucy Sent from my iPhone > On Aug 27, 2016, at 12:43 AM, Alan Bateman wrote: > >> On 26/08/2016 23:31, Lu, Yingqi wrote: >> >> Dear All, >> >> This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to and from this file. File I/O is done directly to/from user-space buffers. Please refer to http://man7.org/linux/man-pages/man2/open.2.html for more details. > FIS/FOS/RAF doesn't seem the right place for this. Have you looked at using extended open options with FileChannel instead? > > -Alan From aph at redhat.com Sun Aug 28 10:23:11 2016 From: aph at redhat.com (Andrew Haley) Date: Sun, 28 Aug 2016 11:23:11 +0100 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> Message-ID: <72b941c6-ce47-e4ac-76ca-4bea287eeb57@redhat.com> On 26/08/16 23:31, Lu, Yingqi wrote: > The proposal adds 4 API methods to java/io/FileInputStream.java, > java/io/OutputStream.java to enable the feature. In addition, it add > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo" > (read-write and direct) to java/io/RandomAccessFile.java. > > public FileInputStream(String name, boolean direct) throws FileNotFoundException Adding a boolean for O_DIRECT does not scale well. There are many other flags, and if there is some future expansion it would mean adding more boolean arguments to the call signature. It might be worth considering a more direct way to make the call to open(2). I appreciate that not every flag passed to open() makes sense, though. And there is Windows etc. to think about. But something like new FileInputStream(filename, File.DIRECT | File.APPEND) is much more scalable and involves less argument marshalling. Andrew. From uschindler at apache.org Sun Aug 28 10:29:51 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 28 Aug 2016 12:29:51 +0200 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <72b941c6-ce47-e4ac-76ca-4bea287eeb57@redhat.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <72b941c6-ce47-e4ac-76ca-4bea287eeb57@redhat.com> Message-ID: <048e01d20117$1e8a9580$5b9fc080$@apache.org> Hi, IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change them anymore. Those are legacy APIs! I'd suggest to add this to StandardOpenOptions (https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html) and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the old-style java.io.File based APIs. This is easy to implement and add, because you would only add the new Enum constant and then implement it in the default FileSystem(-Provider) for each platform. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Andrew Haley > Sent: Sunday, August 28, 2016 12:23 PM > To: Lu, Yingqi ; core-libs-dev at openjdk.java.net > Cc: Kaczmarek, Eric > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > > On 26/08/16 23:31, Lu, Yingqi wrote: > > > The proposal adds 4 API methods to java/io/FileInputStream.java, > > java/io/OutputStream.java to enable the feature. In addition, it add > > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo" > > (read-write and direct) to java/io/RandomAccessFile.java. > > > > public FileInputStream(String name, boolean direct) throws > FileNotFoundException > > Adding a boolean for O_DIRECT does not scale well. There are many > other flags, and if there is some future expansion it would mean > adding more boolean arguments to the call signature. It might be > worth considering a more direct way to make the call to open(2). I > appreciate that not every flag passed to open() makes sense, though. > And there is Windows etc. to think about. But something like > > new FileInputStream(filename, File.DIRECT | File.APPEND) > > is much more scalable and involves less argument marshalling. > > Andrew. From yingqi.lu at intel.com Sun Aug 28 16:11:19 2016 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sun, 28 Aug 2016 16:11:19 +0000 Subject: Proposal for adding O_DIRECT support into JDK 9 In-Reply-To: <048e01d20117$1e8a9580$5b9fc080$@apache.org> References: <9ACD5B67AAC5594CB6268234CF29CF9AA510A5DA@ORSMSX113.amr.corp.intel.com> <72b941c6-ce47-e4ac-76ca-4bea287eeb57@redhat.com> <048e01d20117$1e8a9580$5b9fc080$@apache.org> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AA510BB32@ORSMSX113.amr.corp.intel.com> Hi Uwe/Andrew, Thank you both for the suggestions. I agree it would be cleaner to make O_DIRECT an extended open options within nio package. We will modify the patch and update the community soon! Thanks, Lucy -----Original Message----- From: Uwe Schindler [mailto:uschindler at apache.org] Sent: Sunday, August 28, 2016 3:30 AM To: 'Andrew Haley' ; Lu, Yingqi ; core-libs-dev at openjdk.java.net Cc: Kaczmarek, Eric Subject: RE: Proposal for adding O_DIRECT support into JDK 9 Hi, IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change them anymore. Those are legacy APIs! I'd suggest to add this to StandardOpenOptions (https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html) and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the old-style java.io.File based APIs. This is easy to implement and add, because you would only add the new Enum constant and then implement it in the default FileSystem(-Provider) for each platform. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Andrew Haley > Sent: Sunday, August 28, 2016 12:23 PM > To: Lu, Yingqi ; core-libs-dev at openjdk.java.net > Cc: Kaczmarek, Eric > Subject: Re: Proposal for adding O_DIRECT support into JDK 9 > > On 26/08/16 23:31, Lu, Yingqi wrote: > > > The proposal adds 4 API methods to java/io/FileInputStream.java, > > java/io/OutputStream.java to enable the feature. In addition, it add > > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo" > > (read-write and direct) to java/io/RandomAccessFile.java. > > > > public FileInputStream(String name, boolean direct) throws > FileNotFoundException > > Adding a boolean for O_DIRECT does not scale well. There are many > other flags, and if there is some future expansion it would mean > adding more boolean arguments to the call signature. It might be > worth considering a more direct way to make the call to open(2). I > appreciate that not every flag passed to open() makes sense, though. > And there is Windows etc. to think about. But something like > > new FileInputStream(filename, File.DIRECT | File.APPEND) > > is much more scalable and involves less argument marshalling. > > Andrew. From jbluettduncan at gmail.com Sun Aug 28 16:25:55 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sun, 28 Aug 2016 17:25:55 +0100 Subject: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070 Message-ID: Hi all, My name is Jonathan, and it's my first time posting to this mailing list. I'm writing to you all as I'm rather interested in contributing to this area of the OpenJDK. Particularly, I'm thinking I'd quite like to help out with one of the subtasks for the Immutable Collections enhancements . However I don't have specific ideas and I don't know which of the subtasks would most closely match my skills and knowledge, so I wondered if I could have some guidance as to what I could do and how I can get started. FYI, I've partially read the contribution instructions , and I just submitted an OCA earlier today, so I don't expect to be actually ready to participate until I hear back from Oracle, but nonetheless I'd like to try to get the ball rolling as soon as possible. Kind regards, Jonathan Bluett-Duncan From bodewig at apache.org Sun Aug 28 17:03:14 2016 From: bodewig at apache.org (Stefan Bodewig) Date: Sun, 28 Aug 2016 19:03:14 +0200 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions Message-ID: <87eg58n7vx.fsf@v45346.1blu.de> Hi, I've been told to ask for advice here. Over the past few weeks we've adapted the Apache Ant code base to JDK 9 well enough that Ant's own test suite works - almost. The onyl remaining issue really goes back to Java 1.7 and JAXP 1.4 when secure processing was introduced. If you are running an XSLT transform and it needs extensions - say the Xalan redirect extension - you can't do it if a SecurityManager has been set. https://bz.apache.org/bugzilla/show_bug.cgi?id=51668 This is causing quite a few problems for users running Ant from within IDEs which typically install SecurityManagers. One such instance it Ant's own task which uses XSLT and the redirect extension. Back in Java 1.7 we "solved" the problem with a hack. We simply disable secure processing mode via reflection https://github.com/apache/ant/commit/fe829a9d0fa679df3ae2cc4803e5236ed2ed5c7b The module system now breaks the hack as we can no longer access the necessary field via reflection. Before we try to find new clever or stupid workarounds we may as well ask for advice on how to do it properly. This is our use-case: The user wants to execute Ant's -Task from within Eclipse which has installed a SecurityManager and the transform requires an extension. How can we make this work? Cheers Stefan From amy.lu at oracle.com Mon Aug 29 01:14:36 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 29 Aug 2016 09:14:36 +0800 Subject: JDK 9 RFR of JDK-8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java Message-ID: <50313f90-c353-e529-ecfa-23a42bb54b78@oracle.com> java/lang/ProcessBuilder/Zombies.java This test was failing intermittently (JDK-8160151). Mentioned issue has been resolved and no open bug (no failure reported) till now. This patch is to remove @key intermittent from the test. bug: https://bugs.openjdk.java.net/browse/JDK-8163934 webrev: http://cr.openjdk.java.net/~amlu/8163934/webrev.00/ Thanks, Amy --- old/test/java/lang/ProcessBuilder/Zombies.java 2016-08-29 09:10:18.000000000 +0800 +++ new/test/java/lang/ProcessBuilder/Zombies.java 2016-08-29 09:10:18.000000000 +0800 @@ -25,7 +25,6 @@ * @test * @run main/othervm Zombies * @bug 6474073 6180151 - * @key intermittent * @summary Make sure zombies don't get created on Unix * @author Martin Buchholz */ From joe.darcy at oracle.com Mon Aug 29 01:29:14 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 28 Aug 2016 18:29:14 -0700 Subject: JDK 9 RFR of JDK-8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java In-Reply-To: <50313f90-c353-e529-ecfa-23a42bb54b78@oracle.com> References: <50313f90-c353-e529-ecfa-23a42bb54b78@oracle.com> Message-ID: <78d76f76-6322-7072-bf1d-9a547d7e6f29@oracle.com> Looks fine Amy; thanks, -Joe On 8/28/2016 6:14 PM, Amy Lu wrote: > java/lang/ProcessBuilder/Zombies.java > > This test was failing intermittently (JDK-8160151). Mentioned issue > has been resolved and no open bug (no failure reported) till now. > > This patch is to remove @key intermittent from the test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8163934 > webrev: http://cr.openjdk.java.net/~amlu/8163934/webrev.00/ > > Thanks, > Amy > > --- old/test/java/lang/ProcessBuilder/Zombies.java 2016-08-29 > 09:10:18.000000000 +0800 > +++ new/test/java/lang/ProcessBuilder/Zombies.java 2016-08-29 > 09:10:18.000000000 +0800 > @@ -25,7 +25,6 @@ > * @test > * @run main/othervm Zombies > * @bug 6474073 6180151 > - * @key intermittent > * @summary Make sure zombies don't get created on Unix > * @author Martin Buchholz > */ > > From joe.darcy at oracle.com Mon Aug 29 01:29:58 2016 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 28 Aug 2016 18:29:58 -0700 Subject: JDK 9 RFR of JDK-8163934: Remove intermittent key from java/lang/ProcessBuilder/Zombies.java In-Reply-To: <50313f90-c353-e529-ecfa-23a42bb54b78@oracle.com> References: <50313f90-c353-e529-ecfa-23a42bb54b78@oracle.com> Message-ID: <687ed5a4-e2c7-07b0-e08d-c33c5df42154@oracle.com> Looks fine Amy; thanks, -Joe On 8/28/2016 6:14 PM, Amy Lu wrote: > java/lang/ProcessBuilder/Zombies.java > > This test was failing intermittently (JDK-8160151). Mentioned issue > has been resolved and no open bug (no failure reported) till now. > > This patch is to remove @key intermittent from the test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8163934 > webrev: http://cr.openjdk.java.net/~amlu/8163934/webrev.00/ > > Thanks, > Amy > > --- old/test/java/lang/ProcessBuilder/Zombies.java 2016-08-29 > 09:10:18.000000000 +0800 > +++ new/test/java/lang/ProcessBuilder/Zombies.java 2016-08-29 > 09:10:18.000000000 +0800 > @@ -25,7 +25,6 @@ > * @test > * @run main/othervm Zombies > * @bug 6474073 6180151 > - * @key intermittent > * @summary Make sure zombies don't get created on Unix > * @author Martin Buchholz > */ > > From david.holmes at oracle.com Mon Aug 29 07:24:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 17:24:24 +1000 Subject: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame In-Reply-To: <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> References: <6b96634e-a9c0-47b2-c17b-f6b2057a5f14@oracle.com> <7b2fe986-fca9-dbd1-d20e-17934ac1bc08@oracle.com> <58f4a6da-b3d0-a1c7-9086-a34883e6b590@oracle.com> <70aacfa1-ffa8-a4a9-8092-4cc12949d027@oracle.com> Message-ID: <8082b3e4-1983-8a03-f2c8-b007c8ac91db@oracle.com> Hi David, I still do not understand why you think you need to make any changes in libjli ?? Certainly I do not think you should be printing anything about exceptions. Thanks, David H. On 26/08/2016 9:55 PM, David Simms wrote: > Hi David, > > Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev2/ > > On 26/08/16 02:27, David Holmes wrote: >> Hi David, >> >> I'm missing some pieces of this puzzle I'm afraid. >> >> On 25/08/2016 8:05 PM, David Simms wrote: >>> >>> Updated the webrev here: >>> http://cr.openjdk.java.net/~dsimms/8164086/webrev1/ >> >> hotspot/src/share/vm/prims/whitebox.cpp >> >> First I'm not sure that Whitebox isn't a special case here that could >> be handled in the WB_START/END macros - see below. >> >> More generally you state below that the transition from native back to >> the VM doesn't have to do anything with the pending_exception_check >> flag because well behaved native code in that context will explicitly >> check for exceptions, and so the pending-exception-check will already >> be disabled before returning to Java. First, if that is the case then >> we should assert that it is so in the native->VM return transition. > > Agreed, inserted assert. > >> >> Second though, it doesn't seem to be the case in Whitebox because the >> CHECK_JNI_EXCEPTION_ macro simply calls HAS_PENDING_EXCEPTION and so >> won't touch the pending-exception-check flag. ?? > > Doh, you are correct...I mistook this for the CHECK_JNI_EXCEPTION macro > in "java.c" which does perform check... > >> >> It was a good pick up that some whitebox code was using values that >> might be NULL because an exception had occurred. There are a couple of >> changes that are unnecessary though: >> >> 1235 result = env->NewObjectArray(5, clazz, NULL); >> 1236 CHECK_JNI_EXCEPTION_(env, NULL); >> 1237 if (result == NULL) { >> 1238 return result; >> 1239 } >> >> (and similarly at 1322) >> >> result will be NULL iff there is a pending exception; and vice-versa. >> So the existing check for NULL suffices for correctness. If you want >> to check exceptions for the side-effect of clearing the >> pending-exception-check flag then lines 1237-1239 can be deleted. >> However I would suggest that if you truly do want to clear the >> pending-exception-check flag then the place to do it is the WB_END >> macro. That allows allows exception checks at the end of methods, eg: >> >> 1261 env->SetObjectArrayElement(result, 4, entry_point); >> 1262 CHECK_JNI_EXCEPTION_(env, NULL); >> 1263 >> 1264 return result; >> >> to be elided. >> > > Agreed, introduce StackObj with appropriate destructor, removed the > checks above. > > >> --- >> >> hotspot/src/share/vm/runtime/thread.hpp >> >> ! // which function name. Returning to a Java frame should >> implicitly clear the >> ! // need for, this is done for Native->Java transitions. >> >> Seems to be some text missing after "need for". > > Thanks for seeing that, fixed. > >> >> --- >> >> For the tests we no longer use bug numbers as part of the test names. >> Looks like some recent tests slipped by unfortunately. :( >> > > Moved to "test/runtime/jni/checked" > >> You should be able to get rid of the: >> >> * @modules java.base/jdk.internal.misc >> >> with Christian's just pushed changes to ProcessTools to isolate the >> Unsafe dependency. >> > > Done > >>> core-libs & Kumar: java launcher: are you okay with the >>> CHECK_EXCEPTION_PRINT macro, or would you rather it was silent (i.e. >>> CHECK_EXCEPTION_RETURN) ? >> >> I'm not seeing the point of this logic. Any exceptions that remain >> pending when the main thread detaches from the VM will be reported by >> the uncaught-exception handling logic. The checks you put in are in >> most cases immediately before a return so there is no need to check >> for a pending exception and do an earlier return. And in one case you >> would bypass tracing logic by doing an early return. > > Removed all the extra checks, add JNI exception check to within the > existing CHECK_NULL0 macro (make more sense there). > >> >> I had assumed this was just some debugging code you had left in by >> mistake. > > The method invocations needed to find main class needs to check for the > test to pass. > > Cheers > /David From james.laskey at oracle.com Mon Aug 29 12:16:44 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 29 Aug 2016 09:16:44 -0300 Subject: RFR: JDK-8161000 - GPL header incorrect - classfile/classpath Message-ID: <27A58B57-EC64-4B26-97B6-3ACC5C3B907F@oracle.com> On behalf of Swamy http://cr.openjdk.java.net/~jlaskey/8161000/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161000 From Alan.Bateman at oracle.com Mon Aug 29 12:18:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Aug 2016 13:18:39 +0100 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: References: Message-ID: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> On 25/08/2016 04:55, Weijun Wang wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8164705/webrev.00 > > From the beginning of JDK, FilePermission canonicalizes the input path > and use the result in implies() and equals(). This has been a big > performance hurt and leads to confusing results when symlinks are > involved. > > The code change above removes the canonicalization. > > This means FilePermission on "/the/current/working/directory/x" no > longer implies that on "x". Since this might bring quite some > compatibility risk, the code change includes some tweaks in permission > checking to make sure an app is still able to read "x" when the > FilePermission granted is on "/the/current/working/directory/x". > However, we still hope the policy to be updated to be consistent of > how a file is actually accessed. > > No tweak is devoted to make granting "/this/is/a/symlink" to imply > reading of "/the/actual/target/file", because we think it should not. > > This is quite a big behavior change. If it breaks your app/lib, or > does not work with your customized security manager or policy > implementation, please let us know. > > Feel free to provide any feedback. > > Finally, a new system property "jdk.filepermission.canonicalize" is > introduced and it can be "true", "false", or "compat". The out-of-box > default is "compat", which means no canonicalization with check tweaks. I've taken a first pass over this. A general comment then it's great to see FilePermission changed to not do canonicalization. The "new behavior" approach to match paths and support absolute => relative and relative => absolute all makes sense. I agree that having a property to revert to legacy behavior make sense. Is there any way to reduce this down to just current and legacy behavior, it's otherwise too complicated to describe the subtle differences between "false" and "compat". If it can be reduced to two settings then a name such as jdk.io.permissionsUseCanonicalPath= could be better than the prototype name. For the implementation then I think it will cleanup before this is ready to push. FilePermCompat is a ugly, particularly FilePermission changing its public fields. Also method names like impliesWithAltFP, newPermPlusAltPath, ... could be re-visited to make them much clearer. For the test then it would be good if samepath.sh could be replaced with a non-shell test. -Alan From sundararajan.athijegannathan at oracle.com Mon Aug 29 12:20:26 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 29 Aug 2016 17:50:26 +0530 Subject: RFR: JDK-8161000 - GPL header incorrect - classfile/classpath In-Reply-To: <27A58B57-EC64-4B26-97B6-3ACC5C3B907F@oracle.com> References: <27A58B57-EC64-4B26-97B6-3ACC5C3B907F@oracle.com> Message-ID: <6d28a544-010d-40b5-c384-a4fde2e9e5fe@oracle.com> +1 -Sundar On 8/29/2016 5:46 PM, Jim Laskey (Oracle) wrote: > On behalf of Swamy > > http://cr.openjdk.java.net/~jlaskey/8161000/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8161000 From daniel.fuchs at oracle.com Mon Aug 29 13:10:49 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 29 Aug 2016 14:10:49 +0100 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> Message-ID: <0dd01d6c-dec4-3305-99f2-bb1fe4f09fee@oracle.com> Hi Peter, Mandy, On 20/08/16 21:17, Mandy Chung wrote: > It is a good observation. Pinning on a class loader is a good solution. On the other hand, the Level API isn?t well designed for customization (so does LogManager or Logger) that should be re-examined at some point in the future (which is one cause of the current complicated implementation). > > I think typical pattern would hold a strong reference to the custom level instances for the application/library use and so this compatibility risk may be relatively low. IMO, in the current state of logging API, it?s the subclass?s reponsibility to ensure the custom level instances are not garbage collected, like loggers (where LogManager::getLogger may return null if a logger is GC?ed). I think the right thing to do is to define a proper API for customization as a long-term solution. As for this issue, I don?t have a strong opinion in both approaches (using ClassLoaderValue vs Daniel?s current fix). > > Peter - in any case, as we have identified several usages for it, I suggest to file a separate bug to move ClassLoaderValue to a jdk.internal.xxx package. jdk.internal.loader may be a better home for it. Peter, thanks for doing the groundwork and putting ClassLoaderValue in jdk.internal.loader. I would have been reluctant to using it in this fix otherwise. Here is a new webrev that uses ClassLoaderValue as Peter suggested. http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/ I had to introduce a new private static class (KnownLevelCLV) to avoid using lambdas in KnownLevel.add - as CustomLevel.java was failing with an InternalError raised in MethodHandles$Lookup otherwise. The CustomLevel test is now sadly a bit more complex, as we have to introduce a new ClassLoader that can be garbage collected in order to test the fix. Otherwise the logic remains the same compared to webrev.03. best regards, and thanks for all the feedback! -- daniel > > Mandy > >> On Aug 17, 2016, at 4:20 AM, Peter Levart wrote: >> >> Hi Daniel, >> >> Thinking of this patch from the compatibility standpoint, aren't you afraid that someone might be using the following idiom: >> >> public class MyLevel extends java.util.logging.Level { >> static { >> new MyLevel("LEVEL1", 1); >> new MyLevel("LEVEL2", 2); >> ... >> } >> >> public static void init() {} >> >> private MyLevel(String name, int value) { >> super(name, value); >> } >> ... >> } >> >> ...and then use those levels in code like: >> >> MyLevel.init(); >> ... >> Level level = Level.parse("LEVEL1") ... >> >> >> With the proposed patch, this will not work any more as custom Level subclass instances will possibly be GCed before being "parsed" and retained. >> >> To prevent that from happening and still allow custom Level subclasses and their class loaders to be garbage-collectable, I recommend that you "pin" each constructed subclass instance to its ClassLoader with a strong reference. You could use a ClassLoaderValue for this purpose, like in the following addition to your patch (see KnownLevel.add): >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/ >> >> Regards, Peter >> >> >> On 08/16/2016 12:42 PM, Daniel Fuchs wrote: >>> Hi Mandy, >>> >>> I added an additional selector parameter to the find methods. >>> This made it possible to return Optional instead of >>> KnownLevel - and it does simply the parse() method. >>> >>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.02 >>> >>> best regards, >>> >>> -- daniel >>> >>> On 11/08/16 20:12, Mandy Chung wrote: >>>> >>>>> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs wrote: >>>>> >>>>> On 10/08/16 17:21, Mandy Chung wrote: >>>>>>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >>>>>> This looks pretty good. >>>>>> >>>>>> Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName, findByValue and findByLocalizedLevelName to return Optional instead such that the parse method implementaiton could be simplified. >>>>> >>>>> We need to return KnownLevel because sometimes we need the >>>>> level object and sometimes the mirror. >>>> >>>> So either findByName(String name, boolean mirror) or two methods: findLevelByName and findMirroredLevelByName?? >>>> >>>> Or seriously consider to remove KnownLevel class by introducing a new Level subclass with final Level.getName, Level.getLocalizedName, Level.getResourceBundleName methods?? >>>> >>>> Mandy >>>> >>> >> > From weijun.wang at oracle.com Mon Aug 29 13:13:58 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Aug 2016 21:13:58 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: <43be470d-930e-e3f2-5ed4-ede6ff6f2398@oracle.com> Hi Alan I am glad you think this change is useful. As for the 3-value property, in my opinion even the absolute <=> relative translation might not be really useful in a production environment. Who can guarantee a program is always launched from a certain directory and access a file using a relative path? I secretly wish this never happens and a brave user would set the property to false so that there is no need for any compatibility code. And yes, samepath.sh was from a very early stage of this change and I should rewrite it. Thanks Max On 8/29/2016 20:18, Alan Bateman wrote: > On 25/08/2016 04:55, Weijun Wang wrote: > >> Hi All >> >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8164705/webrev.00 >> >> From the beginning of JDK, FilePermission canonicalizes the input path >> and use the result in implies() and equals(). This has been a big >> performance hurt and leads to confusing results when symlinks are >> involved. >> >> The code change above removes the canonicalization. >> >> This means FilePermission on "/the/current/working/directory/x" no >> longer implies that on "x". Since this might bring quite some >> compatibility risk, the code change includes some tweaks in permission >> checking to make sure an app is still able to read "x" when the >> FilePermission granted is on "/the/current/working/directory/x". >> However, we still hope the policy to be updated to be consistent of >> how a file is actually accessed. >> >> No tweak is devoted to make granting "/this/is/a/symlink" to imply >> reading of "/the/actual/target/file", because we think it should not. >> >> This is quite a big behavior change. If it breaks your app/lib, or >> does not work with your customized security manager or policy >> implementation, please let us know. >> >> Feel free to provide any feedback. >> >> Finally, a new system property "jdk.filepermission.canonicalize" is >> introduced and it can be "true", "false", or "compat". The out-of-box >> default is "compat", which means no canonicalization with check tweaks. > I've taken a first pass over this. A general comment then it's great to > see FilePermission changed to not do canonicalization. The "new > behavior" approach to match paths and support absolute => relative and > relative => absolute all makes sense. > > I agree that having a property to revert to legacy behavior make sense. > Is there any way to reduce this down to just current and legacy > behavior, it's otherwise too complicated to describe the subtle > differences between "false" and "compat". If it can be reduced to two > settings then a name such as > jdk.io.permissionsUseCanonicalPath= could be better than the > prototype name. > > For the implementation then I think it will cleanup before this is ready > to push. FilePermCompat is a ugly, particularly FilePermission changing > its public fields. Also method names like impliesWithAltFP, > newPermPlusAltPath, ... could be re-visited to make them much clearer. > > For the test then it would be good if samepath.sh could be replaced with > a non-shell test. > > -Alan From eatnumber1 at google.com Thu Aug 25 19:39:36 2016 From: eatnumber1 at google.com (Russ Harmon) Date: Thu, 25 Aug 2016 19:39:36 +0000 Subject: Filing Bugs Against the Core Libs Message-ID: Hello, I'd like to report a (minor) feature request / bug in the core libs. What's the best way for me to do that? I recently ran into this stack trace . It's not very useful to me, since I can't determine from either the message or the stack trace why the task was rejected. It would be much more helpful if either a) the message stated the reason, or b) the stack trace pointed at a line of code which unambiguously indicated a reason (e.x. a list of "if" statements which throw this exception, so I can look at the condition to see why the task was rejected) Thanks, Russ Harmon Google Site Reliability Engineer From xueming.shen at oracle.com Mon Aug 29 16:26:14 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 29 Aug 2016 09:26:14 -0700 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> Message-ID: <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> On 8/27/16 12:57 AM, Alan Bateman wrote: > On 26/08/2016 17:48, Xueming Shen wrote: > >> Hi, >> >> This is a aged rfe from Paul's code review comments for the old code. >> base. The >> implementation has been changed lots since. Some has gone, some has >> been updated >> accordingly. Just went through the list and here is the change set >> for some minor issues >> still present. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8066577 >> webrev: http://cr.openjdk.java.net/~sherman/8066577/webrev > You might want to re-check the synchronization in JrtDirectoryStream, > it looks the next/hasNext methods are synchronizing on the Iterator > instance. > > -Alan. Hi Webrev has been updated accordingly http://cr.openjdk.java.net/~sherman/8066577/webrev/ (1) the iterator is to synchronize on JrtDirectoryStream.this (2) to use Collections.singleton() as Claes suggested. It appears the "singleton set" is better choice (light) in this case. thanks, Sherman From paul.sandoz at oracle.com Mon Aug 29 17:04:36 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 29 Aug 2016 10:04:36 -0700 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> Message-ID: <74C89B3B-0235-44FC-B8E8-E13042E71727@oracle.com> Thanks, updated in place, Paul. > On 26 Aug 2016, at 17:20, Stuart Marks wrote: > > Hi Paul, > > Overall looks good. > > A couple minor wording comments. For the 3-arg collectors, the combiner arg is defined as > > * @param combiner an associative, > * non-interfering, > * stateless > * function that accepts two partial result containers and > * merges them, which must be compatible with the accumulator > * function. The combiner function folds the elements in > * result container that is the second argument into the > * result container that is the first argument. > > I'd suggest replacing the last sentence with > > The combiner function must fold the elements from the second > result container into the first result container. > > I think it's implicitly pretty clear that the first and second result containers are the first and second arguments to the combiner function. > > If you're ok with the "must fold" style, then maybe also update the accumulator arg spec > > * @param accumulator an associative, > * non-interfering, > * stateless > * function that folds an element into a result container. > > from "that folds" to "that must fold". That way all three args use the "must" style wording. > > I think the same wording is present in all four Stream types. > > s'marks > > > On 8/26/16 4:13 PM, Paul Sandoz wrote: >> Hi, >> >> Please review some minor tweaks to the stream specification: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691-stream-iterate-collect-spec-updates/webrev/index.html >> >> The first tweak is to clarify the iterate methods and HB edges between function calls, the functions could potentially be stateful, they will never be called concurrently due to the nature of the source, but may be called in different threads. >> >> The second tweak is to the three-arg collect method. The combiner of result containers neglected to state how result containers should be merged. >> >> Thanks, >> Paul. >> From paul.sandoz at oracle.com Mon Aug 29 17:12:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 29 Aug 2016 10:12:24 -0700 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> Message-ID: <47BFA592-58E8-4F75-9FA8-8BAA81E75385@oracle.com> > On 29 Aug 2016, at 09:26, Xueming Shen wrote: > > On 8/27/16 12:57 AM, Alan Bateman wrote: >> On 26/08/2016 17:48, Xueming Shen wrote: >> >>> Hi, >>> >>> This is a aged rfe from Paul's code review comments for the old code. base. The >>> implementation has been changed lots since. Some has gone, some has been updated >>> accordingly. Just went through the list and here is the change set for some minor issues >>> still present. >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8066577 >>> webrev: http://cr.openjdk.java.net/~sherman/8066577/webrev >> You might want to re-check the synchronization in JrtDirectoryStream, it looks the next/hasNext methods are synchronizing on the Iterator instance. >> >> -Alan. > > > Hi > > Webrev has been updated accordingly > > http://cr.openjdk.java.net/~sherman/8066577/webrev/ > > (1) the iterator is to synchronize on JrtDirectoryStream.this > +1 > (2) to use Collections.singleton() as Claes suggested. It appears the "singleton set" is > > better choice (light) in this case. > Yes, better choice, Paul. From amaembo at gmail.com Mon Aug 29 17:18:09 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 29 Aug 2016 20:18:09 +0300 Subject: RFR 8164691 Stream specification clarifications for iterate and collect In-Reply-To: <74C89B3B-0235-44FC-B8E8-E13042E71727@oracle.com> References: <10D2F507-67D4-44BC-9BAE-05B6A3BECE90@oracle.com> <74C89B3B-0235-44FC-B8E8-E13042E71727@oracle.com> Message-ID: Hello! Changes look ok to me, thanks. With best regards, Tagir Valeev. On Mon, Aug 29, 2016 at 8:04 PM, Paul Sandoz wrote: > Thanks, updated in place, > Paul. > > > On 26 Aug 2016, at 17:20, Stuart Marks wrote: > > > > Hi Paul, > > > > Overall looks good. > > > > A couple minor wording comments. For the 3-arg collectors, the combiner > arg is defined as > > > > * @param combiner an associative, > > * non- > interfering, > > * stateless > > * function that accepts two partial result containers > and > > * merges them, which must be compatible with the > accumulator > > * function. The combiner function folds the elements > in > > * result container that is the second argument into > the > > * result container that is the first argument. > > > > I'd suggest replacing the last sentence with > > > > The combiner function must fold the elements from the second > > result container into the first result container. > > > > I think it's implicitly pretty clear that the first and second result > containers are the first and second arguments to the combiner function. > > > > If you're ok with the "must fold" style, then maybe also update the > accumulator arg spec > > > > * @param accumulator an associative, > > * non- > interfering, > > * stateless > > * function that folds an element into a result > container. > > > > from "that folds" to "that must fold". That way all three args use the > "must" style wording. > > > > I think the same wording is present in all four Stream types. > > > > s'marks > > > > > > On 8/26/16 4:13 PM, Paul Sandoz wrote: > >> Hi, > >> > >> Please review some minor tweaks to the stream specification: > >> > >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691- > stream-iterate-collect-spec-updates/webrev/index.html < > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691- > stream-iterate-collect-spec-updates/webrev/index.html> > >> > >> The first tweak is to clarify the iterate methods and HB edges between > function calls, the functions could potentially be stateful, they will > never be called concurrently due to the nature of the source, but may be > called in different threads. > >> > >> The second tweak is to the three-arg collect method. The combiner of > result containers neglected to state how result containers should be merged. > >> > >> Thanks, > >> Paul. > >> > > From brian.burkhalter at oracle.com Mon Aug 29 18:05:50 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 29 Aug 2016 11:05:50 -0700 Subject: Filing Bugs Against the Core Libs In-Reply-To: References: Message-ID: <641C1449-E31C-4937-BAB6-89B603A2FCD6@oracle.com> Hello, You can report issues via [1] or if you have a Java Bug System ID via [2]. Brian [1] http://bugs.java.com/ [2] https://bugs.openjdk.java.net/secure/Dashboard.jspa On Aug 25, 2016, at 12:39 PM, Russ Harmon wrote: > Hello, > > I'd like to report a (minor) feature request / bug in the core libs. What's > the best way for me to do that? > > I recently ran into this stack trace > . It's > not very useful to me, since I can't determine from either the message or > the stack trace why the task was rejected. It would be much more helpful if > either a) the message stated the reason, or b) the stack trace pointed at a > line of code which unambiguously indicated a reason (e.x. a list of "if" > statements which throw this exception, so I can look at the condition to > see why the task was rejected) > > Thanks, > Russ Harmon > Google Site Reliability Engineer From Alan.Bateman at oracle.com Mon Aug 29 18:08:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Aug 2016 19:08:56 +0100 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> Message-ID: On 29/08/2016 17:26, Xueming Shen wrote: > > > Hi > > Webrev has been updated accordingly > > http://cr.openjdk.java.net/~sherman/8066577/webrev/ > > (1) the iterator is to synchronize on JrtDirectoryStream.this > > (2) to use Collections.singleton() as Claes suggested. It appears the > "singleton set" is > > better choice (light) in this case. This looks okay to me. From claes.redestad at oracle.com Mon Aug 29 18:10:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 29 Aug 2016 20:10:28 +0200 Subject: RFR: 8164858: Enable build-time use of java.lang.invoke resolve tracing Message-ID: <57C47A94.30805@oracle.com> Hi, this patch adds generation of a trace of resolved java.lang.invoke classes when generating the classlist, and uses this trace as input when linking the runtime images. Bug: https://bugs.openjdk.java.net/browse/JDK-8164858 Webrevs: http://cr.openjdk.java.net/~redestad/8164858/top.01/ http://cr.openjdk.java.net/~redestad/8164858/jdk.01/ This allows for a small reduction of the number of classes generated during bootstrap across a wide set of applications. Thanks! /Claes From huizhe.wang at oracle.com Mon Aug 29 18:43:41 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 29 Aug 2016 11:43:41 -0700 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <87eg58n7vx.fsf@v45346.1blu.de> References: <87eg58n7vx.fsf@v45346.1blu.de> Message-ID: <57C4825D.5070307@oracle.com> Hi Stefan, If you are using the built-in extension functions, try turning on the following feature: private static final String ENABLE_EXTENSION_FUNCTIONS = "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"; tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); If you are using user-extension functions, then add the following: private static final String EXTENSION_CLASS_LOADER = "jdk.xml.transform.extensionClassLoader"; tf.setAttribute(EXTENSION_CLASS_LOADER, cl); where cl is the user-specified ClassLoader that will load external extension function classes, e.g. runWithPermission(() -> Thread.currentThread().getContextClassLoader()) HTH, and please let me know if it works for you. Thanks, Joe On 8/28/16, 10:03 AM, Stefan Bodewig wrote: > Hi, > > I've been told to ask for advice here. > > Over the past few weeks we've adapted the Apache Ant code base to JDK 9 > well enough that Ant's own test suite works - almost. > > The onyl remaining issue really goes back to Java 1.7 and JAXP 1.4 when > secure processing was introduced. If you are running an XSLT transform > and it needs extensions - say the Xalan redirect extension - you can't > do it if a SecurityManager has been set. > > https://bz.apache.org/bugzilla/show_bug.cgi?id=51668 > > This is causing quite a few problems for users running Ant from within > IDEs which typically install SecurityManagers. One such instance it > Ant's own task which uses XSLT and the redirect extension. > > Back in Java 1.7 we "solved" the problem with a hack. We simply disable > secure processing mode via reflection > > https://github.com/apache/ant/commit/fe829a9d0fa679df3ae2cc4803e5236ed2ed5c7b > > The module system now breaks the hack as we can no longer access the > necessary field via reflection. > > Before we try to find new clever or stupid workarounds we may as well > ask for advice on how to do it properly. > > This is our use-case: The user wants to execute Ant's-Task from > within Eclipse which has installed a SecurityManager and the transform > requires an extension. How can we make this work? > > Cheers > > Stefan From amaembo at gmail.com Mon Aug 29 19:01:11 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 29 Aug 2016 22:01:11 +0300 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> Message-ID: Hello! > (2) to use Collections.singleton() as Claes suggested. It appears the "singleton set" is > better choice (light) in this case. Btw why not new-and-cool Set.of() ? http://download.java.net/java/jdk9/docs/api/java/util/Set.html#of-E- With best regards, Tagir Valeev. From claes.redestad at oracle.com Mon Aug 29 19:04:22 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 29 Aug 2016 21:04:22 +0200 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> Message-ID: <57C48736.8060909@oracle.com> Hi, On 2016-08-29 21:01, Tagir Valeev wrote: > Hello! > >> (2) to use Collections.singleton() as Claes suggested. It appears the > "singleton set" is >> better choice (light) in this case. > > Btw why not new-and-cool Set.of() ? > http://download.java.net/java/jdk9/docs/api/java/util/Set.html#of-E- this is a bit subtle, but there's a special restriction on the jrtfs code to only use 8-compatible APIs to be able to produce the jrt-fs.jar that can be used on JDK 8 to interact with Java 9 runtime images. Thanks! /Claes From amaembo at gmail.com Mon Aug 29 19:08:49 2016 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 29 Aug 2016 22:08:49 +0300 Subject: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code In-Reply-To: <57C48736.8060909@oracle.com> References: <57C072C4.9000108@oracle.com> <9f929b97-32d7-7bde-9cc5-991c65c8e060@oracle.com> <112d3e8b-1cdd-a75f-fa99-a32209a76934@oracle.com> <57C48736.8060909@oracle.com> Message-ID: Hello! > this is a bit subtle, but there's a special restriction on the jrtfs > code to only use 8-compatible APIs to be able to produce the jrt-fs.jar > that can be used on JDK 8 to interact with Java 9 runtime images. > Ah, I see. Thank you for explanation. With best regards, Tagir Valeev. From huizhe.wang at oracle.com Mon Aug 29 19:18:02 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 29 Aug 2016 12:18:02 -0700 Subject: RFR: 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected. Message-ID: <57C48A6A.1070607@oracle.com> Hi, Please review a patch that fixes an issue where circular references were not caught if catalogs are pre-loaded. Note that to trigger the issue (circular references), the Catalog must be instructed to load additional catalogs. This can be done by either setting DEFER to false, or providing an uri that does not have a match in the current catalog (thus causes the CatalogResolver to load alternative catalogs). When the uri is empty as in the original JCK test, the CatalogResolver will skip the resolution and therefore no additional catalogs will be loaded. In the unit test, the test (copied from the JCK test) is fixed by adding a bogus uri 'anyuri'. The JCK test will need a similar fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8162431 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8162431/webrev/ Thanks, Joe From steve.drach at oracle.com Mon Aug 29 19:43:12 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 29 Aug 2016 12:43:12 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware Message-ID: Hi, Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with ?version #/? where version # is 9, 10, etc. webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/ http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ issue: https://bugs.openjdk.java.net/browse/JDK-8153654 Thanks Steve From mandy.chung at oracle.com Mon Aug 29 20:10:29 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Aug 2016 13:10:29 -0700 Subject: RFR: 6543126: Level.known can leak memory In-Reply-To: <0dd01d6c-dec4-3305-99f2-bb1fe4f09fee@oracle.com> References: <18377964-f7c7-e1a2-4cb5-05df2085bb5a@oracle.com> <5AFBD1B8-CC0E-4EBD-8A0E-F674A03920AE@oracle.com> <8698947C-1B48-4E86-ACDD-BF677B057C73@oracle.com> <0eb47d44-09c4-c461-447d-172d335c09d4@oracle.com> <6b05dd74-d0ed-e63f-a7fb-1a3bb1927dfb@gmail.com> <7999F927-ADBF-4C1E-B629-9C8284361359@oracle.com> <0dd01d6c-dec4-3305-99f2-bb1fe4f09fee@oracle.com> Message-ID: > On Aug 29, 2016, at 6:10 AM, Daniel Fuchs wrote: > > Here is a new webrev that uses ClassLoaderValue as Peter suggested. > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.04/ > Looks good in general. 553 // KnowLevelCLV is used to register custom level instances with typo: s/KnowLevelCLV/KnownLevelCLV 568 final Level level; Nit: perhaps renaming level to customLevel to make it clear what this is. line 645, 646: s/gced/GC?ed/ > I had to introduce a new private static class (KnownLevelCLV) > to avoid using lambdas in KnownLevel.add - as CustomLevel.java > was failing with an InternalError raised in MethodHandles$Lookup > otherwise. I agree it?s good to make progress on JDK-6543126. I think it?d be good to understand how we get to this InternalError during bindCaller. Can you file a low priority JBS issue to track that? Mandy From huizhe.wang at oracle.com Mon Aug 29 21:57:52 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 29 Aug 2016 14:57:52 -0700 Subject: RFR (JAXB): 8159240: XSOM parser incorrectly processes type names with whitespaces In-Reply-To: <8ceba21b-dd0c-6caf-1f3d-f4c3811929a0@oracle.com> References: <8ceba21b-dd0c-6caf-1f3d-f4c3811929a0@oracle.com> Message-ID: <57C4AFE0.2030607@oracle.com> Hi Aleksej, The patch is fine. As we discussed, it's too bad the case [number]s were not universally unique in identifying the types (that makes it hard for the code maintenance), otherwise we would have been able to consolidate the collapse calls by types. We can live with the code as is, but we'll keep this in mind in case we may touch these code again. Thanks, Joe On 8/25/16, 5:33 AM, Aleks Efimov wrote: > Hello, > Please, help to review the JDK9 changes in JAXB XSOM parser that > solves issue [0] with incorrectly collapsed namespaces within schema > types names definitions/usages: > http://cr.openjdk.java.net/~aefimov/8159240/9/00/ > > Problem description: > The XMLSchema defines that whitespaces should be collapsed for type > names and different attribute values that can contain type names. > Examples are: > - 'name' attribute value for 'xsd:simpleType', 'xsd:complexType', > 'xsd:attribute' > - 'type' attribute value for 'xsd:attribute' > - 'base' attribute value for 'xsd:restriction' > Almost all type values for such attributes are inherited from NCName > or QName schema types. Both types are defined with whiteSpace > restriction set to "collapse" [1]. > > The XSOM parser state machine was reversed engineered and all NCName > and QName typed values are now collapsed to match the schema definitions. > New regression test was executed alongside to JTREG and JCK tests - no > failures. > > With Best Regards, > Aleksej > > [0] https://bugs.openjdk.java.net/browse/JDK-8159240 > [1] https://www.w3.org/2001/XMLSchema.xsd > [2] XSOM parser page: https://xsom.java.net/ > From alexandre.iline at oracle.com Mon Aug 29 22:15:51 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 29 Aug 2016 15:15:51 -0700 Subject: RFR: 8164982 Fix legal notices in java/lang, java/net, java/util tests. In-Reply-To: <57B25AD3.9000104@oracle.com> References: <57B25AD3.9000104@oracle.com> Message-ID: <05A207F4-7F0E-43AF-92C8-272EA9B035F8@oracle.com> Hi. Webrev: http://cr.openjdk.java.net/~shurailine/8164982/webrev.00/ This was previously reviewed as part of [1]. The script for generating these changes is in process of being fixed. Meanwhile, I suggest to start integrating portions of the work. The tests included in this fix have already been reviewed by Joe [2]. I have also re-reviewed the changes to make sure the problem noted by Iris [3] is not present in these tests. I assume this change can be integrated, then. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004643.html [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004645.html [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004651.html > On Aug 15, 2016, at 5:14 PM, Joseph D. Darcy wrote: > > The lang, net, and util changes looks fine; cheers, > > -Joe > > On 8/15/2016 11:39 AM, Alexandre (Shura) Iline wrote: >> Hi, >> >> Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. >> >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >> >> I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. >> >> Shura >> > From martinrb at google.com Mon Aug 29 22:32:50 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 29 Aug 2016 15:32:50 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> Message-ID: We had already agreed on making these changes, and the detail looks good, so approved! but ... I wish there was less confusion ... maybe it's unavoidable ... I'm going to check the docs carefully every time I use one of these APIs! ... feel free to ignore rambling: I am having second thoughts about whether it's too late to fix our API wart. Suppose we make weakCompareAndSet the one with volatile semantics and weakCompareAndSetPlain the one with plain semantics? The normal rule is never to change the definition of an API, but here: - we would only be strengthening the API, so previous users of weakCompareAndSet will not be broken - all known historical implementations of weakCompareAndSet pre-jdk9 in fact delegated to volatile CAS (is this true?), so future users of weakCompareAndSet will not be broken in practice when their software is used on jdk8. On Thu, Aug 25, 2016 at 1:48 PM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164814-- > atomics-weakCompareAndSet-deprecate/webrev/ psandoz/jdk9/JDK-8164814--atomics-weakCompareAndSet-deprecate/webrev/> > > This patch deprecates weakCompareAndSet and adds a new method > weakCompareAndSetPlain. The intent is to avoid confusion over the memory > effects of such methods, since other read-modify-write methods, with > unqualified names, have volatile memory effects. > > I just modified atomic classes that have already been updated for Java 9 > [*]. > > Paul. > > [*] atomic classes not updated: > AtomicIntegerFieldUpdater > AtomicLongFieldUpdater > AtomicMarkableReference > AtomicReferenceFieldUpdater > AtomicStampedReference > > From paul.sandoz at oracle.com Mon Aug 29 23:12:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 29 Aug 2016 16:12:40 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> Message-ID: <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> > On 29 Aug 2016, at 15:32, Martin Buchholz wrote: > > We had already agreed on making these changes, and the detail looks good, so approved! > Thanks. > but ... I wish there was less confusion ... maybe it's unavoidable ... I'm going to check the docs carefully every time I use one of these APIs! ... feel free to ignore rambling: > > I am having second thoughts about whether it's too late to fix our API wart. Suppose we make weakCompareAndSet the one with volatile semantics and weakCompareAndSetPlain the one with plain semantics? The normal rule is never to change the definition of an API, but here: > > - we would only be strengthening the API, so previous users of weakCompareAndSet will not be broken > - all known historical implementations of weakCompareAndSet pre-jdk9 in fact delegated to volatile CAS (is this true?), so future users of weakCompareAndSet will not be broken in practice when their software is used on jdk8. > .. and deprecate weakCompareAndSetVolatile? I did wonder about that, it seems a little sneaky, so i did not pursue it, existing uses will still function but not necessarily to the same degree, so it could still be perceived as broken. There are however very few use-cases of these methods. I used such usage analysis to justify depreciation, but I suppose that same analysis could also justify a change in behaviour. Thoughts? Paul. From mandy.chung at oracle.com Mon Aug 29 23:59:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Aug 2016 16:59:41 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: References: Message-ID: Hi Steve, > On Aug 29, 2016, at 12:43 PM, Steve Drach wrote: > > Hi, > > Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with ?version #/? where version # is 9, 10, etc. > > webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/ This looks quite good. JDK-8163798 and JDK-8164665 will define public APIs to get the versioned entries and real name which I think are useful for tools. It?s fine to proceed with this change and update jdeps to use the public APIs when available. This patch parse MR-JAR only if ?-multi-release option is specified. It would also be useful to analyze all versioned entries for the default option (i.e. analyze direct dependencies from class files) that can be done in a separate RFE. Comments to this patch: ClassFileReader.java 386 if (Integer.parseInt(v) < 9) { 387 String[] msg = {"err.multirelease.jar.malformed", 388 jarfile.getName(), rn 389 }; 390 throw new MultiReleaseException(msg); 391 } To get here, I can think of the case when it?s not a MRJAR (so JarFile::stream returns all entries). If it?s a MR-JAR, the JarFile will be opened with a valid version. versionedStream should only return the proper versioned entries. Maybe you should emit warning (add it to skippedEntries if this happens) or make it an assert. 382 if (rn.startsWith("META-INF/versions/")) { 383 int n = rn.indexOf('/', 18); // "META-INF/versions/".length() 421 final String META_INF_VERSIONS = "META-INF/versions/?; 429 if (name.length() > META_INF_VERSIONS.length()) { They both extract the version of this entry. This can be refactored to add a method like VersionHelper::getVersion(JarEntry). versionedStream method may be better to be moved to VersionHelper. 442 return (version == jf.getVersion().major() && vStr.length() > offset + 1) This version only selects the entries in the base section and versioned section. Can you add the following scenario in the new test and Bar and Gee are public and shows the result when -?multi-release 9 or 10 or base? p/Foo.class META-INF/versions/9/p/Foo.class META-INF/versions/9/q/Bar.class META-INF/versions/10/q/Bar.class META-INF/versions/10/q/Gee.class JDK-8163798 would cover more scenarios in depth. I?m okay to use the versionedStream you have and leave that to JDK-8163798. BTW the copyright header is missing in the new tests. JdepsTask.java 401 throw new BadArgs("err.multirelease.option.illegal", arg); You can simply use err.invalid.arg.for.option which I think is simple and adequate. MultiReleaseException.java 47 public MultiReleaseException(String[] err) { It would be better to have a key parameter: MultiReleaseException(String key, String? param). VersionHelper.java 40 public static String get(String origin) { s/origin/classname to make the param clearer. jdeps.properties: what about a shorter version: --multi-release Specifies the version when processing multi-release jar files. can be >= 9 or base. > http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ The use of shared secrets is just temporary and I hope it will soon be replaced with a public API when JDK-8164665 is resolved. Mandy From peter.firmstone at zeus.net.au Tue Aug 30 02:07:55 2016 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 30 Aug 2016 12:07:55 +1000 (AEST) Subject: RFR 9: JEP 290: Filter Incoming Serialization Data Message-ID: <2f90677813f116b248c177e667d95e60@org.tizen.email> ??Include original message A quick thought on the array size filter: The system creates an array with a size read from the stream. If Mallory sends a multidimensional array in the stream, then Mallory can consume all jvm memory without exceeding the array size limit or the stream data limit. We also need an array combined length limit. Thanks, Peter. Sent from my Samsung device. ? From david.holmes at oracle.com Tue Aug 30 02:27:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 12:27:36 +1000 Subject: Filing Bugs Against the Core Libs In-Reply-To: References: Message-ID: <06c9d8fd-5b50-1285-0621-ca89ab5e5378@oracle.com> Hi Russ, On 26/08/2016 5:39 AM, Russ Harmon wrote: > Hello, > > I'd like to report a (minor) feature request / bug in the core libs. What's > the best way for me to do that? Brian already gave you the general answer, but in this case one of your colleagues at Google, Martin Buccholz, is one of the primary maintainers of the java.util.concurrent code. > I recently ran into this stack trace > . It's > not very useful to me, since I can't determine from either the message or > the stack trace why the task was rejected. It would be much more helpful if > either a) the message stated the reason, or b) the stack trace pointed at a > line of code which unambiguously indicated a reason (e.x. a list of "if" > statements which throw this exception, so I can look at the condition to > see why the task was rejected) It is documented to be thrown: * If the task cannot be submitted for execution, either because this * executor has been shutdown or because its capacity has been reached, * the task is handled by the current {@code RejectedExecutionHandler}. The actual code that throws it doesn't know the exact reason. But you seem to be running a custom RejectedExeceptionHandler so it should be able to determine whether the executor is shutdown, or if using a bounded queue which may have become full. Cheers, David > Thanks, > Russ Harmon > Google Site Reliability Engineer > From weijun.wang at oracle.com Tue Aug 30 03:07:53 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Aug 2016 11:07:53 +0800 Subject: RFR 8164705: Remove pathname canonicalization from FilePermission In-Reply-To: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> References: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com> Message-ID: <6712f403-4418-dbae-1679-d43bf01d69f1@oracle.com> On 8/29/2016 20:18, Alan Bateman wrote: > FilePermCompat is a ugly, particularly FilePermission changing its > public fields. Do you prefer the traditional SharedSecrets way? SharedSecrets.setJavaIoFilePermissionAccess( new JavaIoFilePermissionAccessImpl()); > Also method names like impliesWithAltFP, > newPermPlusAltPath, ... could be re-visited to make them much clearer. Oh, I stuffed the verb and prepositional phrase into the method name to make it clearer. Or you don't like the abbreviations? Thanks Max From iris.clark at oracle.com Tue Aug 30 03:19:18 2016 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 29 Aug 2016 20:19:18 -0700 (PDT) Subject: RFR: 8164982 Fix legal notices in java/lang, java/net, java/util tests. In-Reply-To: <05A207F4-7F0E-43AF-92C8-272EA9B035F8@oracle.com> References: <57B25AD3.9000104@oracle.com> <05A207F4-7F0E-43AF-92C8-272EA9B035F8@oracle.com> Message-ID: Hi, Shura. > Webrev: http://cr.openjdk.java.net/~shurailine/8164982/webrev.00/ The problem noted in [3] is not present in the latest webrev. The changes look fine with me. Thanks, iris -----Original Message----- From: Alexandre (Shura) Iline Sent: Monday, August 29, 2016 3:16 PM To: core-libs-dev Subject: RFR: 8164982 Fix legal notices in java/lang, java/net, java/util tests. Hi. Webrev: http://cr.openjdk.java.net/~shurailine/8164982/webrev.00/ This was previously reviewed as part of [1]. The script for generating these changes is in process of being fixed. Meanwhile, I suggest to start integrating portions of the work. The tests included in this fix have already been reviewed by Joe [2]. I have also re-reviewed the changes to make sure the problem noted by Iris [3] is not present in these tests. I assume this change can be integrated, then. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004643.html [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004645.html [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004651.html > On Aug 15, 2016, at 5:14 PM, Joseph D. Darcy wrote: > > The lang, net, and util changes looks fine; cheers, > > -Joe > > On 8/15/2016 11:39 AM, Alexandre (Shura) Iline wrote: >> Hi, >> >> Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. >> >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >> >> I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. >> >> Shura >> > From david.holmes at oracle.com Tue Aug 30 04:49:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 14:49:35 +1000 Subject: Filing Bugs Against the Core Libs In-Reply-To: References: <06c9d8fd-5b50-1285-0621-ca89ab5e5378@oracle.com> Message-ID: On 30/08/2016 1:25 PM, Russ Harmon wrote: > On Mon, Aug 29, 2016 at 7:27 PM David Holmes > wrote: > > Hi Russ, > > On 26/08/2016 5:39 AM, Russ Harmon wrote: > > Hello, > > > > I'd like to report a (minor) feature request / bug in the core > libs. What's > > the best way for me to do that? > > Brian already gave you the general answer, but in this case one of your > colleagues at Google, Martin Buccholz, is one of the primary maintainers > of the java.util.concurrent code. > > > Thanks for the pointer. I'll reach out to Martin. > > > > I recently ran into this stack trace > > > . > It's > > not very useful to me, since I can't determine from either the > message or > > the stack trace why the task was rejected. It would be much more > helpful if > > either a) the message stated the reason, or b) the stack trace > pointed at a > > line of code which unambiguously indicated a reason (e.x. a list > of "if" > > statements which throw this exception, so I can look at the > condition to > > see why the task was rejected) > > It is documented to be thrown: > > * If the task cannot be submitted for execution, either because this > * executor has been shutdown or because its capacity has been > reached, > * the task is handled by the current {@code > RejectedExecutionHandler}. > > The actual code that throws it doesn't know the exact reason. > > > To my understanding though, the reason is not outside of the purview of > the JDK (aka, the rejection is not decided upon by outside code), and > therefore some refactoring of the existing code could make it known. Yes, but it would take a lot of reworking to allow the reason to bubble back up to the level where the decision to reject is made. Possible but probably detrimental to the common case of there being no rejection. > > But you > seem to be running a custom RejectedExeceptionHandler so it should be > able to determine whether the executor is shutdown, or if using a > bounded queue which may have become full. > > > There's a race condition if I do that. If the executor has not been > shutdown, and the executor has reached capacity, the > RejectedExceptionHandler will be called. I can then check the queue size > in the RejectedExceptionHandler, but it's possible that tasks completed > before I'm able to check the size, so the queue won't appear full. > > I think that this is actually what has occurred in my case. The stack > trace I linked earlier shows a non-full queue, but I know that the > executor was not shutting down. Therefore, it must have been caused by > the queue filling up, then depleting before the size was read for > generation of the error message. Yes that is true, if the bounded queue is the problem then rejection is a transient condition. Of course if you know that you haven't shutdown the executor then a (transiently) full queue must be the reason. Cheers, David > > Cheers, > David > > > Thanks, > > Russ Harmon > > Google Site Reliability Engineer > > > From erik.joelsson at oracle.com Tue Aug 30 08:20:05 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Aug 2016 10:20:05 +0200 Subject: RFR: 8164858: Enable build-time use of java.lang.invoke resolve tracing In-Reply-To: <57C47A94.30805@oracle.com> References: <57C47A94.30805@oracle.com> Message-ID: Build changes look good. /Erik On 2016-08-29 20:10, Claes Redestad wrote: > Hi, > > this patch adds generation of a trace of resolved java.lang.invoke > classes when generating the classlist, and uses this trace as input > when linking the runtime images. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164858 > > Webrevs: > http://cr.openjdk.java.net/~redestad/8164858/top.01/ > http://cr.openjdk.java.net/~redestad/8164858/jdk.01/ > > This allows for a small reduction of the number of classes generated > during bootstrap across a wide set of applications. > > Thanks! > > /Claes From bodewig at apache.org Tue Aug 30 16:34:02 2016 From: bodewig at apache.org (Stefan Bodewig) Date: Tue, 30 Aug 2016 18:34:02 +0200 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <57C4825D.5070307@oracle.com> (Joe Wang's message of "Mon, 29 Aug 2016 11:43:41 -0700") References: <87eg58n7vx.fsf@v45346.1blu.de> <57C4825D.5070307@oracle.com> Message-ID: <87oa4ai5c5.fsf@v45346.1blu.de> Hi Joe On 2016-08-29, Joe Wang wrote: > If you are using the built-in extension functions, try turning on the > following feature: > private static final String ENABLE_EXTENSION_FUNCTIONS = > "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"; > tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); This is not supported by Xalan's TransformerFactoryImpl: /devel/ASF/ant/build.xml:1744: Errors while applying transformations: javax.xml.transform.TransformerConfigurationException: Cannot set the feature 'http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions' on this TransformerFactory. at org.apache.xalan.processor.TransformerFactoryImpl.setFeature(TransformerFactoryImpl.java:413) When removing Xalan from the classpath and using the JDK's own TransformerFactory I get ,---- | Error! Use of the extension element 'redirect' is not allowed when the | secure processing feature is set to true. `---- even with the feature enabled. So "redirect" - i.e. xmlns:redirect="http://xml.apache.org/xalan/redirect" - which I assumed to be "built-in" for the JDK's fork of Xalan as well - doesn't seem to get through with just that. > If you are using user-extension functions, then add the following: > private static final String EXTENSION_CLASS_LOADER = > "jdk.xml.transform.extensionClassLoader"; > tf.setAttribute(EXTENSION_CLASS_LOADER, cl); > where cl is the user-specified ClassLoader that will load external > extension function classes, e.g. > runWithPermission(() -> > Thread.currentThread().getContextClassLoader()) This attribute isn't supported by Xalan either. Testing this further is going to require a bit more of setup, I'll be traveling the coming days but will give it a try during the weekend. Unfortunately this is going to be cumbersome for our users as Xalan must not be on the system classloader (I'd get Xalan's TransformerFactory in that case) and tasks that didn't require any classpath management suddenly need a more extensive configration. Many thanks Stefan From aleksej.efimov at oracle.com Tue Aug 30 19:01:25 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 30 Aug 2016 22:01:25 +0300 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message Message-ID: Hello, Please, help to review the tests fix. Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 The list of changes: 1. Two tests were modified to print exception occurred during execution. Before that these tests were failing silently. 2. The tests were slightly modified to correctly run with security manager run mode recently added to JAXP tests (JDK-8067170). 3. TransformationWarningsTest were modified to synchronize the TransformerFactory instantiation. The modified tests were executed 2000+ times (alongside to other tests from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 and there were no failures observed. According to this result and that the tests were modified not to fail silently. I would like to remove these two tests from the jaxp problem list. If the tests will continue to fail on some configurations (JPRT shows no failures for few runs though) the proposed changes will help to diagnose the cause of failures. With Best Regards, Aleksej From martinrb at google.com Tue Aug 30 21:50:29 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 30 Aug 2016 14:50:29 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> Message-ID: On Mon, Aug 29, 2016 at 4:12 PM, Paul Sandoz wrote: > > > On 29 Aug 2016, at 15:32, Martin Buchholz wrote: > > > > We had already agreed on making these changes, and the detail looks > good, so approved! > > > > Thanks. > > > > but ... I wish there was less confusion ... maybe it's unavoidable ... > I'm going to check the docs carefully every time I use one of these APIs! > ... feel free to ignore rambling: > > > > I am having second thoughts about whether it's too late to fix our API > wart. Suppose we make weakCompareAndSet the one with volatile semantics > and weakCompareAndSetPlain the one with plain semantics? The normal rule > is never to change the definition of an API, but here: > > > > - we would only be strengthening the API, so previous users of > weakCompareAndSet will not be broken > > - all known historical implementations of weakCompareAndSet pre-jdk9 in > fact delegated to volatile CAS (is this true?), so future users of > weakCompareAndSet will not be broken in practice when their software is > used on jdk8. > > > > .. and deprecate weakCompareAndSetVolatile? > No need to deprecate it; we haven't shipped it in a major release yet! Just kill it! Are there any users of weakCompareAndSet in the wild? If so, how many of them are correct? All I can think of is atomically modified variables that are independent of others, e.g. statistics counters, where weakCompareAndSet is called in a loop (but true counters can use getAndAdd). At least, strengthening the spec to be sequentially consistent won't break these users. I keep hoping for an API where you get sequential consistency by default, and have to ask for relaxed operations explicitly, as in C++. I keep thinking we'll regret making e.g. VarHandle.get the non-volatile variant. I did wonder about that, it seems a little sneaky, so i did not pursue it, > existing uses will still function but not necessarily to the same degree, > so it could still be perceived as broken. > > There are however very few use-cases of these methods. I used such usage > analysis to justify depreciation, but I suppose that same analysis could > also justify a change in behaviour. Thoughts? > From paul.sandoz at oracle.com Tue Aug 30 22:52:02 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 30 Aug 2016 15:52:02 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> Message-ID: <3F2EECFB-220F-4757-B6FB-9197796B94D4@oracle.com> > On 30 Aug 2016, at 14:50, Martin Buchholz wrote: > > > > On Mon, Aug 29, 2016 at 4:12 PM, Paul Sandoz > wrote: > > > On 29 Aug 2016, at 15:32, Martin Buchholz > wrote: > > > > We had already agreed on making these changes, and the detail looks good, so approved! > > > > Thanks. > > > > but ... I wish there was less confusion ... maybe it's unavoidable ... I'm going to check the docs carefully every time I use one of these APIs! ... feel free to ignore rambling: > > > > I am having second thoughts about whether it's too late to fix our API wart. Suppose we make weakCompareAndSet the one with volatile semantics and weakCompareAndSetPlain the one with plain semantics? The normal rule is never to change the definition of an API, but here: > > > > - we would only be strengthening the API, so previous users of weakCompareAndSet will not be broken > > - all known historical implementations of weakCompareAndSet pre-jdk9 in fact delegated to volatile CAS (is this true?), so future users of weakCompareAndSet will not be broken in practice when their software is used on jdk8. > > > > .. and deprecate weakCompareAndSetVolatile? > > No need to deprecate it; we haven't shipped it in a major release yet! Just kill it! > Doh, of course. > Are there any users of weakCompareAndSet in the wild? V. few, a search on grepcode shows one primary user is Guava?s AtomicDoubleArray, which wraps, but which itself has few or no usages reported by grepcode IIRC. I still think it?s kind of sneaky to substitute, especially because of propagation to wrapping classes such as AtomicDoubleArray. Doug, not sure you care enough to have an opinion :-) but i might as well ask, do you? Paul. > If so, how many of them are correct? All I can think of is atomically modified variables that are independent of others, e.g. statistics counters, where weakCompareAndSet is called in a loop (but true counters can use getAndAdd). At least, strengthening the spec to be sequentially consistent won't break these users. > > I keep hoping for an API where you get sequential consistency by default, and have to ask for relaxed operations explicitly, as in C++. I keep thinking we'll regret making e.g. VarHandle.get the non-volatile variant. > > I did wonder about that, it seems a little sneaky, so i did not pursue it, existing uses will still function but not necessarily to the same degree, so it could still be perceived as broken. > > There are however very few use-cases of these methods. I used such usage analysis to justify depreciation, but I suppose that same analysis could also justify a change in behaviour. Thoughts? From dl at cs.oswego.edu Tue Aug 30 23:21:31 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 30 Aug 2016 19:21:31 -0400 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: <3F2EECFB-220F-4757-B6FB-9197796B94D4@oracle.com> References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> <3F2EECFB-220F-4757-B6FB-9197796B94D4@oracle.com> Message-ID: <76d8e2fe-d29f-d5b0-4460-580fc461ee70@cs.oswego.edu> On 08/30/2016 06:52 PM, Paul Sandoz wrote: > I still think it?s kind of sneaky to substitute, especially because of > propagation to wrapping classes such as AtomicDoubleArray. > > Doug, not sure you care enough to have an opinion :-) but i might as well ask, > do you? > Not a strong one, but I don't like anything else any better than the current after this commit) conventions. -Doug From steve.drach at oracle.com Wed Aug 31 02:58:51 2016 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 30 Aug 2016 19:58:51 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: References: Message-ID: new webrev addressing issues below: http://cr.openjdk.java.net/~sdrach/8153654/webrev.09/ >> Hi, >> >> Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with ?version #/? where version # is 9, 10, etc. >> >> webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/ > > This looks quite good. JDK-8163798 and JDK-8164665 will define public APIs to get the versioned entries and real name which I think are useful for tools. It?s fine to proceed with this change and update jdeps to use the public APIs when available. The product team has decided not to move forward on those two issues for now, they will remain unresolved. > > This patch parse MR-JAR only if ?-multi-release option is specified. It would also be useful to analyze all versioned entries for the default option (i.e. analyze direct dependencies from class files) that can be done in a separate RFE. > > Comments to this patch: > > ClassFileReader.java > > 386 if (Integer.parseInt(v) < 9) { > 387 String[] msg = {"err.multirelease.jar.malformed", > 388 jarfile.getName(), rn > 389 }; > 390 throw new MultiReleaseException(msg); > 391 } > > To get here, I can think of the case when it?s not a MRJAR (so JarFile::stream returns all entries). fixed > If it?s a MR-JAR, the JarFile will be opened with a valid version. versionedStream should only return the proper versioned entries. Maybe you should emit warning (add it to skippedEntries if this happens) or make it an assert. I?m not sure what you mean. > > 382 if (rn.startsWith("META-INF/versions/")) { > 383 int n = rn.indexOf('/', 18); // "META-INF/versions/".length() > > 421 final String META_INF_VERSIONS = "META-INF/versions/?; > 429 if (name.length() > META_INF_VERSIONS.length()) { > > They both extract the version of this entry. This can be refactored to add a method like VersionHelper::getVersion(JarEntry). done > > versionedStream method may be better to be moved to VersionHelper. done > > 442 return (version == jf.getVersion().major() && vStr.length() > offset + 1) > > This version only selects the entries in the base section and versioned section. I thought that would work, at least I had a scenario in my head where it worked ;-) But it doesn?t so I changed it. > > Can you add the following scenario in the new test and Bar and Gee are public and shows the result when -?multi-release 9 or 10 or base? > p/Foo.class > META-INF/versions/9/p/Foo.class > META-INF/versions/9/q/Bar.class > META-INF/versions/10/q/Bar.class > META-INF/versions/10/q/Gee.class One can not put new public classes in the versioned section, so that layout is not legal > > JDK-8163798 would cover more scenarios in depth. I?m okay to use the versionedStream you have and leave that to JDK-8163798. > BTW the copyright header is missing in the new tests. All the existing test input source files do not have the copyright header. These little classes are just there to feed the test that does have the required copyright > > JdepsTask.java > 401 throw new BadArgs("err.multirelease.option.illegal", arg); > > You can simply use err.invalid.arg.for.option which I think is simple and adequate. That?s not an existing property, so I left it where it is with all the multi-release properties > > MultiReleaseException.java > 47 public MultiReleaseException(String[] err) { > > It would be better to have a key parameter: MultiReleaseException(String key, String? param) done > VersionHelper.java > 40 public static String get(String origin) { > > s/origin/classname to make the param clearer. done > jdeps.properties: what about a shorter version: > > --multi-release Specifies the version when processing > multi-release jar files. can be >> = 9 or base. I did that but I think it?s more confusing > >> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/ > > > The use of shared secrets is just temporary and I hope it will soon be replaced with a public API when JDK-8164665 is resolved. See my earlier comment > > Mandy From huizhe.wang at oracle.com Wed Aug 31 04:43:32 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 30 Aug 2016 21:43:32 -0700 Subject: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions In-Reply-To: <87oa4ai5c5.fsf@v45346.1blu.de> References: <87eg58n7vx.fsf@v45346.1blu.de> <57C4825D.5070307@oracle.com> <87oa4ai5c5.fsf@v45346.1blu.de> Message-ID: <57C66074.5080608@oracle.com> Hi Stefan, On 8/30/16, 9:34 AM, Stefan Bodewig wrote: > Hi Joe > > On 2016-08-29, Joe Wang wrote: > >> If you are using the built-in extension functions, try turning on the >> following feature: >> private static final String ENABLE_EXTENSION_FUNCTIONS = >> "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions"; >> tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); > This is not supported by Xalan's TransformerFactoryImpl: True, this is an impl-only feature. But Xalan doesn't need it anyways, you may check the factory instance and skip it if it's Xalan. > > /devel/ASF/ant/build.xml:1744: Errors while applying transformations: > javax.xml.transform.TransformerConfigurationException: Cannot set the > feature > 'http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions' on > this TransformerFactory. > at > org.apache.xalan.processor.TransformerFactoryImpl.setFeature(TransformerFactoryImpl.java:413) > > When removing Xalan from the classpath and using the JDK's own > TransformerFactory I get > > ,---- > | Error! Use of the extension element 'redirect' is not allowed when the > | secure processing feature is set to true. > `---- > > even with the feature enabled. So "redirect" - > i.e. xmlns:redirect="http://xml.apache.org/xalan/redirect" - which I > assumed to be "built-in" for the JDK's fork of Xalan as well - doesn't > seem to get through with just that. I'll get this fixed in the next 1 or 2 build. (https://bugs.openjdk.java.net/browse/JDK-8165116) > >> If you are using user-extension functions, then add the following: >> private static final String EXTENSION_CLASS_LOADER = >> "jdk.xml.transform.extensionClassLoader"; >> tf.setAttribute(EXTENSION_CLASS_LOADER, cl); >> where cl is the user-specified ClassLoader that will load external >> extension function classes, e.g. >> runWithPermission(() -> >> Thread.currentThread().getContextClassLoader()) > This attribute isn't supported by Xalan either. > > Testing this further is going to require a bit more of setup, I'll be > traveling the coming days but will give it a try during the weekend. > > Unfortunately this is going to be cumbersome for our users as Xalan must > not be on the system classloader (I'd get Xalan's TransformerFactory in > that case) and tasks that didn't require any classpath management > suddenly need a more extensive configration. As I mentioned above, you can skip the JDK-only process when Xalan is on the classpath, check the factory instance or catch the configuration error. Best, Joe > > Many thanks > > Stefan From christoph.langer at sap.com Wed Aug 31 08:34:01 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 31 Aug 2016 08:34:01 +0000 Subject: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: References: Message-ID: <89c15beb1bab4c358fa3e5c4159fdd3c@DEWDFE13DE11.global.corp.sap> Hi Aleks, looks nice to me. You could maybe use the method reference syntax in 2 places: --- a/test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Wed Aug 31 09:17:55 2016 +0200 +++ b/test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Wed Aug 31 10:32:05 2016 +0200 @@ -68,11 +68,11 @@ EXECUTOR.execute(new TestWorker(id)); } //Initiate shutdown of previously submitted task - runWithAllPerm(() -> EXECUTOR.shutdown()); + runWithAllPerm(EXECUTOR::shutdown); //Wait for termination of submitted tasks if (!EXECUTOR.awaitTermination(THREADS_COUNT, TimeUnit.SECONDS)) { //If not all tasks terminates during the time out force them to shutdown - runWithAllPerm(() -> EXECUTOR.shutdownNow()); + runWithAllPerm(EXECUTOR::shutdownNow); } //Restore default standard error stream runWithAllPerm(() -> System.setErr(defStdErr)); But the Lambda expression might be more consistent, too. I'm not a reviewer though... Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Aleks Efimov > Sent: Dienstag, 30. August 2016 21:01 > To: core-libs-dev > Subject: RFR: 8150145: > javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and > ValidationWarningsTest.java failed intermittently without any error message > > Hello, > > Please, help to review the tests fix. > Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 > > The list of changes: > 1. Two tests were modified to print exception occurred during execution. > Before that these tests were failing silently. > 2. The tests were slightly modified to correctly run with security > manager run mode recently added to JAXP tests (JDK-8067170). > 3. TransformationWarningsTest were modified to synchronize the > TransformerFactory instantiation. > > The modified tests were executed 2000+ times (alongside to other tests > from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 and there > were no failures observed. According to this result and that the tests > were modified not to fail silently. I would like to remove these two > tests from the jaxp problem list. > If the tests will continue to fail on some configurations (JPRT shows no > failures for few runs though) the proposed changes will help to diagnose > the cause of failures. > > With Best Regards, > Aleksej From ramanand.patil at oracle.com Wed Aug 31 09:32:23 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 31 Aug 2016 02:32:23 -0700 (PDT) Subject: RFR: 8160951, 8160958: "Test javax/xml/bind/marshal/8134111/UnmarshalTest.java should be added into :needs_jre group", "Test java/net/SetFactoryPermission/SetFactoryPermission.java should be added into :needs_compact2 group" Message-ID: <5a7b02d5-390d-4817-a8be-5e8b4fefbe98@default> Hi all, Please review this trivial fix which addresses the mentioned 2 bugs. Bugs: 1. https://bugs.openjdk.java.net/browse/JDK-8160951 2. https://bugs.openjdk.java.net/browse/JDK-8160958 Webrev: http://cr.openjdk.java.net/~rpatil/8160951%2b8160958/webrev.00/ Only test/TEST.groups is modified to add these tests to the required group. Regards, Ramanand. From claes.redestad at oracle.com Wed Aug 31 10:46:00 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 31 Aug 2016 12:46:00 +0200 Subject: RFR: 8164858: Enable build-time use of java.lang.invoke resolve tracing In-Reply-To: References: <57C47A94.30805@oracle.com> Message-ID: <57C6B568.7030304@oracle.com> Thanks! Can I get a review of the plugin changes? Mostly ensuring we generate methods in a deterministic order (and weed out duplicates early). /Claes On 2016-08-30 10:20, Erik Joelsson wrote: > Build changes look good. > > /Erik > > > On 2016-08-29 20:10, Claes Redestad wrote: >> Hi, >> >> this patch adds generation of a trace of resolved java.lang.invoke >> classes when generating the classlist, and uses this trace as input >> when linking the runtime images. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8164858 >> >> Webrevs: >> http://cr.openjdk.java.net/~redestad/8164858/top.01/ >> http://cr.openjdk.java.net/~redestad/8164858/jdk.01/ >> >> This allows for a small reduction of the number of classes generated >> during bootstrap across a wide set of applications. >> >> Thanks! >> >> /Claes > From vladimir.x.ivanov at oracle.com Wed Aug 31 11:55:56 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Aug 2016 14:55:56 +0300 Subject: RFR: 8164858: Enable build-time use of java.lang.invoke resolve tracing In-Reply-To: <57C47A94.30805@oracle.com> References: <57C47A94.30805@oracle.com> Message-ID: <29b91813-384f-4244-249f-7f3663ce4198@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 8/29/16 9:10 PM, Claes Redestad wrote: > Hi, > > this patch adds generation of a trace of resolved java.lang.invoke > classes when generating the classlist, and uses this trace as input > when linking the runtime images. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164858 > > Webrevs: > http://cr.openjdk.java.net/~redestad/8164858/top.01/ > http://cr.openjdk.java.net/~redestad/8164858/jdk.01/ > > This allows for a small reduction of the number of classes generated > during bootstrap across a wide set of applications. > > Thanks! > > /Claes From Alan.Burlison at oracle.com Wed Aug 31 11:55:25 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 31 Aug 2016 12:55:25 +0100 Subject: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris Message-ID: <3d79f115-d7f5-28a5-543a-d0901e049ddd@oracle.com> vfork(2) is deprecated on Solaris and using it generates compiler warnings. When compiled with warnings-as-errors, this results in compilation failures. Bug: https://bugs.openjdk.java.net/browse/JDK-8161360 Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8161360 Thanks, -- Alan Burlison -- From chris.hegarty at oracle.com Wed Aug 31 13:03:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 31 Aug 2016 14:03:38 +0100 Subject: RFR: 8161016: Strange behavior of URLConnection with proxy In-Reply-To: References: <7f985cb6-480e-497f-aa8f-55598b81df96@default> <471c04ca-510b-da6b-3245-84475da47e79@gmail.com> Message-ID: <3f425e91-5262-a25f-84f2-d0770babf985@oracle.com> On 12/08/16 20:56, Ramanand Patil wrote: > Hi Aleksey, > > Thank you for your review. > In the exception handler block: when last proxy fails, it was using a DIRECT connection, but in the fixed version it was just a re-try once with the last proxy before failing the connection. > > Considering your points I think the alternate approach of not re-trying and just failing after the last proxy is good. I have updated the code slightly which does the same as you suggested. > And also updated the test case to use one more dummy proxy in MyProxySelector class. > > Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.01/ This looks good to me. -Chris. > > Regards, > Ramanand. > > -----Original Message----- > From: Aleksey Shipilev [mailto:aleksey.shipilev at gmail.com] > Sent: Thursday, August 11, 2016 10:10 PM > To: Ramanand Patil; OpenJDK Network Dev list > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8161016: Strange behavior of URLConnection with proxy > > On 08/11/2016 05:17 PM, Ramanand Patil wrote: >> Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.00/ >> >> Fix: Instead of falling back to direct connection when last proxy >> fails to open connection, re-try once with the last proxy. An >> alternate solution can also be- don't try to open any connection when >> all set proxies fails to open a connection. > > I wonder if the code should traverse the last proxy within the loop, not trying to special-case it in the exception handler -- otherwise we would miss logging, exceptions, and ProxySelector notifications coming from the last proxy? > > E.g. instead of: > > 1116 } catch (IOException ioex) { > 1117 if (p != Proxy.NO_PROXY) { > 1118 sel.connectFailed(uri, p.address(), ioex); > 1119 if (!it.hasNext()) { > 1120 // re-try once with the last Proxy > 1121 http = getNewHttpClient(url, p, connectTimeout, false); > 1122 http.setReadTimeout(readTimeout); > 1123 break; > 1124 } > 1125 } else { > 1126 throw ioex; > 1127 } > 1128 continue; > 1129 } > > ...do: > > } catch (IOException ioex) { > if (p == Proxy.NO_PROXY) { > throw ioex; > } > sel.connectFailed(uri, p.address(), ioex); > if (it.hasNext()) { > continue; // try the next Proxy > } else { > throw ioex; // that was the last Proxy, time to fail > } > } > > Thanks, > -Aleksey > From aleksej.efimov at oracle.com Wed Aug 31 14:00:25 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 31 Aug 2016 17:00:25 +0300 Subject: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: <89c15beb1bab4c358fa3e5c4159fdd3c@DEWDFE13DE11.global.corp.sap> References: <89c15beb1bab4c358fa3e5c4159fdd3c@DEWDFE13DE11.global.corp.sap> Message-ID: <8fd165bb-d017-d700-51e6-1f87e161d351@oracle.com> Hi Christoph, Thanks for the review and suggestion. I've converted 'shutdown' and 'shutdownNow' calls to use method references. Best Regards, Aleksej On 31/08/16 11:34, Langer, Christoph wrote: > Hi Aleks, > > looks nice to me. > > You could maybe use the method reference syntax in 2 places: > > --- a/test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Wed Aug 31 09:17:55 2016 +0200 > +++ b/test/javax/xml/jaxp/unittest/common/WarningsTestBase.java Wed Aug 31 10:32:05 2016 +0200 > @@ -68,11 +68,11 @@ > EXECUTOR.execute(new TestWorker(id)); > } > //Initiate shutdown of previously submitted task > - runWithAllPerm(() -> EXECUTOR.shutdown()); > + runWithAllPerm(EXECUTOR::shutdown); > //Wait for termination of submitted tasks > if (!EXECUTOR.awaitTermination(THREADS_COUNT, TimeUnit.SECONDS)) { > //If not all tasks terminates during the time out force them to shutdown > - runWithAllPerm(() -> EXECUTOR.shutdownNow()); > + runWithAllPerm(EXECUTOR::shutdownNow); > } > //Restore default standard error stream > runWithAllPerm(() -> System.setErr(defStdErr)); > > But the Lambda expression might be more consistent, too. > > I'm not a reviewer though... > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Aleks Efimov >> Sent: Dienstag, 30. August 2016 21:01 >> To: core-libs-dev >> Subject: RFR: 8150145: >> javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and >> ValidationWarningsTest.java failed intermittently without any error message >> >> Hello, >> >> Please, help to review the tests fix. >> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >> >> The list of changes: >> 1. Two tests were modified to print exception occurred during execution. >> Before that these tests were failing silently. >> 2. The tests were slightly modified to correctly run with security >> manager run mode recently added to JAXP tests (JDK-8067170). >> 3. TransformationWarningsTest were modified to synchronize the >> TransformerFactory instantiation. >> >> The modified tests were executed 2000+ times (alongside to other tests >> from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 and there >> were no failures observed. According to this result and that the tests >> were modified not to fail silently. I would like to remove these two >> tests from the jaxp problem list. >> If the tests will continue to fail on some configurations (JPRT shows no >> failures for few runs though) the proposed changes will help to diagnose >> the cause of failures. >> >> With Best Regards, >> Aleksej From roger.riggs at Oracle.com Wed Aug 31 14:14:38 2016 From: roger.riggs at Oracle.com (Roger Riggs) Date: Wed, 31 Aug 2016 10:14:38 -0400 Subject: RFR 9: JEP 290: Filter Incoming Serialization Data In-Reply-To: <2f90677813f116b248c177e667d95e60@org.tizen.email> References: <2f90677813f116b248c177e667d95e60@org.tizen.email> Message-ID: Hi Peter, Since the filter is passed information about each object created, a stateful filter can tabulate the cumulative size itself if that is a concern. Also, a stateless filter can be constructed to check a combination of the total number of objects, depth, array sizes, and stream size. Since arrays are initialized with data from the stream, the stream size provides a practical limit. Roger On 8/29/16 10:07 PM, Peter Firmstone wrote: > Include original message > > A quick thought on the array size filter: > > The system creates an array with a size read from the stream. > > If Mallory sends a multidimensional array in the stream, then Mallory can consume all jvm memory without exceeding the array size limit or the stream data limit. > > We also need an array combined length limit. > > Thanks, > > Peter. > > Sent from my Samsung device. > From paul.sandoz at oracle.com Wed Aug 31 15:51:11 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 31 Aug 2016 08:51:11 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: References: Message-ID: <08936004-20E5-46BD-91E5-357B645EDAFD@oracle.com> > On 30 Aug 2016, at 19:58, Steve Drach wrote: > > new webrev addressing issues below: http://cr.openjdk.java.net/~sdrach/8153654/webrev.09/ > > > >>> Hi, >>> >>> Please review the following two changesets that enables jdeps to use multi-release jar files. The output from the tool shows versioned dependencies by prefixing them with ?version #/? where version # is 9, 10, etc. >>> >>> webrevs: http://cr.openjdk.java.net/~sdrach/8153654/webrev.08/ >> >> This looks quite good. JDK-8163798 and JDK-8164665 will define public APIs to get the versioned entries and real name which I think are useful for tools. It?s fine to proceed with this change and update jdeps to use the public APIs when available. > > The product team has decided not to move forward on those two issues for now, they will remain unresolved. > There appear to be a number of use-cases pulling on versions streams with slightly different requirements. That made me uncomfortable and I am concerned about the time taken to churn on such a public API, so rather that trying to get the API right at this point i felt it more expedient to focus on internal implementations, and when those implementations settle we can stand back and see how to expose as a public API. Paul. From huizhe.wang at oracle.com Wed Aug 31 16:25:09 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 09:25:09 -0700 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: References: Message-ID: <57C704E5.6010202@oracle.com> Hi Aleksej, It's good to put the tests back online. Thanks for the diligent work! I believe the change that made the tests run in othervm could have fixed the intermittent issue. But adding debugging code can always be helpful in case of failures. Thanks, Joe On 8/30/16, 12:01 PM, Aleks Efimov wrote: > Hello, > > Please, help to review the tests fix. > Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 > > The list of changes: > 1. Two tests were modified to print exception occurred during > execution. Before that these tests were failing silently. > 2. The tests were slightly modified to correctly run with security > manager run mode recently added to JAXP tests (JDK-8067170). > 3. TransformationWarningsTest were modified to synchronize the > TransformerFactory instantiation. > > The modified tests were executed 2000+ times (alongside to other tests > from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 and there > were no failures observed. According to this result and that the tests > were modified not to fail silently. I would like to remove these two > tests from the jaxp problem list. > If the tests will continue to fail on some configurations (JPRT shows > no failures for few runs though) the proposed changes will help to > diagnose the cause of failures. > > With Best Regards, > Aleksej > From huizhe.wang at oracle.com Wed Aug 31 16:47:08 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 09:47:08 -0700 Subject: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present Message-ID: <57C70A0C.9080507@oracle.com> Hi, Please review a fix to the XSLTFunctionsTest. After enabling SecurityManager, the test now needs to set the extension ClassLoader for the extension class. JBS: https://bugs.openjdk.java.net/browse/JDK-8161454 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8161454/webrev/ Thanks, Joe From aleksej.efimov at oracle.com Wed Aug 31 17:51:45 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 31 Aug 2016 20:51:45 +0300 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: <57C704E5.6010202@oracle.com> References: <57C704E5.6010202@oracle.com> Message-ID: <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> Hi Joe, Thank you for reviewing the changes. I found one more inconsistency with these tests: The TestSAXDriver class is not compiled by default now and because of that the default SAX driver were used and the original issue was not reproduced properly. New webrev can be found here: http://cr.openjdk.java.net/~aefimov/8150145/01 About intermittent failure: The test was added with 'othervm' initially, but few months ago the transformation test was failing due to concurrency issue in PackageEntry::package_exports_do ( JDK-8152404). Now failures are not reproducible with latest JDK9 builds and latest version of the tests. -Aleksej On 31/08/16 19:25, Joe Wang wrote: > Hi Aleksej, > > It's good to put the tests back online. Thanks for the diligent work! > I believe the change that made the tests run in othervm could have > fixed the intermittent issue. But adding debugging code can always be > helpful in case of failures. > > Thanks, > Joe > > On 8/30/16, 12:01 PM, Aleks Efimov wrote: >> Hello, >> >> Please, help to review the tests fix. >> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >> >> The list of changes: >> 1. Two tests were modified to print exception occurred during >> execution. Before that these tests were failing silently. >> 2. The tests were slightly modified to correctly run with security >> manager run mode recently added to JAXP tests (JDK-8067170). >> 3. TransformationWarningsTest were modified to synchronize the >> TransformerFactory instantiation. >> >> The modified tests were executed 2000+ times (alongside to other >> tests from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 and >> there were no failures observed. According to this result and that >> the tests were modified not to fail silently. I would like to remove >> these two tests from the jaxp problem list. >> If the tests will continue to fail on some configurations (JPRT shows >> no failures for few runs though) the proposed changes will help to >> diagnose the cause of failures. >> >> With Best Regards, >> Aleksej >> From paul.sandoz at oracle.com Wed Aug 31 18:09:54 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 31 Aug 2016 11:09:54 -0700 Subject: RFR 8164814: Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAndSetPlain In-Reply-To: <76d8e2fe-d29f-d5b0-4460-580fc461ee70@cs.oswego.edu> References: <547E7223-1234-4B7E-9F44-CB82F1602681@oracle.com> <0D1FBA33-5E00-4B01-AE13-66FE3376EBEB@oracle.com> <3F2EECFB-220F-4757-B6FB-9197796B94D4@oracle.com> <76d8e2fe-d29f-d5b0-4460-580fc461ee70@cs.oswego.edu> Message-ID: <25B397A7-4FDB-4471-BE59-3BEC93655A31@oracle.com> > On 30 Aug 2016, at 16:21, Doug Lea

    wrote: > > On 08/30/2016 06:52 PM, Paul Sandoz wrote: > >> I still think it?s kind of sneaky to substitute, especially because of >> propagation to wrapping classes such as AtomicDoubleArray. >> >> Doug, not sure you care enough to have an opinion :-) but i might as well ask, >> do you? >> > > Not a strong one, but I don't like anything else any better than > the current after this commit) conventions. > Ok, onward! Thanks, Paul. From aleksej.efimov at oracle.com Wed Aug 31 18:26:04 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 31 Aug 2016 21:26:04 +0300 Subject: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present In-Reply-To: <57C70A0C.9080507@oracle.com> References: <57C70A0C.9080507@oracle.com> Message-ID: <5d76065f-3ea4-4f28-ed08-2682d5da6356@oracle.com> Hi Joe, The changes looks nice (I'm not a reviewer) Best Regards, Aleksej On 31/08/16 19:47, Joe Wang wrote: > Hi, > > Please review a fix to the XSLTFunctionsTest. After enabling > SecurityManager, the test now needs to set the extension ClassLoader > for the extension class. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8161454 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8161454/webrev/ > > Thanks, > Joe From mandy.chung at oracle.com Wed Aug 31 18:26:41 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 31 Aug 2016 11:26:41 -0700 Subject: RFR: 8153654: Update jdeps to be multi-release jar aware In-Reply-To: References: Message-ID: <8E7A5A0F-1789-43B5-AA88-AA3FBC57C267@oracle.com> > On Aug 30, 2016, at 7:58 PM, Steve Drach wrote: > >> >> This looks quite good. JDK-8163798 and JDK-8164665 will define public APIs to get the versioned entries and real name which I think are useful for tools. It?s fine to proceed with this change and update jdeps to use the public APIs when available. > > The product team has decided not to move forward on those two issues for now, they will remain unresolved. OK. What about putting these helper methods in jdk.internal.jar package as jlink and jdeps both use them to would avoid duplicated code. >> >> This patch parse MR-JAR only if ?-multi-release option is specified. It would also be useful to analyze all versioned entries for the default option (i.e. analyze direct dependencies from class files) that can be done in a separate RFE. >> >> Comments to this patch: >> >> ClassFileReader.java >> >> 386 if (Integer.parseInt(v) < 9) { >> 387 String[] msg = {"err.multirelease.jar.malformed", >> 388 jarfile.getName(), rn >> 389 }; >> 390 throw new MultiReleaseException(msg); >> 391 } >> >> To get here, I can think of the case when it?s not a MRJAR (so JarFile::stream returns all entries). > > fixed > >> If it?s a MR-JAR, the JarFile will be opened with a valid version. versionedStream should only return the proper versioned entries. Maybe you should emit warning (add it to skippedEntries if this happens) or make it an assert. > > I?m not sure what you mean. My point is that JarFile::getEntry should not return such JarEntry - is that true? In that case, how SharedSecrets.javaUtilJarAccess().getRealName(jarfile, e) would return META-INF/versions/$n where n < 9? This is not an expected error and so InternalError (or assert) is more appropriate than throwing MultiReleaseException. > >> >> Can you add the following scenario in the new test and Bar and Gee are public and shows the result when -?multi-release 9 or 10 or base? >> p/Foo.class >> META-INF/versions/9/p/Foo.class >> META-INF/versions/9/q/Bar.class >> META-INF/versions/10/q/Bar.class >> META-INF/versions/10/q/Gee.class > > One can not put new public classes in the versioned section, so that layout is not legal But such JAR file can be created. What about adding a non-public class under: META-INF/versions/9/q/Zee.class META-INF/versions/10/q/Zee.class Keeping public q/Bar.class is okay as JarFile::getName(?q/Bar.class?) should return null if not allowed for any Runtime.Version. > >> >> JDK-8163798 would cover more scenarios in depth. I?m okay to use the versionedStream you have and leave that to JDK-8163798. > >> BTW the copyright header is missing in the new tests. > > All the existing test input source files do not have the copyright header. These little classes are just there to feed the test that does have the required copyright I put the copyright headers in all source files, including tiny test classes. > >> >> JdepsTask.java >> 401 throw new BadArgs("err.multirelease.option.illegal", arg); >> >> You can simply use err.invalid.arg.for.option which I think is simple and adequate. > > That?s not an existing property, so I left it where it is with all the multi-release properties err.invalid.arg.for.option is an existing property. > >> jdeps.properties: what about a shorter version: >> >> --multi-release Specifies the version when processing >> multi-release jar files. can be >>> = 9 or base. > > I did that but I think it?s more confusing User guides, man page to include examples would help that. Mandy From huizhe.wang at oracle.com Wed Aug 31 18:39:25 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 11:39:25 -0700 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> References: <57C704E5.6010202@oracle.com> <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> Message-ID: <57C7245D.5080008@oracle.com> On 8/31/16, 10:51 AM, Aleks Efimov wrote: > Hi Joe, > > Thank you for reviewing the changes. I found one more inconsistency > with these tests: > > The TestSAXDriver class is not compiled by default now and because of > that the default SAX driver were used and the original issue was not > reproduced properly. New webrev can be found here: > > http://cr.openjdk.java.net/~aefimov/8150145/01 > > About intermittent failure: The test was added with 'othervm' > initially, but few months ago the transformation test was failing due > to concurrency issue in PackageEntry::package_exports_do ( > JDK-8152404). Now failures are not reproducible with latest JDK9 > builds and latest version of the tests. Did you mean it was later changed to othervm? The initial check-in record shows it wasn't [1] othervm provents the potential interference by other tests that also set the system property, and therefore removes the need for a further refactoring of the code. So this is not required, but you may remove the SAX driver setting and use a new instance instead, e.g. SAXSource saxSource = new SAXSource(new TestSAXDriver(), new InputSource(new StringReader(xml))); [1] http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/6aa83d55614a/test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java Thanks, Joe > > -Aleksej > > > On 31/08/16 19:25, Joe Wang wrote: >> Hi Aleksej, >> >> It's good to put the tests back online. Thanks for the diligent work! >> I believe the change that made the tests run in othervm could have >> fixed the intermittent issue. But adding debugging code can always be >> helpful in case of failures. >> >> Thanks, >> Joe >> >> On 8/30/16, 12:01 PM, Aleks Efimov wrote: >>> Hello, >>> >>> Please, help to review the tests fix. >>> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >>> >>> The list of changes: >>> 1. Two tests were modified to print exception occurred during >>> execution. Before that these tests were failing silently. >>> 2. The tests were slightly modified to correctly run with security >>> manager run mode recently added to JAXP tests (JDK-8067170). >>> 3. TransformationWarningsTest were modified to synchronize the >>> TransformerFactory instantiation. >>> >>> The modified tests were executed 2000+ times (alongside to other >>> tests from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 >>> and there were no failures observed. According to this result and >>> that the tests were modified not to fail silently. I would like to >>> remove these two tests from the jaxp problem list. >>> If the tests will continue to fail on some configurations (JPRT >>> shows no failures for few runs though) the proposed changes will >>> help to diagnose the cause of failures. >>> >>> With Best Regards, >>> Aleksej >>> > From aleksej.efimov at oracle.com Wed Aug 31 19:08:56 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 31 Aug 2016 22:08:56 +0300 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: <57C7245D.5080008@oracle.com> References: <57C704E5.6010202@oracle.com> <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> <57C7245D.5080008@oracle.com> Message-ID: Joe, (answers in-lined) On 31/08/16 21:39, Joe Wang wrote: > > > On 8/31/16, 10:51 AM, Aleks Efimov wrote: >> Hi Joe, >> >> Thank you for reviewing the changes. I found one more inconsistency >> with these tests: >> >> The TestSAXDriver class is not compiled by default now and because of >> that the default SAX driver were used and the original issue was not >> reproduced properly. New webrev can be found here: >> >> http://cr.openjdk.java.net/~aefimov/8150145/01 >> >> About intermittent failure: The test was added with 'othervm' >> initially, but few months ago the transformation test was failing due >> to concurrency issue in PackageEntry::package_exports_do ( >> JDK-8152404). Now failures are not reproducible with latest JDK9 >> builds and latest version of the tests. > > Did you mean it was later changed to othervm? The initial check-in > record shows it wasn't [1] Yes, you're right - it was added without othervm initially. I was looking at the different changeset *sigh*... > > othervm provents the potential interference by other tests that also > set the system property, and therefore removes the need for a further > refactoring of the code. So this is not required, but you may remove > the SAX driver setting and use a new instance instead, e.g. > SAXSource saxSource = new SAXSource(new TestSAXDriver(), new > InputSource(new StringReader(xml))); Thanks for the suggestion. Even with all sources changed to SAXSource() and with explicitly specified TestSAXDriver the warning generated by Validation test can't be reproduced. Hopefully, it is ok to leave "org.xml.sax.driver" property setup in-place. > > [1] > http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/6aa83d55614a/test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java > > Thanks, > Joe >> >> -Aleksej >> >> >> On 31/08/16 19:25, Joe Wang wrote: >>> Hi Aleksej, >>> >>> It's good to put the tests back online. Thanks for the diligent >>> work! I believe the change that made the tests run in othervm could >>> have fixed the intermittent issue. But adding debugging code can >>> always be helpful in case of failures. >>> >>> Thanks, >>> Joe >>> >>> On 8/30/16, 12:01 PM, Aleks Efimov wrote: >>>> Hello, >>>> >>>> Please, help to review the tests fix. >>>> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >>>> >>>> The list of changes: >>>> 1. Two tests were modified to print exception occurred during >>>> execution. Before that these tests were failing silently. >>>> 2. The tests were slightly modified to correctly run with security >>>> manager run mode recently added to JAXP tests (JDK-8067170). >>>> 3. TransformationWarningsTest were modified to synchronize the >>>> TransformerFactory instantiation. >>>> >>>> The modified tests were executed 2000+ times (alongside to other >>>> tests from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 >>>> and there were no failures observed. According to this result and >>>> that the tests were modified not to fail silently. I would like to >>>> remove these two tests from the jaxp problem list. >>>> If the tests will continue to fail on some configurations (JPRT >>>> shows no failures for few runs though) the proposed changes will >>>> help to diagnose the cause of failures. >>>> >>>> With Best Regards, >>>> Aleksej >>>> >> From henry.jen at oracle.com Wed Aug 31 19:51:21 2016 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 31 Aug 2016 12:51:21 -0700 Subject: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c Message-ID: Hi, Please review a trivial fix for 8081388, in a nutshell, - Return NULL from NewPlatformStringArray if an exception occurred - All other places call this function already handled return value NULL - Launcher handles exception in JavaMain, report error and exit. Cheers, Henry diff --git a/src/java.base/share/native/libjli/java.c b/src/java.base/share/native/libjli/java.c --- a/src/java.base/share/native/libjli/java.c +++ b/src/java.base/share/native/libjli/java.c @@ -1497,6 +1497,7 @@ ? ? ?NULL_CHECK0(cls = FindBootStrapClass(env, "java/lang/String")); ? ? ?NULL_CHECK0(ary = (*env)->NewObjectArray(env, strc, cls, 0)); + ? ?CHECK_EXCEPTION_RETURN_VALUE(0); ? ? ?for (i = 0; i < strc; i++) { ? ? ? ? ?jstring str = NewPlatformString(env, *strv++); ? ? ? ? ?NULL_CHECK0(str); diff --git a/src/java.base/share/native/libjli/java.h b/src/java.base/share/native/libjli/java.h --- a/src/java.base/share/native/libjli/java.h +++ b/src/java.base/share/native/libjli/java.h @@ -253,6 +253,13 @@ ?#define NULL_CHECK(NC_check_pointer) \ ? ? ?NULL_CHECK_RETURN_VALUE(NC_check_pointer, ) +#define CHECK_EXCEPTION_RETURN_VALUE(CER_value) \ + ? ?do { \ + ? ? ? ?if ((*env)->ExceptionOccurred(env)) { \ + ? ? ? ? ? ?return CER_value; \ + ? ? ? ?} \ + ? ?} while (JNI_FALSE) + ?#define CHECK_EXCEPTION_RETURN() \ ? ? ?do { \ ? ? ? ? ?if ((*env)->ExceptionOccurred(env)) { \ From lance.andersen at oracle.com Wed Aug 31 20:14:51 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 31 Aug 2016 16:14:51 -0400 Subject: RFR: 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected. In-Reply-To: <57C48A6A.1070607@oracle.com> References: <57C48A6A.1070607@oracle.com> Message-ID: <42EF593C-64FC-430D-94F8-42C88CECD72B@oracle.com> Looks OK Joe Best Lance > On Aug 29, 2016, at 3:18 PM, Joe Wang wrote: > > Hi, > > Please review a patch that fixes an issue where circular references were not caught if catalogs are pre-loaded. Note that to trigger the issue (circular references), the Catalog must be instructed to load additional catalogs. This can be done by either setting DEFER to false, or providing an uri that does not have a match in the current catalog (thus causes the CatalogResolver to load alternative catalogs). When the uri is empty as in the original JCK test, the CatalogResolver will skip the resolution and therefore no additional catalogs will be loaded. In the unit test, the test (copied from the JCK test) is fixed by adding a bogus uri 'anyuri'. The JCK test will need a similar fix. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8162431 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8162431/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 huizhe.wang at oracle.com Wed Aug 31 20:47:18 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 13:47:18 -0700 Subject: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present In-Reply-To: <5d76065f-3ea4-4f28-ed08-2682d5da6356@oracle.com> References: <57C70A0C.9080507@oracle.com> <5d76065f-3ea4-4f28-ed08-2682d5da6356@oracle.com> Message-ID: <57C74256.10102@oracle.com> Thanks Aleksej! -Joe On 8/31/16, 11:26 AM, Aleks Efimov wrote: > Hi Joe, > > The changes looks nice (I'm not a reviewer) > > > Best Regards, > > Aleksej > > > On 31/08/16 19:47, Joe Wang wrote: >> Hi, >> >> Please review a fix to the XSLTFunctionsTest. After enabling >> SecurityManager, the test now needs to set the extension ClassLoader >> for the extension class. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8161454 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8161454/webrev/ >> >> Thanks, >> Joe > From huizhe.wang at oracle.com Wed Aug 31 20:55:43 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 13:55:43 -0700 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: References: <57C704E5.6010202@oracle.com> <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> <57C7245D.5080008@oracle.com> Message-ID: <57C7444F.7020304@oracle.com> On 8/31/16, 12:08 PM, Aleks Efimov wrote: > Joe, > > (answers in-lined) > > > On 31/08/16 21:39, Joe Wang wrote: >> >> >> On 8/31/16, 10:51 AM, Aleks Efimov wrote: >>> Hi Joe, >>> >>> Thank you for reviewing the changes. I found one more inconsistency >>> with these tests: >>> >>> The TestSAXDriver class is not compiled by default now and because >>> of that the default SAX driver were used and the original issue was >>> not reproduced properly. New webrev can be found here: >>> >>> http://cr.openjdk.java.net/~aefimov/8150145/01 >>> >>> About intermittent failure: The test was added with 'othervm' >>> initially, but few months ago the transformation test was failing >>> due to concurrency issue in PackageEntry::package_exports_do ( >>> JDK-8152404). Now failures are not reproducible with latest JDK9 >>> builds and latest version of the tests. >> >> Did you mean it was later changed to othervm? The initial check-in >> record shows it wasn't [1] > > Yes, you're right - it was added without othervm initially. I was > looking at the different changeset *sigh*... Our memories can elude us, esp. after playing with it so many times :-) > >> >> othervm provents the potential interference by other tests that also >> set the system property, and therefore removes the need for a further >> refactoring of the code. So this is not required, but you may remove >> the SAX driver setting and use a new instance instead, e.g. >> SAXSource saxSource = new SAXSource(new TestSAXDriver(), new >> InputSource(new StringReader(xml))); > Thanks for the suggestion. Even with all sources changed to > SAXSource() and with explicitly specified TestSAXDriver the warning > generated by Validation test can't be reproduced. Hopefully, it is ok > to leave "org.xml.sax.driver" property setup in-place. It's okay now it's running in othervm. I was saying that the system property might have been the cause for the intermittent failure. I'm not sure I understand what you meant that the Validation test can't be reproduced. Did you mean no warning was generated or not more than 1 warning generated? Thanks, Joe > >> >> [1] >> http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/6aa83d55614a/test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >> >> Thanks, >> Joe >>> >>> -Aleksej >>> >>> >>> On 31/08/16 19:25, Joe Wang wrote: >>>> Hi Aleksej, >>>> >>>> It's good to put the tests back online. Thanks for the diligent >>>> work! I believe the change that made the tests run in othervm could >>>> have fixed the intermittent issue. But adding debugging code can >>>> always be helpful in case of failures. >>>> >>>> Thanks, >>>> Joe >>>> >>>> On 8/30/16, 12:01 PM, Aleks Efimov wrote: >>>>> Hello, >>>>> >>>>> Please, help to review the tests fix. >>>>> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >>>>> >>>>> The list of changes: >>>>> 1. Two tests were modified to print exception occurred during >>>>> execution. Before that these tests were failing silently. >>>>> 2. The tests were slightly modified to correctly run with security >>>>> manager run mode recently added to JAXP tests (JDK-8067170). >>>>> 3. TransformationWarningsTest were modified to synchronize the >>>>> TransformerFactory instantiation. >>>>> >>>>> The modified tests were executed 2000+ times (alongside to other >>>>> tests from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 >>>>> and there were no failures observed. According to this result and >>>>> that the tests were modified not to fail silently. I would like to >>>>> remove these two tests from the jaxp problem list. >>>>> If the tests will continue to fail on some configurations (JPRT >>>>> shows no failures for few runs though) the proposed changes will >>>>> help to diagnose the cause of failures. >>>>> >>>>> With Best Regards, >>>>> Aleksej >>>>> >>> > From huizhe.wang at oracle.com Wed Aug 31 20:56:14 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 31 Aug 2016 13:56:14 -0700 Subject: RFR: 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected. In-Reply-To: <42EF593C-64FC-430D-94F8-42C88CECD72B@oracle.com> References: <57C48A6A.1070607@oracle.com> <42EF593C-64FC-430D-94F8-42C88CECD72B@oracle.com> Message-ID: <57C7446E.5030402@oracle.com> Thanks Lance! Joe On 8/31/16, 1:14 PM, Lance Andersen wrote: > Looks OK Joe > > Best > Lance >> On Aug 29, 2016, at 3:18 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review a patch that fixes an issue where circular references >> were not caught if catalogs are pre-loaded. Note that to trigger the >> issue (circular references), the Catalog must be instructed to load >> additional catalogs. This can be done by either setting DEFER to >> false, or providing an uri that does not have a match in the current >> catalog (thus causes the CatalogResolver to load alternative >> catalogs). When the uri is empty as in the original JCK test, the >> CatalogResolver will skip the resolution and therefore no additional >> catalogs will be loaded. In the unit test, the test (copied from the >> JCK test) is fixed by adding a bogus uri 'anyuri'. The JCK test will >> need a similar fix. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8162431 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8162431/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 aleksej.efimov at oracle.com Wed Aug 31 21:58:29 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 1 Sep 2016 00:58:29 +0300 Subject: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message In-Reply-To: <57C7444F.7020304@oracle.com> References: <57C704E5.6010202@oracle.com> <94b5af5b-f645-70c3-cfa3-0895076ccd8c@oracle.com> <57C7245D.5080008@oracle.com> <57C7444F.7020304@oracle.com> Message-ID: <04b25177-a4d6-d53c-d1c3-e49db89f78ca@oracle.com> On 31/08/16 23:55, Joe Wang wrote: > > > On 8/31/16, 12:08 PM, Aleks Efimov wrote: >> Joe, >> >> (answers in-lined) >> >> >> On 31/08/16 21:39, Joe Wang wrote: >>> >>> >>> On 8/31/16, 10:51 AM, Aleks Efimov wrote: >>>> Hi Joe, >>>> >>>> Thank you for reviewing the changes. I found one more inconsistency >>>> with these tests: >>>> >>>> The TestSAXDriver class is not compiled by default now and because >>>> of that the default SAX driver were used and the original issue was >>>> not reproduced properly. New webrev can be found here: >>>> >>>> http://cr.openjdk.java.net/~aefimov/8150145/01 >>>> >>>> About intermittent failure: The test was added with 'othervm' >>>> initially, but few months ago the transformation test was failing >>>> due to concurrency issue in PackageEntry::package_exports_do ( >>>> JDK-8152404). Now failures are not reproducible with latest JDK9 >>>> builds and latest version of the tests. >>> >>> Did you mean it was later changed to othervm? The initial check-in >>> record shows it wasn't [1] >> >> Yes, you're right - it was added without othervm initially. I was >> looking at the different changeset *sigh*... > > Our memories can elude us, esp. after playing with it so many times :-) >> >>> >>> othervm provents the potential interference by other tests that also >>> set the system property, and therefore removes the need for a >>> further refactoring of the code. So this is not required, but you >>> may remove the SAX driver setting and use a new instance instead, e.g. >>> SAXSource saxSource = new SAXSource(new TestSAXDriver(), new >>> InputSource(new StringReader(xml))); >> Thanks for the suggestion. Even with all sources changed to >> SAXSource() and with explicitly specified TestSAXDriver the warning >> generated by Validation test can't be reproduced. Hopefully, it is ok >> to leave "org.xml.sax.driver" property setup in-place. > > It's okay now it's running in othervm. I was saying that the system > property might have been the cause for the intermittent failure. I'm > not sure I understand what you meant that the Validation test can't be > reproduced. Did you mean no warning was generated or not more than 1 > warning generated? Ok, agree that without the othervm the system property might have been the cause of the intermittent failures. By "Validation test can't be reproduced" I meant that 0 warnings were generated during ValidationWarningsTest run when the property setting was removed and all sources were replaced with "new SAXSource(new TestSAXDriver() ..." > > Thanks, > Joe > >> >>> >>> [1] >>> http://hg.openjdk.java.net/jdk9/jdk9/jaxp/file/6aa83d55614a/test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java >>> >>> Thanks, >>> Joe >>>> >>>> -Aleksej >>>> >>>> >>>> On 31/08/16 19:25, Joe Wang wrote: >>>>> Hi Aleksej, >>>>> >>>>> It's good to put the tests back online. Thanks for the diligent >>>>> work! I believe the change that made the tests run in othervm >>>>> could have fixed the intermittent issue. But adding debugging code >>>>> can always be helpful in case of failures. >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>>> On 8/30/16, 12:01 PM, Aleks Efimov wrote: >>>>>> Hello, >>>>>> >>>>>> Please, help to review the tests fix. >>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 >>>>>> >>>>>> The list of changes: >>>>>> 1. Two tests were modified to print exception occurred during >>>>>> execution. Before that these tests were failing silently. >>>>>> 2. The tests were slightly modified to correctly run with >>>>>> security manager run mode recently added to JAXP tests >>>>>> (JDK-8067170). >>>>>> 3. TransformationWarningsTest were modified to synchronize the >>>>>> TransformerFactory instantiation. >>>>>> >>>>>> The modified tests were executed 2000+ times (alongside to other >>>>>> tests from jaxp/test/javax/xml/jaxp/unittest/common) on linux-x64 >>>>>> and there were no failures observed. According to this result and >>>>>> that the tests were modified not to fail silently. I would like >>>>>> to remove these two tests from the jaxp problem list. >>>>>> If the tests will continue to fail on some configurations (JPRT >>>>>> shows no failures for few runs though) the proposed changes will >>>>>> help to diagnose the cause of failures. >>>>>> >>>>>> With Best Regards, >>>>>> Aleksej >>>>>> >>>> >> From kumar.x.srinivasan at oracle.com Wed Aug 31 22:09:01 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 31 Aug 2016 15:09:01 -0700 Subject: RFR: 8081388: JNI exception pending in jdk/src/windows/bin/java_md.c In-Reply-To: References: Message-ID: <57C7557D.9010304@oracle.com> Looks good, thanks Henry for fixing this. Kumar > Hi, > > Please review a trivial fix for 8081388, in a nutshell, > > - Return NULL from NewPlatformStringArray if an exception occurred > - All other places call this function already handled return value NULL > - Launcher handles exception in JavaMain, report error and exit. > > Cheers, > Henry > > diff --git a/src/java.base/share/native/libjli/java.c b/src/java.base/share/native/libjli/java.c > --- a/src/java.base/share/native/libjli/java.c > +++ b/src/java.base/share/native/libjli/java.c > @@ -1497,6 +1497,7 @@ > > NULL_CHECK0(cls = FindBootStrapClass(env, "java/lang/String")); > NULL_CHECK0(ary = (*env)->NewObjectArray(env, strc, cls, 0)); > + CHECK_EXCEPTION_RETURN_VALUE(0); > for (i = 0; i < strc; i++) { > jstring str = NewPlatformString(env, *strv++); > NULL_CHECK0(str); > diff --git a/src/java.base/share/native/libjli/java.h b/src/java.base/share/native/libjli/java.h > --- a/src/java.base/share/native/libjli/java.h > +++ b/src/java.base/share/native/libjli/java.h > @@ -253,6 +253,13 @@ > #define NULL_CHECK(NC_check_pointer) \ > NULL_CHECK_RETURN_VALUE(NC_check_pointer, ) > > +#define CHECK_EXCEPTION_RETURN_VALUE(CER_value) \ > + do { \ > + if ((*env)->ExceptionOccurred(env)) { \ > + return CER_value; \ > + } \ > + } while (JNI_FALSE) > + > #define CHECK_EXCEPTION_RETURN() \ > do { \ > if ((*env)->ExceptionOccurred(env)) { \ From eatnumber1 at google.com Tue Aug 30 03:25:37 2016 From: eatnumber1 at google.com (Russ Harmon) Date: Tue, 30 Aug 2016 03:25:37 +0000 Subject: Filing Bugs Against the Core Libs In-Reply-To: <06c9d8fd-5b50-1285-0621-ca89ab5e5378@oracle.com> References: <06c9d8fd-5b50-1285-0621-ca89ab5e5378@oracle.com> Message-ID: On Mon, Aug 29, 2016 at 7:27 PM David Holmes wrote: > Hi Russ, > > On 26/08/2016 5:39 AM, Russ Harmon wrote: > > Hello, > > > > I'd like to report a (minor) feature request / bug in the core libs. > What's > > the best way for me to do that? > > Brian already gave you the general answer, but in this case one of your > colleagues at Google, Martin Buccholz, is one of the primary maintainers > of the java.util.concurrent code. > Thanks for the pointer. I'll reach out to Martin. > > I recently ran into this stack trace > > . > It's > > not very useful to me, since I can't determine from either the message or > > the stack trace why the task was rejected. It would be much more helpful > if > > either a) the message stated the reason, or b) the stack trace pointed > at a > > line of code which unambiguously indicated a reason (e.x. a list of "if" > > statements which throw this exception, so I can look at the condition to > > see why the task was rejected) > > It is documented to be thrown: > > * If the task cannot be submitted for execution, either because this > * executor has been shutdown or because its capacity has been reached, > * the task is handled by the current {@code RejectedExecutionHandler}. > > The actual code that throws it doesn't know the exact reason. To my understanding though, the reason is not outside of the purview of the JDK (aka, the rejection is not decided upon by outside code), and therefore some refactoring of the existing code could make it known. > But you > seem to be running a custom RejectedExeceptionHandler so it should be > able to determine whether the executor is shutdown, or if using a > bounded queue which may have become full. > There's a race condition if I do that. If the executor has not been shutdown, and the executor has reached capacity, the RejectedExceptionHandler will be called. I can then check the queue size in the RejectedExceptionHandler, but it's possible that tasks completed before I'm able to check the size, so the queue won't appear full. I think that this is actually what has occurred in my case. The stack trace I linked earlier shows a non-full queue, but I know that the executor was not shutting down. Therefore, it must have been caused by the queue filling up, then depleting before the size was read for generation of the error message. > Cheers, > David > > > Thanks, > > Russ Harmon > > Google Site Reliability Engineer > > >