Re: RFR 9: 8086278 : java/lang/ProcessHandle/TreeTest.java failed - ProcessReaper StackOverflowException

On 13/04/16 16:42, Roger Riggs wrote: Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible. Webrev:

RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported

This review is for the second significant part of the changes for JEP 260 [1]. When created, the jdk.unsupported module [2] initially contained the sun.misc package. This issue is will move all the non-Critical APIs out of sun.reflect, leaving only the critical ones, at which point sun.reflect

Re: Review request 8153895 (proxy) redundant read edges to superinterfaces of proxy interfaces

Looks ok Mandy. -Chris. On 12 Apr 2016, at 00:45, Mandy Chung wrote: > Peter spots the redundant read edges are added to dynamic module when > creating a proxy class. Proxy class does not access super interfaces of > proxy interfaces. I have verified this simple

Re: RFR 8153928, test/lib/share/classes/jdk/test/lib/Utils.java introduced dependency to java.base/jdk.internal.misc

> On 11 Apr 2016, at 07:57, Felix Yang wrote: > > Hi Alan and Amy, >thanks for figuring this out. Updated to suggested practice. > > New webrev: http://cr.openjdk.java.net/~xiaofeya/8153928/webrev.01/ Thanks for jumping on this, Felix. +1 -Chris. > Felix > >> On

Re: RFR [9] 8153737: Unsupported Module

This change has been pushed to jdk9/dev. The hotspot gatekeeper will bring it down into the hotspot forests. -Chris. > On 7 Apr 2016, at 18:14, Chris Hegarty <chris.hega...@oracle.com> wrote: > > Enough technical debt has been paid down that we can now create the new > J

Re: RFR [9] 8153737: Unsupported Module

On 08/04/16 03:52, Mandy Chung wrote: On Apr 7, 2016, at 10:14 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially c

Re: RFR [9] 8153737: Unsupported Module

On 07/04/16 19:57, Alan Bateman wrote: On 07/04/2016 18:14, Chris Hegarty wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package

Re: RFR [9] 8153737: Unsupported Module

On 08/04/16 15:31, Peter Levart wrote: On 04/08/2016 12:24 PM, Paul Sandoz wrote: On 7 Apr 2016, at 19:14, Chris Hegarty <chris.hega...@oracle.com> wrote: Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1],

RFR [9] 8153737: Unsupported Module

Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect package too ( once it has been sanitized

RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module

sun.misc.PostVMInitHook::run is called by the VM once its initialization is complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. Since sun.misc will be moved out of the base module, the VM should look for the PostVMInitHook in a more suitable place, say jdk.internal.vm.

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

[ including build-dev ] sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native

RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native component, and no other code

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On 03/04/16 21:39, Claes Redestad wrote: Thanks for looking at this, Alan! Cleaned things up here: http://cr.openjdk.java.net/~redestad/8153334/webrev.02/ Looks good Claes. -Chris.

Re: RFR [9] 8153181: Examine sun.misc.VMSupport

al.perf.Perf. >> It could although I assume this means that introducing a new shared library. > > jdk.internal.perf is in java.base. Another option is to move it to > jdk.jvmstat that i considered but may not worth it since perf counter is > still in java.base. > > Mandy

RFR [9] 8153181: Examine sun.misc.VMSupport

As part of JEP 260, all non-Critical APIs in sun.misc are being examined. sun.misc.VMSupport is a utility class supporting two functions: 1) the initialization of management Agent properties, and 2) the retrieval of the VM temporary directory used by the attach and perf data files. The

Re: 8153118 Remove sun.misc.resources

On 30 Mar 2016, at 21:57, Mandy Chung <mandy.ch...@oracle.com> wrote: >> >> On Mar 30, 2016, at 1:35 PM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> sun.misc.resources claims to contain a ResourceBundle for sun.misc, >> which has localize

Re: Review request 8153035: GenModuleInfoSource strips away the API

On 30 Mar 2016, at 20:09, Mandy Chung wrote: > GenModuleInfoSource is a build tool that augments module-info.java with > platform-specific declaration such as exports, uses and provides and > generates the resulting module-info.java in gensrc directory. This utility

Re: RFR [9] 8152190: Move sun.misc.JarIndex and InvalidJarIndexException to an internal package

le.com/javase/8/docs/technotes/guides/jar/jar.html#Overview [2] https://bugs.openjdk.java.net/browse/JDK-8152276 [3] https://bugs.openjdk.java.net/browse/JDK-8152190 On 21 Mar 2016, at 17:42, Chris Hegarty <chris.hega...@oracle.com> wrote: > > On 21 Mar 2016, at 08:33, Alan Bateman

Re: RFR: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient

Looks good Daniel. -Chris. On 24 Mar 2016, at 11:36, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > > 8152606: java.base no longer needs to export sun.util.logging > to java.httpclient > https://bugs.openjdk.java.net/browse/JDK-8152606 > >

RFR [9] 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy

Trivially, looks like a minor oversight that inadvertently introduced a dependency on sun.misc.Unsafe. diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java b/src/java.base/share/classes/java/lang/reflect/Proxy.java --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java

Re: RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization

On 24 Mar 2016, at 09:15, Peter Levart wrote: > Hi Aleksey, > > Looks nice to me, but I'm not a Reviewer. Quite an improvement for longer > strings. +1 -Chris. > Regards, Peter > > On 03/24/2016 08:31 AM, Aleksey Shipilev wrote: >> On 03/16/2016 11:13 AM, Aleksey

Re: RFR [9] 8152277: Move URLClassPath.pathToURLs(String) to RegistryImpl

On 21/03/16 18:35, Alan Bateman wrote: On 21/03/2016 17:45, Chris Hegarty wrote: In the context of 8149122 & 8152190 it was noticed that sun.rmi.registry.RegistryImpl is the only invoker of URLClassPath::pathToURLs. Rather that adding a qualified export to java.rmi for this, it makes s

Re: Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925

Hi Mandy, On 22/03/16 18:41, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ I think this is fine. ( I also agree with Alan's comment ) Just a few minor, subjective, comments: - Maybe update the CleanerFactory class-level docs, OpenJDK modules ->

RFR [9] 8152277: Move URLClassPath.pathToURLs(String) to RegistryImpl

In the context of 8149122 & 8152190 it was noticed that sun.rmi.registry.RegistryImpl is the only invoker of URLClassPath::pathToURLs. Rather that adding a qualified export to java.rmi for this, it makes sense to move pathToURLs(String) to RegistryImpI ( and "modernize" the implementation a

Re: RFR [9] 8152190: Move sun.misc.JarIndex and InvalidJarIndexException to an internal package

On 21 Mar 2016, at 08:33, Alan Bateman <alan.bate...@oracle.com> wrote: > On 21/03/2016 05:53, Chris Hegarty wrote: >> sun.misc.JarIndex, and its accompanying InvalidJarIndexException, are not >> "Critical APIs", as defined by JEP 260, so they should be move

RFR [9] 8152190: Move sun.misc.JarIndex and InvalidJarIndexException to an internal package

sun.misc.JarIndex, and its accompanying InvalidJarIndexException, are not "Critical APIs", as defined by JEP 260, so they should be moved out of sun.misc and placed into a more appropriate package where they can be encapsulated. http://cr.openjdk.java.net/~chegar/8152190/00/

Re: RFR: 8152074: Avoid lambda usage in StringConcatFactory initializer

> On 17 Mar 2016, at 07:10, Claes Redestad wrote: > > On 2016-03-17 08:05, Aleksey Shipilev wrote: >> On 17.03.2016 09:50, Claes Redestad wrote: >>> please review this patch to remove lambda usage in the >>> StringConcatFactory initializer, which saves some parts of

Re: JDK 9 RFR of JDK-8151763; Use more informative format for problem list

Looks good Joe. -Chris > On 11 Mar 2016, at 22:28, joe darcy wrote: > > Hello, > > As Jon Gibbons has noted off-list, the problem list entries can directly > include the bug number associated with the test in question, enabling better > reporting. This format should be

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

On 9 Mar 2016, at 16:10, Claes Redestad wrote: > > On 2016-03-09 16:58, Peter Levart wrote: >>> Can this really happen? ASCIICaseInsensitiveComparator was asserting that >>> string characters were ASCII, so this situation would have triggered an >>> assert >>> with

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

On 9 Mar 2016, at 14:43, Peter Levart <peter.lev...@gmail.com> wrote: > > On 03/09/2016 02:44 PM, Chris Hegarty wrote: >> On 9 Mar 2016, at 13:03, Claes Redestad <claes.redes...@oracle.com> wrote: >> >>> On 2016-03-09 13:17, Peter Levart wrote: >&g

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

On 9 Mar 2016, at 13:03, Claes Redestad wrote: > On 2016-03-09 13:17, Peter Levart wrote: >>> >>> When digging through old history to try to find out why >>> java.util.jar.Attributes >>> was ever using ASCIICaseInsensitiveComparator, it was not clear that >>>

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Hi Peter, On 9 Mar 2016, at 08:42, Peter Levart wrote: > Hi Chris, > > While Attribute.Name.equals() should be comparably fast, what about > Attribute.Name.hashCode() ? Could you for example extend the > AvailableCharsetsCompare benchmark with a a @Setup method that

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

… and the links: http://cr.openjdk.java.net/~chegar/8151384/webrev.02/ http://cr.openjdk.java.net/~chegar/8151384/bench.02/ -Chris. On 8 Mar 2016, at 11:07, Chris Hegarty <chris.hega...@oracle.com> wrote: > On 7 Mar 2016, at 22:36, Xueming Shen <xueming.s...@oracle.com> w

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

On 7 Mar 2016, at 22:36, Xueming Shen <xueming.s...@oracle.com> wrote: > 515 hashCode = name.toLowerCase(Locale.ROOT).hashCode(); Fixed. On 7 Mar 2016, at 22:20, Aleksey Shipilev <aleksey.shipi...@oracle.com> wrote: > Hi Chris, > > On 03/08/2016 12:55

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

://cr.openjdk.java.net/~chegar/8151384/bench.01/ -Chris. On 7 Mar 2016, at 16:51, Aleksey Shipilev <aleksey.shipi...@oracle.com> wrote: > Hi, > > On 03/07/2016 07:29 PM, Chris Hegarty wrote: >> What is in the webrev is specialized versions of compare when >> the coder of the s

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

On 06/03/16 13:00, Peter Levart wrote: Hi, I have been asked to split the changes needed to remove jdk.internal.ref.Cleaner into two changesets. The first one is to contain the straightforward non-controversial changes that remove the references to jdk.internal.ref.Cleaner and swaps them with

RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

sun.misc.ASCIICaseInsensitiveComparator appears to be a specialized comparator for comparing strings that contain only ASCII characters. Its main usage seems to be in sorted maps that support the character set implementation. This is startup/performance sensitive code. It looks like an

RFR [9] 8151140: Replace use of lambda/method ref in jdk.Version constructor

Since 8150163 [1], jdk.Version can now be used earlier in startup, but not always. It was noticed that the use of lambda / method ref in the constructor, in some cases, was the first usage of such, and incurred the initialization costs of the java.lang.invoke infrastructure ( which can take a

RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API

Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major runtime version. They should be updated to use the new JDK specific Version API. Note: There is an issue, 8144062 [1], to revisit the JDK specific Version API to determine if it should be moved, or even standardized.

RFR [9] 8149122: Move sun.misc.URLClassPath and Resource to an internal package

sun.misc.URLClassPath, and its accompanying Resource, are not "Critical APIs", as defined by JEP 260, so they should be moved out of sun.misc and placed into a more appropriate package where they can be encapsulated. http://cr.openjdk.java.net/~chegar/8149122/

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

t; [0] >> http://cr.openjdk.java.net/~chegar/8150162/jdk/src/java.base/share/classes/java/lang/Version.java.template.html >> >> -Original Message- >> From: Mandy Chung >> Sent: Friday, February 19, 2016 10:48 AM >> To: Iris Clark >> Cc: Ma

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

aintainer, but I'd consider deprecating them. Or just removing them. Thanks, -Chris > Thanks, > iris > (not a Reviewer) > > -Original Message- > From: Chris Hegarty > Sent: Thursday, February 18, 2016 7:53 AM > To: core-libs-dev; Iris Clark > Subject:

RFR [9] 8150162: Move sun.misc.Version to a truly internal package

sun.misc.Version is the core libraries part of a private interface with the JVM to query and set specific JVM version and capabilities, as well as being responsible for setting the system properties for "java.version”, "java.runtime.version", and "java.runtime.name" ( which are generated during

RFR [9] 8150163: JarFileSystem support for MRJARs should use the JDK specific Version API

To support MRJARs, currently JarFileSystem uses sun.misc.Version to retrieve the major version. It should be updated to use the new JDK specific Version API. http://cr.openjdk.java.net/~chegar/8150163/ https://bugs.openjdk.java.net/browse/JDK-8150163 -Chris.

Re: RFR 9: 8149750 Decouple sun.misc.Signal from the base module

On 16 Feb 2016, at 21:38, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Chris, > > Webrev updated in place: >http://cr.openjdk.java.net/~rriggs/webrev-signal-9149750/ Thanks Roger, I’m happy with the source changes. -Chris. > On 2/15/2016 6:22 AM, Chris Hegarty

RFR[9] 8068686: Remove meta-index support

The Modular Run-Time image, integrated in b41, no longer has JAR files, see JEP 220 [1], The meta-index is no longer generated or used. This issue proposes to remove the meta-index support from the runtime and the build. http://cr.openjdk.java.net/~chegar/8068686/

Re: We don't need jdk.internal.ref.Cleaner any more

On 15 Feb 2016, at 20:05, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> On Feb 15, 2016, at 9:06 AM, Uwe Schindler <uschind...@apache.org> wrote: >> >> Hi, >> >>> On 15/02/2016 14:57, Chris Hegarty wrote: >>>> Pe

Re: We don't need jdk.internal.ref.Cleaner any more

ain ). -Chris. On 09/02/16 13:35, Chris Hegarty wrote: Peter, On 08/02/16 10:58, Peter Levart wrote: On 02/08/2016 10:33 AM, Chris Hegarty wrote: On 8 Feb 2016, at 06:27, Alan Bateman<alan.bate...@oracle.com> wrote: On 07/02/2016 22:20, Peter Levart wrote: : If the decision

Re: RFR 9: 8149750 Decouple sun.misc.Signal from the base module

On 12/02/16 17:47, Roger Riggs wrote: Please review moving the functionality of sun.misc.Signal to jdk.internal.misc and creating a wrapper sun.misc.Signal for existing external uses. +++ This time including the hotspot changes to update the target of the upcalls. A new replacement API will be

Re: RFR 9:8148775 : Spec for j.l.ProcessBuilder.Redirect.DISCARD need to be improved

On 12/02/16 23:10, Martin Buchholz wrote: Still looks good! +1. -Chris. On Fri, Feb 12, 2016 at 3:08 PM, Roger Riggs wrote: Thanks, Martin Updated in place. On 2/12/2016 5:48 PM, Martin Buchholz wrote: looks good. The previous line Redirect.DISCARD.file()

RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

sun.misc.LRUCache is a utility class for implementing Least Recently Used Caches. It is only used by j.u.Scanner in the JDK. It should be relocated to a more suitable location, possibly an inner class of Scanner. http://cr.openjdk.java.net/~chegar/8149656/ -Chris.

Re: RFR [9 ] 8149656: Examine usages of sun.misc.LRUCache

Thanks for the feedback. On 12/02/16 16:05, e...@zusammenkunft.net wrote: Since it is only implemented with one anonymous class you could also think about making it a concrete PatternLRUCache On 12/02/16 15:59, Claes Redestad wrote: > +1 > > nits: I guess the class should be made static if

Re: RFR: jsr166 jdk9 integration wave 4

;> * when the action returns. >> * >> - * Unlike method {@link #handle}, this method is not designed >> + * Unlike method {@link #handleAsync(BiFunction,Executor) >> handleAsync}, this method is not designed >> * to translate completion outcome

RFR [9] 8149653: Move sun.misc.InnocuousThread to jdk.internal.misc

In preparation for JEP 260, InnocuousThread should be moved out of the sun.misc package and placed into a more appropriate package where it can be encapsulated. http://cr.openjdk.java.net/~chegar/8149653/ -Chris.

Re: RFR [9] 8149653: Move sun.misc.InnocuousThread to jdk.internal.misc

for consistency of style. I can go either way. I’ll change it before pushing. -Chris. > Roger > > > On 2/11/2016 9:04 AM, Chris Hegarty wrote: >> In preparation for JEP 260, InnocuousThread should be moved out of the >> sun.misc package and placed into a more app

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

Ha, such a seemingly innocuous little perf change has generated much noise ;-) You are of course right. On 11 Feb 2016, at 15:23, Roger Riggs wrote: > Hi Chris, > > The change to preallocate the StringBuffer is fine. > > But I have misgivings about not consuming the

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 11 Feb 2016, at 15:59, Roger Riggs wrote: > Hi Chris, > > ok, but can I suggest using 65535 instead of 16384, it will match the length > of the short encoded strings in writeObjectStream.writeString. That sounds reasonable. So the final change is: diff --git

Re: RFR: 8149601 Update references from "1.9" to "9"

On 11 Feb 2016, at 17:13, Iris Clark wrote: > Hi. > > Please review the following changes to the jaxp and jdk > repositories to fix a few additional references to "1.9". > > Bug > > 8149601 Update references from "1.9" to "9" >

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 10/02/16 13:57, Aleksey Shipilev wrote: Um (Integer.MAX_VALUE + 1L) is still a positive long, you probably want: int ilen = (int)utflen; if (ilen < 0) return ""; int initialCapacity = Math.min(ilen, 16384); ...or: if (utflen < 0 || utflen > Integer.MAX_INT)

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 08/02/16 21:54, Aleksey Shipilev wrote: ... Still, the corrupted stream may call readUTFBody(1L + Integer.MAX_VALUE), that yields initial capacity of -2147483648, which in turn fails StringBuilder(...) with NegativeArraySizeException. But I wonder if that is actually a valid UTF8 input,

Re: RFR: jsr166 jdk9 integration wave 4

6-jdk9-integration-CompletableFuture/CompletionStage.html <http://cr.openjdk.java.net/~chegar/jsr166-jdk9-integration-CompletableFuture/CompletionStage.html> > Sorry for our "endless fiddling"; we do have future changes in mind, > but no spec changes. No problem. -Chris. > On

Re: RFR: jsr166 jdk9 integration wave 4

On 02/02/16 15:23, Martin Buchholz wrote: On Tue, Feb 2, 2016 at 6:37 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: On 1 Feb 2016, at 18:45, Martin Buchholz <marti...@google.com> wrote: After much debate on what to do when CompleteableFuture.whenComplete encounters an excep

Re: RFR (S): 8149529: Adapt SAP copyrights to new company name in jdk repository

On 10/02/16 11:15, Volker Simonis wrote: Hi, can I please have a review for this boring change which simply changes all the SAP copyright messages from "SAP AG" to "SAP SE". The reason for this change is that SAP changed from a German stock corporation (AG) to a European one (SE).

Re: ObjectInputStream SPI

Peter, I, along with others within Oracle, are interested in this general area. We are tied up with other issues at the moment, but I hope to get this within the next couple of weeks. -Chris. On 04/02/16 00:40, Peter Firmstone wrote: In light of recent examples of gadget deserialization

Re: We don't need jdk.internal.ref.Cleaner any more

Peter, On 08/02/16 10:58, Peter Levart wrote: On 02/08/2016 10:33 AM, Chris Hegarty wrote: On 8 Feb 2016, at 06:27, Alan Bateman<alan.bate...@oracle.com> wrote: On 07/02/2016 22:20, Peter Levart wrote: : If the decision to remove sun.misc.Cleaner was partly influenced by the

Re: RFR [9] 8148861: Remove sun.misc.ManagedLocalsThread from jaxws

Receiving some feedback off list, this code needs to be able to run on older releases, so the new Thread constructor, added in JDK 9, should be accessed reflectively. Webrev updated in-place: http://cr.openjdk.java.net/~chegar/8148861/ -Chris. On 8 Feb 2016, at 10:52, Chris Hegarty <chris.h

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

); if (!blkmode) { end = pos = 0; } -Chris. On 8 Feb 2016, at 11:15, Chris Hegarty <chris.hega...@oracle.com> wrote: > Low hanging fruit to avoid unnecessary allocations when deserializing. > readUTF knows the string size ahead of the read a

Re: We don't need jdk.internal.ref.Cleaner any more

On 7 Feb 2016, at 19:01, Jeremy Manson wrote: > Hadoop seems to use sun.misc.Cleaner: > > http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java There is an issue in the Hadoop JIRA

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 8 Feb 2016, at 07:02, Stuart Marks wrote: > On 2/5/16 4:54 PM, David Holmes wrote: >> Regardless of whether I agree with this API or not, it does, as Stuart points >> out, require a JEP and to go through the normal rigorous process of >> determining >> whether an API

Re: We don't need jdk.internal.ref.Cleaner any more

On 8 Feb 2016, at 06:27, Alan Bateman wrote: > > On 07/02/2016 22:20, Peter Levart wrote: >> : >> >> If the decision to remove sun.misc.Cleaner was partly influenced by the >> desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to >> migrate JDK code

RFR [9] 8148861: Remove sun.misc.ManagedLocalsThread from jaxws

Miran, JDK-8056152 added a new constructor to java.lang.Thread for constructing Threads that do not inherit inheritable thread-local initial values. All usages of sun.misc.ManagedLocalsThread in the base module were also replaced with this new constructor. Given there is now a supported API for

RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

Low hanging fruit to avoid unnecessary allocations when deserializing. readUTF knows the string size ahead of the read and can avoid expandCapacity() by constructing the StringBuilder with the expected size. It is an implementation detail, but if the size is larger than Integer.MAX_VALUE, then

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

And of course, this should read... > On 8 Feb 2016, at 15:34, Chris Hegarty <chris.hega...@oracle.com> wrote: > > It was suggested to me off-list that the implementation should choose a > reasonable initial capacity value ,to size the StringBuilder, rather than > the value

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 03/02/16 15:20, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:05 AM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: Hi Roger, It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big mistake.

Re: JDK 9 RFR of JDK-8149003: Mark more jdk_core tests as intermittently failing

s/May/Amy ;-) -Chris. On 4 Feb 2016, at 06:23, Chris Hegarty <chris.hega...@oracle.com> wrote: > Seems reasonable to me May. > > -Chris. > > On 4 Feb 2016, at 06:22, Amy Lu <amy...@oracle.com> wrote: > >> java/net/NetworkInterface/NetworkInterfa

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 03/02/16 15:43, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:20 PM, Thomas Stüfe wrote: On Wed, Feb 3, 2016 at 4:05 AM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: Hi Roger, It will be good to get this into the JDK.

Re: RFR: jsr166 jdk9 integration wave 4

On 1 Feb 2016, at 18:45, Martin Buchholz wrote: > After much debate on what to do when CompleteableFuture.whenComplete > encounters an exception in both the source and the action, we chose > what was acceptable to the most people - add the action's exception to > the source

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 2 Feb 2016, at 16:35, Roger Riggs wrote: : - I agree with Peter, about the permission regarding the thread that executes the consumer. Does it make sense to support a ThreadFactory, or may that is overkill. >>> Using

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 2 Feb 2016, at 16:14, Peter Levart wrote: > Hi Roger, > > On 02/02/2016 04:16 PM, Roger Riggs wrote: >> Hi Peter, >> >> On 2/2/2016 6:44 AM, Peter Levart wrote: >>> >> ... >>> >>> Also if this is to become public API, There's a chance users would want to >>> add

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 1 Feb 2016, at 19:10, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Chris, > > On 2/1/2016 11:47 AM, Chris Hegarty wrote: >> Thank you for taking this on Roger. >> >> An initial question to help my understanding. [ I think I need to >> unders

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

I think this API should be a good replacement for sun.misc.Signal. Some comments: - The second @implNote, referring to s.m.Signal, I assume can be removed? - I agree with Peter, about the permission regarding the thread that executes the consumer. Does it make sense to support a

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Thank you for taking this on Roger. An initial question to help my understanding. [ I think I need to understand this, before I can comment further on the API ] I'm a little confused about how the default handler is supposed to work, so I looked at the implementation and become even more

Re: RFR: 8148626: URI.toURL needs to use protocol Handler to parse file URIs

> On 31 Jan 2016, at 00:58, Claes Redestad wrote: > > Hi, > > On 2016-01-30 19:35, joe darcy wrote: >> Hello, >> >> The change looks okay in that the new code is limited to the jrt protocol. I >> assume the failing test >> >>java/net/URL/B5086147.java >> >>

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

On 29/01/16 14:52, Roger Riggs wrote: Hi Nadeesh, Looks fine, Thanks, Roger On 1/27/2016 11:34 AM, nadeesh tv wrote: Hi all, Thanks for the suggestions. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8141452/webrev.01/ +1 This looks fine. Martin, Doug, I assume you

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

; Thanks for taking care of this issue. > Uwe > > - > Uwe Schindler > uschind...@apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -Original Message----- >> From: Uwe Schindler [mailto:uschind..

Re: RFR: 8147607: Remove test library dependency on sun.security.tools.jarsigner.Main

On 28 Jan 2016, at 15:16, Wang Weijun <weijun.w...@oracle.com> wrote: > Shouldn't you also include the FileOuputStream in try-with-resources? It is. Do you need to refresh your browers? -Chris. > --Max > >> On Jan 28, 2016, at 5:32 PM, Chris Hegarty <chris.h

Re: RFR: 8147607: Remove test library dependency on sun.security.tools.jarsigner.Main

On 28 Jan 2016, at 00:35, Steve Drach wrote: > Please review a small change to the zipfs test library. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8147607 > Webrev: http://cr.openjdk.java.net/~sdrach/8147607/webrev > > This change uses the public

RFR [9] 8148220: Update TEST.groups to include jdk/internal/math and jdk/internal/misc

The test groups, that make up jdk_core, should be updated to include jdk/internal/math and jdk/internal/misc. These updates were overlooked when doing re-orgaziation and cleanup in preparation for JEP 260. diff --git a/test/TEST.groups b/test/TEST.groups --- a/test/TEST.groups +++

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

the webrev as per Alan’s comments and suggestion ( to extend Runnable ). http://cr.openjdk.java.net/~chegar/8148117/ -Chris. On 23 Jan 2016, at 16:36, Alan Bateman <alan.bate...@oracle.com> wrote: > On 23/01/2016 16:16, Chris Hegarty wrote: >> : >> >> Webrev: >

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

<alan.bate...@oracle.com> wrote: > On 26/01/2016 13:55, Chris Hegarty wrote: >> It is wonderful to see the various ideas on this thread about the longer >> term solution to the prompt releasing of direct buffer native memory. I >> do not want to obstruct that ( it is very

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/16 15:47, Alan Bateman wrote: On 25/01/2016 15:38, Chris Hegarty wrote: JOpt Simple [1] is a Java library for parsing command line options. The JDK has several different home-grown versions of command line option-parsing code. Where possible, new and existing tools in the JDK should

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

rnal.joptsimple" be a better name for the module? For consistency, I took the same terse approach applied to the jdk.internal.le module. -Chris. /Claes On 2016-01-25 16:38, Chris Hegarty wrote: JOpt Simple [1] is a Java library for parsing command line options. The JDK has several different

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

module-info.java missing? "jdk.internal.opt" might be ever so slightly misleading, wouldn't "jdk.internal.joptsimple" be a better name for the module? /Claes On 2016-01-25 16:38, Chris Hegarty wrote: JOpt Simple [1] is a Java library for parsing command line options. The JDK h

RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

JOpt Simple [1] is a Java library for parsing command line options. The JDK has several different home-grown versions of command line option-parsing code. Where possible, new and existing tools in the JDK should consider using JOpt Simple. JOpt Simple is being used in a number of tools in project

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

On 25/01/16 16:16, Alan Bateman wrote: On 25/01/2016 16:09, Chris Hegarty wrote: Bringing this into jdk9/dev in the advance looks good. One thing, should we add a README so that we know exactly which version of JOpt Simple this is? Good idea Alan. Added and webrev updated in-place. Thanks

RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

sun.misc.Cleaner was previously listed as a critical internal API in JEP 260 [1], but on further investigation it has been moved to an open issue, for the following reasons: 1) its primary use in the JDK is within NIO direct buffers to release native memory. The base module cannot have a

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

Just catching up… I see no objection to the proposed patch, but the obvious concern ( that is highlighted in JEP 260 ), about the digging into the private internal details of NIO buffers. I think Alan summarized the issues around providing a public API for releasing/unmapping native memory very

Re: JDK RFR of 8147545: Remove sun.misc.ManagedLocalsThread from java.prefs

On 22 Jan 2016, at 20:17, Brian Burkhalter wrote: > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8147545 > Patch:http://cr.openjdk.java.net/~bpb/8147545/webrev.00/ Looks good to me. Thanks Brian. -Chris. >

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

Claes, On 22/01/16 12:07, Claes Redestad wrote: On 2016-01-22 12:56, Claes Redestad wrote: On 2016-01-22 12:53, Alan Bateman wrote: On 22/01/2016 11:34, Claes Redestad wrote: : During testing I discovered that EnumSet was missing a serialVersionUID, which needs to be added. I assume this

Re: RFR (XS): 8148044: Remove Enum[0] constants from EnumSet and EnumMap

> On 22 Jan 2016, at 15:44, Claes Redestad <claes.redes...@oracle.com> wrote: > > > > On 2016-01-22 15:22, Chris Hegarty wrote: >> Claes, >> >> On 22/01/16 12:07, Claes Redestad wrote: >>> On 2016-01-22 12:56, Claes Redestad wrote: >>>&

<    2   3   4   5   6   7   8   9   10   11   >