Re: RFR 8080225: FileInputStream cleanup should be improved

Hello, if UnreferencedRAFClosesFd.java is supposed to test the behavior of unreachable ˋrafˋ I wonder how it works as it hold on raf with a reachabilityFence at the end of the main method? Maybe that asks for an explanative comment? Gruss Bernd -- http://bernd.eckenfels.net

RFR: 8187954 Update JAX-WS RI integration to latest version

Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17, 1:18 PM, Peter Levart wrote: Hi Sherman, I looked into ZipFile as promised. One thing I noticed is that FinalizeZipFile.java test fails compilation: test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java:49: error: unreported exception Throwable; must be caught or declared to be

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17, 1:18 PM, Peter Levart wrote: Hi Sherman, putStream> streams = Collections.newSetFromMap(new WeakHashMap<>()); I also noticed that it is useless to test whether the inflater is ended() when obtaining it from or releasing it into cache if the code keeps the invariant that it never

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Very cool, i learn something today :) Rémi - Mail original - > De: "mandy chung" > À: "core-libs-dev" > Envoyé: Vendredi 29 Septembre 2017 23:45:18 > Objet: Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not >

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17 2:38 PM, Peter Levart wrote: I think the hotspot has an optimization and detects that finalize() has no bytecodes and treats the object as not needing finalization. http://hg.openjdk.java.net/jdk10/master/file/7d67bb6b0599/src/hotspot/share/classfile/classFileParser.cpp#l4250   //

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 09/29/17 23:23, Remi Forax wrote: - Mail original - De: "Peter Levart" À: "Roger Riggs" , "core-libs-dev" Envoyé: Vendredi 29 Septembre 2017 23:14:33 Objet: Re: RFR JDK-8185582, Update Zip

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

- Mail original - > De: "Peter Levart" > À: "Roger Riggs" , "core-libs-dev" > > Envoyé: Vendredi 29 Septembre 2017 23:14:33 > Objet: Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not >

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 09/29/17 23:11, Peter Levart wrote: Hi Roger, On 09/29/17 22:55, Roger Riggs wrote: fyi, The proposed[1]  changes to FileInputStream and FileOutputStream remove the finalize method exposing Object.finalize (throws Throwable) to subclasses.  We may need retain the finalize methods (with

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17, 1:58 PM, mandy chung wrote: On 9/27/17 4:41 PM, Xueming Shen wrote: Thanks Mandy! I removed the ln#657-#663, and updated the @apiNote in deflter, inflater and zipfile accordingly, mainly combined your comment and the approach for the fis/fo. they are "simpler" and straightforward

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Roger, On 09/29/17 22:55, Roger Riggs wrote: fyi, The proposed[1]  changes to FileInputStream and FileOutputStream remove the finalize method exposing Object.finalize (throws Throwable) to subclasses.  We may need retain the finalize methods (with empty bodies) to mitigate source

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

> De: "Peter Levart" > À: "Remi Forax" , "mandy chung" > Cc: "Xueming Shen" , "core-libs-dev" > > Envoyé: Vendredi 29 Septembre 2017 22:56:26 > Objet: Re: RFR JDK-8185582,

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/27/17 4:41 PM, Xueming Shen wrote: Thanks Mandy! I removed the ln#657-#663, and updated the @apiNote in deflter, inflater and zipfile accordingly, mainly combined your comment and the approach for the fis/fo. they are "simpler" and straightforward now, at least for me.

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Remi, On 09/29/17 22:49, Remi Forax wrote: - Mail original - De: "mandy chung" À: "Peter Levart" , "Xueming Shen" , "core-libs-dev" Envoyé: Vendredi 29 Septembre 2017 22:34:52

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

fyi, The proposed[1]  changes to FileInputStream and FileOutputStream remove the finalize method exposing Object.finalize (throws Throwable) to subclasses.  We may need retain the finalize methods (with empty bodies) to mitigate source compatibility. Roger [1]

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17 1:49 PM, Remi Forax wrote: On 9/27/17 2:31 AM, Peter Levart wrote: Up to a point where 'this' is dereferenced to obtain the 'zsRef' value (line 261), the Deflater instance is reachable. But after that, even ensureOpen() may be inlined and 'this' is not needed any more. After that

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 09/29/17 22:34, mandy chung wrote: On 9/27/17 2:31 AM, Peter Levart wrote: Up to a point where 'this' is dereferenced to obtain the 'zsRef' value (line 261), the Deflater instance is reachable. But after that, even ensureOpen() may be inlined and 'this' is not needed any more. After

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17 1:49 PM, Xueming Shen wrote: On 9/29/17, 1:18 PM, Peter Levart wrote: Hi Sherman, I looked into ZipFile as promised. One thing I noticed is that FinalizeZipFile.java test fails compilation: test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java:49: error: unreported exception

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

- Mail original - > De: "mandy chung" > À: "Peter Levart" , "Xueming Shen" > , "core-libs-dev" > > Envoyé: Vendredi 29 Septembre 2017 22:34:52 > Objet: Re: RFR JDK-8185582, Update

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/29/17, 1:18 PM, Peter Levart wrote: Hi Sherman, I looked into ZipFile as promised. One thing I noticed is that FinalizeZipFile.java test fails compilation: test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java:49: error: unreported exception Throwable; must be caught or declared to be

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 9/27/17 2:31 AM, Peter Levart wrote: Up to a point where 'this' is dereferenced to obtain the 'zsRef' value (line 261), the Deflater instance is reachable. But after that, even ensureOpen() may be inlined and 'this' is not needed any more. After that point, obtaining zsRef.address() and

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, I looked into ZipFile as promised. One thing I noticed is that FinalizeZipFile.java test fails compilation: test/jdk/java/util/zip/ZipFile/FinalizeZipFile.java:49: error: unreported exception Throwable; must be caught or declared to be thrown super.finalize();

Re: RFR 8080225: FileInputStream cleanup should be improved

Hi Roger, Looks good overall; total nitpicks here: FileInputStream (similar story in FileOutputStream) 48-49: “explicitly" is used twice 53: could probably drop “explicitly” here altogether. The “Shd” in a couple of test names is kind of annoying; perhaps s/Shd/Should/ ? Copyright dates are

RFR 8080225: FileInputStream cleanup should be improved

Replacing finalizers in FileInputStream, FileOutputStream, and adding cleanup to RandomAccessFile and NIO File Channels with Cleaner based implementations required changes to FileDescriptor. The specification of FileInputStream and FileOutputStream is changed to remove the finalizer behavior

Re: RFR: jsr166 jdk10 integration wave 3

On Wed, Sep 27, 2017 at 1:44 PM, Doug Lea wrote: > On 09/27/2017 02:38 PM, Paul Sandoz wrote: > >> Looks good, i just need to look a little more closely at the > ConcurrentSkipListMap changes. > >> > > > > > > 328 * Note that, with VarHandles, a boolean result of > >

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

On 2017-09-28 16:22, Jason Mehrens wrote: Admittedly this is more of a Claes Redestad faster boot up type change but, the use of the AlphaDecimalComparator constructor in Comparator might force the bytecode verifier to force load AlphaDecimalComparator just to check the return type. If you

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Makes sense on the sub-sequences having to be string. Looks good. Jason From: Ivan Gerasimov Sent: Thursday, September 28, 2017 3:19 PM To: Jason Mehrens; core-libs-dev Subject: Re: [10] RFR 8134512 : provide Alpha-Numeric

Re: RFR(XS): 8188135: Fix VS 2010 build after "8187631: Refactor FileDescriptor close implementation"

+1 On 9/29/2017 4:43 AM, Alan Bateman wrote: On 29/09/2017 09:05, Lindenmaier, Goetz wrote: Hi, please review this tiny fix for the build with Visual Studio 2010: http://cr.openjdk.java.net/~goetz/wr17/8188135-winBuild/webrev.01/ Looks okay although I thought VS 2010 was dropped a long

RE: RFR(XS): 8188135: Fix VS 2010 build after "8187631: Refactor FileDescriptor close implementation"

Thanks, Alan! Unfotunately SAP has to stick to VS 2010 a while. Best regards, Goetz. > -Original Message- > From: Alan Bateman [mailto:alan.bate...@oracle.com] > Sent: Freitag, 29. September 2017 10:43 > To: Lindenmaier, Goetz ; core-libs- >

RE: RFR(XS): 8188135: Fix VS 2010 build after "8187631: Refactor FileDescriptor close implementation"

Thanks David! ... at least SAP got rid of gcc 4.1.2 :) Best regards, Goetz. > -Original Message- > From: David Holmes [mailto:david.hol...@oracle.com] > Sent: Freitag, 29. September 2017 10:33 > To: Lindenmaier, Goetz ; core-libs- > d...@openjdk.java.net >

Re: RFR(XS): 8188135: Fix VS 2010 build after "8187631: Refactor FileDescriptor close implementation"

On 29/09/2017 09:05, Lindenmaier, Goetz wrote: Hi, please review this tiny fix for the build with Visual Studio 2010: http://cr.openjdk.java.net/~goetz/wr17/8188135-winBuild/webrev.01/ Looks okay although I thought VS 2010 was dropped a long time ago. -Alan

Re: RFR(XS): 8188135: Fix VS 2010 build after "8187631: Refactor FileDescriptor close implementation"

On 29/09/2017 6:05 PM, Lindenmaier, Goetz wrote: Hi, please review this tiny fix for the build with Visual Studio 2010: http://cr.openjdk.java.net/~goetz/wr17/8188135-winBuild/webrev.01/ Looks fine. One day we'll stop getting bitten by archaic compilers :( Cheers, David Best regards,

RFR(XS): 8188135: Fix VS 2010 build after "8187631: Refactor FileDescriptor close implementation"

Hi, please review this tiny fix for the build with Visual Studio 2010: http://cr.openjdk.java.net/~goetz/wr17/8188135-winBuild/webrev.01/ Best regards, Goetz.