Re: Array equality, comparison and mismatch

> On 13 Oct 2015, at 12:03, Andrew Haley wrote: > > On 13/10/15 10:22, Paul Sandoz wrote: >> Analysis so far indicate big gains are to be had on larger arrays with >> better or no impact on small arrays if i do the following instead: >> >> if

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Peter, On 15 Oct 2015, at 09:12, Peter Levart wrote: > On 10/14/2015 07:43 PM, Roger Riggs wrote: >> Hi Alan, Mandy, >> >> I looked at a few of the many uses of finalize and the likely changes. >> The zip Inflater and Deflater are relatively simple cases. >> Some

Re: RFR (xs) : 8038502: Deflater.needsInput() should use synchronization

Looks good to me Sean. All other state seems to be accessed when holding zsRef. -Chris. On 15 Oct 2015, at 10:02, Seán Coffey wrote: > bug report : https://bugs.openjdk.java.net/browse/JDK-8038502 > > The len instance variable should be read/written while holding the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Roger, On 14 Oct 2015, at 18:43, Roger Riggs wrote: > Hi Alan, Mandy, > > I looked at a few of the many uses of finalize and the likely changes. > The zip Inflater and Deflater are relatively simple cases. > Some finalizers are not used and can be removed. It is not

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Chris, I think this warrants some discussion related to the normal deprecation practice. If there is specified behavior related to finalize, then the behavior has to be replicated using the Cleaner to ensure backward compatibility. It is a spec change (at least a documentation change)

Re: RFR: JDK-8046565: Platform Logger API and Service

On 14 October 2015 at 12:20, Daniel Fuchs wrote: > On 14/10/15 07:21, Mandy Chung wrote: >> Several log methods throws NPE if the level is legible and the parameter >> is null. E.g. >> * @throws NullPointerException if {@code level} is {@code null}, or if the >> level >>

Re: Array equality, comparison and mismatch

On 10/15/2015 11:52 AM, Paul Sandoz wrote: > I would be very interested in your opinion on being able to make > intrinsic on ARM the method ArraysSupport.vectorizedMismatch [1]. Pretty easy, I'm sure. We already have MacroAssembler::string_compare which does essentially the same thing but with

RFR (xs) : 8038502: Deflater.needsInput() should use synchronization

bug report : https://bugs.openjdk.java.net/browse/JDK-8038502 The len instance variable should be read/written while holding the zsRef lock. needsInput() seems to be missing that. Simple change : diff --git a/src/java.base/share/classes/java/util/zip/Deflater.java

RFR (JAXP) : 8081248: Implement JEP 268: XML Catalog API

Hi all, Please help review JEP 268 implementation: https://bugs.openjdk.java.net/browse/JDK-8081248 Catalog specification: https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8081248/webrev/ A Catalog is basically an

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 10/14/2015 07:43 PM, Roger Riggs wrote: Hi Alan, Mandy, I looked at a few of the many uses of finalize and the likely changes. The zip Inflater and Deflater are relatively simple cases. Some finalizers are not used and can be removed. The sun.net.www.MeteredStream example subclasses

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 15 Oct 2015, at 05:00, Xueming Shen wrote: > > I'm not sure if it is a good idea, from performance perspective, to add a > "versionEntry" field into the JarEntry > to support this feature, given most of the jar files might not be > multi-release-jar aware, and

Re: RFC: draft API for JEP 269 Convenience Collection Factories

> On 15 Oct 2015, at 16:28, Stephen Colebourne wrote: > > I've been working on a Java 8 wrapper class around double[] in my day > job, and added the following factory method: > > /** > * Obtains an instance with entries filled using a function. > * > * The

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 10/15/2015 03:21 PM, Roger Riggs wrote: Peter, Chris, Plausible but getting complicated as Chris observed. We can be on the lookout for specific cases in the JDK like that. I expect most can be resolved by specific cooperation between the super/subclasses. How? Such "cooperation" can

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Peter, Chris, Plausible but getting complicated as Chris observed. We can be on the lookout for specific cases in the JDK like that. I expect most can be resolved by specific cooperation between the super/subclasses. The cleanup of each class should *only* be doing cleanup for their own

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 15 Oct 2015, at 14:21, Roger Riggs wrote: > ... > > Also, I've seen a few calls to super.finalize() where there were no finalizers > in any of the superclasses. It would be considered good design to always > include it. > I don't know if the optimization for empty

Re: RFC: draft API for JEP 269 Convenience Collection Factories

I've been working on a Java 8 wrapper class around double[] in my day job, and added the following factory method: /** * Obtains an instance with entries filled using a function. * * The function is passed the array index and returns the value for that index. * * @param size

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

On 10/15/15 3:08 PM, Claes Redestad wrote: On 2015-10-15 23:21, Chris Hegarty wrote: On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: Hello, This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 10/15/15 1:53 AM, Paul Sandoz wrote: On 15 Oct 2015, at 05:00, Xueming Shen wrote: I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry to support this feature, given most of the jar files might not be

Re: [9] RFR(XS): 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific

2015/10/1 10:57 -0700, zoltan.m...@oracle.com: > On 10/01/2015 05:54 PM, mark.reinh...@oracle.com wrote: >> I suggest putting this into jdk.internal.vm.annotation, which is >> also a good place for the ReservedStackAccess annotation envisioned >> in JEP 270 (http://openjdk.java.net/jeps/270). > >

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: > > Hello, > > This does change a bit the semantic of the length check. If the stream would > return more bytes than the zipentry says the new version would ignore them, > the old version was consuming then and then fail the check.

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

On 2015-10-15 23:21, Chris Hegarty wrote: On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: Hello, This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

Copy-pasting the comment I made earlier (internally): >> make/bsd/makefiles/gcc.make: >> >> + ifeq ($(BUILD_STATIC),true) >> + CXXFLAGS += -DSTATIC_BUILD >> + CFLAGS += -DSTATIC_BUILD >> >> Can we use the same name everywhere? > > We were trying to differentiate Makefile options from compile

RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

Hi all, java.util.jar.JarFile could be improved further by using InputStream.readNBytes when there's information in the ZipEntry about the entry size. Webrev: http://cr.openjdk.java.net/~redestad/8139706/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8139706 Testing: verified

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

Hi Bernd, thanks for looking at this! You're right about the semantic change for this patch in isolation, but compared to the previous implementation that used sun.misc.IOUtils the semantics are unchanged (compare with theprevious implementation of JarFiles::getBytes and

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

> On 15 Oct 2015, at 11:08 p.m., Claes Redestad > wrote: > > > On 2015-10-15 23:21, Chris Hegarty wrote: >>> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: >>> >>> Hello, >>> >>> This does change a bit the semantic of the length check. If the stream >>>

Re: RFR [9] 8139706: JarFile.getBytes could use InputStream.readNBytes

Hello, This does change a bit the semantic of the length check. If the stream would return more bytes than the zipentry says the new version would ignore them, the old version was consuming then and then fail the check. However I am not sure if this is relevant. Gruss Bernd --

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

> On Oct 15, 2015, at 11:32 PM, Doug Lea wrote: > > On 10/14/2015 11:53 PM, Gil Tene wrote: >> I agree on the separation between spin-hinting and monitor-like constructs. >> But not so much on the analogy to or use of the term "yield" to describe what >> is intended y spin

Re: RFR: JDK-8046565: Platform Logger API and Service

Hi Stephen, On 15/10/15 12:48, Stephen Colebourne wrote: On 14 October 2015 at 12:20, Daniel Fuchs wrote: On 14/10/15 07:21, Mandy Chung wrote: Several log methods throws NPE if the level is legible and the parameter is null. E.g. * @throws NullPointerException if

Re: [9] RFR 8138838: docs cleanup for java.desktop

Hi Alexander, Since you are doing cosmetic changes, could please wrap the amended lines to 80 characters per line? Also some notes: MultiResolutionImage.java interface has a mix of verbose/implicit method modifiers. It would be nice to reduce it to the uniform style. MenuComponent.java :

RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. https://bugs.openjdk.java.net/browse/JDK-8136556 The change involves: 1. Producing “.a” archives for each native libraries. 2.