From chris at hazelcast.com Sun Aug 2 07:52:05 2015 From: chris at hazelcast.com (Christoph Engelbert) Date: Sun, 2 Aug 2015 10:52:05 +0300 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> Message-ID: <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> Hey Paul, The assumption of non creating JDK classes without calling constructors is not completely right. Seen serialization frameworks that create String instances and ?injecting? a char[] afterwards however I prefer calling the package private constructor to just prevent copying of the char[] (in cases where it won?t break the immutability contract like deserialization). Chris > Am 30.06.2015 um 12:22 schrieb Paul Sandoz : > > Hi Henri, > > Thanks for raising this discussion. > > Just to augment what Chris says here. > > We cannot directly expose Unsafe.allocateInstance in a public API and try and place in a little known corner and hope only the people who are meant to use it will and will do so responsibly :-) > > There are a bunch of general use-cases: > > 1) Mocking; > 2) Proxying; and > 3) Serialization. > > It should be possible to corral 3 (and possibly 2) in some safe mechanism. I dunno how to do that for 1. > > Constructing an object without calling its constructor is inherently integrity busting (unless somehow hidden or contained) and IIUC mocking by design is a form of semi-controlled integrity busting. > > Would i be correct in assuming that mocking is primarily used for testing and that if used in production would raise some eye brows? > > One approach we could consider for 1, trying to be pragmatic and recognising the reality here, is a method that constructs an object without calling it's constructor under the following conditions: > > 1) a security check is performed if a security manager is present; and > > 2) it would not be possible to construct any JDK class (e.g. classes loaded by the boot loader). > > That is not a definite proposal but i would be really interested in your feedback given your experience with Objenesis and mocking. > > Paul. From paul.sandoz at oracle.com Mon Aug 3 09:50:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 3 Aug 2015 11:50:14 +0200 Subject: Result: New JDK9 Committer: Amy Lu Message-ID: Voting for Amy Lu [1] is now closed. Yes: 32 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Paul. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002433.html From charlie.hunt at oracle.com Mon Aug 3 14:27:13 2015 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 3 Aug 2015 09:27:13 -0500 Subject: Replacing Unsafe.allocateInstance In-Reply-To: <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> References: <558EB8B7.4000102@redhat.com> <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> Message-ID: <9AFE42F2-D202-4BFD-9259-A1F8EBE87DC3@oracle.com> Hi Chris, You mentioned you have ?Seen serialization frameworks that create String instances and ?injecting? a char[] afterwards however I prefer calling the package private constructor to just prevent copying of the char[] (in cases where it won?t break the immutability contract like deserialization).? Could you possibly point me to such serialization frameworks, and you also mentioned you prefer calling the package private constructor (I?m assuming this is on java.lang.String) ? I do not need to see the entire code base, a segment of code that shows how java.lang.String is being constructed would be sufficient, (in the case you described and the aforementioned serialization frameworks). thanks, charlie > On Aug 2, 2015, at 2:52 AM, Christoph Engelbert wrote: > > Hey Paul, > > The assumption of non creating JDK classes without calling constructors is not completely right. > Seen serialization frameworks that create String instances and ?injecting? a char[] afterwards however I prefer calling the package private constructor to just prevent copying of the char[] (in cases where it won?t break the immutability contract like deserialization). > > Chris > >> Am 30.06.2015 um 12:22 schrieb Paul Sandoz : >> >> Hi Henri, >> >> Thanks for raising this discussion. >> >> Just to augment what Chris says here. >> >> We cannot directly expose Unsafe.allocateInstance in a public API and try and place in a little known corner and hope only the people who are meant to use it will and will do so responsibly :-) >> >> There are a bunch of general use-cases: >> >> 1) Mocking; >> 2) Proxying; and >> 3) Serialization. >> >> It should be possible to corral 3 (and possibly 2) in some safe mechanism. I dunno how to do that for 1. >> >> Constructing an object without calling its constructor is inherently integrity busting (unless somehow hidden or contained) and IIUC mocking by design is a form of semi-controlled integrity busting. >> >> Would i be correct in assuming that mocking is primarily used for testing and that if used in production would raise some eye brows? >> >> One approach we could consider for 1, trying to be pragmatic and recognising the reality here, is a method that constructs an object without calling it's constructor under the following conditions: >> >> 1) a security check is performed if a security manager is present; and >> >> 2) it would not be possible to construct any JDK class (e.g. classes loaded by the boot loader). >> >> That is not a definite proposal but i would be really interested in your feedback given your experience with Objenesis and mocking. >> >> Paul. > From amy.lu at oracle.com Tue Aug 4 02:18:01 2015 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 04 Aug 2015 10:18:01 +0800 Subject: Result: New JDK9 Committer: Amy Lu In-Reply-To: References: Message-ID: <55C020D9.1040005@oracle.com> Thanks everyone for your great help and support! Thanks, Amy On 8/3/15 5:50 PM, Paul Sandoz wrote: > Voting for Amy Lu [1] is now closed. > > Yes: 32 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. > > Paul. > > [1]http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002433.html From mark.reinhold at oracle.com Tue Aug 4 14:56:04 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Aug 2015 07:56:04 -0700 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) Message-ID: <20150804075604.598755@eggemoggin.niobe.net> FYI: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html (Please reply on jigsaw-dev rather than on jdk9-dev or core-libs-dev.) - Mark From paul.sandoz at oracle.com Tue Aug 4 15:39:13 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Aug 2015 17:39:13 +0200 Subject: Replacing Unsafe.allocateInstance In-Reply-To: <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> References: <558EB8B7.4000102@redhat.com> <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> Message-ID: On 2 Aug 2015, at 09:52, Christoph Engelbert wrote: > Hey Paul, > > The assumption of non creating JDK classes without calling constructors is not completely right. > Seen serialization frameworks that create String instances and ?injecting? a char[] afterwards however I prefer calling the package private constructor to just prevent copying of the char[] (in cases where it won?t break the immutability contract like deserialisation) This is of course playing with fire on many levels and totally unsupported :-) The package private constructor could go away, the internals of String could change (e.g. optimise for UTF-8 ) in a manner that is also not global (imagine species of String, each with different layouts, char[], byte[] UTF-8, String object header fused with an array). We need frozen arrays: http://cr.openjdk.java.net/~jrose/arrays/frozen-array-value-rules.html Paul. From henri at tremblay.pro Tue Aug 4 19:14:51 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Tue, 4 Aug 2015 15:14:51 -0400 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> Message-ID: Hi, I might have missed something but the purpose of injecting the char[] is to prevent copying it. But frozen arrays seem to require a copy to get the frozen version. I would much prefer the JVM to be able to guess that an array will in fact never be modified and so could be used without copying (A copy can be made if needed afterwards). Or maybe just be able to annotate @Constant Is there something I'm not understanding? Thanks, Henri On 4 August 2015 at 11:39, Paul Sandoz wrote: > > On 2 Aug 2015, at 09:52, Christoph Engelbert wrote: > > > Hey Paul, > > > > The assumption of non creating JDK classes without calling constructors > is not completely right. > > Seen serialization frameworks that create String instances and > ?injecting? a char[] afterwards however I prefer calling the package > private constructor to just prevent copying of the char[] (in cases where > it won?t break the immutability contract like deserialisation) > > This is of course playing with fire on many levels and totally unsupported > :-) > > The package private constructor could go away, the internals of String > could change (e.g. optimise for UTF-8 ) in a manner that is also not global > (imagine species of String, each with different layouts, char[], byte[] > UTF-8, String object header fused with an array). > > We need frozen arrays: > > http://cr.openjdk.java.net/~jrose/arrays/frozen-array-value-rules.html > > Paul. > > > > > > From paul.sandoz at oracle.com Tue Aug 4 19:49:25 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Aug 2015 21:49:25 +0200 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> Message-ID: On 4 Aug 2015, at 21:14, Henri Tremblay wrote: > Hi, > > I might have missed something but the purpose of injecting the char[] is to prevent copying it. But frozen arrays seem to require a copy to get the frozen version. > > I would much prefer the JVM to be able to guess that an array will in fact never be modified and so could be used without copying (A copy can be made if needed afterwards). Or maybe just be able to annotate @Constant > > Is there something I'm not understanding? > I was hoping in certain cases that the compiler would be able to work out that the frozen array does not escape and can therefore optimise away the copy. Perhaps i am being naive on this point :-) I don?t know how difficult/fragile that would be in practice to detect. Paul. From chris at hazelcast.com Tue Aug 4 20:20:02 2015 From: chris at hazelcast.com (Christoph Engelbert) Date: Tue, 4 Aug 2015 22:20:02 +0200 Subject: Replacing Unsafe.allocateInstance In-Reply-To: References: <558EB8B7.4000102@redhat.com> <24C00A2A-A79B-4438-8A31-ADE39C739C0B@hazelcast.com> Message-ID: <1EC3CE14-B065-45B2-93CB-97DC73E979C1@hazelcast.com> Such optimizations would be absolutely awesome but yeah questions is the complexity. About where you can find such kind of optimizations? At least in Hazelcast since we have our own high performance UTF8 encoder / decoder. To eventually create the String we either call String package private constructors or use other tricks (in the past) like sun.misc.JavaLangAccess::newStringUnsafe just to prevent the char[] copy in almost all cases. For a system that needs low jitter rate and predictable throughput any kind of additional allocation hurts. And yeah I know that Java 9 String memory consumption optimization will give us a hard time. I guess somebody will already look into it. In the worst case we always have a fallback to call default constructors but we really don?t want to do that :) > Am 04.08.2015 um 21:49 schrieb Paul Sandoz : > > > On 4 Aug 2015, at 21:14, Henri Tremblay wrote: > >> Hi, >> >> I might have missed something but the purpose of injecting the char[] is to prevent copying it. But frozen arrays seem to require a copy to get the frozen version. >> >> I would much prefer the JVM to be able to guess that an array will in fact never be modified and so could be used without copying (A copy can be made if needed afterwards). Or maybe just be able to annotate @Constant >> >> Is there something I'm not understanding? >> > > I was hoping in certain cases that the compiler would be able to work out that the frozen array does not escape and can therefore optimise away the copy. Perhaps i am being naive on this point :-) I don?t know how difficult/fragile that would be in practice to detect. > > Paul. From alejandro.murillo at oracle.com Wed Aug 5 05:22:43 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 4 Aug 2015 22:22:43 -0700 (PDT) Subject: jdk9-dev: HotSpot Message-ID: <55C19DA3.3040606@oracle.com> jdk9-hs-2015-07-31 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/cf76386db5c7 http://hg.openjdk.java.net/jdk9/dev/corba/rev/d8126bc88fa5 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b5d723199d45 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/13824e252a5f http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/55bb88306dc5 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/19a9b9a933eb http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7eef740c1482 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ed56500172f4 Component : VM Status : Go for integration Date : 08/04/2015 at 14:00 MSK Tested By : VM SQE &leonid.mesnik at oracle.com Bundles : 2015-07-31-171927.amurillo.jdk9-hs-2015-07-31-snapshot Testing: 86 new failures, 2246 known failures, 387462 passed. Issues and Notes: No detailed analysis. No stoppers have been detected. The linux-arm64 execution was broken in UTE. Go for integration CRs for testing: 8004687: G1: Parallelize object self-forwarding and scanning during an evacuation failure 8026324: hs_err improvement: Add summary section to hs_err file 8026333: hs_err improvement: Print GC Strategy 8026336: hs_err improvement: Print compilation mode, server, client or tiered 8048353: jstack -l crashes VM when a Java mirror for a primitive type is locked 8059038: Create new launcher for SA tools 8062938: sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgumentException: Could not map vmid to user name 8079082: VerifyNoCSetOopsClosure is derived twice from Closure 8081695: Old verifier fails to reject bad access to protected method 8082782: vm crash on StressRedefineWithoutBytecodeCorruption fails with assert(((Metadata*)obj)->is_valid()) failed: obj is valid 8087315: SIGBUS error in nsk/jvmti/RedefineClasses/StressRedefine 8129895: New verifier fails to reject erroneous cast from int[] to other arrays of small integer types 8129897: Old verifier fails to reject erroneous cast from boolean[] to byte[] 8129971: TestStackTrace.java: ArrayIndexOutOfBoundsException thrown by AARCH64ThreadContext.setRegister 8130434: [TESTBUG] Harden TestLargePageUseForAuxMemory for more page size combinations 8130459: Add additional validation after heap creation 8130676: [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 8130832: Extend the WhiteBox API to provide information about the availability of compiler intrinsics 8130858: CICompilerCount=1 when tiered is off is not allowed any more 8130931: Refactor CardTableModRefBS[ForCTRS] 8131062: aarch64: add support for GHASH acceleration 8131319: Move G1Allocator::_summary_bytes_used back to G1CollectedHeap 8131343: Remove unused imports from hotspot/test/testlibrary/jdk/test/lib/*.java 8131362: aarch64: C2 does not handle large stack offsets 8131600: heapdump/JMapHeap EXCEPTION_ACCESS_VIOLATION 8131761: Fix merge error adding code that was removed in 8077936 8131779: AARCH64: add Montgomery multiply intrinsic 8131782: C1 Class.cast optimization breaks when Class is loaded from static final 8132010: aarch64: regression test fails compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnSupportedCPU.java 8132094: Mark intermittently failuring core-svc tests 8132148: G1 hs_err region dump legend out of sync with region values 8132232: Signature mismatch between declaration and definition of PosixSemaphore::timedwait 8132286: change 'InlineNotify' flag option from "product" to "diagnostic" -- Alejandro From Sergey.Bylokhov at oracle.com Wed Aug 5 07:33:40 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Aug 2015 10:33:40 +0300 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky Message-ID: <55C1BC54.10200@oracle.com> I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to JDK 9 Reviewer. Semyon is currently a JDK9 Committer and a member of AWT/Swing teams at Oracle. Here is the list of fixes(40): http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 Votes are due by August 19, 2015. Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Sergey Bylokhov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote -- Best regards, Sergey. From sundararajan.athijegannathan at oracle.com Wed Aug 5 07:45:29 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 05 Aug 2015 13:15:29 +0530 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1BF19.2010208@oracle.com> Vote: yes -Sundar On 8/5/2015 1:03 PM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to > JDK 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams > at Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From yuri.nesterenko at oracle.com Wed Aug 5 09:18:59 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 05 Aug 2015 12:18:59 +0300 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1D503.2080009@oracle.com> Vote: yes -yan On 08/05/2015 10:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to JDK > 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams at > Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From alexandr.scherbatiy at oracle.com Wed Aug 5 09:41:44 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Aug 2015 12:41:44 +0300 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1DA58.2060008@oracle.com> Vote: yes Thanks, Alexandr. On 8/5/2015 10:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to > JDK 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams > at Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From volker.simonis at gmail.com Wed Aug 5 09:52:49 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Aug 2015 11:52:49 +0200 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: Vote: yes Regards, Volker On Wed, Aug 5, 2015 at 9:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to JDK 9 > Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams at > Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Wed Aug 5 10:26:53 2015 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 05 Aug 2015 13:26:53 +0300 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1E4ED.3010708@oracle.com> Vote: YES Artem On 08/05/15 10:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to JDK > 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams at > Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From alexander.zvegintsev at oracle.com Wed Aug 5 10:31:33 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 05 Aug 2015 13:31:33 +0300 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1E605.2070807@oracle.com> Vote: yes Thanks, Alexander. On 08/05/2015 10:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to > JDK 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams > at Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From vladimir.x.ivanov at oracle.com Wed Aug 5 10:40:42 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 05 Aug 2015 13:40:42 +0300 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1E82A.4080802@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/5/15 10:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to JDK > 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams at > Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From serguei.spitsyn at oracle.com Wed Aug 5 11:46:49 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 05 Aug 2015 04:46:49 -0700 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C1F7A9.3010905@oracle.com> Vote: yes On 8/5/15 12:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to > JDK 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams > at Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From yumin.qi at oracle.com Wed Aug 5 16:03:48 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 5 Aug 2015 09:03:48 -0700 Subject: CFV: New JDK 9 Reviewer: Semyon Sadetsky In-Reply-To: <55C1BC54.10200@oracle.com> References: <55C1BC54.10200@oracle.com> Message-ID: <55C233E4.6060702@oracle.com> Vote: Yes On 8/5/2015 12:33 AM, Sergey Bylokhov wrote: > I hereby nominate Semyon Sadetsky (OpenJDK user name: ssadetsky) to > JDK 9 Reviewer. > > Semyon is currently a JDK9 Committer and a member of AWT/Swing teams > at Oracle. > Here is the list of fixes(40): > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=ssadetsky&revcount=40 > > > Votes are due by August 19, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From lana.steuck at oracle.com Wed Aug 5 21:09:15 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 5 Aug 2015 14:09:15 -0700 (PDT) Subject: jdk9-b76: dev Message-ID: <201508052109.t75L9FwS020052@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/d82072b699b8 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/ab231613d720 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/80ab772222fb http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4526c0da8fb3 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/55bb88306dc5 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/36801a89a042 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/0bc8d1656d6f http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/d8126bc88fa5 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8076164 client-libs [JTextField] When input too long Thai character, cursor's behavior is JDK-8098835 client-libs [PIT] Endless loop in JEditorPane JDK-8085948 client-libs [Regression] Few Swing, AWT and 2D case fails with Decoder isn't imple JDK-8131673 client-libs [TEST_BUG] add @modules to some OS X-specific regtests JDK-8130430 client-libs [TEST_BUG] remove unnecessary internal calls from javax/swing/JRadioBu JDK-8080932 client-libs [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Ba JDK-8080953 client-libs [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly JDK-8087110 client-libs [TESTBUG] Test javax/swing/JFileChooser/8002077/bug8002077.java fails JDK-8130390 client-libs Applet fails to launch on virtual desktop JDK-8132408 client-libs Check os.name before os.version in SunGraphicsEnvironment constructor JDK-8129457 client-libs Disposer.pollRemove may fail to dispose JDK-8065081 client-libs Intermittent NPE in Java2Demo applet on Stop/Restart in appletviewer JDK-8129894 client-libs NSApplicationAWT.m:343:72: error: comparison of constant 777 with expr JDK-8087201 client-libs OGL: rendering of lcd text is slow JDK-8129511 client-libs PlatformMidi.c:83 uses malloc without malloc header JDK-8130772 client-libs Util.hitMnemonics does not work: getSystemMnemonicKeyCodes() returns A JDK-8065556 core-libs (bf) Buffer.position and other methods should include detail in IAE JDK-8066013 core-libs (prefs) Unused variable in src/java.prefs/share/classes/java/util/pref JDK-8027607 core-libs (rb) Provide UTF-8 based properties resource bundles JDK-8132374 core-libs AIX: fix value of os.version property JDK-8132459 core-libs ExceptionInInitializerError from 'java -version' under zh_CN.GB18030 l JDK-8132305 core-libs fix incorrect title assignment in Nashorn JavaFX samples JDK-8129361 core-libs ISO 4217 amendment 160 JDK-8132335 core-libs jimage tool extract and recreate options are not consistent JDK-8132206 core-libs move ScanTest.java into OpenJDK JDK-8062849 core-libs Optimize EnumMap.equals JDK-8132705 core-libs Refactor SharedSecrets in sun.misc.JavaNetAccess JDK-8132475 core-libs The commands in the modular images are executable by the owner only (o JDK-8037957 core-svc [TEST_BUG] javax/management/mxbean/LeakTest.java misses MerlinMXBean & JDK-8132059 core-svc com/sun/jdi/BreakpointTest.java fails with java.lang.IllegalArgumentEx JDK-8075658 core-svc Mark intermittently failuring core-svc tests JDK-8131783 core-svc Put LowMemoryTest.java in quarantine JDK-8079618 deploy AccessControlException with deployment cache and RMI JDK-8003984 deploy Allow relaunch between 32 / 64 bit versions in Java Web Start when you JDK-8055448 deploy Provide a way to specify JRE data model requirements in JNLP file JDK-8056013 deploy Web Start looks in currently directory for all classes prior to jars - JDK-8131483 hotspot aarch64: illegal stlxr instructions JDK-8131358 hotspot aarch64: test compiler/loopopts/superword/ProdRed_Float.java fails whe JDK-8131054 hotspot aix: fix two minor issues: large page size and hs_err printing. JDK-8132166 hotspot closed/com/oracle/jfr/sa tests failing since removed from exclude list JDK-8075171 hotspot Contended Locking fast notify bucket JDK-8131675 hotspot EA fails with assert(false) failed: not unsafe or G1 barrier raw Store JDK-8131326 hotspot Enable CheckIntrinsics in all types of builds JDK-8131676 hotspot Fix warning 'negative int converted to unsigned' after 8085932. JDK-8085932 hotspot Fixing bugs in detecting memory alignments in SuperWord JDK-8131344 hotspot Missing klass.inline.hpp include in compiler files JDK-8122944 hotspot perfdata used is seen as too high on sparc zone with jdk1.9 and causes JDK-8131048 hotspot ppc: implement CRC32 intrinsic JDK-8131166 hotspot Remove additional whitespace in G1Allocator JDK-8079301 hotspot Some command line options not settable via JAVA_TOOL_OPTIONS JDK-8078629 hotspot VM should constant fold Unsafe.get*() loads from final fields JDK-7035456 install Reduce numbers of XmlParser.cpp JDK-8048596 security-libs Tests for AEAD ciphers JDK-8129214 tools Access error when unboxing a primitive whose target is a type-variable JDK-8086737 tools Add support for -release to Javadoc JDK-8132215 tools class InferenceContext should live in a separate file JDK-8081769 tools Redundant error message on bad usage of 'class' literal JDK-8131742 tools Syntactically meaningless code accepted by javac JDK-8130826 tools test writes file in test source directory JDK-8062647 tools Wrong indentation of arguments of annotated methods JDK-8132256 xml jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/Cla JDK-8130059 xml jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/En From volker.simonis at gmail.com Thu Aug 6 09:56:14 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 6 Aug 2015 11:56:14 +0200 Subject: CFV: New jdk9 Committer: Axel Siebenborn Message-ID: I hereby nominate Axel Siebenborn to jdk9 Committer. Axel is a long-term member of the SAP JVM team at SAP. He was one of the initial authors of our Hotspot port to PPC64 and is currently working on fixing and improving the various garbage collectors on our weak memory platforms. He has contributed 10 changes to the hotspot repository so far: 8074561: Wrong volatile qualifier for field ClassLoaderDataGraphKlassIteratorAtomic::_next_klass http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 8036976: PPC64: implement the template interpreter http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 8034867: Object references from expression stack are not visible as roots via jvmti FollowReferences and HeapDump http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 8035392: cppInterpreter: fix message of NPE http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 8025599: Missing store barrier with OptimizeStringConcat http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 7158988: jvm crashes while debugging on x86_32 and x86_64 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 Votes are due by 20:00 CET, August 20, 2015. Only current JDK9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Volker [1] http://openjdk.java.net/census#jdk9 [2] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Thu Aug 6 10:03:46 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 06 Aug 2015 13:03:46 +0300 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C33102.4030101@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/6/15 12:56 PM, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From jesper.wilhelmsson at oracle.com Thu Aug 6 12:12:14 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 06 Aug 2015 14:12:14 +0200 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C34F1E.6050208@oracle.com> Vote: Yes /Jesper Volker Simonis skrev den 6/8/15 11:56: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From serguei.spitsyn at oracle.com Thu Aug 6 12:14:14 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 6 Aug 2015 05:14:14 -0700 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C34F96.2000402@oracle.com> Vote: yes On 8/6/15 02:56, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From coleen.phillimore at oracle.com Thu Aug 6 12:32:07 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Aug 2015 08:32:07 -0400 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C353C7.6030205@oracle.com> Vote: yes On 8/6/15 5:56 AM, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From volker.simonis at gmail.com Thu Aug 6 12:47:05 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 6 Aug 2015 14:47:05 +0200 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: Vote: yes On Thu, Aug 6, 2015 at 11:56 AM, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From james.laskey at oracle.com Thu Aug 6 13:32:12 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 6 Aug 2015 10:32:12 -0300 Subject: Result: CFV: New JDK9 Committer: Michael Haupt In-Reply-To: <1C4004C7-F95B-4EA3-ACE1-5DAB88E241AD@oracle.com> References: <1C4004C7-F95B-4EA3-ACE1-5DAB88E241AD@oracle.com> Message-ID: <7295D447-2C09-459B-9825-85068774F609@oracle.com> Voting for Michael Haupt [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Cheers, ? Jim [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002462.html > On Jul 20, 2015, at 10:51 AM, Jim Laskey (Oracle) wrote: > > I hereby nominate Michael Haupt to jdk9 Committer > > Michael has made many contributions in several areas of the JDK. [1] > > Michael is a recent addition to the Nashorn team; his focus is on dynamic language implementations. He also collaborates with the Valhalla project for value types. Prior to joining Nashorn, Michael worked briefly in the HotSpot compiler team. He has been an Oracle employee since 2011, which is when he joined the Virtual Machine Research Group at Oracle Labs, where he has worked on the Maxine meta-circular JVM and on dynamic language implementations. He used to be the tech lead of the FastR project, a high-performance Java-based implementation of the R programming language. Michael has also contributed to the Invokedynamic infrastructure in the past. > > Votes are due by Aug 3rd, 2015 > > Only current JDK9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Cheers, > > ? Jim > > [1] > *** JSR 292: > > changeset: 5688:050116960e99 > user: twisti > date: Tue Jul 24 10:47:44 2012 -0700 > summary: 7023639: JSR 292 method handle invocation needs a fast path for compiled code > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/050116960e99 > > changeset: 8369:465e5b2bb615 > user: acorn > date: Fri May 08 14:00:24 2015 -0400 > summary: 8030680: 292 cleanup from default method code assessment > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/465e5b2bb615 > > changeset: 12416:2919a03653a8 > user: mhaupt > date: Fri Jul 17 08:10:41 2015 +0200 > summary: 8062543: Replace uses of MethodHandleImpl.castReference with Class.cast > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2919a03653a8 > > changeset: 8208:6c4ca18a0666 > user: mhaupt > date: Tue Apr 14 18:16:10 2015 +0300 > summary: 8076461: JSR292: remove unused native and constants > http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/44a53b8e25e6 > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017588.html (verification) > > changeset: 11850:e0ac3e9decb0 > user: mhaupt > date: Tue Apr 14 18:26:01 2015 +0300 > summary: 8033465: JSR292: InvokerBytecodeGenerator: convert a check for REF_invokeVirtual on an interface into an assert > http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/e0ac3e9decb0 > > *** hotspot: > > changeset: 8632:8d246004a89f > user: mhaupt > date: Tue Mar 31 21:46:44 2015 +0200 > summary: 6900757: minor bug fixes to LogCompilation tool > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0fb7705845de > > changeset: 8345:d3413c4fee16 > user: mhaupt > date: Tue May 05 13:06:10 2015 +0200 > summary: 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d3413c4fee16 > > *** nashorn: > > changeset: 1277:4dc7eb763139 > user: mhaupt > date: Fri May 15 10:21:48 2015 +0200 > summary: 8080471: fix usage of replace and file separator in Nashorn tests > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/7320ba416df1 > > changeset: 1342:becb3bb6a422 > user: mhaupt > date: Thu Jul 02 11:20:47 2015 +0200 > summary: 8130307: improve Nashorn Javadoc target > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/becb3bb6a422 > > changeset: 1341:6eca661ddf79 > user: mhaupt > date: Thu Jul 02 11:09:20 2015 +0200 > summary: 8130306: enable running Nashorn test on Windows > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6eca661ddf79 > > Other changes follow. > > changeset: 1279:71d7a37e6dfb > user: mhaupt > date: Fri May 15 16:36:25 2015 +0200 > summary: 8049300: jjs scripting: need way to quote $EXEC command arguments to protect spaces > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/71d7a37e6dfb > > changeset: 1339:d95394322204 > user: mhaupt > date: Wed Jul 01 16:26:25 2015 +0200 > summary: 8130127: streamline input parameter of Nashorn scripting $EXEC function > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d95394322204 > > changeset: 1307:0eeaadd17fff > user: mhaupt > date: Fri Jun 05 12:38:53 2015 +0200 > summary: 8080087: Nashorn $ENV.PWD is originally undefined > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0eeaadd17fff > > changeset: 1300:14ec7d7af490 > user: mhaupt > date: Tue Jun 02 14:35:03 2015 +0200 > summary: 8080275: transparently download testng.jar for Nashorn testing > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/14ec7d7af490 > > changeset: 1299:078107e0651f > user: mhaupt > date: Tue Jun 02 14:34:37 2015 +0200 > summary: 8081668: fix Nashorn ant externals command > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/078107e0651f > > changeset: 1311:d1689c1df3aa > user: mhaupt > date: Mon Jun 08 10:28:04 2015 +0200 > summary: 8085885: address Javadoc warnings in Nashorn source code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d1689c1df3aa > > changeset: 1298:0d4841f2c800 > user: mhaupt > date: Tue Jun 02 10:40:19 2015 +0200 > summary: 8081604: rename ScriptingFunctions.tokenizeCommandLine > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0d4841f2c800 > > changeset: 1297:776551a5b3a2 > user: mhaupt > date: Tue Jun 02 10:40:10 2015 +0200 > summary: 8081603: erroneous dot file generated from Nashorn --print-code > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/776551a5b3a2 > > changeset: 1271:063ed2f959e4 > user: mhaupt > date: Wed May 13 15:41:46 2015 +0200 > summary: 8080286: use path separator setting consistently in Nashorn project properties > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/063ed2f959e4 > > changeset: 1301:10553f87f3e7 > user: mhaupt > date: Tue Jun 02 17:08:13 2015 +0200 > summary: 8081696: reduce dependency of Nashorn tests on external components > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/10553f87f3e7 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote From michael.haupt at oracle.com Thu Aug 6 13:40:31 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 6 Aug 2015 15:40:31 +0200 Subject: Result: CFV: New JDK9 Committer: Michael Haupt In-Reply-To: <7295D447-2C09-459B-9825-85068774F609@oracle.com> References: <1C4004C7-F95B-4EA3-ACE1-5DAB88E241AD@oracle.com> <7295D447-2C09-459B-9825-85068774F609@oracle.com> Message-ID: <011AC5BE-ADFB-4856-9E2B-23DC86AFFE1D@oracle.com> ... thanks, everyone! Michael > Am 06.08.2015 um 15:32 schrieb Jim Laskey (Oracle) : > > Voting for Michael Haupt [1] is now closed. > > Yes: 18 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. > > Cheers, > > ? Jim > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-July/002462.html -- 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 is committed to developing practices and products that help protect the environment From yumin.qi at oracle.com Thu Aug 6 16:38:17 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 6 Aug 2015 09:38:17 -0700 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C38D79.8050201@oracle.com> Vote: Yes On 8/6/2015 2:56 AM, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote From alejandro.murillo at oracle.com Thu Aug 6 20:11:02 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 6 Aug 2015 14:11:02 -0600 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C3BF56.7070000@oracle.com> vote: yes On 8/6/2015 3:56 AM, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. -- Alejandro From david.holmes at oracle.com Fri Aug 7 02:19:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Aug 2015 12:19:50 +1000 Subject: CFV: New jdk9 Committer: Axel Siebenborn In-Reply-To: References: Message-ID: <55C415C6.7010503@oracle.com> Vote: yes David On 6/08/2015 7:56 PM, Volker Simonis wrote: > I hereby nominate Axel Siebenborn to jdk9 Committer. > > Axel is a long-term member of the SAP JVM team at SAP. > He was one of the initial authors of our Hotspot port to PPC64 and is > currently working on fixing and improving the various garbage > collectors on our weak memory platforms. > > He has contributed 10 changes to the hotspot repository so far: > > 8074561: Wrong volatile qualifier for field > ClassLoaderDataGraphKlassIteratorAtomic::_next_klass > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e8652b6ab788?revcount=40 > > 8068909: SIGSEGV in c2 compiled code with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8596a20c8de1?revcount=40 > > 8036666: VMTI GetObjectMonitorUsage does not return correct recursion count > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5d9a04b11ea2?revcount=40 > > 8036976: PPC64: implement the template interpreter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/58cf34613a72?revcount=40 > > 8034867: Object references from expression stack are not visible as > roots via jvmti FollowReferences and HeapDump > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/dcca80b5e7e7?revcount=40 > > 8035392: cppInterpreter: fix message of NPE > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1e820011ee5f?revcount=40 > > 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1b422ef5288a?revcount=40 > > 8025599: Missing store barrier with OptimizeStringConcat > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d8d059e90ec1?revcount=40 > > 7158988: jvm crashes while debugging on x86_32 and x86_64 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/19e197e2a1af?revcount=40 > > 7100935: win32: memmove is not atomic but is used for > pd_conjoint_*_atomic operations > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/16f9fa2bf76c?revcount=40 > > Votes are due by 20:00 CET, August 20, 2015. > > Only current JDK9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Volker > > [1] http://openjdk.java.net/census#jdk9 > [2] http://openjdk.java.net/projects#committer-vote > From erik.joelsson at oracle.com Mon Aug 10 10:02:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Aug 2015 12:02:06 +0200 Subject: RFR - 8027634: Support @argfiles for java command-line tool In-Reply-To: References: Message-ID: <55C8769E.3080008@oracle.com> Hello Henry, Build changes look good to me. /Erik On 2015-07-10 05:48, Henry Jen wrote: > Hi, > > Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. > > Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib. > > I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. > > Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases. > > Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile. > > If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token. > > CCing build-dev for build changes, jdk9-dev for wider audience for tools. > > Cheers, > Henry > > [1] https://bugs.openjdk.java.net/browse/JDK-8027634 > [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile > [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java From alejandro.murillo at oracle.com Tue Aug 11 04:59:38 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 10 Aug 2015 22:59:38 -0600 Subject: jdk9-dev: HotSpot Message-ID: <55C9813A.1030604@oracle.com> jdk9-hs-2015-08-06 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/4c85a31c02e8 http://hg.openjdk.java.net/jdk9/dev/corba/rev/8bb2441c0fec http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/9edd3f7341f8 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/a7b1a86945e0 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/bd6ece68cf8a http://hg.openjdk.java.net/jdk9/dev/jdk/rev/66e2f4decc2a http://hg.openjdk.java.net/jdk9/dev/langtools/rev/48f213c93965 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/33cecbc59f2a Component : VM Status : Go for integration Date : 08/10/2015 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-08-06-200512.amurillo.jdk9-hs-2015-08-06-snapshot Testing: 498 new failures, 2556 known failures, 416299 passed. Issues and Notes: The high number of new failures (498) in fact is caused by a few minor issue, new bugs will be submitted during this week. No stoppers have been detected so far. Go for integration CRs for testing: 6661889: thread id on Linux is inconsistent in error and log outputs 8004073: Implement C2 Ideal node specific dump() method 8059036: Implement Diagnostic Commands for heap and finalizerinfo 8080298: Clean up os::...::supports_variable_stack_size() 8129215: com.sun.jmx.mbeanserver.Introspector may provide results inconsistent with the JavaBeans Introspector 8129976: RunFinalizationTest.java times out frequently 8130309: Need to bailout cleanly if creation of stubs fails when codecache is out of space 8130339: Add tracing info to LowMemoryTest.java to help 8130339 diagnosis 8130527: Serviceability tests fails with Can't attach to process 8132242: LogTouchedMethods (8025692) asserts if TieredCompilation is off. 8132457: Unify command-line flags controlling the usage of compiler intrinsics 8132525: java -client -XX:+TieredCompilation -XX:CICompilerCount=1 -version asserts since 8130858 8132875: AArch64: Fix error introduced into AArch64 CodeCache by commit for 8130309 8132876: Increase PerfDataMemorySize to 64K 8132953: imageDecompressor.hpp should not include precompiled.hpp -- Alejandro From gs.biju at gmail.com Tue Aug 11 14:11:43 2015 From: gs.biju at gmail.com (Biju G.S Nair) Date: Tue, 11 Aug 2015 10:11:43 -0400 Subject: DirectByteBuffer change proposal Message-ID: Hello All, While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 currently applied to jdk 9 (which I had requested to be back ported to JDK 8 & 7) fixes the OOM exception during memory allocation by exponentially increasing the sleep time, this can negatively impact low latency applications using DirectByteBuffers. If we are able to provide a new JVM parameter which the users can set to a percentage value of DirectBuffer use as threshold when the "System.gc()" call in java/nio/Bits.java to be made, then the probability of sleep time being much lower is high. Also it gives users some control over when the gc() need to be requested instead of starting the gc() at the last moment when the direct memory is used fully. Without knowing all the details, to me it looks like a straight forward change. Let me know if there is any issue with the proposed change. If this change is a possibility let me know how I can make a request for this change. Thanks, Biju From sean.coffey at oracle.com Tue Aug 11 14:30:08 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 11 Aug 2015 15:30:08 +0100 Subject: DirectByteBuffer change proposal In-Reply-To: References: Message-ID: <55CA06F0.9020705@oracle.com> Biju, These lists are often not suitable for JDK component specific issues. You should discuss your issue on the nio-dev specific mailing list : http://mail.openjdk.java.net/mailman/listinfo/nio-dev Regards, Sean. On 11/08/2015 15:11, Biju G.S Nair wrote: > Hello All, > While the patch https://bugs.openjdk.java.net/browse/JDK-6857566 > currently applied to jdk 9 (which I had requested to be back ported to JDK > 8 & 7) fixes the OOM exception during memory allocation by exponentially > increasing the sleep time, this can negatively impact low latency > applications using DirectByteBuffers. If we are able to provide a new JVM > parameter which the users can set to a percentage value of DirectBuffer use > as threshold when the "System.gc()" call in java/nio/Bits.java to be made, > then the probability of sleep time being much lower is high. Also it gives > users some control over when the gc() need to be requested instead of > starting the gc() at the last moment when the direct memory is used fully. > Without knowing all the details, to me it looks like a straight forward > change. Let me know if there is any issue with the proposed change. If this > change is a possibility let me know how I can make a request for this > change. > > Thanks, > Biju From lana.steuck at oracle.com Tue Aug 11 20:27:18 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 11 Aug 2015 13:27:18 -0700 (PDT) Subject: jdk9-b77: dev Message-ID: <201508112027.t7BKRIRj029730@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/7972dc8f2a47 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/33cecbc59f2a http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/6ec3d5cb1bfc http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7fd081100f48 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/bd6ece68cf8a http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/be357705874c http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e66c3813789d http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/8bb2441c0fec --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8132500 client-libs Add imageio test to tier 3 JDK-8129633 core-libs (fs) Investigate removing the GNOME-based FileTypeDetector from the Li JDK-8132704 core-libs [TESTBUG] jdk/internal/jimage/ExecutableTest.java incorrectly asserts JDK-8132854 core-libs Adjust tier 1 and 2 definitions for nio-related intrinsics JDK-8132795 core-libs Bug ID accidentally omitted from top level regression test in fix for JDK-8130845 core-libs Change to CLDR Locale data in JDK 9 b71 causes SimpleDateFormat parsin JDK-8132800 core-libs clarify stream package documentation regarding sequential vs parallel JDK-8131034 core-libs Cleanup in j.u.regex.Pattern.quote() JDK-8132468 core-libs docs: replace tags (obsolete in html5) for java.io, java.lang, ja JDK-8132877 core-libs docs: replace tags (obsolete in html5) for java.naming JDK-8133115 core-libs docs: replace tags (obsolete in html5) for java.util.logging, jav JDK-8133119 core-libs Error message associated with TypeError for call and new should includ JDK-8130828 core-libs Fix some typos and omissions in the the j.u.stream JavaDoc JDK-8132125 core-libs German (Switzerland) formatting broken if CLDR Locale Data is used JDK-8133022 core-libs Instant.toEpochMilli() silently overflows JDK-8132652 core-libs Java_sun_nio_ch_Net_poll passes a long to an int JDK-8080252 core-libs java.util.Formatter documentation of %n converter is misleading JDK-8130274 core-libs java/nio/file/FileStore/Basic.java fails when two successive stores in JDK-8073078 core-libs java/nio/file/FileStore/Basic.java sensitive to NFS configuration JDK-8132550 core-libs java/util/logging/LoggingDeadlock2.java times out JDK-8129881 core-libs JDK-8008577 breaks Nashorn test JDK-8022224 core-libs Rare bug in JISAutodetect charset detected by FindDecoderBugs test JDK-8132801 core-libs Remove extra '" from javax.sql.RowSet.setBlob(String,InputStream,long) JDK-8132505 core-libs Signature of Java_sun_nio_ch_Net_socket0 should return jint not int JDK-8132745 core-libs TEST_BUG: minor cleanup of java/util/Scanner/ScanTest.java JDK-8073733 core-libs TypeError messages with "call" and "new" could be improved JDK-8132494 core-libs Wrong CLDR resource bundle names for legacy ISO language codes JDK-8059038 core-svc Create new launcher for SA tools JDK-8133040 core-svc docs: replace tags (obsolete in html5) for java.management JDK-8132094 core-svc Mark intermittently failuring core-svc tests JDK-8133060 core-svc Problem list BasicLauncherTest until fix for JDK-8132648 propagates JDK-8130676 hotspot [TESTBUG] aix: Port CreateCoreDumpOnCrash added in 8078121 JDK-8130434 hotspot [TESTBUG] Harden TestLargePageUseForAuxMemory for more page size combi JDK-8131779 hotspot AARCH64: add Montgomery multiply intrinsic JDK-8131062 hotspot aarch64: add support for GHASH acceleration JDK-8131362 hotspot aarch64: C2 does not handle large stack offsets JDK-8132010 hotspot aarch64: regression test fails compiler/intrinsics/sha/cli/TestUseSHA2 JDK-8130459 hotspot Add additional validation after heap creation JDK-8131782 hotspot C1 Class.cast optimization breaks when Class is loaded from static fin JDK-8132286 hotspot change 'InlineNotify' flag option from "product" to "diagnostic" JDK-8130858 hotspot CICompilerCount=1 when tiered is off is not allowed any more JDK-8130832 hotspot Extend the WhiteBox API to provide information about the availability JDK-8131761 hotspot Fix merge error adding code that was removed in 8077936. JDK-8132148 hotspot G1 hs_err region dump legend out of sync with region values JDK-8004687 hotspot G1: Parallelize object self-forwarding and scanning during an evacuati JDK-8026324 hotspot hs_err improvement: Add summary section to hs_err file JDK-8026336 hotspot hs_err improvement: Print compilation mode, server, client or tiered JDK-8026333 hotspot hs_err improvement: Print GC Strategy JDK-8048353 hotspot jstack -l crashes VM when a Java mirror for a primitive type is locked JDK-8131319 hotspot Move G1Allocator::_summary_bytes_used back to G1CollectedHeap JDK-8130931 hotspot Refactor CardTableModRefBS[ForCTRS] JDK-8131343 hotspot Remove unused imports from hotspot/test/testlibrary/jdk/test/lib/*.jav JDK-8132232 hotspot Signature mismatch between declaration and definition of PosixSemaphor JDK-8062938 hotspot sun/jvmstat/monitor/MonitoredVm/CR6672135.java: java.lang.IllegalArgum JDK-8079082 hotspot VerifyNoCSetOopsClosure is derived twice from Closure JDK-8132855 security-libs Adjust tier 1 and 2 definitions for security-related intrinsics JDK-8132111 security-libs Do not request for addresses for forwarded TGT JDK-8046321 security-libs JEP 249: OCSP Stapling for TLS JDK-8132130 security-libs Some docs cleanup JDK-8130850 security-libs Support loading a keystore with a custom KeyStore.LoadStoreParameter c JDK-8131915 tools CompletionFailure during import listing crashes javac JDK-8130058 xml jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/Pr From staffan.friberg at oracle.com Tue Aug 11 23:34:45 2015 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 11 Aug 2015 16:34:45 -0700 Subject: JDK-8061281 (JEP-230): Push Makefiles, repository layout and small set of benchmarks Message-ID: <55CA8695.1050808@oracle.com> Hi, Unfortunately we have not yet got the new repositories created in OpenJDK for JEP-230 that was discussed earlier this year [1]. However I wanted to make sure we are ready to push as soon as those repositories are created. These two webrevs contain updates to the build scripts to add the build-microbenchmark target, and the new repository for the benchmarks. Makefile change The configure script now has a new flag that allows you to specifify a directory where JMH is available, --with-jmh=. If the build environment has been setup correctly the benchmarks can be built using "make build-microbenchmark". The directory must include the following JARs commons-math3-3.2.jar, jopt-simple-4.6.jar, jmh-core-1.10.2.jar, jmh-generator-annprocess-1.10.2.jar, which is verified by the configure script. webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_jdk/webrev Benchmarks Repository Contains the new repository and the directory structure for microbenchmarks and the specific microbenchmark Makefile. Maven POM files have been added to make it easy to work with the benchmarks in IDEs, but are not used as part of the Makefile build process. webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_benchmark/webrev [1] - http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-January/001889.html Thanks, Staffan From erik.joelsson at oracle.com Wed Aug 12 10:15:16 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Aug 2015 12:15:16 +0200 Subject: JDK-8061281 (JEP-230): Push Makefiles, repository layout and small set of benchmarks In-Reply-To: <55CA8695.1050808@oracle.com> References: <55CA8695.1050808@oracle.com> Message-ID: <55CB1CB4.2040905@oracle.com> Hello, On 2015-08-12 01:34, Staffan Friberg wrote: > Hi, > > Unfortunately we have not yet got the new repositories created in > OpenJDK for JEP-230 that was discussed earlier this year [1]. However > I wanted to make sure we are ready to push as soon as those > repositories are created. > > These two webrevs contain updates to the build scripts to add the > build-microbenchmark target, and the new repository for the benchmarks. > > > Makefile change > The configure script now has a new flag that allows you to specifify a > directory where JMH is available, --with-jmh=. If the build > environment has been setup correctly the benchmarks can be built using > "make build-microbenchmark". The directory must include the following > JARs commons-math3-3.2.jar, jopt-simple-4.6.jar, jmh-core-1.10.2.jar, > jmh-generator-annprocess-1.10.2.jar, which is verified by the > configure script. > > > webrev: > http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_jdk/webrev > Only a minor detail in Main.gmk line 288. I would like a + at the start of the line to indicate to make that the command line is running a submake. It likely works anyway, but we have this pattern in the rest of the file. > > > Benchmarks Repository > Contains the new repository and the directory structure for > microbenchmarks and the specific microbenchmark Makefile. Maven POM > files have been added to make it easy to work with the benchmarks in > IDEs, but are not used as part of the Makefile build process. > > webrev: > http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_benchmark/webrev > Only style issues which you may or may not change. These style changes improves readability and maintainability and we have rather recently improved the framework to support them. Examples: Add a space after comma. This wasn't supported before but is now. $(eval $(call SetupArchive, BUILD_OLDJDK_JAR, \ On the last named variable, finish with ", \" and put the double parentheses on a new line, indented to the same level as the start of the expression: JAR := $(OLDJDK_JAR), \ )) In addition tot hat, in the rules with touch files I would recommend using $(@D) to refer to the directory instead of repeating it several times in the recipe to reduce code duplication. I find this to be an interesting construct: 123 $(foreach jar, $(UNPACK_JARS), \ 124 $$($(UNZIP) -oq $(jar) -d $(JMH_UNPACKED))) I haven't tested, but I think this would work: 123 $(foreach jar, $(UNPACK_JARS), \ 124 $(UNZIP) -oq $(jar) -d $(JMH_UNPACKED) $(NEWLINE)) /Erik > > > [1] - > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-January/001889.html > > Thanks, > Staffan From joe.darcy at oracle.com Wed Aug 12 16:53:48 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 12 Aug 2015 09:53:48 -0700 Subject: A fix to watch: JDK-6260652: (coll) Arrays.asList(x).toArray().getClass() should be Object[].class Message-ID: <55CB7A1C.2020909@oracle.com> FYI, As of build 73, the following change has been present in JDK 9: JDK-6260652: (coll) Arrays.asList(x).toArray().getClass() should be Object[].class https://bugs.openjdk.java.net/browse/JDK-6260652 As the summary implies, the long-standing behavior of Arrays.asList(x).toArray() was changed from returning a clone of the backing array, which might be say, a String[], to returning the specified type, Object[]. As early users of JDK 9, please be aware of this change and report on experiences using it. Thanks, -Joe From staffan.friberg at oracle.com Wed Aug 12 22:24:16 2015 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Wed, 12 Aug 2015 15:24:16 -0700 Subject: JDK-8061281 (JEP-230): Push Makefiles, repository layout and small set of benchmarks In-Reply-To: <55CB1CB4.2040905@oracle.com> References: <55CA8695.1050808@oracle.com> <55CB1CB4.2040905@oracle.com> Message-ID: <55CBC790.7050308@oracle.com> Hi Erik, Thank you for the quick review. I have fixed all your comments in this new webrev, http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.02 Cheers, Staffan On 08/12/2015 03:15 AM, Erik Joelsson wrote: > Hello, > > On 2015-08-12 01:34, Staffan Friberg wrote: >> Hi, >> >> Unfortunately we have not yet got the new repositories created in >> OpenJDK for JEP-230 that was discussed earlier this year [1]. However >> I wanted to make sure we are ready to push as soon as those >> repositories are created. >> >> These two webrevs contain updates to the build scripts to add the >> build-microbenchmark target, and the new repository for the benchmarks. >> >> >> Makefile change >> The configure script now has a new flag that allows you to specifify >> a directory where JMH is available, --with-jmh=. If the build >> environment has been setup correctly the benchmarks can be built >> using "make build-microbenchmark". The directory must include the >> following JARs commons-math3-3.2.jar, jopt-simple-4.6.jar, >> jmh-core-1.10.2.jar, jmh-generator-annprocess-1.10.2.jar, which is >> verified by the configure script. >> >> >> webrev: >> http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_jdk/webrev >> > Only a minor detail in Main.gmk line 288. I would like a + at the > start of the line to indicate to make that the command line is running > a submake. It likely works anyway, but we have this pattern in the > rest of the file. >> >> >> Benchmarks Repository >> Contains the new repository and the directory structure for >> microbenchmarks and the specific microbenchmark Makefile. Maven POM >> files have been added to make it easy to work with the benchmarks in >> IDEs, but are not used as part of the Makefile build process. >> >> webrev: >> http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_benchmark/webrev >> > Only style issues which you may or may not change. These style changes > improves readability and maintainability and we have rather recently > improved the framework to support them. Examples: > > Add a space after comma. This wasn't supported before but is now. > $(eval $(call SetupArchive, BUILD_OLDJDK_JAR, \ > > On the last named variable, finish with ", \" and put the double > parentheses on a new line, indented to the same level as the start of > the expression: > JAR := $(OLDJDK_JAR), \ > )) > > In addition tot hat, in the rules with touch files I would recommend > using $(@D) to refer to the directory instead of repeating it several > times in the recipe to reduce code duplication. > > I find this to be an interesting construct: > 123 $(foreach jar, $(UNPACK_JARS), \ > 124 $$($(UNZIP) -oq $(jar) -d $(JMH_UNPACKED))) > > I haven't tested, but I think this would work: > 123 $(foreach jar, $(UNPACK_JARS), \ > 124 $(UNZIP) -oq $(jar) -d $(JMH_UNPACKED) $(NEWLINE)) > > /Erik >> >> >> [1] - >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-January/001889.html >> >> Thanks, >> Staffan > From stefan.karlsson at oracle.com Mon Aug 17 09:11:25 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 17 Aug 2015 11:11:25 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm Message-ID: <55D1A53D.90704@oracle.com> |I hereby nominate David Lindholm to JDK 9 Committer. He's a member of the HotSpot GC Team and has contributed 17 patches [3] Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. StefanK [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] List of patches: 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor 7169803: Usage of pretenured value is not correct 8025608: GC trace events missing nursery size information 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint 8080947: Add uint as a valid VM flag type 8076542: G1 does not print heap page size information with -XX:+TracePageSizes 8079337: Format string issues in workgroup.cpp and taskqueue.cpp 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary allocation failure handling 8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files 8073463: G1 does not mangle freed heap regions 8073545: Use shorter and more descriptive names for GC worker threads 8073464: GC workers do not have thread names | From stefan.karlsson at oracle.com Mon Aug 17 09:14:41 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 17 Aug 2015 11:14:41 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1A601.1040103@oracle.com> Vote: yes StefanK On 2015-08-17 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From bengt.rutisson at oracle.com Mon Aug 17 09:08:27 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 17 Aug 2015 11:08:27 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1A48B.8010600@oracle.com> Vote: yes Bengt On 2015-08-17 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From david.buck at oracle.com Mon Aug 17 09:16:18 2015 From: david.buck at oracle.com (david buck) Date: Mon, 17 Aug 2015 18:16:18 +0900 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1A662.1020707@oracle.com> Vote: yes -Buck On 2015/08/17 18:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary > allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to > be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From jaroslav.bachorik at oracle.com Mon Aug 17 09:18:16 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 17 Aug 2015 11:18:16 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1A6D8.7000204@oracle.com> Vote: yes -JB- On 17.8.2015 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary > allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to > be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From claes.redestad at oracle.com Mon Aug 17 09:16:42 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Aug 2015 11:16:42 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1A67A.7070909@oracle.com> Vote: yes /Claes On 2015-08-17 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From staffan.larsen at oracle.com Mon Aug 17 09:28:38 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 17 Aug 2015 11:28:38 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: Vote: yes. > On 17 aug 2015, at 11:11, Stefan Karlsson wrote: > > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From erik.gahlin at oracle.com Mon Aug 17 09:50:18 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 17 Aug 2015 11:50:18 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1AE5A.6000203@oracle.com> Vote: yes Erik Den 17/08/15 kl. 11:11, skrev Stefan Karlsson: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From jesper.wilhelmsson at oracle.com Mon Aug 17 11:48:54 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 17 Aug 2015 13:48:54 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1CA26.10000@oracle.com> Vote: Yes /Jesper Stefan Karlsson skrev den 17/8/15 11:11: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary > allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() have > different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from > source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from > source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from > source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source > files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From stefan.johansson at oracle.com Mon Aug 17 11:54:15 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 17 Aug 2015 13:54:15 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1CB67.4090403@oracle.com> Vote: yes Stefan On 2015-08-17 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From thomas.schatzl at oracle.com Mon Aug 17 12:01:59 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 17 Aug 2015 14:01:59 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <1439812919.2351.11.camel@oracle.com> Vote: yes On Mon, 2015-08-17 at 11:11 +0200, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From per.liden at oracle.com Mon Aug 17 12:02:31 2015 From: per.liden at oracle.com (Per Liden) Date: Mon, 17 Aug 2015 14:02:31 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1CD57.6020704@oracle.com> Vote: Yes /Per On 2015-08-17 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary > allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to > be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From magnus.ihse.bursie at oracle.com Mon Aug 17 12:07:14 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Aug 2015 14:07:14 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1CE72.8090201@oracle.com> Vote: yes /Magnus On 2015-08-17 11:11, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From alejandro.murillo at oracle.com Mon Aug 17 15:17:17 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 17 Aug 2015 09:17:17 -0600 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D1FAFD.1030508@oracle.com> vote: yes On 8/17/2015 3:11 AM, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. -- Alejandro From erik.helin at oracle.com Mon Aug 17 16:17:15 2015 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 17 Aug 2015 18:17:15 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <20150817161715.GH31725@ehelin.jrpg.bea.com> Vote: yes Erik On 2015-08-17, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From jon.masamitsu at oracle.com Mon Aug 17 17:27:36 2015 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 17 Aug 2015 10:27:36 -0700 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D21988.70903@oracle.com> Vote: yes On 08/17/2015 02:11 AM, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From coleen.phillimore at oracle.com Mon Aug 17 19:08:20 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 17 Aug 2015 15:08:20 -0400 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D23124.1050909@oracle.com> Vote: yes On 8/17/15 5:11 AM, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From alejandro.murillo at oracle.com Mon Aug 17 22:05:44 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 17 Aug 2015 16:05:44 -0600 Subject: jdk9-dev: HotSpot Message-ID: <55D25AB8.2050903@oracle.com> jdk9-hs-2015-08-13 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/0a877885e849 http://hg.openjdk.java.net/jdk9/dev/corba/rev/182bb7accc52 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6f56da5908e6 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/5b1899c9822d http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/ac1748bab074 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/34a56352697a http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7fd155b7041c http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/23f843804b05 Component : VM Status : Go for integration Date : 08/17/2015 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-08-13-225416.amurillo.jdk9-hs-2015-08-13-snapshot Testing: 574 new failures, 2895 known failures, 462460 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8011858: Use Compile::live_nodes() instead of Compile::unique() in appropriate places 8033577: [parfait] warnings from b128 for hotspot/src/os/solaris/dtrace: Unportable format string argument mismatch 8060245: update bsd version of jhelper.d to be in sync with the fix of 8009204 on solaris 8073052: Rename and clean up the allocation manager hierarchy in g1Allocator.?pp 8075773: jps running as root fails after the fix of JDK-8050807 8076470: Remove the JVM TI hprof Agent 8078904: CMS: Assert failed: Ctl pt invariant 8080401: Uninitialised variable in hotspot/src/os/solaris/dtrace/ 8085919: OperatingSystemMXBean/TestTotalSwap.java failure : Total Swap Space figures mismatch 8087342: Crash in klassItable::initialize_itable_for_interface 8130212: Thread::current() might access freed memory on Solaris 8131682: C1 should use multibyte nops everywhere 8132214: [TESTBUG] Create basic shared strings test for CDS archive 8132306: java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Error: poll() returned null; expected ref object" 8132648: sun/tools/jhsdb/BasicLauncherTest fails with java.lang.RuntimeException 8132892: Memory must be freed after calling Arguments::set_sysclasspath function 8132969: C++11 requires a space between literal and identifier 8133042: Remove some direct accesses of G1Allocator to G1CollectedHeap members 8133043: Clean up code related to termination stats printing 8133047: Rename G1ParScanThreadState::_queue_num to _worker_id 8133222: [TESTBUG] Quarantine runtime/SharedArchiveFile/SharedStrings.java until the fix -- Alejandro From vladimir.x.ivanov at oracle.com Tue Aug 18 00:23:34 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 17 Aug 2015 17:23:34 -0700 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D27B06.7080401@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/17/15 2:11 AM, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary > allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to > be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From erik.joelsson at oracle.com Tue Aug 18 08:21:29 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Aug 2015 10:21:29 +0200 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D2EB09.7010107@oracle.com> Vote: yes From christoph.langer at sap.com Tue Aug 18 09:52:16 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Aug 2015 09:52:16 +0000 Subject: Fix for small leak in TimeZone_md.c Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> Hi all, I think there is a small memory leak in TimeZone_md.c in the case of solaris "localtime". When getPlatformTimeZoneID() is called and its result is "localtime", the returned string buffer is not freed as the pointer "freetz" is overwritten after the call to getSolarisDefaultZoneID(). Please have a look at my webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential fix. A bug was not yet created but should be done after you agree that this is an issue. Thanks in advance for comments. Best regards Christoph From magnus.ihse.bursie at oracle.com Tue Aug 18 10:16:00 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Aug 2015 12:16:00 +0200 Subject: JDK-8061281 (JEP-230): Push Makefiles, repository layout and small set of benchmarks In-Reply-To: <55CBC790.7050308@oracle.com> References: <55CA8695.1050808@oracle.com> <55CB1CB4.2040905@oracle.com> <55CBC790.7050308@oracle.com> Message-ID: <55D305E0.9040104@oracle.com> On 2015-08-13 00:24, Staffan Friberg wrote: > Hi Erik, > > Thank you for the quick review. I have fixed all your comments in this > new webrev, http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.02 Looks good to me! /Magnus > > Cheers, > Staffan > > On 08/12/2015 03:15 AM, Erik Joelsson wrote: >> Hello, >> >> On 2015-08-12 01:34, Staffan Friberg wrote: >>> Hi, >>> >>> Unfortunately we have not yet got the new repositories created in >>> OpenJDK for JEP-230 that was discussed earlier this year [1]. >>> However I wanted to make sure we are ready to push as soon as those >>> repositories are created. >>> >>> These two webrevs contain updates to the build scripts to add the >>> build-microbenchmark target, and the new repository for the benchmarks. >>> >>> >>> Makefile change >>> The configure script now has a new flag that allows you to specifify >>> a directory where JMH is available, --with-jmh=. If the build >>> environment has been setup correctly the benchmarks can be built >>> using "make build-microbenchmark". The directory must include the >>> following JARs commons-math3-3.2.jar, jopt-simple-4.6.jar, >>> jmh-core-1.10.2.jar, jmh-generator-annprocess-1.10.2.jar, which is >>> verified by the configure script. >>> >>> >>> webrev: >>> http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_jdk/webrev >>> >> Only a minor detail in Main.gmk line 288. I would like a + at the >> start of the line to indicate to make that the command line is >> running a submake. It likely works anyway, but we have this pattern >> in the rest of the file. >>> >>> >>> Benchmarks Repository >>> Contains the new repository and the directory structure for >>> microbenchmarks and the specific microbenchmark Makefile. Maven POM >>> files have been added to make it easy to work with the benchmarks in >>> IDEs, but are not used as part of the Makefile build process. >>> >>> webrev: >>> http://cr.openjdk.java.net/~sfriberg/JDK-8061281/webrev.01/webrev_benchmark/webrev >>> >> Only style issues which you may or may not change. These style >> changes improves readability and maintainability and we have rather >> recently improved the framework to support them. Examples: >> >> Add a space after comma. This wasn't supported before but is now. >> $(eval $(call SetupArchive, BUILD_OLDJDK_JAR, \ >> >> On the last named variable, finish with ", \" and put the double >> parentheses on a new line, indented to the same level as the start of >> the expression: >> JAR := $(OLDJDK_JAR), \ >> )) >> >> In addition tot hat, in the rules with touch files I would recommend >> using $(@D) to refer to the directory instead of repeating it several >> times in the recipe to reduce code duplication. >> >> I find this to be an interesting construct: >> 123 $(foreach jar, $(UNPACK_JARS), \ >> 124 $$($(UNZIP) -oq $(jar) -d $(JMH_UNPACKED))) >> >> I haven't tested, but I think this would work: >> 123 $(foreach jar, $(UNPACK_JARS), \ >> 124 $(UNZIP) -oq $(jar) -d $(JMH_UNPACKED) $(NEWLINE)) >> >> /Erik >>> >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-January/001889.html >>> >>> >>> Thanks, >>> Staffan >> > From christoph.langer at sap.com Tue Aug 18 13:45:50 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Aug 2015 13:45:50 +0000 Subject: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EEF6E4@DEWDFEMB12B.global.corp.sap> Hi, we've created a bug report for this issue now: https://bugs.openjdk.java.net/browse/JDK-8133830 I also updated the webrev, as I would like to take the chance to do some minor refactoring of the AIX porting code for better readability: http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ Please review this change. I also need a sponsor. Thanks Christoph -----Original Message----- From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph Sent: Dienstag, 18. August 2015 11:52 To: jdk9-dev at openjdk.java.net Subject: Fix for small leak in TimeZone_md.c Hi all, I think there is a small memory leak in TimeZone_md.c in the case of solaris "localtime". When getPlatformTimeZoneID() is called and its result is "localtime", the returned string buffer is not freed as the pointer "freetz" is overwritten after the call to getSolarisDefaultZoneID(). Please have a look at my webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential fix. A bug was not yet created but should be done after you agree that this is an issue. Thanks in advance for comments. Best regards Christoph From yumin.qi at oracle.com Tue Aug 18 16:03:16 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 18 Aug 2015 09:03:16 -0700 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D35744.3090205@oracle.com> Vote: Yes On 8/17/2015 2:11 AM, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have > desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with > -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of > unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() > have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be > removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs > to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed > from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From vladimir.kozlov at oracle.com Tue Aug 18 16:08:22 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Aug 2015 09:08:22 -0700 Subject: CFV: New JDK 9 Committer: David Lindholm In-Reply-To: <55D1A53D.90704@oracle.com> References: <55D1A53D.90704@oracle.com> Message-ID: <55D35876.9010502@oracle.com> Vote: yes On 8/17/15 2:11 AM, Stefan Karlsson wrote: > |I hereby nominate David Lindholm to JDK 9 Committer. > > He's a member of the HotSpot GC Team and has contributed 17 patches [3] > > Votes are due by|| 11:15 AM CEST, Monday August 31, 2015. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > StefanK > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of patches: > 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor > 7169803: Usage of pretenured value is not correct > 8025608: GC trace events missing nursery size information > 8081382: Make flags ParallelGCThreads and ConcGCThreads of type uint > 8080947: Add uint as a valid VM flag type > 8076542: G1 does not print heap page size information with -XX:+TracePageSizes > 8079337: Format string issues in workgroup.cpp and taskqueue.cpp > 8016276: CMS concurrentMarkSweepGeneration contains lots of unnecessary allocation failure handling > 8076173: VirtualSpaceNode container_count() and container_count_slow() have different return types > 8076073: shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076072: parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076071: parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076055: cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8076054: g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files > 8073463: G1 does not mangle freed heap regions > 8073545: Use shorter and more descriptive names for GC worker threads > 8073464: GC workers do not have thread names > > | > From thomas.stuefe at gmail.com Wed Aug 19 11:12:16 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 19 Aug 2015 13:12:16 +0200 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> Message-ID: Hi Christoph, looks fine. I opened a bug for you: https://bugs.openjdk.java.net/browse/JDK-8133933 But this needs another reviewer and a sponsor. Kind Regards, Thomas On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph < christoph.langer at sap.com> wrote: > Hi all, > > I think there is a small memory leak in TimeZone_md.c in the case of > solaris "localtime". > > When getPlatformTimeZoneID() is called and its result is "localtime", the > returned string buffer is not freed as the pointer "freetz" is overwritten > after the call to getSolarisDefaultZoneID(). > > Please have a look at my webrev: > http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential > fix. > > A bug was not yet created but should be done after you agree that this is > an issue. > > Thanks in advance for comments. > > Best regards > Christoph > > From christoph.langer at sap.com Wed Aug 19 13:14:33 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Aug 2015 13:14:33 +0000 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> Hi Thomas, thanks for your review. Axel already helped me to create a bug report: https://bugs.openjdk.java.net/browse/JDK-8133830 I had also updated my webrev, as I would like to take the chance to do some minor refactoring of the AIX porting code for better readability: http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ Can you review the updated change as well? Thanks Christoph From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Mittwoch, 19. August 2015 13:12 To: Langer, Christoph Cc: jdk9-dev at openjdk.java.net Subject: Re: Fix for small leak in TimeZone_md.c Hi Christoph, looks fine. I opened a bug for you: https://bugs.openjdk.java.net/browse/JDK-8133933 But this needs another reviewer and a sponsor. Kind Regards, Thomas On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > wrote: Hi all, I think there is a small memory leak in TimeZone_md.c in the case of solaris "localtime". When getPlatformTimeZoneID() is called and its result is "localtime", the returned string buffer is not freed as the pointer "freetz" is overwritten after the call to getSolarisDefaultZoneID(). Please have a look at my webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential fix. A bug was not yet created but should be done after you agree that this is an issue. Thanks in advance for comments. Best regards Christoph From gnu.andrew at redhat.com Wed Aug 19 15:17:05 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Aug 2015 11:17:05 -0400 (EDT) Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> Message-ID: <868300158.12416221.1439997425266.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Thomas, > > thanks for your review. > > Axel already helped me to create a bug report: > https://bugs.openjdk.java.net/browse/JDK-8133830 > > I had also updated my webrev, as I would like to take the chance to do some > minor refactoring of the AIX porting code for better readability: > http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > > Can you review the updated change as well? > > Thanks > Christoph > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Mittwoch, 19. August 2015 13:12 > To: Langer, Christoph > Cc: jdk9-dev at openjdk.java.net > Subject: Re: Fix for small leak in TimeZone_md.c > > Hi Christoph, > > looks fine. I opened a bug for you: > https://bugs.openjdk.java.net/browse/JDK-8133933 > > But this needs another reviewer and a sponsor. > > Kind Regards, Thomas > > > > On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > > wrote: > Hi all, > > I think there is a small memory leak in TimeZone_md.c in the case of solaris > "localtime". > > When getPlatformTimeZoneID() is called and its result is "localtime", the > returned string buffer is not freed as the pointer "freetz" is overwritten > after the call to getSolarisDefaultZoneID(). > > Please have a look at my webrev: > http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential > fix. > > A bug was not yet created but should be done after you agree that this is an > issue. > > Thanks in advance for comments. > > Best regards > Christoph > > The revised change looks good to me. Feel free to add me as a second reviewer if you still need one. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dmitry.samersoff at oracle.com Wed Aug 19 16:53:59 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 19 Aug 2015 19:53:59 +0300 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> Message-ID: <55D4B4A7.1020807@oracle.com> Lander, My few cents ... 1. After you refactoring freetz is never actually used. It might be better to just get rid of this variable. 2. Also you can remove javatz as well and further refactor the code to return (tz == NULL) ? NULL : strdup(tz); -Dmitry On 2015-08-19 16:14, Langer, Christoph wrote: > Hi Thomas, > > thanks for your review. > > Axel already helped me to create a bug report: https://bugs.openjdk.java.net/browse/JDK-8133830 > > I had also updated my webrev, as I would like to take the chance to do some minor refactoring of the AIX porting code for better readability: http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > > Can you review the updated change as well? > > Thanks > Christoph > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Mittwoch, 19. August 2015 13:12 > To: Langer, Christoph > Cc: jdk9-dev at openjdk.java.net > Subject: Re: Fix for small leak in TimeZone_md.c > > Hi Christoph, > > looks fine. I opened a bug for you: https://bugs.openjdk.java.net/browse/JDK-8133933 > > But this needs another reviewer and a sponsor. > > Kind Regards, Thomas > > > > On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > wrote: > Hi all, > > I think there is a small memory leak in TimeZone_md.c in the case of solaris "localtime". > > When getPlatformTimeZoneID() is called and its result is "localtime", the returned string buffer is not freed as the pointer "freetz" is overwritten after the call to getSolarisDefaultZoneID(). > > Please have a look at my webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential fix. > > A bug was not yet created but should be done after you agree that this is an issue. > > Thanks in advance for comments. > > Best regards > Christoph > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From thomas.stuefe at gmail.com Wed Aug 19 17:39:57 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 19 Aug 2015 19:39:57 +0200 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> Message-ID: Hi Christoph, ok, I closed my bug report as a duplicate of the one Axel opened. Also, I marked Axels bug report as Solaris only. As for the second webrev: I don't really like that we now mix in AIX-only code cleanup into a fix for a solaris-only bug. I think this should go into a separate issue. Apart from that: Sorry, I am not a big fan of the changes: they introduce a new unnecessary copy operation (before, we returned the return value of mapPlatformToJavaTimezone() directly, now we strdup it once more before returning) and introduces a new exit point (line 711) where before was only one exit point at the end of the function. I admit the code before was not nice nor readable but the new code is not much clearer. Just my opinion though, lets hear some others. Regards, Thomas On Wed, Aug 19, 2015 at 3:14 PM, Langer, Christoph wrote: > Hi Thomas, > > > > thanks for your review. > > > > Axel already helped me to create a bug report: > https://bugs.openjdk.java.net/browse/JDK-8133830 > > > > I had also updated my webrev, as I would like to take the chance to do > some minor refactoring of the AIX porting code for better readability: > http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > > > > Can you review the updated change as well? > > > > Thanks > > Christoph > > > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Mittwoch, 19. August 2015 13:12 > *To:* Langer, Christoph > *Cc:* jdk9-dev at openjdk.java.net > *Subject:* Re: Fix for small leak in TimeZone_md.c > > > > Hi Christoph, > > > > looks fine. I opened a bug for you: > https://bugs.openjdk.java.net/browse/JDK-8133933 > > > > But this needs another reviewer and a sponsor. > > > > Kind Regards, Thomas > > > > > > > > On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph < > christoph.langer at sap.com> wrote: > > Hi all, > > I think there is a small memory leak in TimeZone_md.c in the case of > solaris "localtime". > > When getPlatformTimeZoneID() is called and its result is "localtime", the > returned string buffer is not freed as the pointer "freetz" is overwritten > after the call to getSolarisDefaultZoneID(). > > Please have a look at my webrev: > http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential > fix. > > A bug was not yet created but should be done after you agree that this is > an issue. > > Thanks in advance for comments. > > Best regards > Christoph > > > From gnu.andrew at redhat.com Wed Aug 19 20:51:42 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Aug 2015 16:51:42 -0400 (EDT) Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <55D4B4A7.1020807@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> <55D4B4A7.1020807@oracle.com> Message-ID: <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Lander, > > My few cents ... > > 1. After you refactoring freetz is never actually used. It might be > better to just get rid of this variable. > At present, it's still being used to hold the old version of tz: tz = getPlatformTimeZoneID(); freetz = tz; So both tz and freetz point to the return value of getPlatformTimeZoneID. tz may then be moved forward due to: if (tz != NULL && *tz == ':') { tz++; } and then it is replaced altogether: if (tz != NULL && strcmp(tz, "localtime") == 0) { tz = getSolarisDefaultZoneID(); Now tz contains the return value of getSolarisDefaultZoneID, so only freetz references the old return value from getPlatformTimeZoneID. This code then frees it: if (freetz != NULL) { free((void *) freetz); } freetz = tz; and tz and freetz match again. You could get rid of freetz if tz was freed before being overwritten in this case, but the same isn't true in the AIX case where tz is passed to mapPlatformToJavaTimezone. So it would need further refactoring rather than simply being dropped. > 2. Also you can remove javatz as well and further refactor the code to > > return (tz == NULL) ? NULL : strdup(tz); > At present, tz, as referenced by freetz, is freed after the strdup. I do wonder why it needs to be copied at all when tz itself is the result of a strdup from the call to getPlatformTimeZoneID, getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > -Dmitry > > On 2015-08-19 16:14, Langer, Christoph wrote: > > Hi Thomas, > > > > thanks for your review. > > > > Axel already helped me to create a bug report: > > https://bugs.openjdk.java.net/browse/JDK-8133830 > > > > I had also updated my webrev, as I would like to take the chance to do some > > minor refactoring of the AIX porting code for better readability: > > http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > > > > Can you review the updated change as well? > > > > Thanks > > Christoph > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > > Sent: Mittwoch, 19. August 2015 13:12 > > To: Langer, Christoph > > Cc: jdk9-dev at openjdk.java.net > > Subject: Re: Fix for small leak in TimeZone_md.c > > > > Hi Christoph, > > > > looks fine. I opened a bug for you: > > https://bugs.openjdk.java.net/browse/JDK-8133933 > > > > But this needs another reviewer and a sponsor. > > > > Kind Regards, Thomas > > > > > > > > On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > > > wrote: > > Hi all, > > > > I think there is a small memory leak in TimeZone_md.c in the case of > > solaris "localtime". > > > > When getPlatformTimeZoneID() is called and its result is "localtime", the > > returned string buffer is not freed as the pointer "freetz" is overwritten > > after the call to getSolarisDefaultZoneID(). > > > > Please have a look at my webrev: > > http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential > > fix. > > > > A bug was not yet created but should be done after you agree that this is > > an issue. > > > > Thanks in advance for comments. > > > > Best regards > > Christoph > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dmitry.samersoff at oracle.com Wed Aug 19 21:16:44 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 20 Aug 2015 00:16:44 +0300 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> <55D4B4A7.1020807@oracle.com> <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> Message-ID: <55D4F23C.4000300@oracle.com> Andrew, > So it would need further refactoring rather than simply being dropped. Agree. > I do wonder why it needs to be copied at all when tz itself is the > result of a strdup from the call to getPlatformTimeZoneID, > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. If getenv("TZ") returns some value the code just return this value (except AIX and "localtime" under Solaris) and it has to be strdup'ed before return. It might be better to create separate function for each platform despite some code duplication. It makes the code better readable. -Dmitry On 2015-08-19 23:51, Andrew Hughes wrote: > > ----- Original Message ----- >> Lander, >> >> My few cents ... >> >> 1. After you refactoring freetz is never actually used. It might be >> better to just get rid of this variable. >> > At present, it's still being used to hold the old version of tz: > > tz = getPlatformTimeZoneID(); > freetz = tz; > > So both tz and freetz point to the return value of getPlatformTimeZoneID. > tz may then be moved forward due to: > > if (tz != NULL && *tz == ':') { > tz++; > } > > and then it is replaced altogether: > > if (tz != NULL && strcmp(tz, "localtime") == 0) { > tz = getSolarisDefaultZoneID(); > > Now tz contains the return value of getSolarisDefaultZoneID, so only > freetz references the old return value from getPlatformTimeZoneID. > This code then frees it: > > if (freetz != NULL) { > free((void *) freetz); > } > freetz = tz; > > and tz and freetz match again. > > You could get rid of freetz if tz was freed before being overwritten > in this case, but the same isn't true in the AIX case where tz is > passed to mapPlatformToJavaTimezone. > > So it would need further refactoring rather than simply being dropped. > >> 2. Also you can remove javatz as well and further refactor the code to >> >> return (tz == NULL) ? NULL : strdup(tz); >> > At present, tz, as referenced by freetz, is freed after the strdup. > I do wonder why it needs to be copied at all when tz itself is the > result of a strdup from the call to getPlatformTimeZoneID, > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > >> -Dmitry >> >> On 2015-08-19 16:14, Langer, Christoph wrote: >>> Hi Thomas, >>> >>> thanks for your review. >>> >>> Axel already helped me to create a bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8133830 >>> >>> I had also updated my webrev, as I would like to take the chance to do some >>> minor refactoring of the AIX porting code for better readability: >>> http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ >>> >>> Can you review the updated change as well? >>> >>> Thanks >>> Christoph >>> >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>> Sent: Mittwoch, 19. August 2015 13:12 >>> To: Langer, Christoph >>> Cc: jdk9-dev at openjdk.java.net >>> Subject: Re: Fix for small leak in TimeZone_md.c >>> >>> Hi Christoph, >>> >>> looks fine. I opened a bug for you: >>> https://bugs.openjdk.java.net/browse/JDK-8133933 >>> >>> But this needs another reviewer and a sponsor. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph >>> > wrote: >>> Hi all, >>> >>> I think there is a small memory leak in TimeZone_md.c in the case of >>> solaris "localtime". >>> >>> When getPlatformTimeZoneID() is called and its result is "localtime", the >>> returned string buffer is not freed as the pointer "freetz" is overwritten >>> after the call to getSolarisDefaultZoneID(). >>> >>> Please have a look at my webrev: >>> http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential >>> fix. >>> >>> A bug was not yet created but should be done after you agree that this is >>> an issue. >>> >>> Thanks in advance for comments. >>> >>> Best regards >>> Christoph >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >> >> -- 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 lana.steuck at oracle.com Wed Aug 19 22:24:53 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 19 Aug 2015 15:24:53 -0700 (PDT) Subject: jdk9-b78: dev Message-ID: <201508192224.t7JMOrSF003688@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/8c40d4143ee1 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/6f634e84387e http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/7fd155b7041c http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0940ce86c614 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/ac1748bab074 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/5b1899c9822d http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/20dc06b04fe5 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/182bb7accc52 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8132382 client-libs [macosx] Crash during JMC or JavaFX execution when NSApplication is co JDK-8132136 client-libs [PIT] RTL orientation in JEditorPane is broken JDK-8131752 client-libs [Regression] Test java/awt/GraphicsDevice/CheckDisplayModes.java fails JDK-8131055 client-libs [TEST] bean annotations: add a test checking if a separate user-define JDK-8013586 client-libs audioInputStream.close() does not release the resource JDK-8025815 client-libs Child FileDialog of modal dialog does not get focus on Gnome JDK-8132249 client-libs Clean up JAB debugging code JDK-8067093 client-libs Fix windows-specific deprecation warnings in the java.desktop module JDK-8132355 client-libs Incorrect guard block in HPkeysym.h, awt_Event.h JDK-6544871 client-libs java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html fails from jdk b09 on JDK-8130735 client-libs javax.swing.TimerQueue: timer fires late when another timer starts JDK-6206439 client-libs JInternalFrame.setLayer(Integer layer) should throw NullPointerExcepti JDK-8132123 client-libs MultiResolutionCachedImage unnecessarily creates base image to get its JDK-8130478 client-libs Reconsider "awt.toolkit" property usage in java.awt.Toolkit getDefault JDK-8130776 client-libs Remove EmbeddedFrame.requestFocusToEmbedder() method JDK-8074831 client-libs Resolve disabled warnings for libjsound JDK-8074832 client-libs Resolve disabled warnings for libjsoundalsa JDK-8130937 client-libs Several methods in BeanProperty return null instead of boolean value JDK-8130400 client-libs Test java/awt/image/DrawImage/IncorrectClipXorModeSurface2Surface.java JDK-8130892 client-libs Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails JDK-8066404 client-libs The case is failed automatically and thrown the "java.lang.IllegalSta JDK-8130769 client-libs The new menu can't be shown on the menubar after clicking the "Add" bu JDK-8080115 core-libs (fs) Crash in libgio when calling Files.probeContentType(path) from pa JDK-8132539 core-libs (fs) Files.lines(path).collect() returns wrong value in JDK 9 with cer JDK-8132497 core-libs (fs) FileSystems.newFileSystem(URI, ..) doesn't handle UOE thrown by p JDK-8133287 core-libs (fs) java/nio/file/Files/probeContentType/ParallelProbes.java should u JDK-8133232 core-libs [fs] Regex has redundant | in the char class JDK-8133347 core-libs Add makefiles support and basic session, persistence history navigatio JDK-8133188 core-libs docs: replace tags (obsolete in html5) for java.util JDK-8133105 core-libs Fix getFinalAttributes() on Windows to handle more special cases JDK-8133231 core-libs Mark TimeoutLockLoops.java as failing intermittently JDK-8133207 core-libs ParallelProbes.java test fails after changes for JDK-8080115 JDK-8133588 core-libs Place TimeoutLockLoops.java on the problem list JDK-8133459 core-libs replace tags (obsolete in html5) in java.nio docs JDK-8079769 core-libs tools/pack200/PackTestZip64.java may timeout at preparing the large te JDK-8065595 core-libs Wrong JNI_OnLoad called if just loaded lib does not have JNI_OnLoad fu JDK-8129215 core-svc com.sun.jmx.mbeanserver.Introspector may provide results inconsistent JDK-8130339 core-svc java/lang/management/MemoryMXBean/LowMemoryTest.java timed out JDK-8077380 deploy JNLPSigning exception when signed jnlp is launched from local tomcat s JDK-8132875 hotspot AArch64: Fix error introduced into AArch64 CodeCache by commit for 813 JDK-8080298 hotspot Clean up os::...::supports_variable_stack_size() JDK-8132953 hotspot imageDecompressor.hpp should not include precompiled.hpp JDK-8004073 hotspot Implement C2 Ideal node specific dump() method JDK-8059036 hotspot Implement Diagnostic Commands for heap and finalizerinfo JDK-8132876 hotspot Increase PerfDataMemorySize to 64K JDK-8132525 hotspot java -client -XX:+TieredCompilation -XX:CICompilerCount=1 -version ass JDK-8132242 hotspot LogTouchedMethods (8025692) asserts if TieredCompilation is off. JDK-8130309 hotspot Need to bailout cleanly if creation of stubs fails when codecache is o JDK-8129976 hotspot RunFinalizationTest.java times out frequently JDK-6661889 hotspot thread id on Linux is inconsistent in error and log outputs JDK-8132457 hotspot Unify command-line flags controlling the usage of compiler intrinsics JDK-8129562 infrastructure JDK 9 build using boot-jdk classes instead of newly compiled classes JDK-8077055 security-libs Allow other named SecurityPermissions, RuntimePermissions, and AuthPer JDK-8133318 security-libs Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and ea JDK-8132551 security-libs Initialize local variables before returning them in p11_convert.c JDK-8048624 security-libs Tests for SealedObject JDK-8133223 tools Clean up package handling code in JavadocTool JDK-8053906 tools javac is accepting a self-referencing variable initializer inside a la From christoph.langer at sap.com Thu Aug 20 08:22:18 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Aug 2015 08:22:18 +0000 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <55D4F23C.4000300@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> <55D4B4A7.1020807@oracle.com> <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> <55D4F23C.4000300@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF1084@DEWDFEMB12B.global.corp.sap> Hi Thomas, Andrew and Dmitry, thanks for your comments - they are very valuable and lead me to the following: 1. The initial change which just fixes the sport where the Solaris leak could occur should be commited as fix to bugreport https://bugs.openjdk.java.net/browse/JDK-8133830 I'll do a separate posting for review 2. I will attempt to do a better refactoring of the "findJavaTZ_md" code for better readability and to avoid unnecessary string copy operations. Will post a new webrev later. Thanks & Best regards Christoph -----Original Message----- From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] Sent: Mittwoch, 19. August 2015 23:17 To: Andrew Hughes Cc: Langer, Christoph; Thomas St?fe; jdk9-dev at openjdk.java.net Subject: Re: Fix for small leak in TimeZone_md.c Andrew, > So it would need further refactoring rather than simply being dropped. Agree. > I do wonder why it needs to be copied at all when tz itself is the > result of a strdup from the call to getPlatformTimeZoneID, > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. If getenv("TZ") returns some value the code just return this value (except AIX and "localtime" under Solaris) and it has to be strdup'ed before return. It might be better to create separate function for each platform despite some code duplication. It makes the code better readable. -Dmitry On 2015-08-19 23:51, Andrew Hughes wrote: > > ----- Original Message ----- >> Lander, >> >> My few cents ... >> >> 1. After you refactoring freetz is never actually used. It might be >> better to just get rid of this variable. >> > At present, it's still being used to hold the old version of tz: > > tz = getPlatformTimeZoneID(); > freetz = tz; > > So both tz and freetz point to the return value of getPlatformTimeZoneID. > tz may then be moved forward due to: > > if (tz != NULL && *tz == ':') { > tz++; > } > > and then it is replaced altogether: > > if (tz != NULL && strcmp(tz, "localtime") == 0) { > tz = getSolarisDefaultZoneID(); > > Now tz contains the return value of getSolarisDefaultZoneID, so only > freetz references the old return value from getPlatformTimeZoneID. > This code then frees it: > > if (freetz != NULL) { > free((void *) freetz); > } > freetz = tz; > > and tz and freetz match again. > > You could get rid of freetz if tz was freed before being overwritten > in this case, but the same isn't true in the AIX case where tz is > passed to mapPlatformToJavaTimezone. > > So it would need further refactoring rather than simply being dropped. > >> 2. Also you can remove javatz as well and further refactor the code to >> >> return (tz == NULL) ? NULL : strdup(tz); >> > At present, tz, as referenced by freetz, is freed after the strdup. > I do wonder why it needs to be copied at all when tz itself is the > result of a strdup from the call to getPlatformTimeZoneID, > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > >> -Dmitry >> >> On 2015-08-19 16:14, Langer, Christoph wrote: >>> Hi Thomas, >>> >>> thanks for your review. >>> >>> Axel already helped me to create a bug report: >>> https://bugs.openjdk.java.net/browse/JDK-8133830 >>> >>> I had also updated my webrev, as I would like to take the chance to do some >>> minor refactoring of the AIX porting code for better readability: >>> http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ >>> >>> Can you review the updated change as well? >>> >>> Thanks >>> Christoph >>> >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] >>> Sent: Mittwoch, 19. August 2015 13:12 >>> To: Langer, Christoph >>> Cc: jdk9-dev at openjdk.java.net >>> Subject: Re: Fix for small leak in TimeZone_md.c >>> >>> Hi Christoph, >>> >>> looks fine. I opened a bug for you: >>> https://bugs.openjdk.java.net/browse/JDK-8133933 >>> >>> But this needs another reviewer and a sponsor. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph >>> > wrote: >>> Hi all, >>> >>> I think there is a small memory leak in TimeZone_md.c in the case of >>> solaris "localtime". >>> >>> When getPlatformTimeZoneID() is called and its result is "localtime", the >>> returned string buffer is not freed as the pointer "freetz" is overwritten >>> after the call to getSolarisDefaultZoneID(). >>> >>> Please have a look at my webrev: >>> http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential >>> fix. >>> >>> A bug was not yet created but should be done after you agree that this is >>> an issue. >>> >>> Thanks in advance for comments. >>> >>> Best regards >>> Christoph >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >> >> -- 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 christoph.langer at sap.com Thu Aug 20 10:11:54 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Aug 2015 10:11:54 +0000 Subject: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF1653@DEWDFEMB12B.global.corp.sap> Hi all, as per the discussion in thread "Fix for small leak in TimeZone_md.c", I would like to get the following tiny change reviewed: Bug: https://bugs.openjdk.java.net/browse/JDK-8133830 Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ As said before, I also need a sponsor since I can't commit yet. Thanks Christoph From Alan.Bateman at oracle.com Thu Aug 20 10:14:39 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Aug 2015 11:14:39 +0100 Subject: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF1653@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EF1653@DEWDFEMB12B.global.corp.sap> Message-ID: <55D5A88F.6020807@oracle.com> On 20/08/2015 11:11, Langer, Christoph wrote: > Hi all, > > as per the discussion in thread "Fix for small leak in TimeZone_md.c", I would like to get the following tiny change reviewed: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133830 > Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ > > As said before, I also need a sponsor since I can't commit yet. > Best to move this to core-libs-dev or i18n-dev to complete the review and get a sponsor. -Alan From thomas.stuefe at gmail.com Thu Aug 20 11:19:46 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 20 Aug 2015 13:19:46 +0200 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF1084@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> <55D4B4A7.1020807@oracle.com> <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> <55D4F23C.4000300@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338EF1084@DEWDFEMB12B.global.corp.sap> Message-ID: Hi Christoph, On Thu, Aug 20, 2015 at 10:22 AM, Langer, Christoph < christoph.langer at sap.com> wrote: > Hi Thomas, Andrew and Dmitry, > > thanks for your comments - they are very valuable and lead me to the > following: > > 1. The initial change which just fixes the sport where the Solaris leak > could occur should be commited as fix to bugreport > https://bugs.openjdk.java.net/browse/JDK-8133830 > I'll do a separate posting for review > That makes sense, thanks. I can open a separate issue for the AIX cleanup, if you want. Thomas > 2. I will attempt to do a better refactoring of the "findJavaTZ_md" code > for better readability and to avoid unnecessary string copy operations. > Will post a new webrev later. > > Thanks & Best regards > Christoph > > > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Mittwoch, 19. August 2015 23:17 > To: Andrew Hughes > Cc: Langer, Christoph; Thomas St?fe; jdk9-dev at openjdk.java.net > Subject: Re: Fix for small leak in TimeZone_md.c > > Andrew, > > So it would need further refactoring rather than simply being dropped. > Agree. > > I do wonder why it needs to be copied at all when tz itself is the > > result of a strdup from the call to getPlatformTimeZoneID, > > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > If getenv("TZ") returns some value the code just return this value > (except AIX and "localtime" under Solaris) and it has to be strdup'ed > before return. > > It might be better to create separate function for each platform despite > some code duplication. It makes the code better readable. > > -Dmitry > > > On 2015-08-19 23:51, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Lander, > >> > >> My few cents ... > >> > >> 1. After you refactoring freetz is never actually used. It might be > >> better to just get rid of this variable. > >> > > At present, it's still being used to hold the old version of tz: > > > > tz = getPlatformTimeZoneID(); > > freetz = tz; > > > > So both tz and freetz point to the return value of getPlatformTimeZoneID. > > tz may then be moved forward due to: > > > > if (tz != NULL && *tz == ':') { > > tz++; > > } > > > > and then it is replaced altogether: > > > > if (tz != NULL && strcmp(tz, "localtime") == 0) { > > tz = getSolarisDefaultZoneID(); > > > > Now tz contains the return value of getSolarisDefaultZoneID, so only > > freetz references the old return value from getPlatformTimeZoneID. > > This code then frees it: > > > > if (freetz != NULL) { > > free((void *) freetz); > > } > > freetz = tz; > > > > and tz and freetz match again. > > > > You could get rid of freetz if tz was freed before being overwritten > > in this case, but the same isn't true in the AIX case where tz is > > passed to mapPlatformToJavaTimezone. > > > > So it would need further refactoring rather than simply being dropped. > > > >> 2. Also you can remove javatz as well and further refactor the code to > >> > >> return (tz == NULL) ? NULL : strdup(tz); > >> > > At present, tz, as referenced by freetz, is freed after the strdup. > > I do wonder why it needs to be copied at all when tz itself is the > > result of a strdup from the call to getPlatformTimeZoneID, > > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > > > >> -Dmitry > >> > >> On 2015-08-19 16:14, Langer, Christoph wrote: > >>> Hi Thomas, > >>> > >>> thanks for your review. > >>> > >>> Axel already helped me to create a bug report: > >>> https://bugs.openjdk.java.net/browse/JDK-8133830 > >>> > >>> I had also updated my webrev, as I would like to take the chance to do > some > >>> minor refactoring of the AIX porting code for better readability: > >>> http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > >>> > >>> Can you review the updated change as well? > >>> > >>> Thanks > >>> Christoph > >>> > >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >>> Sent: Mittwoch, 19. August 2015 13:12 > >>> To: Langer, Christoph > >>> Cc: jdk9-dev at openjdk.java.net > >>> Subject: Re: Fix for small leak in TimeZone_md.c > >>> > >>> Hi Christoph, > >>> > >>> looks fine. I opened a bug for you: > >>> https://bugs.openjdk.java.net/browse/JDK-8133933 > >>> > >>> But this needs another reviewer and a sponsor. > >>> > >>> Kind Regards, Thomas > >>> > >>> > >>> > >>> On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > >>> > wrote: > >>> Hi all, > >>> > >>> I think there is a small memory leak in TimeZone_md.c in the case of > >>> solaris "localtime". > >>> > >>> When getPlatformTimeZoneID() is called and its result is "localtime", > the > >>> returned string buffer is not freed as the pointer "freetz" is > overwritten > >>> after the call to getSolarisDefaultZoneID(). > >>> > >>> Please have a look at my webrev: > >>> http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a > potential > >>> fix. > >>> > >>> A bug was not yet created but should be done after you agree that this > is > >>> an issue. > >>> > >>> Thanks in advance for comments. > >>> > >>> Best regards > >>> Christoph > >>> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > >> > >> > > > -- > 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 henri.tremblay at gmail.com Fri Aug 21 16:34:59 2015 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Fri, 21 Aug 2015 12:34:59 -0400 Subject: VirtualMachine in tools.jar Message-ID: Hi, I don't know if that was discussed before. If yes, I'm sorry to be redundant. I had the problem yesterday while playing with JMX and thought it could be of interest. Are there any plans to move some code from tools.jar to the JDK? Specifically, I'm thinking about the VirtualMachine object. When connecting with JMX, you can connect in remote using the JDK but if you want to connect using the PID, it seems that you absolutely need tools.jar. I find this discrepancy quite odd and would like to have your thoughts about that. Thanks Henri From henri at tremblay.pro Mon Aug 24 15:04:41 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Mon, 24 Aug 2015 11:04:41 -0400 Subject: VirtualMachine in tools.jar In-Reply-To: References: Message-ID: Does the absence of answer means that this subject was never raised before? Or that it is considered of no interest? On 21 August 2015 at 12:34, Henri Tremblay wrote: > Hi, > > I don't know if that was discussed before. If yes, I'm sorry to be > redundant. > > I had the problem yesterday while playing with JMX and thought it could be > of interest. > > Are there any plans to move some code from tools.jar to the JDK? > > Specifically, I'm thinking about the VirtualMachine object. When > connecting with JMX, you can connect in remote using the JDK but if you > want to connect using the PID, it seems that you absolutely need tools.jar. > > I find this discrepancy quite odd and would like to have your thoughts > about that. > > Thanks > Henri > From david.holmes at oracle.com Tue Aug 25 02:54:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Aug 2015 12:54:25 +1000 Subject: VirtualMachine in tools.jar In-Reply-To: References: Message-ID: <55DBD8E1.20207@oracle.com> On 25/08/2015 1:04 AM, Henri Tremblay wrote: > Does the absence of answer means that this subject was never raised before? > > Or that it is considered of no interest? More likely that there are a number of factors involved and the right people may not be monitoring this particular list closely. Once the modular image comes along (as part of Jigsaw) tools.jar will be gone. Asking on core-libs-dev or serviceability-dev may get more of a response. Cheers, David > On 21 August 2015 at 12:34, Henri Tremblay wrote: > >> Hi, >> >> I don't know if that was discussed before. If yes, I'm sorry to be >> redundant. >> >> I had the problem yesterday while playing with JMX and thought it could be >> of interest. >> >> Are there any plans to move some code from tools.jar to the JDK? >> >> Specifically, I'm thinking about the VirtualMachine object. When >> connecting with JMX, you can connect in remote using the JDK but if you >> want to connect using the PID, it seems that you absolutely need tools.jar. >> >> I find this discrepancy quite odd and would like to have your thoughts >> about that. >> >> Thanks >> Henri >> From Alan.Bateman at oracle.com Tue Aug 25 07:58:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Aug 2015 08:58:18 +0100 Subject: VirtualMachine in tools.jar In-Reply-To: <55DBD8E1.20207@oracle.com> References: <55DBD8E1.20207@oracle.com> Message-ID: <55DC201A.3050807@oracle.com> On 25/08/2015 03:54, David Holmes wrote: > On 25/08/2015 1:04 AM, Henri Tremblay wrote: >> Does the absence of answer means that this subject was never raised >> before? >> >> Or that it is considered of no interest? > > More likely that there are a number of factors involved and the right > people may not be monitoring this particular list closely. Once the > modular image comes along (as part of Jigsaw) tools.jar will be gone. > Asking on core-libs-dev or serviceability-dev may get more of a response. If I understand Henri's mail correctly then he is advocating that the attach API be included in the JRE builds. The attach API was developed as an API for tools so this is why it has always been in the JDK builds and not the JRE builds. Maybe there are new use-cases now that mean it should be re-examined but it's not clear from the original mail. In general, there are many interesting tools and tool APIs in the JDK builds that might sometimes be useful in environments that only have a run-time installed so I guess a similar argument could be made for those too. Henri - for you build environment then you you might want to look at the top-level make/Images.gmk as that is the make file in the current JDK 9 builds that configures which modules go into the JRE and JDK builds. I see tools.jar was mentioned in a few of the mails but that has not existed in JDK 9 builds since the integration of JEP 220 in late 2014. Once the module system comes along (there should be builds with this any day now) then there will be a linker tool that will allow you to create run-time images that include the modules that you specify (along with their transitive dependences) so this may be something to try out. -Alan From adinn at redhat.com Tue Aug 25 09:12:50 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 25 Aug 2015 10:12:50 +0100 Subject: VirtualMachine in tools.jar In-Reply-To: <55DC201A.3050807@oracle.com> References: <55DBD8E1.20207@oracle.com> <55DC201A.3050807@oracle.com> Message-ID: <55DC3192.1070009@redhat.com> On 25/08/15 08:58, Alan Bateman wrote: > If I understand Henri's mail correctly then he is advocating that the > attach API be included in the JRE builds. The attach API was developed > as an API for tools so this is why it has always been in the JDK builds > and not the JRE builds. Maybe there are new use-cases now that mean it > should be re-examined but it's not clear from the original mail. In > general, there are many interesting tools and tool APIs in the JDK > builds that might sometimes be useful in environments that only have a > run-time installed so I guess a similar argument could be made for those > too. I think the attach classes are a very special case and there are extremely important security reasons for not having the attach API classes in the JRE as the normal case. Their presence in a runtime poses the threat of exploding a small security hole into a gaping breach (since the attach mechanism could be used by rogue code to install a JVMTI Java agent into the current JVM -- with game over consequences). Any runtime that is going to load code that needs to be constrained (e.g. a browser running stuff like applets) probably doesn't want these classes to be in the runtime. I know there are other ways of restricting access but I believe the status quo is belt and braces. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From goetz.lindenmaier at sap.com Tue Aug 25 13:54:28 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Aug 2015 13:54:28 +0000 Subject: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF425D@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EF425D@DEWDFEMB12B.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2D019A1A@DEWDFEMB12A.global.corp.sap> Hi Christoph, the change looks good, Reviewed. In case this code gets reengineered, you could add a comment that memory of getenv must not be freed. Thanks for fixing this, Goetz. -----Original Message----- From: Langer, Christoph Sent: Donnerstag, 20. August 2015 12:12 To: 'jdk9-dev at openjdk.java.net' Subject: RE: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: Hi all, as per the discussion in thread "Fix for small leak in TimeZone_md.c", I would like to get the following tiny change reviewed: Bug: https://bugs.openjdk.java.net/browse/JDK-8133830 Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ As said before, I also need a sponsor since I can't commit yet. Thanks Christoph From goetz.lindenmaier at sap.com Tue Aug 25 14:02:34 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Aug 2015 14:02:34 +0000 Subject: CFV: New jdk9 Committer: Axel Siebenborn Message-ID: <4295855A5C1DE049A61835A1887419CC2D019A30@DEWDFEMB12A.global.corp.sap> Vote: yes Goetz From henri at tremblay.pro Tue Aug 25 15:16:49 2015 From: henri at tremblay.pro (Henri Tremblay) Date: Tue, 25 Aug 2015 11:16:49 -0400 Subject: VirtualMachine in tools.jar In-Reply-To: <55DC3192.1070009@redhat.com> References: <55DBD8E1.20207@oracle.com> <55DC201A.3050807@oracle.com> <55DC3192.1070009@redhat.com> Message-ID: David, thanks a lot for your answer. In fact, I dumbly haven't tried on jdk9 to see how it behaves. I will and give you feedback. I just felt on a weird asymmetry and felt it could be addressed by Jigsaw. I'm not sure I agree with Andrew but I don't have the necessary knowledge on that topic to be a good judge. So I will rephrase my first statement hoping it will now be intelligible. There are two ways to retrieve JMX information with another process. - Remotely. This is only possible when jmx remote is enabled explicitly by the process we are connecting to - Locally. This is always possible. A local process can connect to another using its PID. It should also run under the same user (previously, it was possible to also be root but due to a JDK change, this isn't working that well anymore. I can find the exact change if needed) The API to connect locally used to be available in tools.jar. We can connect remotely without tools.jar. This is the asymmetry I'm talking about. Connect locally is used by many monitoring tools: VisualVM, jstatd, jmxtrans, jmxterm. It is a useful feature because it prevents triggering all the JMX remote machinery. On 25 August 2015 at 05:12, Andrew Dinn wrote: > On 25/08/15 08:58, Alan Bateman wrote: > > If I understand Henri's mail correctly then he is advocating that the > > attach API be included in the JRE builds. The attach API was developed > > as an API for tools so this is why it has always been in the JDK builds > > and not the JRE builds. Maybe there are new use-cases now that mean it > > should be re-examined but it's not clear from the original mail. In > > general, there are many interesting tools and tool APIs in the JDK > > builds that might sometimes be useful in environments that only have a > > run-time installed so I guess a similar argument could be made for those > > too. > > I think the attach classes are a very special case and there are > extremely important security reasons for not having the attach API > classes in the JRE as the normal case. Their presence in a runtime poses > the threat of exploding a small security hole into a gaping breach > (since the attach mechanism could be used by rogue code to install a > JVMTI Java agent into the current JVM -- with game over consequences). > Any runtime that is going to load code that needs to be constrained > (e.g. a browser running stuff like applets) probably doesn't want these > classes to be in the runtime. I know there are other ways of restricting > access but I believe the status quo is belt and braces. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > From lana.steuck at oracle.com Tue Aug 25 17:52:20 2015 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 25 Aug 2015 10:52:20 -0700 (PDT) Subject: jdk9-b79: dev Message-ID: <201508251752.t7PHqKSj025939@sc11152554.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/ba08a9f79b98 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/9b3eca69b88b http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/eaab8a16dcfb http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d99c2ffdd0f1 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/42ae657e0e10 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/cf809edc840f http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e9e63d93bbfe http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/4ab250b8fac6 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8133321 core-libs (tz) Support tzdata2015f JDK-8060717 core-libs [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments JDK-8133543 core-libs [TESTBUG] java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java sh JDK-8132478 core-libs [tidy] three new warnings from java docs (java.net, javax.annotation) JDK-8077168 core-libs CodeStoreAndPathTest.java fails in jtreg mode on Mac JDK-8133872 core-libs Expression completion should work on contexts where an expression is a JDK-8133812 core-libs identifier and member expression completion handling is not uniform JDK-8133695 core-libs Implement tab-completion for identifiers JDK-8133652 core-libs Implement tab-completion for member select expressions JDK-8132527 core-libs jimage tool extract and recreate options are not consistent (no NPE) JDK-8133624 core-libs Move JDK-8055034.js and JDK-8130127.js to currently-failing directory JDK-8133808 core-libs Place java/lang/ProcessHandle/InfoTest.java on the Problem List JDK-8131168 core-libs Refactor ProcessHandleImpl_*.c and add implememtation for AIX JDK-8133480 core-libs replace some tags (obsolete in html5) in core-libs docs JDK-8074821 core-libs Resolve disabled warnings for libnio JDK-8132944 core-libs test java/lang/ClassLoader/GetSystemPackage.java writes stuff to Agent JDK-8039390 core-libs Unexpected behaviour of String.format with null arguments JDK-8133777 core-libs Use file based persistence for history instead of preferences JDK-8075773 core-svc jps running as root fails after the fix of JDK-8050807 JDK-8085919 core-svc OperatingSystemMXBean/TestTotalSwap.java failure : Total Swap Space fi JDK-8076470 core-svc Remove the code and update makefiles JDK-8132648 core-svc sun/tools/jhsdb/BasicLauncherTest fails with java.lang.RuntimeExceptio JDK-8132214 hotspot [TESTBUG] Create basic shared strings test for CDS archive JDK-8133222 hotspot [TESTBUG] Quarantine runtime/SharedArchiveFile/SharedStrings.java unti JDK-8132969 hotspot C++11 requires a space between literal and identifier JDK-8131682 hotspot C1 should use multibyte nops everywhere JDK-8133043 hotspot Clean up code related to termination stats printing JDK-8078904 hotspot CMS: Assert failed: Ctl pt invariant JDK-8087342 hotspot Crash in klassItable::initialize_itable_for_interface when running Sel JDK-8132306 hotspot java/lang/ref/ReferenceEnqueue.java fails with "RuntimeException: Erro JDK-8132892 hotspot Memory must be freed after calling Arguments::set_sysclasspath functio JDK-8133042 hotspot Remove some direct accesses of G1Allocator to G1CollectedHeap members JDK-8073052 hotspot Rename and clean up the allocation manager hierarchy in g1Allocator.?p JDK-8133047 hotspot Rename G1ParScanThreadState::_queue_num to _worker_id JDK-8060245 hotspot update bsd version of jhelper.d to be in sync with the fix of 8009204 JDK-8011858 hotspot Use Compile::live_nodes() instead of Compile::unique() in appropriate JDK-8132330 security-libs Ineffective SecureRandom usage in RSA encoding with PKCS1Padding. JDK-8050460 security-libs JAAS login/logout tests with LoginContext JDK-8130799 security-libs KeyStoreSpi.engineProbe does not throw the expected NullPointerExcepti JDK-8086002 security-libs Move apple.security.AppleProvider to a proper module From gnu.andrew at redhat.com Wed Aug 26 18:31:41 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Aug 2015 14:31:41 -0400 (EDT) Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <55D4F23C.4000300@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> <55D4B4A7.1020807@oracle.com> <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> <55D4F23C.4000300@oracle.com> Message-ID: <1230816333.1692011.1440613901121.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Andrew, > > So it would need further refactoring rather than simply being dropped. > Agree. > > I do wonder why it needs to be copied at all when tz itself is the > > result of a strdup from the call to getPlatformTimeZoneID, > > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > If getenv("TZ") returns some value the code just return this value > (except AIX and "localtime" under Solaris) and it has to be strdup'ed > before return. Yes, I get that, but it appears to happen twice; once in the function that obtains the value and then once again in the calling function. > > It might be better to create separate function for each platform despite > some code duplication. It makes the code better readable. +1. I don't think there's enough duplication here to warrant how unreadable the code is. > > -Dmitry > > > On 2015-08-19 23:51, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Lander, > >> > >> My few cents ... > >> > >> 1. After you refactoring freetz is never actually used. It might be > >> better to just get rid of this variable. > >> > > At present, it's still being used to hold the old version of tz: > > > > tz = getPlatformTimeZoneID(); > > freetz = tz; > > > > So both tz and freetz point to the return value of getPlatformTimeZoneID. > > tz may then be moved forward due to: > > > > if (tz != NULL && *tz == ':') { > > tz++; > > } > > > > and then it is replaced altogether: > > > > if (tz != NULL && strcmp(tz, "localtime") == 0) { > > tz = getSolarisDefaultZoneID(); > > > > Now tz contains the return value of getSolarisDefaultZoneID, so only > > freetz references the old return value from getPlatformTimeZoneID. > > This code then frees it: > > > > if (freetz != NULL) { > > free((void *) freetz); > > } > > freetz = tz; > > > > and tz and freetz match again. > > > > You could get rid of freetz if tz was freed before being overwritten > > in this case, but the same isn't true in the AIX case where tz is > > passed to mapPlatformToJavaTimezone. > > > > So it would need further refactoring rather than simply being dropped. > > > >> 2. Also you can remove javatz as well and further refactor the code to > >> > >> return (tz == NULL) ? NULL : strdup(tz); > >> > > At present, tz, as referenced by freetz, is freed after the strdup. > > I do wonder why it needs to be copied at all when tz itself is the > > result of a strdup from the call to getPlatformTimeZoneID, > > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > > > >> -Dmitry > >> > >> On 2015-08-19 16:14, Langer, Christoph wrote: > >>> Hi Thomas, > >>> > >>> thanks for your review. > >>> > >>> Axel already helped me to create a bug report: > >>> https://bugs.openjdk.java.net/browse/JDK-8133830 > >>> > >>> I had also updated my webrev, as I would like to take the chance to do > >>> some > >>> minor refactoring of the AIX porting code for better readability: > >>> http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > >>> > >>> Can you review the updated change as well? > >>> > >>> Thanks > >>> Christoph > >>> > >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >>> Sent: Mittwoch, 19. August 2015 13:12 > >>> To: Langer, Christoph > >>> Cc: jdk9-dev at openjdk.java.net > >>> Subject: Re: Fix for small leak in TimeZone_md.c > >>> > >>> Hi Christoph, > >>> > >>> looks fine. I opened a bug for you: > >>> https://bugs.openjdk.java.net/browse/JDK-8133933 > >>> > >>> But this needs another reviewer and a sponsor. > >>> > >>> Kind Regards, Thomas > >>> > >>> > >>> > >>> On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > >>> > wrote: > >>> Hi all, > >>> > >>> I think there is a small memory leak in TimeZone_md.c in the case of > >>> solaris "localtime". > >>> > >>> When getPlatformTimeZoneID() is called and its result is "localtime", the > >>> returned string buffer is not freed as the pointer "freetz" is > >>> overwritten > >>> after the call to getSolarisDefaultZoneID(). > >>> > >>> Please have a look at my webrev: > >>> http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential > >>> fix. > >>> > >>> A bug was not yet created but should be done after you agree that this is > >>> an issue. > >>> > >>> Thanks in advance for comments. > >>> > >>> Best regards > >>> Christoph > >>> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > >> > >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Aug 26 18:32:44 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 26 Aug 2015 14:32:44 -0400 (EDT) Subject: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D019A1A@DEWDFEMB12A.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338EF425D@DEWDFEMB12B.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2D019A1A@DEWDFEMB12A.global.corp.sap> Message-ID: <1761854951.1692266.1440613964673.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Christoph, > > the change looks good, Reviewed. > > In case this code gets reengineered, you could add a comment that > memory of getenv must not be freed. > > Thanks for fixing this, > Goetz. > > > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 20. August 2015 12:12 > To: 'jdk9-dev at openjdk.java.net' > Subject: RE: RFR(S): 8133830: Fix for small leak in TimeZone_md.c: > > Hi all, > > as per the discussion in thread "Fix for small leak in TimeZone_md.c", I > would like to get the following tiny change reviewed: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133830 > Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ > > As said before, I also need a sponsor since I can't commit yet. > > Thanks > Christoph > I'm happy to sponsor this if still needed. This version is almost so trivial now as to barely need review :) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From christoph.langer at sap.com Wed Aug 26 21:34:35 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Aug 2015 21:34:35 +0000 Subject: Fix for small leak in TimeZone_md.c In-Reply-To: <1230816333.1692011.1440613901121.JavaMail.zimbra@redhat.com> References: <0DFD2E72402C9243A8630A7759B27E4338EEF2AF@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338EF0434@DEWDFEMB12B.global.corp.sap> <55D4B4A7.1020807@oracle.com> <1571261947.12638576.1440017502519.JavaMail.zimbra@redhat.com> <55D4F23C.4000300@oracle.com> <1230816333.1692011.1440613901121.JavaMail.zimbra@redhat.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF5AC7@DEWDFEMB12B.global.corp.sap> Hi Andrew, today I have posted the following RFR in i18n-dev: when working on TimeZone_md.c lately, I found it worthwhile to do some cleanup on it. Please review my changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8134505 Webrev: http://cr.openjdk.java.net/~goetz/webrevs/8134505-timeZone/webrev.01/ I basically did the following things: - clean up some typos and comment errors - added #include "TimeZone_md.h" - split up the platform specific define sections into an #ifdef #elif #elif ? #endif construct - moved some AIX coding from the #ifdef block at the bottom of the file into the first AIX specific block - AIX function ?mapPlatformToJavaTimezone?: use a dynamic malloced buffer instead of a fixed length buffer - refactor function ?findJavaTZ_md? to make it more straightforward and to avoid unnecessary mallocs and don?t forget necessary frees I?m also wondering if the ?if (tz == NULL || *tz == '\0') {? of line 770 could be used for all platforms instead of Solaris and AIX only. The other platforms will only do a check if TZ is NULL but not if it is an empty string. I did not follow the suggestion to split up "findJavaTZ_md" in platform versions, though. I'd be grateful for your feedback. Thanks Christoph -----Original Message----- From: Andrew Hughes [mailto:gnu.andrew at redhat.com] Sent: Mittwoch, 26. August 2015 20:32 To: Dmitry Samersoff Cc: Langer, Christoph ; Thomas St?fe ; jdk9-dev at openjdk.java.net Subject: Re: Fix for small leak in TimeZone_md.c ----- Original Message ----- > Andrew, > > So it would need further refactoring rather than simply being dropped. > Agree. > > I do wonder why it needs to be copied at all when tz itself is the > > result of a strdup from the call to getPlatformTimeZoneID, > > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > If getenv("TZ") returns some value the code just return this value > (except AIX and "localtime" under Solaris) and it has to be strdup'ed > before return. Yes, I get that, but it appears to happen twice; once in the function that obtains the value and then once again in the calling function. > > It might be better to create separate function for each platform despite > some code duplication. It makes the code better readable. +1. I don't think there's enough duplication here to warrant how unreadable the code is. > > -Dmitry > > > On 2015-08-19 23:51, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Lander, > >> > >> My few cents ... > >> > >> 1. After you refactoring freetz is never actually used. It might be > >> better to just get rid of this variable. > >> > > At present, it's still being used to hold the old version of tz: > > > > tz = getPlatformTimeZoneID(); > > freetz = tz; > > > > So both tz and freetz point to the return value of getPlatformTimeZoneID. > > tz may then be moved forward due to: > > > > if (tz != NULL && *tz == ':') { > > tz++; > > } > > > > and then it is replaced altogether: > > > > if (tz != NULL && strcmp(tz, "localtime") == 0) { > > tz = getSolarisDefaultZoneID(); > > > > Now tz contains the return value of getSolarisDefaultZoneID, so only > > freetz references the old return value from getPlatformTimeZoneID. > > This code then frees it: > > > > if (freetz != NULL) { > > free((void *) freetz); > > } > > freetz = tz; > > > > and tz and freetz match again. > > > > You could get rid of freetz if tz was freed before being overwritten > > in this case, but the same isn't true in the AIX case where tz is > > passed to mapPlatformToJavaTimezone. > > > > So it would need further refactoring rather than simply being dropped. > > > >> 2. Also you can remove javatz as well and further refactor the code to > >> > >> return (tz == NULL) ? NULL : strdup(tz); > >> > > At present, tz, as referenced by freetz, is freed after the strdup. > > I do wonder why it needs to be copied at all when tz itself is the > > result of a strdup from the call to getPlatformTimeZoneID, > > getSolarisDefaultZoneID or mapPlatformToJavaTimezone. > > > >> -Dmitry > >> > >> On 2015-08-19 16:14, Langer, Christoph wrote: > >>> Hi Thomas, > >>> > >>> thanks for your review. > >>> > >>> Axel already helped me to create a bug report: > >>> https://bugs.openjdk.java.net/browse/JDK-8133830 > >>> > >>> I had also updated my webrev, as I would like to take the chance to do > >>> some > >>> minor refactoring of the AIX porting code for better readability: > >>> http://cr.openjdk.java.net/~asiebenborn/8133830/webrev/ > >>> > >>> Can you review the updated change as well? > >>> > >>> Thanks > >>> Christoph > >>> > >>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > >>> Sent: Mittwoch, 19. August 2015 13:12 > >>> To: Langer, Christoph > >>> Cc: jdk9-dev at openjdk.java.net > >>> Subject: Re: Fix for small leak in TimeZone_md.c > >>> > >>> Hi Christoph, > >>> > >>> looks fine. I opened a bug for you: > >>> https://bugs.openjdk.java.net/browse/JDK-8133933 > >>> > >>> But this needs another reviewer and a sponsor. > >>> > >>> Kind Regards, Thomas > >>> > >>> > >>> > >>> On Tue, Aug 18, 2015 at 11:52 AM, Langer, Christoph > >>> > wrote: > >>> Hi all, > >>> > >>> I think there is a small memory leak in TimeZone_md.c in the case of > >>> solaris "localtime". > >>> > >>> When getPlatformTimeZoneID() is called and its result is "localtime", the > >>> returned string buffer is not freed as the pointer "freetz" is > >>> overwritten > >>> after the call to getSolarisDefaultZoneID(). > >>> > >>> Please have a look at my webrev: > >>> http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/ for a potential > >>> fix. > >>> > >>> A bug was not yet created but should be done after you agree that this is > >>> an issue. > >>> > >>> Thanks in advance for comments. > >>> > >>> Best regards > >>> Christoph > >>> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > >> > >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bourges.laurent at gmail.com Thu Aug 27 10:23:08 2015 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 27 Aug 2015 12:23:08 +0200 Subject: JEP submitted: Update Java2D to use the Marlin Renderer as the default Graphics Rasterizer In-Reply-To: References: Message-ID: FYI, the JEP is waiting for Candidate review: https://bugs.openjdk.java.net/browse/JDK-8131760 Best regards, Laurent ---------- Message transf?r? ---------- De : "Laurent Bourg?s" Date : 24 juil. 2015 17:30 Objet : JEP submitted: Update Java2D to use the Marlin Renderer as the default Graphics Rasterizer ? : , <2d-dev at openjdk.java.net> Cc : > Dear all, > > I submitted a JEP to use the Marlin renderer instead of Pisces to improve both performance, scalability and also quality. > > FYI Marlin is in development for few months within the graphics rasterizer project. > > Please look at the JBS bug JDK-8131760 for more details: > https://bugs.openjdk.java.net/browse/JDK-8131760 > > Comments & feedback are welcome. > > Regards, > Laurent Bourges From Sergey.Bylokhov at oracle.com Mon Aug 31 10:36:14 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 31 Aug 2015 13:36:14 +0300 Subject: Subject: Result: New JDK 9 Reviewer: Semyon Sadetsky Message-ID: <55E42E1E.9020105@oracle.com> Voting for Semyon Sadetsky [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Sergey Bylokhov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-August/002503.html -- Best regards, Sergey. From stefan.karlsson at oracle.com Mon Aug 31 10:48:48 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 31 Aug 2015 12:48:48 +0200 Subject: Result: New JDK 9 Committer: David Lindholm Message-ID: <55E43110.4090102@oracle.com> Voting for David Lindholm [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Stefan Karlsson [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-August/002534.html From gerard.ziemski at oracle.com Mon Aug 31 15:29:50 2015 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Mon, 31 Aug 2015 10:29:50 -0500 Subject: JEP submitted: Update Java2D to use the Marlin Renderer as the default Graphics Rasterizer In-Reply-To: References: Message-ID: <55E472EE.3040903@oracle.com> It's very exciting to see that we're addressing the performance issues of our currently existing Pisces 2D engine. I'm not sure how detailed we want to have the JEP, but the following are the issues I would love to see the JEP go into a bit more detail: #1 In the "Success Metrics" we say "significantly outperforms", but we're not committing to any hard numbers - do we have an expectation on how much better the new engine will be, that can be stated? Especially since we claim that the development version already meets this goal? #2 What is the expected CPU usage allowed when scaling up in a multi-threaded environment - 2 threads probably do not mean 2x performance? Is Merlin allowed to use all threads, or does it have a limit on how many will be used? Can/should this be controlled via some sort of a runtime flag available to developers? #3 Is Merlin's quality and accuracy high enough that it could one day replace the font rendered as well? #4 Is Merlin performing well on both desktop and mobile platforms? Is such platform separation still needed? #5 Would it be helpful to find an external use case scenario, in addition to the internal ones (ie. Pisces and Ductus), such as the performance of Adobe's Flash to compare Merlin's performance? #6 In the "Alternatives" section, shouldn't we at least mention a GPU based 2D rendering? cheers On 08/27/2015 05:23 AM, Laurent Bourg?s wrote: > FYI, the JEP is waiting for Candidate review: > https://bugs.openjdk.java.net/browse/JDK-8131760 > > Best regards, > Laurent > > ---------- Message transf?r? ---------- > De : "Laurent Bourg?s" > Date : 24 juil. 2015 17:30 > Objet : JEP submitted: Update Java2D to use the Marlin Renderer as the > default Graphics Rasterizer > ? : , <2d-dev at openjdk.java.net> > Cc : > >> Dear all, >> >> I submitted a JEP to use the Marlin renderer instead of Pisces to improve > both performance, scalability and also quality. >> >> FYI Marlin is in development for few months within the graphics > rasterizer project. >> >> Please look at the JBS bug JDK-8131760 for more details: >> https://bugs.openjdk.java.net/browse/JDK-8131760 >> >> Comments & feedback are welcome. >> >> Regards, >> Laurent Bourges > > From alejandro.murillo at oracle.com Mon Aug 31 22:21:11 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 31 Aug 2015 16:21:11 -0600 Subject: jdk9-dev: HotSpot Message-ID: <55E4D357.7010602@oracle.com> jdk9-hs-2015-08-27 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/f7c5ae2933c0 http://hg.openjdk.java.net/jdk9/dev/corba/rev/821a0373ef2d http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/22400a67babe http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/f464f9b2fb11 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/e9940bf1c8dd http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4f3c5f831833 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/176472b94f2e http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/eea9202e8930 Component : VM Status : Go for integration Date : 08/31/2015 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2015-08-27-214436.amurillo.jdk9-hs-2015-08-27-snapshot Testing: 103 new failures, 3228 known failures, 466793 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8003237: G1: Reduce unnecessary (and failing) allocation attempts when handling an evacuation failure 8019968: Reference CAS induces GC store barrier even on failure 8029453: java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout 8040162: Avoid reallocating PLABs between GC phases in G1 8041565: JMX ObjectName could be refactored to save memory 8067336: Allow that PLAB allocations at the end of regions are flexible 8067339: PLAB reallocation might result in failure to allocate object in that recently allocated PLAB 8073013: Add detailed information about PLAB memory usage 8073146: G1 merges thread local age tables too early with global age table 8075805: Crash while trying to release CompiledICHolder 8076373: In 32-bit VM interpreter and compiled code process NaN values differently 8078743: AARCH64: Extend use of stlr to cater for volatile object stores 8080289: Intermediate writes in a loop not eliminated by optimizer 8087323: Unify and split the work gang classes 8087324: Use semaphores when starting and stopping GC task threads 8098791: Remove PrintClassStatistics and PrintMethodStatistics 8112746: Followup to JDK-8059557 (JEP 245) 8130115: REDO - Reduce Symbol::_identity_hash to 2 bytes 8130308: Too low memory usage in TestPromotionFromSurvivorToTenuredAfterMinorGC.java 8130847: Cloned object's fields observed as null after C2 escape analysis 8130910: hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_ has wrong permissions 8131969: jit/FloatingPoint/gen_math/Loops05 assert(2 <= size && size <= 16) failed: update low bits table 8133121: Move implementation of process_grey_object to concurrentMark.inline.hpp 8133193: Memory leak in G1 because G1RootProcessor doesn't have desctructor 8133314: Update launcher.properties to remove reference to hprof 8133349: CMS: Assert failed: Ctl pt invariant 8133352: aarch64: generates constrained unpredictable instructions 8133455: VM ignores setting of the -XX:MemoryRestriction flag. 8133456: HeapRegionManager::shrink_by() iterates suboptimally across regions 8133470: Uses of Atomic methods in plab.hpp should be moved to .inline.hpp file 8133530: Add JFR event for evacuation statistics 8133537: clarify position of unlock options in error messages 8133553: Running with -XX:+UseParallelGC -XX:OldSize=30k crashes jvm 8133557: Missing test before a branch when checking for MethodCounters in TemplateTable::branch() on x86 8133599: Unsafe.getAndSetObject() is no longer intrinsified by c2 8133625: src/share/vm/opto/compile.hpp:96: error: integer constant is too large for ?long? type 8133666: OperatingSystemMXBean reports abnormally high machine CPU consumption on Linux 8133669: Remove unused code in Arguments 8133678: test fails due to 'CICompilerCount=0 must be at least 1' missing from stdout/stderr 8133821: Refactor initialization of the heap and the collector policy 8133825: Remove the class G1CollectorPolicyExt 8133842: aarch64: C2 generates illegal instructions with int shifts >=32 8133935: aarch64: fails to build from source 8133951: Zero interpreter asserts in stubRoutines.cpp 8133984: print_compressed_class_space() is only defined in 64-bit VM 8134321: tools/pack200/Pack200Test.java crashes in the VM PIT jdk9 b79 -- Alejandro