Re: [8] WXP minor fixes for a cleaner compile of c code

I see you were directed here from the build-dev list. Unfortunately these are core library fixes, not hotspot fixes. I’ve added core-libs and bcc:d hotspot-dev. Thanks, /Staffan On 11 dec 2013, at 07:34, Francis ANDRE wrote: > > Hi > > Below are some warnings produced by the build of jdk8.

RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

/Hi everyone I am working on bug JDK-7168267 . Root Cause: - Per Stuart's comment, this is a clean up bug. Suggested Fix: - Will use timeout to replace loop. - Also I am fixing two test's performance java/rmi/activation/Activatable/forceLogSna

Re: RFR: 8029944: (xs) Primitive Stream reduce method documentation pseudo code misidentifies apply method

On 12/10/2013 5:05 PM, Mike Duigou wrote: Hello all; This is a documentation only fix for a bug reported by Michael McMahon. The reduce methods of the primitive streams classes currently reference an "apply" method rather than the appropriate applyAsInt, applyAsLong or applyAsDouble methods.

RFR: 8029944: (xs) Primitive Stream reduce method documentation pseudo code misidentifies apply method

Hello all; This is a documentation only fix for a bug reported by Michael McMahon. The reduce methods of the primitive streams classes currently reference an "apply" method rather than the appropriate applyAsInt, applyAsLong or applyAsDouble methods. http://cr.openjdk.java.net/~mduigou/JDK-802

Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)

I have added tests and documentation for the other methods. http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/ The documentation for some of the methods is ambiguous about how many access events are generated. For LRU cache is OK but other cases (counting based eviction) may care about t

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

On 10/12/2013 19:20, Phil Race wrote: > was trusted to bring up a top-level winodw. It no longer has a use What's a winodw ? :-) Thanks, I'll fix that. "It no longer has a use" suggests it does nothing so might be better phrased as "no longer the recommended or sole way to perform this chec

Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)

I believe C2 compiler is more aggressive about inlining, and will inline hot methods over the 35 bytes limit. I guess interpreter and C1 (and other JVMs, potentially) may get impacted though. In this case, the issue may be more about the fact that getOrDefault() is virtual and not so much about b

Re: Map.forEach

On 12/10/2013 01:15 PM, Martin Buchholz wrote: Perhaps Doug could provide history on the intent of ConcurrentMap. See the package-level docs in java.util.concurrent that compare Hashtable to ConcurrentMap, implying that it might not be a good idea to now retrospectively declare Hashtable as a C

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

> was trusted to bring up a top-level winodw. It no longer has a use What's a winodw ? :-) "It no longer has a use" suggests it does nothing so might be better phrased as "no longer the recommended or sole way to perform this check and is superseded by .. " Is there a CCC for this ? It seem

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

Alan, The change looks good. A minor one - in the class description of java.lang.SecurityManager, I suggest to remove the references to java.awt.AWTPermission line 143 and 214. Mandy On 12/10/2013 5:51 AM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager method

Re: Theoretical data race on java.util.logging.Handler.sealed

On 12/10/2013 12:48 AM, Alan Bateman wrote: On 10/12/2013 04:13, Mandy Chung wrote: On 12/8/2013 11:19 AM, Peter Levart wrote: : You're right, doPrivileged() is a more straight-forward approach than 'sealed' variable. Since this might only be considered for inclusion in JDK9 when lambdas

Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

Looks good. Happy to see these methods finally removed for a clean jdk modularization! Mandy On 12/10/2013 3:06 AM, Alan Bateman wrote: (This one is for the jdk9-dev forest once it is created) The addPropertyChangeListener and removePropertyChangeListener methods defined by Pack200.{Packer

Re: RFR: JDK-8022219, Intermittent test failures in java/util/zip/ZipFile

Hi Alan and Chris, Thanks for your review. Unfortunately, my jtreg is still an old version. And when I tried to use /lib/testlibrary, my jprt job also failed. -Dan On 12/10/2013 03:04 AM, Chris Hegarty wrote: On 10 Dec 2013, at 09:10, Alan Bateman wrote: On 08/12/2013 17:29, Dan Xu wrote

Re: Map.forEach

On Dec 10 2013, at 01:06 , Paul Sandoz wrote: > On Dec 10, 2013, at 5:14 AM, Martin Buchholz wrote: >> >> Hmmm... it was time that I studied Map.forEach I see you convert to >> ISE to CME ... >> >> (Synchronized maps (like Hashtable) do not implement ConcurrentMap. Is >> that a bug?) >>

Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)

I considered it but was worried that the combined size would prevent inlining of the method. The getOrDefault method is currently 33 bytes long which is right at the common borderline for inlining. It does seem a shame to duplicate the code but I couldn't be confident I wouldn't degrade performa

Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

Hi Alan: (This one is for the jdk9-dev forest once it is created) The addPropertyChangeListener and removePropertyChangeListener methods defined by Pack200.{Packer,Unpacker} and LogManager methods are deprecated and flagged with a warning that they "will be removed in a future release". Thi

8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we changed the java.awt.Window and Toolkit methods

Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

On 12/10/13 12:06 PM, Alan Bateman wrote: (This one is for the jdk9-dev forest once it is created) The addPropertyChangeListener and removePropertyChangeListener methods defined by Pack200.{Packer,Unpacker} and LogManager methods are deprecated and flagged with a warning that they "will be remo

8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

(This one is for the jdk9-dev forest once it is created) The addPropertyChangeListener and removePropertyChangeListener methods defined by Pack200.{Packer,Unpacker} and LogManager methods are deprecated and flagged with a warning that they "will be removed in a future release". This is highli

Re: RFR: JDK-8022219, Intermittent test failures in java/util/zip/ZipFile

On 10 Dec 2013, at 09:10, Alan Bateman wrote: > On 08/12/2013 17:29, Dan Xu wrote: >> Hi All, >> >> Please review the fix towards the intermittent test failure in >> java/util/zip/ZipFile. It is a similar failure that I encountered before, >> due to the interferences from other software or da

Re: RFR: JDK-8022219, Intermittent test failures in java/util/zip/ZipFile

On 08/12/2013 17:29, Dan Xu wrote: Hi All, Please review the fix towards the intermittent test failure in java/util/zip/ZipFile. It is a similar failure that I encountered before, due to the interferences from other software or daemon services in Windows platforms. The fix is to use the metho

Re: Map.forEach

On Dec 10, 2013, at 5:14 AM, Martin Buchholz wrote: > > Hmmm... it was time that I studied Map.forEach I see you convert to > ISE to CME ... > > (Synchronized maps (like Hashtable) do not implement ConcurrentMap. Is > that a bug?) > > Imagine a third party implementation of a synchronized

Re: Theoretical data race on java.util.logging.Handler.sealed

On 10/12/2013 04:13, Mandy Chung wrote: On 12/8/2013 11:19 AM, Peter Levart wrote: : You're right, doPrivileged() is a more straight-forward approach than 'sealed' variable. Since this might only be considered for inclusion in JDK9 when lambdas are already a tried technology, how do you fee

Re: MappedFile call sync occur Cannot allocate memory

On 10/12/2013 00:05, fuyou wrote: I write a MappedFile ,and a task call sync write to disk. but occur : java.io.IOException: Cannot allocate memory at java.nio.MappedByteBuffer.force0(Native Method) at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:154) the os is Red Hat Ente