From Alan.Bateman at oracle.com Thu Jan 2 17:49:05 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Jan 2020 17:49:05 +0000 Subject: [15] RFR: 8236595: Add more comments about how to setup simulated NVRAM before run java/nio/MappedByteBuffer/PmemTest.java In-Reply-To: <0A0D0788-D935-463D-9257-552D56BD4F8D@oracle.com> References: <0A0D0788-D935-463D-9257-552D56BD4F8D@oracle.com> Message-ID: Looks okay to me but probably best if Andrew Dinn reviews (as the test is part of JEP 352). -Alan On 31/12/2019 05:18, Chris Yin wrote: > Please have a review for below comments change only to manual test java/nio/MappedByteBuffer/PmemTest.java, the motivation is to make the pre-config steps for setup simulated NVRAM device more clear to newbie, thanks > > JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8236595 > Webrev: http://cr.openjdk.java.net/~xyin/8236595/webrev.00/ > > > Patch: > --- old/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 12:47:34.000000000 +0800 > +++ new/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 12:47:34.000000000 +0800 > @@ -50,10 +50,20 @@ > * > * https://developers.redhat.com/blog/2016/12/05/configuring-and-using-persistent-memory-rhel-7-3/ > * https://nvdimm.wiki.kernel.org/ > - * TL;DR: add "memmap=1G!4G" to /etc/default/grub, > - * then grub2-mkconfig -o /boot/grub2/grub.cfg and reboot > + * TL;DR: add "memmap=1G!4G" to /etc/default/grub, eg. GRUB_CMDLINE_LINUX="memmap=1G!4G" > + * then ("sudo" may required) > + * for RHEL(BIOS-based): grub2-mkconfig -o /boot/grub2/grub.cfg > + * for RHEL(UEFI-based): grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg > + * for Ubuntu: update-grub2 > + * finally reboot > + * after the host been rebooted, a new /dev/pmem{N} device should exist, > + * naming conversion starts at /dev/pmem0 > + * > + * Prepare test directory follow below commands, "sudo" may required > + * (if ndctl or mkfs.xfs not exist, install ndctl or xfsprogs package first) > + * (for RHEL8, when call mkfs.xfs, specify the -m reflink=0 option to disable reflink feature) > * > - * ndctl create-namespace * -f -e namespace0.0 -m memory -M mem > + * ndctl create-namespace -f -e namespace0.0 -m memory -M mem > * mkdir /mnt/pmem > * mkfs.xfs -f /dev/pmem0; mount -o dax /dev/pmem0 /mnt/pmem/ > * mkdir /mnt/pmem/test; chmod a+rwx /mnt/pmem/test > > Regards, > Chris > From xu.y.yin at oracle.com Fri Jan 3 04:53:31 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 3 Jan 2020 12:53:31 +0800 Subject: [15] RFR: 8236595: Add more comments about how to setup simulated NVRAM before run java/nio/MappedByteBuffer/PmemTest.java In-Reply-To: References: <0A0D0788-D935-463D-9257-552D56BD4F8D@oracle.com> Message-ID: <343960B4-44B7-49E2-9211-2B213CDA2755@oracle.com> Thank you, Alan. Sure, I will wait to see if any comments/suggestions from Andrew. Thanks, Chris > On 3 Jan 2020, at 1:49 AM, Alan Bateman wrote: > > Looks okay to me but probably best if Andrew Dinn reviews (as the test is part of JEP 352). > > -Alan > > On 31/12/2019 05:18, Chris Yin wrote: >> Please have a review for below comments change only to manual test java/nio/MappedByteBuffer/PmemTest.java, the motivation is to make the pre-config steps for setup simulated NVRAM device more clear to newbie, thanks >> >> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8236595 >> Webrev: http://cr.openjdk.java.net/~xyin/8236595/webrev.00/ >> >> >> Patch: >> --- old/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 12:47:34.000000000 +0800 >> +++ new/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 12:47:34.000000000 +0800 >> @@ -50,10 +50,20 @@ >> * >> * https://developers.redhat.com/blog/2016/12/05/configuring-and-using-persistent-memory-rhel-7-3/ >> * https://nvdimm.wiki.kernel.org/ >> - * TL;DR: add "memmap=1G!4G" to /etc/default/grub, >> - * then grub2-mkconfig -o /boot/grub2/grub.cfg and reboot >> + * TL;DR: add "memmap=1G!4G" to /etc/default/grub, eg. GRUB_CMDLINE_LINUX="memmap=1G!4G" >> + * then ("sudo" may required) >> + * for RHEL(BIOS-based): grub2-mkconfig -o /boot/grub2/grub.cfg >> + * for RHEL(UEFI-based): grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg >> + * for Ubuntu: update-grub2 >> + * finally reboot >> + * after the host been rebooted, a new /dev/pmem{N} device should exist, >> + * naming conversion starts at /dev/pmem0 >> + * >> + * Prepare test directory follow below commands, "sudo" may required >> + * (if ndctl or mkfs.xfs not exist, install ndctl or xfsprogs package first) >> + * (for RHEL8, when call mkfs.xfs, specify the -m reflink=0 option to disable reflink feature) >> * >> - * ndctl create-namespace * -f -e namespace0.0 -m memory -M mem >> + * ndctl create-namespace -f -e namespace0.0 -m memory -M mem >> * mkdir /mnt/pmem >> * mkfs.xfs -f /dev/pmem0; mount -o dax /dev/pmem0 /mnt/pmem/ >> * mkdir /mnt/pmem/test; chmod a+rwx /mnt/pmem/test >> >> Regards, >> Chris >> > From adinn at redhat.com Fri Jan 3 10:49:47 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 3 Jan 2020 10:49:47 +0000 Subject: [15] RFR: 8236595: Add more comments about how to setup simulated NVRAM before run java/nio/MappedByteBuffer/PmemTest.java In-Reply-To: References: <0A0D0788-D935-463D-9257-552D56BD4F8D@oracle.com> Message-ID: <4fdca689-f1db-6bc6-b90b-a2b3604d3a46@redhat.com> Hi Chris, On 02/01/2020 17:49, Alan Bateman wrote: > Looks okay to me but probably best if Andrew Dinn reviews (as the test > is part of JEP 352). Yes, thanks for making this improvement, Chris (especially removing the spurious wildcard arg to nodectl). The patch is fine by me. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill > On 31/12/2019 05:18, Chris Yin wrote: >> Please have a review for below comments change only to manual test >> java/nio/MappedByteBuffer/PmemTest.java, the motivation is to make the >> pre-config steps for setup simulated NVRAM device more clear to >> newbie, thanks >> >> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8236595 >> Webrev: http://cr.openjdk.java.net/~xyin/8236595/webrev.00/ >> >> >> Patch: >> --- old/test/jdk/java/nio/MappedByteBuffer/PmemTest.java??? 2019-12-31 >> 12:47:34.000000000 +0800 >> +++ new/test/jdk/java/nio/MappedByteBuffer/PmemTest.java??? 2019-12-31 >> 12:47:34.000000000 +0800 >> @@ -50,10 +50,20 @@ >> ?? * >> ?? * >> https://developers.redhat.com/blog/2016/12/05/configuring-and-using-persistent-memory-rhel-7-3/ >> >> ?? * https://nvdimm.wiki.kernel.org/ >> - * TL;DR: add "memmap=1G!4G" to /etc/default/grub, >> - *??????? then grub2-mkconfig -o /boot/grub2/grub.cfg and reboot >> + * TL;DR: add "memmap=1G!4G" to /etc/default/grub, eg. >> GRUB_CMDLINE_LINUX="memmap=1G!4G" >> + *??????? then ("sudo" may required) >> + *????????? for RHEL(BIOS-based): grub2-mkconfig -o /boot/grub2/grub.cfg >> + *????????? for RHEL(UEFI-based): grub2-mkconfig -o >> /boot/efi/EFI/redhat/grub.cfg >> + *????????? for Ubuntu: update-grub2 >> + *??????? finally reboot >> + *??????? after the host been rebooted, a new /dev/pmem{N} device >> should exist, >> + *??????? naming conversion starts at /dev/pmem0 >> + * >> + *? Prepare test directory follow below commands, "sudo" may required >> + *? (if ndctl or mkfs.xfs not exist, install ndctl or xfsprogs >> package first) >> + *? (for RHEL8, when call mkfs.xfs, specify the -m reflink=0 option >> to disable reflink feature) >> ?? * >> - *? ndctl create-namespace? * -f -e namespace0.0 -m memory -M mem >> + *? ndctl create-namespace -f -e namespace0.0 -m memory -M mem >> ?? *? mkdir /mnt/pmem >> ?? *? mkfs.xfs -f /dev/pmem0; mount -o dax /dev/pmem0 /mnt/pmem/ >> ?? *? mkdir /mnt/pmem/test; chmod a+rwx /mnt/pmem/test >> >> Regards, >> Chris >> From xu.y.yin at oracle.com Mon Jan 6 03:39:51 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Mon, 6 Jan 2020 11:39:51 +0800 Subject: [15] RFR: 8236595: Add more comments about how to setup simulated NVRAM before run java/nio/MappedByteBuffer/PmemTest.java In-Reply-To: <4fdca689-f1db-6bc6-b90b-a2b3604d3a46@redhat.com> References: <0A0D0788-D935-463D-9257-552D56BD4F8D@oracle.com> <4fdca689-f1db-6bc6-b90b-a2b3604d3a46@redhat.com> Message-ID: Thank you Andrew. Pushed. Regards, Chris > On 3 Jan 2020, at 6:49 PM, Andrew Dinn wrote: > > Hi Chris, > > On 02/01/2020 17:49, Alan Bateman wrote: >> Looks okay to me but probably best if Andrew Dinn reviews (as the test >> is part of JEP 352). > > Yes, thanks for making this improvement, Chris (especially removing the > spurious wildcard arg to nodectl). The patch is fine by me. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > >> On 31/12/2019 05:18, Chris Yin wrote: >>> Please have a review for below comments change only to manual test >>> java/nio/MappedByteBuffer/PmemTest.java, the motivation is to make the >>> pre-config steps for setup simulated NVRAM device more clear to >>> newbie, thanks >>> >>> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8236595 >>> Webrev: http://cr.openjdk.java.net/~xyin/8236595/webrev.00/ >>> >>> >>> Patch: >>> --- old/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 >>> 12:47:34.000000000 +0800 >>> +++ new/test/jdk/java/nio/MappedByteBuffer/PmemTest.java 2019-12-31 >>> 12:47:34.000000000 +0800 >>> @@ -50,10 +50,20 @@ >>> * >>> * >>> https://developers.redhat.com/blog/2016/12/05/configuring-and-using-persistent-memory-rhel-7-3/ >>> >>> * https://nvdimm.wiki.kernel.org/ >>> - * TL;DR: add "memmap=1G!4G" to /etc/default/grub, >>> - * then grub2-mkconfig -o /boot/grub2/grub.cfg and reboot >>> + * TL;DR: add "memmap=1G!4G" to /etc/default/grub, eg. >>> GRUB_CMDLINE_LINUX="memmap=1G!4G" >>> + * then ("sudo" may required) >>> + * for RHEL(BIOS-based): grub2-mkconfig -o /boot/grub2/grub.cfg >>> + * for RHEL(UEFI-based): grub2-mkconfig -o >>> /boot/efi/EFI/redhat/grub.cfg >>> + * for Ubuntu: update-grub2 >>> + * finally reboot >>> + * after the host been rebooted, a new /dev/pmem{N} device >>> should exist, >>> + * naming conversion starts at /dev/pmem0 >>> + * >>> + * Prepare test directory follow below commands, "sudo" may required >>> + * (if ndctl or mkfs.xfs not exist, install ndctl or xfsprogs >>> package first) >>> + * (for RHEL8, when call mkfs.xfs, specify the -m reflink=0 option >>> to disable reflink feature) >>> * >>> - * ndctl create-namespace * -f -e namespace0.0 -m memory -M mem >>> + * ndctl create-namespace -f -e namespace0.0 -m memory -M mem >>> * mkdir /mnt/pmem >>> * mkfs.xfs -f /dev/pmem0; mount -o dax /dev/pmem0 /mnt/pmem/ >>> * mkdir /mnt/pmem/test; chmod a+rwx /mnt/pmem/test >>> >>> Regards, >>> Chris >>> > From Alan.Bateman at oracle.com Mon Jan 6 11:22:26 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Jan 2020 11:22:26 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> <8c8a61c5-5aab-9202-e285-f4b9258e9d16@oracle.com> Message-ID: <015becc7-dd05-14df-6bdd-807649ab6456@oracle.com> On 30/12/2019 22:48, Langer, Christoph wrote: > Hi Alan, > > I checked... Although AIX documentation only refers to IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP, as per: https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/apis/ssocko.htm we can find this in netinet/in.h in both, AIX 7.1 and AIX 7.2: > > #define IPV6_ADD_MEMBERSHIP IP_ADD_MEMBERSHIP > #define IPV6_JOIN_GROUP IP_ADD_MEMBERSHIP > #define IPV6_DROP_MEMBERSHIP IP_DROP_MEMBERSHIP > #define IPV6_LEAVE_GROUP IP_DROP_MEMBERSHIP > > So, both symbols are defined and to me it seems fine to drop their (conditional) definition from Net.c > Thanks for checking. Would you have time to check one more thing? As part of JDK-8236410 I want to improve the underlying join/drop/block/unblock so that we use the protocol independent MCAST_XXXX socket options where possible. I have an initial patch [1] that should be good enough to try if you have time. My guess is that USE_MCAST_XXXX should be defined on AIX. Also I suspect Net.canJoin6WithV4Group should return true. It has historically returned false on AIX which means that a DatagramChannel to an IPv6 socket cannot join IPv4 multicast groups. The spec allows tolerates this but it will become an issue in the future once legacy MulticastSocket is switched to use a DatagramChannel. -Alan [1] http://cr.openjdk.java.net/~alanb/8236410/webrev/ From brian.burkhalter at oracle.com Tue Jan 7 15:44:27 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Jan 2020 07:44:27 -0800 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled Message-ID: This issue [1] is caused by using privateLookupIn() outside a privileged block. The patch [2] fixes this. The added test fails without the source patch but passes with it. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8236582 [2] http://cr.openjdk.java.net/~bpb/8236582/webrev.00/ From Alan.Bateman at oracle.com Tue Jan 7 15:55:57 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Jan 2020 15:55:57 +0000 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: References: Message-ID: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> On 07/01/2020 15:44, Brian Burkhalter wrote: > This issue [1] is caused by using privateLookupIn() outside a privileged block. The patch [2] fixes this. The added test fails without the source patch but passes with it. > Thanks for picking this up, it's a small regression from JEP 352. The change to ExtendedMapMode looks good. I think the test should be in the FileChannel directory with the other tests for FileChannel.map. The test should close the FileChannel (try-with-resources should be best here). -Alan From brian.burkhalter at oracle.com Tue Jan 7 18:19:08 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Jan 2020 10:19:08 -0800 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> Message-ID: <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> > On Jan 7, 2020, at 7:55 AM, Alan Bateman wrote: > > On 07/01/2020 15:44, Brian Burkhalter wrote: >> This issue [1] is caused by using privateLookupIn() outside a privileged block. The patch [2] fixes this. The added test fails without the source patch but passes with it. >> > Thanks for picking this up, it's a small regression from JEP 352. The change to ExtendedMapMode looks good. I think the test should be in the FileChannel directory with the other tests for FileChannel.map. Agreed. Maybe the test could have a better name, too. > The test should close the FileChannel (try-with-resources should be best here). Above fixed here: http://cr.openjdk.java.net/~bpb/8236582/webrev.01/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 7 18:44:00 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Jan 2020 18:44:00 +0000 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> Message-ID: On 07/01/2020 18:19, Brian Burkhalter wrote: > : > > Agreed. Maybe the test could have a better name, too. Right, it probably should be something like MapWithSecurityManager. Also the @summary should probably say that it tests the map method when running with a security manager as the test is not a test for an extended map mode. -Alan From brian.burkhalter at oracle.com Tue Jan 7 19:35:15 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 7 Jan 2020 11:35:15 -0800 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> Message-ID: <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> > On Jan 7, 2020, at 10:44 AM, Alan Bateman wrote: > > On 07/01/2020 18:19, Brian Burkhalter wrote: >> : >> >> Agreed. Maybe the test could have a better name, too. > Right, it probably should be something like MapWithSecurityManager. Also the @summary should probably say that it tests the map method when running with a security manager as the test is not a test for an extended map mode. So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 7 20:25:30 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Jan 2020 20:25:30 +0000 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> Message-ID: <4dec5cb5-f9c7-b757-29e3-11634d0d6cd4@oracle.com> On 07/01/2020 19:35, Brian Burkhalter wrote: > > So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/. > > Thanks for the updates, this version looks good to me. -Alan From chris.hegarty at oracle.com Wed Jan 8 12:20:10 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 8 Jan 2020 12:20:10 +0000 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> Message-ID: <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> Brian, > On 7 Jan 2020, at 19:35, Brian Burkhalter wrote: > > ... > > So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/ . The source changes look good. The test should be run in othervm mode, since it depends on triggering the loading of ExtendedMapMode when a security manager is present - which is not guaranteed to be the case as the test stands. For example, the test passes ( without the fix ) when I run it with all the other tests in test/jdk/java/nio/channels/FileChannel/ and `-conc:1 -agentvm` - since ExtendedMapMode is loaded from a previous test run in the same agent. * @run main/othervm MapWithSecurityManager -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jan 8 16:44:32 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Jan 2020 08:44:32 -0800 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> Message-ID: <51EC6568-3ECD-45FC-9160-7E6FDF5B3538@oracle.com> > On Jan 8, 2020, at 4:20 AM, Chris Hegarty wrote: > >> So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/ . > > The source changes look good. > > The test should be run in othervm mode, since it depends on triggering > the loading of ExtendedMapMode when a security manager is present - > which is not guaranteed to be the case as the test stands. For example, > the test passes ( without the fix ) when I run it with all the other > tests in test/jdk/java/nio/channels/FileChannel/ and `-conc:1 -agentvm` > - since ExtendedMapMode is loaded from a previous test run in the same > agent. > > * @run main/othervm MapWithSecurityManager Oops, already pushed before I saw this message. I guess I?ll open another issue to make the change to the test. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jan 8 18:22:52 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Jan 2020 10:22:52 -0800 Subject: 8236804: java/nio/channels/FileChannel/MapWithSecurityManager.java should be run in othervm mode In-Reply-To: <51EC6568-3ECD-45FC-9160-7E6FDF5B3538@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> <51EC6568-3ECD-45FC-9160-7E6FDF5B3538@oracle.com> Message-ID: <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8236804 following up on the comments below. Diff: --- a/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java +++ b/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java @@ -24,6 +24,7 @@ /* @test * @bug 8236582 * @summary Tests the map method when running with a security manager + * @run main/othervm MapWithSecurityManager */ Thanks, Brian > On Jan 8, 2020, at 8:44 AM, Brian Burkhalter wrote: > >> On Jan 8, 2020, at 4:20 AM, Chris Hegarty > wrote: >> >>> So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/ . >> >> The source changes look good. >> >> The test should be run in othervm mode, since it depends on triggering >> the loading of ExtendedMapMode when a security manager is present - >> which is not guaranteed to be the case as the test stands. For example, >> the test passes ( without the fix ) when I run it with all the other >> tests in test/jdk/java/nio/channels/FileChannel/ and `-conc:1 -agentvm` >> - since ExtendedMapMode is loaded from a previous test run in the same >> agent. >> >> * @run main/othervm MapWithSecurityManager > > Oops, already pushed before I saw this message. I guess I?ll open another issue to make the change to the test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Jan 8 18:25:10 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 8 Jan 2020 18:25:10 +0000 Subject: 8236804: java/nio/channels/FileChannel/MapWithSecurityManager.java should be run in othervm mode In-Reply-To: <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> <51EC6568-3ECD-45FC-9160-7E6FDF5B3538@oracle.com> <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> Message-ID: <620E545B-12BB-4045-B7AC-EC98B471E0D1@oracle.com> Thanks Brian. Reviewed. -Chris. > On 8 Jan 2020, at 18:22, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8236804 following up on the comments below. > > Diff: > > --- a/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java > +++ b/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java > @@ -24,6 +24,7 @@ > /* @test > * @bug 8236582 > * @summary Tests the map method when running with a security manager > + * @run main/othervm MapWithSecurityManager > */ > > Thanks, > > Brian > >> On Jan 8, 2020, at 8:44 AM, Brian Burkhalter > wrote: >> >>> On Jan 8, 2020, at 4:20 AM, Chris Hegarty > wrote: >>> >>>> So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/ . >>> >>> The source changes look good. >>> >>> The test should be run in othervm mode, since it depends on triggering >>> the loading of ExtendedMapMode when a security manager is present - >>> which is not guaranteed to be the case as the test stands. For example, >>> the test passes ( without the fix ) when I run it with all the other >>> tests in test/jdk/java/nio/channels/FileChannel/ and `-conc:1 -agentvm` >>> - since ExtendedMapMode is loaded from a previous test run in the same >>> agent. >>> >>> * @run main/othervm MapWithSecurityManager >> >> Oops, already pushed before I saw this message. I guess I?ll open another issue to make the change to the test. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Wed Jan 8 18:53:59 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 8 Jan 2020 13:53:59 -0500 Subject: 8236804: java/nio/channels/FileChannel/MapWithSecurityManager.java should be run in othervm mode In-Reply-To: <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> <51EC6568-3ECD-45FC-9160-7E6FDF5B3538@oracle.com> <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> Message-ID: <0E57EBD9-9D55-435F-88EA-9E3E047DAE67@oracle.com> +1 > On Jan 8, 2020, at 1:22 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8236804 following up on the comments below. > > Diff: > > --- a/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java > +++ b/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java > @@ -24,6 +24,7 @@ > /* @test > * @bug 8236582 > * @summary Tests the map method when running with a security manager > + * @run main/othervm MapWithSecurityManager > */ > > Thanks, > > Brian > >> On Jan 8, 2020, at 8:44 AM, Brian Burkhalter > wrote: >> >>> On Jan 8, 2020, at 4:20 AM, Chris Hegarty > wrote: >>> >>>> So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/ . >>> >>> The source changes look good. >>> >>> The test should be run in othervm mode, since it depends on triggering >>> the loading of ExtendedMapMode when a security manager is present - >>> which is not guaranteed to be the case as the test stands. For example, >>> the test passes ( without the fix ) when I run it with all the other >>> tests in test/jdk/java/nio/channels/FileChannel/ and `-conc:1 -agentvm` >>> - since ExtendedMapMode is loaded from a previous test run in the same >>> agent. >>> >>> * @run main/othervm MapWithSecurityManager >> >> Oops, already pushed before I saw this message. I guess I?ll open another issue to make the change to the test. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From brian.burkhalter at oracle.com Wed Jan 8 20:37:45 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Jan 2020 12:37:45 -0800 Subject: 8236582: (fc) FileChannel.map fails with InternalError when security manager enabled In-Reply-To: <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> Message-ID: I inadvertently pushed this fix to the JDK mainline (15) and need also to push it to the JDK 14 fork unless there are objections to the contrary. Mea culpa. Thanks, Brian > On Jan 8, 2020, at 4:20 AM, Chris Hegarty wrote: > >> So modified: http://cr.openjdk.java.net/~bpb/8236582/webrev.02/ . -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jan 8 20:37:49 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 8 Jan 2020 12:37:49 -0800 Subject: 8236804: java/nio/channels/FileChannel/MapWithSecurityManager.java should be run in othervm mode In-Reply-To: <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> References: <81e2563e-c367-4977-a698-9518868b2c35@oracle.com> <9C628A54-9764-4160-813A-69DF3481BD3F@oracle.com> <397CF682-65FD-4B8C-AD6B-184D1BB31750@oracle.com> <3B992D35-62AE-4A47-B938-B411C250F3DC@oracle.com> <51EC6568-3ECD-45FC-9160-7E6FDF5B3538@oracle.com> <7576D62B-80B1-4A9D-A1CC-0870E2B407BC@oracle.com> Message-ID: <052EE8A1-DF94-42DB-AECE-A239DFB7BA7E@oracle.com> I inadvertently pushed this fix to the JDK mainline (15) and need also to push it to the JDK 14 fork unless there are objections to the contrary. Mea culpa. Thanks, Brian > On Jan 8, 2020, at 10:22 AM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8236804 following up on the comments below. > > Diff: > > --- a/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java > +++ b/test/jdk/java/nio/channels/FileChannel/MapWithSecurityManager.java > @@ -24,6 +24,7 @@ > /* @test > * @bug 8236582 > * @summary Tests the map method when running with a security manager > + * @run main/othervm MapWithSecurityManager > */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 9 17:59:03 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 9 Jan 2020 17:59:03 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: <015becc7-dd05-14df-6bdd-807649ab6456@oracle.com> References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> <8c8a61c5-5aab-9202-e285-f4b9258e9d16@oracle.com> <015becc7-dd05-14df-6bdd-807649ab6456@oracle.com> Message-ID: Hi Alan, I'll try your patch on AIX in the next days... Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Montag, 6. Januar 2020 12:22 > To: Langer, Christoph > Cc: Lindenmaier, Goetz ; nio- > dev at openjdk.java.net > Subject: Re: Is isSourceFilterSupported still needed on AIX builds? > > On 30/12/2019 22:48, Langer, Christoph wrote: > > Hi Alan, > > > > I checked... Although AIX documentation only refers to IPV6_JOIN_GROUP > and IPV6_LEAVE_GROUP, as per: > https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/apis/ss > ocko.htm we can find this in netinet/in.h in both, AIX 7.1 and AIX 7.2: > > > > #define IPV6_ADD_MEMBERSHIP IP_ADD_MEMBERSHIP > > #define IPV6_JOIN_GROUP IP_ADD_MEMBERSHIP > > #define IPV6_DROP_MEMBERSHIP IP_DROP_MEMBERSHIP > > #define IPV6_LEAVE_GROUP IP_DROP_MEMBERSHIP > > > > So, both symbols are defined and to me it seems fine to drop their > (conditional) definition from Net.c > > > Thanks for checking. Would you have time to check one more thing? As > part of JDK-8236410 I want to improve the underlying > join/drop/block/unblock so that we use the protocol independent > MCAST_XXXX socket options where possible. I have an initial patch [1] > that should be good enough to try if you have time. My guess is that > USE_MCAST_XXXX should be defined on AIX. Also I suspect > Net.canJoin6WithV4Group should return true. It has historically returned > false on AIX which means that a DatagramChannel to an IPv6 socket cannot > join IPv4 multicast groups. The spec allows tolerates this but it will > become an issue in the future once legacy MulticastSocket is switched to > use a DatagramChannel. > > -Alan > > [1] http://cr.openjdk.java.net/~alanb/8236410/webrev/ From Alan.Bateman at oracle.com Fri Jan 10 08:12:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2020 08:12:24 +0000 Subject: Is isSourceFilterSupported still needed on AIX builds? In-Reply-To: References: <68ea8bc3-6eae-3a5b-3195-a685fd1aba38@oracle.com> <8c8a61c5-5aab-9202-e285-f4b9258e9d16@oracle.com> <015becc7-dd05-14df-6bdd-807649ab6456@oracle.com> Message-ID: On 09/01/2020 17:59, Langer, Christoph wrote: > Hi Alan, > > I'll try your patch on AIX in the next days... > Thanks. If it builds then the test to run is test/jdk/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java. If AIX has support for dual sockets joining IPv4 multicast groups then add Platform.isAIX to the value of canIPv6JoinIPv4Group. This test will then quickly tell you if the AIX port is configured correctly or not. -Alan From Alan.Bateman at oracle.com Fri Jan 10 14:55:34 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2020 14:55:34 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket Message-ID: This is a patch to "upgrade" the DatagramChannel socket adaptor to extend MulticastSocket. This is one of the final changes needed to DatagramChannel and its socket adaptor buddy to make it easy to replace the legacy DatagramSocket and MulticastSocket implementation. Daniel has a draft JEP [1] with the all the details on this effort. The changes should be straight-forward to review as most of the methods defined by MulticastSocket are easy to implement on DatagramChannel. A few review notes: 1. MulticastSocket does not have a protected constructor to create the socket with a custom DatagramSocketImpl. The DatagramSocketImpl mechanism is legacy and not worth adding a constructor now. So the most significant change in the patch is that the socket adaptor is changed to invoke the MulticastSocket(SocketAddress) constructor. This requires a special checked in the MulticastSocket and DatagramSocket constructor that isn't pretty but it has the advantage that the dummy DatagramSocketImpl can go away (it was never used anyway). 2. The DatagramSocket.impl field is changed to final. This is nice because it avoids accidents with lazily creating an impl (say where the socket adaptor doesn't override all methods). The final field means there are several opportunities to for cleanup but I don't want to go there in this patch (this is why getImpl continues to declare that it throws SocketException). I also don't want to complicate things for the JEP implementation in the sandbox. 3. The MulticastSocket spec in lacking in many areas and doesn't specify the exceptions or behavior for many scenarios. The joinGroup methods don't specify how they behave when already a member of the group. The leaveGroup method doesn't specify the behavior when not a member. Several methods don't specify the exception when invoked with null or other bad input. The overrides in the socket adaptor try to maintain compatibility with the the long standing behavior. 4. The DatagramSocket::socket spec is modified to drop the statement that the socket adaptor doesn't have any public methods beyond those defined by DatagramSocket. We need to drop the same statement from SocketChannel and ServerSocketChannel, something for another issue. So I need a CSR and that can also track the observable change that the returned object is a MulticastSocket. 5. One issue with the test is that is initially tickled an intermittent bug on macOS. The underlying setsockopt fails intermittently with ENOMEM when attempting to join the group. There have been sightings of this issue going back to JDK 7 [2]. Also sightings with the legacy MulticastSocket implementation. The patch has a temporary workaround to this issue. It's ugly but I can't duplicate it with this change. Daniel has been thinking about doing the same workaround while we figure out if there is a fix for macOS. The webrev with the changes is here: ??? http://cr.openjdk.java.net/~alanb/8236925/webrev/ -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8235674 [2] https://mail.openjdk.java.net/pipermail/net-dev/2013-July/006769.html From patrick.concannon at oracle.com Fri Jan 10 15:26:21 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Fri, 10 Jan 2020 15:26:21 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> Message-ID: Hi Alan, Thanks for the feedback. I've incorporated your comments into the webrev below. http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/ Kind regards, Patrick On 18/12/2019 10:01, Alan Bateman wrote: > On 17/12/2019 14:35, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my fix and CSR for issue JDK-8235783 >> 'DatagramSocket::disconnect should allow an implementation to throw >> UncheckedIOException'? >> >> DatagramChannel's connect and disconnect methods throw an IOException >> while DatagramSocket's corresponding methods do not. The proposed fix >> changes the specification of DatagramSocket::connect and >> DatagramSocket::disconnect to document that an implementation may >> throw UncheckedIOException. >> In addition, and similar to what was done for DatagramChannel, an >> @apiNote is added to DatagramSocket::disconnect to recommend closing >> the socket if an IO exception occurs, as the underlying socket might >> have been left in an inconsistent and unspecified state >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8235783 >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8236076 >> webrev: >> http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.00/ > A couple of things in this area to think about: > > 1. DatagramSocket connect does nothing when the socket is closed and > we might want specify that some day to avoid the reader wondering if > UncheckedIOException will be thrown when the socket is closed. > > 2. DatagramSocket connect will bind the socket is not already bound > and we might want to specify that some day. The bind could fail so > that is a potential reason for throwing UncheckedIOException (or > SecurityException is unlikely scenarios). > > 3. DatagramSocket.connect silently falls back to emulation when the > underlying connect fails. I think this is a bug as it hides a problem > like trying to connect to a non-routable addresses, but may have been > done this way to avoid incomplete DatagramSocketImpl implementations. > I guess my point here is that UncheckedIOException will never be > thrown, which might be okay if the primary motive is to prepare > DatagramSocket for the new implementation. > > 4. If you are open to word smithing on the @throws descriptions then I > think dropping "by an implementation" will help the wording a bit. > Also I think the description should make it clear that the exception > cause is the IOException with the underlying I/O error. > > -Alan. From Alan.Bateman at oracle.com Fri Jan 10 16:00:07 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2020 16:00:07 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> Message-ID: <4bae757c-0c19-fa54-df39-aa3cbeed7754@oracle.com> On 10/01/2020 15:26, Patrick Concannon wrote: > Hi Alan, > > Thanks for the feedback. > > I've incorporated your comments into the webrev below. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/ Thanks, this version looks good to me. -Alan From chris.hegarty at oracle.com Fri Jan 10 16:17:17 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2020 16:17:17 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> Message-ID: <3ADFEB88-C377-4A70-9049-BF6563F23BCC@oracle.com> Patrick. > On 10 Jan 2020, at 15:26, Patrick Concannon wrote: > > Hi Alan, > > Thanks for the feedback. > > I've incorporated your comments into the webrev below. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/ Mostly looks good. A few small comments: 1) "If this **channel?s** socket is not bound then ...? - please remove ?channel?s" 2) Maybe start the text of the new throws clauses with lowercase - which seems to be the existing style -Chris. From patrick.concannon at oracle.com Fri Jan 10 16:29:02 2020 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Fri, 10 Jan 2020 16:29:02 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: <3ADFEB88-C377-4A70-9049-BF6563F23BCC@oracle.com> References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <3ADFEB88-C377-4A70-9049-BF6563F23BCC@oracle.com> Message-ID: Hi Chris, Well spotted. I've made those changes and updated the webrev. http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/ Kind regards, Patrick On 10/01/2020 16:17, Chris Hegarty wrote: > Patrick. > >> On 10 Jan 2020, at 15:26, Patrick Concannon wrote: >> >> Hi Alan, >> >> Thanks for the feedback. >> >> I've incorporated your comments into the webrev below. >> >> http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/ > Mostly looks good. A few small comments: > > 1) "If this **channel?s** socket is not bound then ...? - please remove ?channel?s" > > 2) Maybe start the text of the new throws clauses with lowercase - which seems to be the existing style > > -Chris. From chris.hegarty at oracle.com Fri Jan 10 16:36:44 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2020 16:36:44 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <3ADFEB88-C377-4A70-9049-BF6563F23BCC@oracle.com> Message-ID: <365A60F5-6248-4F6B-AA29-AC38489805D6@oracle.com> > On 10 Jan 2020, at 16:29, Patrick Concannon wrote: > > Hi Chris, > > Well spotted. > > I've made those changes and updated the webrev. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/ LGTM. -Chris. From daniel.fuchs at oracle.com Fri Jan 10 18:46:12 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Jan 2020 18:46:12 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <3ADFEB88-C377-4A70-9049-BF6563F23BCC@oracle.com> Message-ID: Looks good to me as well. Is there a CSR ready to be reviewed too? best regards, -- daniel On 10/01/2020 16:29, Patrick Concannon wrote: > Hi Chris, > > Well spotted. > > I've made those changes and updated the webrev. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/ > > Kind regards, > > Patrick From brian.burkhalter at oracle.com Sat Jan 11 01:39:03 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 10 Jan 2020 17:39:03 -0800 Subject: [14] 8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned Message-ID: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> The issue [1] arose because a negative internal address value caused a negative alignment offset value to be returned which is not supposed to happen. The alignment offset is supposed to be non-negative, with a value of zero denoting alignment, and a positive value indicating the amount of misalignment. The specification is rather unclear about the significance of the returned value. Also, the implementation does not work if the internal address is negative. This patch corrects both the specification and implementation. The CSR is at [2] and the proposed fix at [3]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8230665 [2] https://bugs.openjdk.java.net/browse/JDK-8236826 [3] http://cr.openjdk.java.net/~bpb/8230665/webrev.00/ From Alan.Bateman at oracle.com Sat Jan 11 08:10:13 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2020 08:10:13 +0000 Subject: [14] 8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned In-Reply-To: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> References: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> Message-ID: On 11/01/2020 01:39, Brian Burkhalter wrote: > The issue [1] arose because a negative internal address value caused a negative alignment offset value to be returned which is not supposed to happen. The alignment offset is supposed to be non-negative, with a value of zero denoting alignment, and a positive value indicating the amount of misalignment. The specification is rather unclear about the significance of the returned value. Also, the implementation does not work if the internal address is negative. This patch corrects both the specification and implementation. The CSR is at [2] and the proposed fix at [3]. > The spec/impl looks good. The tests for alignmentOffset are in open/test/java/nio/ByteBuffer so better to keep them in one place if possible. -Alan From Alan.Bateman at oracle.com Sat Jan 11 09:12:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2020 09:12:36 +0000 Subject: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException In-Reply-To: References: <32da23e3-f50d-63a3-5c03-fa42c57591e4@oracle.com> <3ADFEB88-C377-4A70-9049-BF6563F23BCC@oracle.com> Message-ID: On 10/01/2020 16:29, Patrick Concannon wrote: > Hi Chris, > > Well spotted. > > I've made those changes and updated the webrev. > > http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/ "channel's socket" -> "socket". Well spotted! Something for another (and not important) issue is that DatagramSocket.close is similar to connect/disconnect in that it doesn't specify any exceptions. The socket adaptor throws an Error for this case this. -Alan From jai.forums2013 at gmail.com Sat Jan 11 09:51:25 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 11 Jan 2020 15:21:25 +0530 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider Message-ID: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> Can I please get a review and a sponsor for a patch which fixes JDK-7143743[1]? The patch is hosted as a webrev at [2]. As noted in the JBS issue, the ZipFileSystem, even after being closed can end up holding on to large amounts of memory. The root of the issue is the "inodes" map which is maintained by the jdk.nio.zipfs.ZipFileSystem class. This map holds on to "IndexNode"(s). IndexNode(s) are added/updated/removed to/from this map as and when the filesystem is used to add/update/remove files. One such IndexNode type is the jdk.nio.zipfs.ZipFileSystem$Entry type and an instance of this type will actually hold on to the underlying data of the file as a byte[] (the member is called "bytes"). Once the instance of the ZipFileSystem is closed, this "inodes" map isn't cleared and as a result, potentially, large amounts of data can end up staying in the jdk.nio.zipfs.ZipFileSystem$Entry.bytes member(s). The commit here fixes that issue by simply clearing the "inodes" map in the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage of the "inodes" map and from what I see, it's usage in various places is guarded by "ensureOpen" checks, which means that once the ZipFileSystem instance is closed, the contents of these "inodes" map is no longer relevant and hence clearing it shouldn't cause any issues. Given the nature of this issue, I haven't included a jtreg test for this change. However, I have run the existing ZipFSTester.java testcase to make sure no obvious regressions are introduced. That test passed successfully with this change. A program (a slightly modified version of the one available in the JBS issue) is made available at the end of this mail to reproduce this issue (and verify the fix). To run this program, pass it a path to a directory (as first argument) which contains files with large sizes and a path to a (non-existent) zip file that needs to be created (as second argument). In my manual testing, I used a directory with 3 files of a total size of around 831MB: $ pwd /home/me/testdir $ ls -lh total 1702360 -rw-r--r--@ 1 jaikiran? 184M Oct 29 09:52 a -rw-r--r--@ 1 jaikiran? 258M Oct? 9 19:52 b -rw-r--r--@ 1 jaikiran? 368M Dec 26 08:30 c $ du -sh 831M . Running the program resulted in: $ java ZipFSLeak.java /home/me/testdir/ before-fix.zip Zipping /home/me/testdir/ to before-fix.zip Copied a total of 849617826 bytes from /home/me/testdir/ Running some GC ... Memory in use (after GC): 853071256 (notice that the memory in use at the end of the program, after the ZipFileSystem has been closed a while back, stays extremely high and almost equal to the total bytes of the files that were added to the ZipFileSystem). Now after the fix, running the same program against the same directory results in: $ java ZipFSLeak.java /home/me/testdir/ after-fix.zip Zipping /home/me/testdir/ to after-fix.zip Copied a total of 849617826 bytes from /home/me/testdir/ Running some GC ... Memory in use (after GC): 4769904 (notice the drastic improvement in the memory usage) Following is the program used to reproduce the issue: import java.io.IOException; import java.net.URI; import java.nio.file.DirectoryStream; import java.nio.file.FileSystem; import java.nio.file.FileSystems; import java.nio.file.Files; import java.nio.file.Path; import java.util.HashMap; import java.util.Map; public class ZipFSLeak { ??? public static void main(String[] args) throws IOException { ??? ??? // first arg is dir contatining (preferably) files of large sizes ??? ??? final Path srcDir = FileSystems.getDefault().getPath(args[0]); ??? ??? // second arg is path to the target zip which will be created by this program ??? ??? final Path targetZip = FileSystems.getDefault().getPath(args[1]); ??? ??? System.out.println("Zipping " + srcDir + " to " + targetZip); ??? ??? final FileSystem zip = createZipFileSystem(targetZip, true); ??? ??? long totalCopiedSize = 0; ??? ??? try (final DirectoryStream dirStream = Files.newDirectoryStream(srcDir); ??? ??? ??? ??? var zipFS = zip) { ??? ??? ??? final Path zipRoot = zipFS.getPath("/"); ??? ??? ??? for (Path path : dirStream) { ??? ??? ??? ??? Files.copy(path, zipRoot.resolve(path.getFileName().toString())); ??? ??? ??? ??? totalCopiedSize += path.toFile().length(); ??? ??? ??? } ??? ??? } ??? ??? System.out.println("Copied a total of " + totalCopiedSize + " bytes from " + srcDir); ??? ??? System.out.println("Running some GC ..."); ??? ??? // run some GC ??? ??? for (int i = 0; i < 10; i++) { ??? ??? ??? Runtime.getRuntime().gc(); ??? ??? } ??? ??? System.out.println("Memory in use (after GC): " + (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); ??? } ??? private static FileSystem createZipFileSystem(Path path, boolean create) throws IOException { ??? ??? final URI uri = URI.create("jar:file:" + path.toUri().getPath()); ??? ??? final Map env = new HashMap<>(); ??? ??? if (create) { ??? ??? ??? env.put("create", "true"); ??? ??? } ??? ??? return FileSystems.newFileSystem(uri, env); ??? } } [1] https://bugs.openjdk.java.net/browse/JDK-7143743 [2] https://cr.openjdk.java.net/~jpai/webrev/7143743/1/webrev/ P.S: This affects all prominent Java versions since Java 8 (that's the least one I tested) and not just the latest upstream. -Jaikiran From Alan.Bateman at oracle.com Sat Jan 11 10:07:28 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2020 10:07:28 +0000 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> Message-ID: On 11/01/2020 09:51, Jaikiran Pai wrote: > : > > The commit here fixes that issue by simply clearing the "inodes" map in > the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage > of the "inodes" map and from what I see, it's usage in various places is > guarded by "ensureOpen" checks, which means that once the ZipFileSystem > instance is closed, the contents of these "inodes" map is no longer > relevant and hence clearing it shouldn't cause any issues. > Clearing the inodes map should be okay for cases where something is holding a reference to a closed zip file system. However, you should look at beginWrite/endWrite so that all access to the map is consistently synchronized. -Alan. From jai.forums2013 at gmail.com Sat Jan 11 10:24:16 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 11 Jan 2020 15:54:16 +0530 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> Message-ID: Hello Alan, On 11/01/20 3:37 pm, Alan Bateman wrote: > On 11/01/2020 09:51, Jaikiran Pai wrote: >> : >> >> The commit here fixes that issue by simply clearing the "inodes" map in >> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage >> of the "inodes" map and from what I see, it's usage in various places is >> guarded by "ensureOpen" checks, which means that once the ZipFileSystem >> instance is closed, the contents of these "inodes" map is no longer >> relevant and hence clearing it shouldn't cause any issues. >> > Clearing the inodes map should be okay for cases where something is > holding a reference to a closed zip file system. However, you should > look at beginWrite/endWrite so that all access to the map is > consistently synchronized. > Thank you very much for that input - I hadn't considered the concurrency aspect of it. Based on your input and after looking at the usage of the "inodes", I have now updated the patch to use proper locks during the clearing of the inodes. The updated webrev is available at https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ -Jaikiran From lance.andersen at oracle.com Sat Jan 11 20:56:22 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 11 Jan 2020 15:56:22 -0500 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> Message-ID: <5278C64C-9BF1-4616-BA7E-67771FD3AB3D@oracle.com> I am happy to sponsor this next week after providing time for additional review feedback and also sanity check it via Mach5 Best Lance > On Jan 11, 2020, at 5:24 AM, Jaikiran Pai wrote: > > Hello Alan, > > On 11/01/20 3:37 pm, Alan Bateman wrote: >> On 11/01/2020 09:51, Jaikiran Pai wrote: >>> : >>> >>> The commit here fixes that issue by simply clearing the "inodes" map in >>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage >>> of the "inodes" map and from what I see, it's usage in various places is >>> guarded by "ensureOpen" checks, which means that once the ZipFileSystem >>> instance is closed, the contents of these "inodes" map is no longer >>> relevant and hence clearing it shouldn't cause any issues. >>> >> Clearing the inodes map should be okay for cases where something is >> holding a reference to a closed zip file system. However, you should >> look at beginWrite/endWrite so that all access to the map is >> consistently synchronized. >> > Thank you very much for that input - I hadn't considered the concurrency > aspect of it. Based on your input and after looking at the usage of the > "inodes", I have now updated the patch to use proper locks during the > clearing of the inodes. The updated webrev is available at > https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ > > -Jaikiran Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From jai.forums2013 at gmail.com Sun Jan 12 03:27:31 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 12 Jan 2020 08:57:31 +0530 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: <5278C64C-9BF1-4616-BA7E-67771FD3AB3D@oracle.com> References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> <5278C64C-9BF1-4616-BA7E-67771FD3AB3D@oracle.com> Message-ID: <326a43ed-9c67-89ff-b46e-b66e4985d8ea@gmail.com> Thank you Lance. -Jaikiran On 12/01/20 2:26 am, Lance Andersen wrote: > I am happy to sponsor this next week after providing time for > additional review feedback and also sanity check it via Mach5 > > Best > Lance > >> On Jan 11, 2020, at 5:24 AM, Jaikiran Pai > > wrote: >> >> Hello Alan, >> >> On 11/01/20 3:37 pm, Alan Bateman wrote: >>> On 11/01/2020 09:51, Jaikiran Pai wrote: >>>> : >>>> >>>> The commit here fixes that issue by simply clearing the "inodes" map in >>>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the >>>> usage >>>> of the "inodes" map and from what I see, it's usage in various >>>> places is >>>> guarded by "ensureOpen" checks, which means that once the ZipFileSystem >>>> instance is closed, the contents of these "inodes" map is no longer >>>> relevant and hence clearing it shouldn't cause any issues. >>>> >>> Clearing the inodes map should be okay for cases where something is >>> holding a reference to a closed zip file system. However, you should >>> look at beginWrite/endWrite so that all access to the map is >>> consistently synchronized. >>> >> Thank you very much for that input - I hadn't considered the concurrency >> aspect of it. Based on your input and after looking at the usage of the >> "inodes", I have now updated the patch to use proper locks during the >> clearing of the inodes. The updated webrev is available at >> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ >> >> -Jaikiran > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering? > 1 Network Drive? > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From christoph.langer at sap.com Mon Jan 13 06:56:47 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 13 Jan 2020 06:56:47 +0000 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> Message-ID: Hi, I'm wondering whether we shouldn't just do "inodes = null;"? I guess this is cheaper and accesses to the inodes map on a closed filesystem object should not happen anyway (e.g. all is guarded by ensureOpen()). Other than that, the change looks fine. Cheers Christoph > -----Original Message----- > From: nio-dev On Behalf Of Jaikiran > Pai > Sent: Samstag, 11. Januar 2020 11:24 > To: Alan Bateman ; nio-dev at openjdk.java.net > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider > > Hello Alan, > > On 11/01/20 3:37 pm, Alan Bateman wrote: > > On 11/01/2020 09:51, Jaikiran Pai wrote: > >> : > >> > >> The commit here fixes that issue by simply clearing the "inodes" map in > >> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage > >> of the "inodes" map and from what I see, it's usage in various places is > >> guarded by "ensureOpen" checks, which means that once the > ZipFileSystem > >> instance is closed, the contents of these "inodes" map is no longer > >> relevant and hence clearing it shouldn't cause any issues. > >> > > Clearing the inodes map should be okay for cases where something is > > holding a reference to a closed zip file system. However, you should > > look at beginWrite/endWrite so that all access to the map is > > consistently synchronized. > > > Thank you very much for that input - I hadn't considered the concurrency > aspect of it. Based on your input and after looking at the usage of the > "inodes", I have now updated the patch to use proper locks during the > clearing of the inodes. The updated webrev is available at > https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ > > -Jaikiran From jai.forums2013 at gmail.com Mon Jan 13 10:31:38 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 13 Jan 2020 16:01:38 +0530 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> Message-ID: <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com> Hello Christoph, Setting inodes to null sounds fine to me and as you say since its usage is already guarded by ensureOpen, IMO, it should be fine. I've now updated the patch to set inodes to null in close() and the new updated webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/ -Jaikiran On 13/01/20 12:26 pm, Langer, Christoph wrote: > Hi, > > I'm wondering whether we shouldn't just do "inodes = null;"? I guess this is cheaper and accesses to the inodes map on a closed filesystem object should not happen anyway (e.g. all is guarded by ensureOpen()). Other than that, the change looks fine. > > Cheers > Christoph > >> -----Original Message----- >> From: nio-dev On Behalf Of Jaikiran >> Pai >> Sent: Samstag, 11. Januar 2020 11:24 >> To: Alan Bateman ; nio-dev at openjdk.java.net >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider >> >> Hello Alan, >> >> On 11/01/20 3:37 pm, Alan Bateman wrote: >>> On 11/01/2020 09:51, Jaikiran Pai wrote: >>>> : >>>> >>>> The commit here fixes that issue by simply clearing the "inodes" map in >>>> the jdk.nio.zipfs.ZipFileSystem.close() method. I have checked the usage >>>> of the "inodes" map and from what I see, it's usage in various places is >>>> guarded by "ensureOpen" checks, which means that once the >> ZipFileSystem >>>> instance is closed, the contents of these "inodes" map is no longer >>>> relevant and hence clearing it shouldn't cause any issues. >>>> >>> Clearing the inodes map should be okay for cases where something is >>> holding a reference to a closed zip file system. However, you should >>> look at beginWrite/endWrite so that all access to the map is >>> consistently synchronized. >>> >> Thank you very much for that input - I hadn't considered the concurrency >> aspect of it. Based on your input and after looking at the usage of the >> "inodes", I have now updated the patch to use proper locks during the >> clearing of the inodes. The updated webrev is available at >> https://cr.openjdk.java.net/~jpai/webrev/7143743/2/webrev/ >> >> -Jaikiran From brian.burkhalter at oracle.com Mon Jan 13 16:49:14 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 Jan 2020 08:49:14 -0800 Subject: [14] 8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned In-Reply-To: References: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> Message-ID: <90D637BF-A0A0-4CB1-A4C6-58E6416C450F@oracle.com> > On Jan 11, 2020, at 12:10 AM, Alan Bateman wrote: > > The spec/impl looks good. The tests for alignmentOffset are in open/test/java/nio/ByteBuffer so better to keep them in one place if possible. Are you suggested simply to move the test as-is or incorporate the testing into, e.g., BasicByte? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Mon Jan 13 18:35:34 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 18:35:34 +0000 Subject: Draft JEP: 8235674: Reimplement the Legacy DatagramSocket API Message-ID: <77885b10-6fac-7b55-3af1-f31f17d6f498@oracle.com> Hi, For some time now we've been considering replacing the implementation of DatagramSocket and MulticastSocket with something more modern, based on NIO, much similar to what was done for Socket and ServerSocket in JEP 353 [1]. We have been doing some prototyping, and finally got a draft JEP written: 8235674: Reimplement the Legacy DatagramSocket API [2] We also have a prototype implementation (work in progress) in the `JDK-8230211-branch` of the JDK Sandbox: hg clone http://hg.openjdk.java.net/jdk/sandbox hg update -r JDK-8230211-branch The draft JEP explains the motivation and also lists a couple of alternatives we have considered/prototyped before reaching the current proposal. A side effect of this JEP will be to obsolete the DatagramSocketImpl and DatagramSocketImpl factory - which we are considering deprecating (either before, after, or as part of the JEP). Feedback on this JEP before submission would be very welcome. best regards, -- daniel [1] https://openjdk.java.net/jeps/353 [2] https://bugs.openjdk.java.net/browse/JDK-8235674 From Alan.Bateman at oracle.com Mon Jan 13 18:53:39 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Jan 2020 18:53:39 +0000 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com> References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com> Message-ID: On 13/01/2020 10:31, Jaikiran Pai wrote: > Hello Christoph, > > Setting inodes to null sounds fine to me and as you say since its usage > is already guarded by ensureOpen, IMO, it should be fine. I've now > updated the patch to set inodes to null in close() and the new updated > webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/ > This version looks good except it might be better if the comment just says that it clears the inodes map to allow the keys/values be GC'ed. -Alan From lance.andersen at oracle.com Mon Jan 13 20:26:01 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 13 Jan 2020 15:26:01 -0500 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com> Message-ID: > On Jan 13, 2020, at 1:53 PM, Alan Bateman wrote: > > On 13/01/2020 10:31, Jaikiran Pai wrote: >> Hello Christoph, >> >> Setting inodes to null sounds fine to me and as you say since its usage >> is already guarded by ensureOpen, IMO, it should be fine. I've now >> updated the patch to set inodes to null in close() and the new updated >> webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/ >> > This version looks good except it might be better if the comment just says that it clears the inodes map to allow the keys/values be GC?ed. I revised the comment to: ???????? $ hg diff diff -r 9338d0f52b2e src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Mon Jan 13 11:51:45 2020 -0500 +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Mon Jan 13 15:24:37 2020 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -490,6 +490,14 @@ def.end(); } + beginWrite(); // lock and sync + try { + // Clear the map so that its keys & values can be garbage collected + inodes = null; + } finally { + endWrite(); + } + IOException ioe = null; synchronized (tmppaths) { for (Path p : tmppaths) { $ ??????????? I will push the change tomorrow barring any hiccups with Mach5 or additional comments?. Best lance > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From brian.burkhalter at oracle.com Tue Jan 14 00:18:00 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 Jan 2020 16:18:00 -0800 Subject: [14] 8236661: Launcher test PatchSystemModules.java fails frequently after JDK-8234049 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8236661 Don?t init ExtendedMapMode until modules have been initialized. --- a/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java +++ b/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java @@ -49,6 +49,7 @@ import jdk.internal.access.SharedSecrets; import jdk.internal.misc.ExtendedMapMode; import jdk.internal.misc.Unsafe; +import jdk.internal.misc.VM; import jdk.internal.ref.Cleaner; import jdk.internal.ref.CleanerFactory; @@ -1116,8 +1117,11 @@ } private boolean isSync(MapMode mode) { - return mode == ExtendedMapMode.READ_ONLY_SYNC || - mode == ExtendedMapMode.READ_WRITE_SYNC; + // Do not want to initialize ExtendedMapMode until + // after the module system has been initialized + return !VM.isModuleSystemInited() ? false : + (mode == ExtendedMapMode.READ_ONLY_SYNC || + mode == ExtendedMapMode.READ_WRITE_SYNC); } Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Jan 14 00:44:06 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 13 Jan 2020 16:44:06 -0800 Subject: [14] 8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned In-Reply-To: <90D637BF-A0A0-4CB1-A4C6-58E6416C450F@oracle.com> References: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> <90D637BF-A0A0-4CB1-A4C6-58E6416C450F@oracle.com> Message-ID: <483CDBF2-EDC2-481F-9280-A580F00B10DA@oracle.com> > On Jan 13, 2020, at 8:49 AM, Brian Burkhalter wrote: > >> On Jan 11, 2020, at 12:10 AM, Alan Bateman > wrote: >> >> The spec/impl looks good. The tests for alignmentOffset are in open/test/java/nio/ByteBuffer so better to keep them in one place if possible. > > Are you suggested simply to move the test as-is or incorporate the testing into, e.g., BasicByte? Here [1] is a version which puts the new test code into existing files. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8230665/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Tue Jan 14 01:59:46 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 13 Jan 2020 17:59:46 -0800 Subject: [14] 8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned In-Reply-To: <483CDBF2-EDC2-481F-9280-A580F00B10DA@oracle.com> References: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> <90D637BF-A0A0-4CB1-A4C6-58E6416C450F@oracle.com> <483CDBF2-EDC2-481F-9280-A580F00B10DA@oracle.com> Message-ID: <6F8E05FB-6604-4B9D-83AF-118B4A1827F8@oracle.com> +1 Paul. > On Jan 13, 2020, at 4:44 PM, Brian Burkhalter wrote: > > >> On Jan 13, 2020, at 8:49 AM, Brian Burkhalter > wrote: >> >>> On Jan 11, 2020, at 12:10 AM, Alan Bateman > wrote: >>> >>> The spec/impl looks good. The tests for alignmentOffset are in open/test/java/nio/ByteBuffer so better to keep them in one place if possible. >> >> Are you suggested simply to move the test as-is or incorporate the testing into, e.g., BasicByte? > > Here [1] is a version which puts the new test code into existing files. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8230665/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Tue Jan 14 03:11:49 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 14 Jan 2020 08:41:49 +0530 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com> Message-ID: <7d48fd19-502d-39df-96b3-1397b3e42c36@gmail.com> Looks fine Lance. I forgot about the copyright year, thank you for taking care of that one too. -Jaikiran On 14/01/20 1:56 am, Lance Andersen wrote: > > >> On Jan 13, 2020, at 1:53 PM, Alan Bateman > > wrote: >> >> On 13/01/2020 10:31, Jaikiran Pai wrote: >>> Hello Christoph, >>> >>> Setting inodes to null sounds fine to me and as you say since its usage >>> is already guarded by ensureOpen, IMO, it should be fine. I've now >>> updated the patch to set inodes to null in close() and the new updated >>> webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/ >>> >> This version looks good except it might be better if the comment just >> says that it clears the inodes map to allow the keys/values be GC?ed. > > I revised the comment to: > > ???????? > > $ hg diff > *diff -r 9338d0f52b2e > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java* > *--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java? ? > ? Mon Jan 13 11:51:45 2020 -0500* > *+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java? ? > ? Mon Jan 13 15:24:37 2020 -0500* > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2009, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -490,6 +490,14 @@ > ?? ? ? ? ? ? ? ? def.end(); > ?? ? ? ? } > > ? > > +? ? ? ? beginWrite();? ? ? ? ? ? ? ? // lock and sync > +? ? ? ? try { > +? ? ? ? ? ? // Clear the map so that its keys & values can be garbage > collected > +? ? ? ? ? ? inodes = null; > +? ? ? ? } finally { > +? ? ? ? ? ? endWrite(); > +? ? ? ? } > + > ?? ? ? ? IOException ioe = null; > ?? ? ? ? synchronized (tmppaths) { > ?? ? ? ? ? ? for (Path p : tmppaths) { > $ > ??????????? > > I will push the change tomorrow barring any hiccups with Mach5 or > additional comments?. > > Best > lance >> >> -Alan > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering? > 1 Network Drive? > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From mandy.chung at oracle.com Tue Jan 14 06:02:38 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Jan 2020 22:02:38 -0800 Subject: [14] 8236661: Launcher test PatchSystemModules.java fails frequently after JDK-8234049 In-Reply-To: References: Message-ID: This looks okay.? No one can access ExtendedMapNode until the module system is fully initialized. Mandy On 1/13/20 4:18 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8236661 > > Don?t init ExtendedMapMode until modules have been initialized. > > --- a/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java > +++ b/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java > @@ -49,6 +49,7 @@ > ?import jdk.internal.access.SharedSecrets; > ?import jdk.internal.misc.ExtendedMapMode; > ?import jdk.internal.misc.Unsafe; > +import jdk.internal.misc.VM; > ?import jdk.internal.ref.Cleaner; > ?import jdk.internal.ref.CleanerFactory; > > > @@ -1116,8 +1117,11 @@ > ?? ? } > > > ?? ? private boolean isSync(MapMode mode) { > -? ? ? ? return mode == ExtendedMapMode.READ_ONLY_SYNC || > -? ? ? ? ? ? ? ? mode == ExtendedMapMode.READ_WRITE_SYNC; > +? ? ? ? // Do not want to initialize ExtendedMapMode until > +? ? ? ? // after the module system has been initialized > +? ? ? ? return !VM.isModuleSystemInited() ? false : > +? ? ? ? ? ? (mode == ExtendedMapMode.READ_ONLY_SYNC || > +? ? ? ? ? ? ? ? mode == ExtendedMapMode.READ_WRITE_SYNC); > ?? ? } > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 14 08:15:12 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2020 08:15:12 +0000 Subject: [14] 8236661: Launcher test PatchSystemModules.java fails frequently after JDK-8234049 In-Reply-To: References: Message-ID: <34323108-005a-570b-0eba-ff44aeea61f9@oracle.com> On 14/01/2020 06:02, Mandy Chung wrote: > This looks okay.? No one can access ExtendedMapNode until the module > system is fully initialized. Right, although thing that isn't clear from the bug report is why the failure is intermittent. I would have expected it to fail consistently. In any case, the change looks good. -Alan From Alan.Bateman at oracle.com Tue Jan 14 08:18:42 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2020 08:18:42 +0000 Subject: [14] 8230665: (bf spec) ByteBuffer::alignmentOffset spec misleading when address is misaligned In-Reply-To: <483CDBF2-EDC2-481F-9280-A580F00B10DA@oracle.com> References: <6EDCB1DD-A4EE-4907-9126-1C6BD311AC8F@oracle.com> <90D637BF-A0A0-4CB1-A4C6-58E6416C450F@oracle.com> <483CDBF2-EDC2-481F-9280-A580F00B10DA@oracle.com> Message-ID: On 14/01/2020 00:44, Brian Burkhalter wrote: > > > Here [1] is a version which puts the new test code into existing files. > I think this is the right place, looks good. -Alan From christoph.langer at sap.com Tue Jan 14 10:16:52 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Jan 2020 10:16:52 +0000 Subject: RFR 7143743: (zipfs) Potential memory leak with zip provider In-Reply-To: References: <38fe7570-241a-d5f3-edeb-524ddde9bf52@gmail.com> <47a51344-422b-b088-6c2a-9c366276e6d1@gmail.com> Message-ID: Hi, Looks good to me ?? Cheers Christoph From: Lance Andersen Sent: Montag, 13. Januar 2020 21:26 To: Alan Bateman Cc: Jaikiran Pai ; Langer, Christoph ; nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR 7143743: (zipfs) Potential memory leak with zip provider On Jan 13, 2020, at 1:53 PM, Alan Bateman > wrote: On 13/01/2020 10:31, Jaikiran Pai wrote: Hello Christoph, Setting inodes to null sounds fine to me and as you say since its usage is already guarded by ensureOpen, IMO, it should be fine. I've now updated the patch to set inodes to null in close() and the new updated webrev is at https://cr.openjdk.java.net/~jpai/webrev/7143743/3/webrev/ This version looks good except it might be better if the comment just says that it clears the inodes map to allow the keys/values be GC?ed. I revised the comment to: ???????? $ hg diff diff -r 9338d0f52b2e src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Mon Jan 13 11:51:45 2020 -0500 +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java Mon Jan 13 15:24:37 2020 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2009, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -490,6 +490,14 @@ def.end(); } + beginWrite(); // lock and sync + try { + // Clear the map so that its keys & values can be garbage collected + inodes = null; + } finally { + endWrite(); + } + IOException ioe = null; synchronized (tmppaths) { for (Path p : tmppaths) { $ ??????????? I will push the change tomorrow barring any hiccups with Mach5 or additional comments?. Best lance -Alan [cid:image001.gif at 01D5CACC.1E85C500] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From daniel.fuchs at oracle.com Tue Jan 14 17:49:58 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Jan 2020 17:49:58 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket In-Reply-To: References: Message-ID: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> Hi Alan, Globally this looks good to me. One small nit is that the `oldImpl` field could now also become final (by applying the same trick you did with createImpl - that is - have oldImpl() return a boolean rather than set the field and assign the result in the constructor. I've imported your patch and am currently running some tests. best regards, -- daniel On 10/01/2020 14:55, Alan Bateman wrote: > This is a patch to "upgrade" the DatagramChannel socket adaptor to > extend MulticastSocket. This is one of the final changes needed to > DatagramChannel and its socket adaptor buddy to make it easy to replace > the legacy DatagramSocket and MulticastSocket implementation. Daniel has > a draft JEP [1] with the all the details on this effort. > > The changes should be straight-forward to review as most of the methods > defined by MulticastSocket are easy to implement on DatagramChannel. A > few review notes: > > 1. MulticastSocket does not have a protected constructor to create the > socket with a custom DatagramSocketImpl. The DatagramSocketImpl > mechanism is legacy and not worth adding a constructor now. So the most > significant change in the patch is that the socket adaptor is changed to > invoke the MulticastSocket(SocketAddress) constructor. This requires a > special checked in the MulticastSocket and DatagramSocket constructor > that isn't pretty but it has the advantage that the dummy > DatagramSocketImpl can go away (it was never used anyway). > > 2. The DatagramSocket.impl field is changed to final. This is nice > because it avoids accidents with lazily creating an impl (say where the > socket adaptor doesn't override all methods). The final field means > there are several opportunities to for cleanup but I don't want to go > there in this patch (this is why getImpl continues to declare that it > throws SocketException). I also don't want to complicate things for the > JEP implementation in the sandbox. > > 3. The MulticastSocket spec in lacking in many areas and doesn't specify > the exceptions or behavior for many scenarios. The joinGroup methods > don't specify how they behave when already a member of the group. The > leaveGroup method doesn't specify the behavior when not a member. > Several methods don't specify the exception when invoked with null or > other bad input. The overrides in the socket adaptor try to maintain > compatibility with the the long standing behavior. > > 4. The DatagramSocket::socket spec is modified to drop the statement > that the socket adaptor doesn't have any public methods beyond those > defined by DatagramSocket. We need to drop the same statement from > SocketChannel and ServerSocketChannel, something for another issue. So I > need a CSR and that can also track the observable change that the > returned object is a MulticastSocket. > > 5. One issue with the test is that is initially tickled an intermittent > bug on macOS. The underlying setsockopt fails intermittently with ENOMEM > when attempting to join the group. There have been sightings of this > issue going back to JDK 7 [2]. Also sightings with the legacy > MulticastSocket implementation. The patch has a temporary workaround to > this issue. It's ugly but I can't duplicate it with this change. Daniel > has been thinking about doing the same workaround while we figure out if > there is a fix for macOS. > > The webrev with the changes is here: > ??? http://cr.openjdk.java.net/~alanb/8236925/webrev/ > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8235674 > [2] https://mail.openjdk.java.net/pipermail/net-dev/2013-July/006769.html From Alan.Bateman at oracle.com Tue Jan 14 19:23:31 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2020 19:23:31 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket In-Reply-To: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> References: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> Message-ID: <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> On 14/01/2020 17:49, Daniel Fuchs wrote: > Hi Alan, > > Globally this looks good to me. One small nit is that the `oldImpl` > field could now also become final (by applying the same trick you > did with createImpl - that is - have oldImpl() return a boolean > rather than set the field and assign the result in the constructor. Thanks for going through this. I tried to keep the changes to DatagramSocket to a minimum but I don't mind making an exception for oldImpl. It's a slippery slope as there is a lot of technical debt in this area. Also oldImpl is the the support for DatagramSocketImpl that were compiled for JDK 1.3 or older and I really hope we can drop that code soon. Here's the updated webrev that changes oldImpl to be final. ?? http://cr.openjdk.java.net/~alanb/8236925/2/webrev/ -Alan From daniel.fuchs at oracle.com Tue Jan 14 19:54:29 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 14 Jan 2020 19:54:29 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket In-Reply-To: <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> References: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> Message-ID: <7411f10e-16ac-049f-d242-9f6f838e6686@oracle.com> Looks good Alan! best regards. -- daniel On 14/01/20 19:23, Alan Bateman wrote: > Thanks for going through this. I tried to keep the changes to > DatagramSocket to a minimum but I don't mind making an exception for > oldImpl. It's a slippery slope as there is a lot of technical debt in > this area. Also oldImpl is the the support for DatagramSocketImpl that > were compiled for JDK 1.3 or older and I really hope we can drop that > code soon. > > Here's the updated webrev that changes oldImpl to be final. > ?? http://cr.openjdk.java.net/~alanb/8236925/2/webrev/ > > -Alan From brian.burkhalter at oracle.com Tue Jan 14 20:23:24 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 Jan 2020 12:23:24 -0800 Subject: [14] 8236661: Launcher test PatchSystemModules.java fails frequently after JDK-8234049 In-Reply-To: <34323108-005a-570b-0eba-ff44aeea61f9@oracle.com> References: <34323108-005a-570b-0eba-ff44aeea61f9@oracle.com> Message-ID: <7A538FE7-BCD3-49E0-BB6C-30C036742F7A@oracle.com> > On Jan 14, 2020, at 12:15 AM, Alan Bateman wrote: > > On 14/01/2020 06:02, Mandy Chung wrote: >> This looks okay. No one can access ExtendedMapNode until the module system is fully initialized. > Right, although thing that isn't clear from the bug report is why the failure is intermittent. I would have expected it to fail consistently. In any case, the change looks good. Unclear why it?s only on Windows, either. In any case, pushed. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Jan 15 00:42:32 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 14 Jan 2020 16:42:32 -0800 Subject: 8237183: Bug ID missing for test in patch which fixed JDK-8230665 Message-ID: <67E8B8F0-8DA5-498F-B65B-9DB4828A270E@oracle.com> Please review this simple tag change @@ -26,7 +26,7 @@ * @bug 4413135 4414911 4416536 4416562 4418782 4471053 4472779 4490253 4523725 * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 5029431 * 5071718 6231529 6221101 6234263 6535542 6591971 6593946 6795561 7190219 - * 7199551 8065556 8149469 + * 7199551 8065556 8149469 8230665 which fixes [1] in order to rectify an oversight in the patch which fixed [2]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8237183 [2] https://bugs.openjdk.java.net/browse/JDK-8230665 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Wed Jan 15 00:46:54 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 14 Jan 2020 19:46:54 -0500 Subject: 8237183: Bug ID missing for test in patch which fixed JDK-8230665 In-Reply-To: <67E8B8F0-8DA5-498F-B65B-9DB4828A270E@oracle.com> References: <67E8B8F0-8DA5-498F-B65B-9DB4828A270E@oracle.com> Message-ID: <32FAC77E-391E-4797-99B9-9823656FEF0E@oracle.com> +1 > On Jan 14, 2020, at 7:42 PM, Brian Burkhalter wrote: > > Please review this simple tag change > > @@ -26,7 +26,7 @@ > * @bug 4413135 4414911 4416536 4416562 4418782 4471053 4472779 4490253 4523725 > * 4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 5029431 > * 5071718 6231529 6221101 6234263 6535542 6591971 6593946 6795561 7190219 > - * 7199551 8065556 8149469 > + * 7199551 8065556 8149469 8230665 > > which fixes [1] in order to rectify an oversight in the patch which fixed [2]. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8237183 > [2] https://bugs.openjdk.java.net/browse/JDK-8230665 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Wed Jan 15 09:04:44 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jan 2020 09:04:44 +0000 Subject: 8053479: (dc) DatagramChannel.read() throws exception instead of discarding data when buffer too small Message-ID: <6a48c2cd-d235-da9c-afe3-206997107df1@oracle.com> If the DatagramChannel receive or read methods are called with a buffer that has fewer bytes remaining that is required for the datagram then the remainder is silently discarded. This scenario isn't handled correctly on Windows when the channel's socket is connected because the implementation doesn't handle WSAEMSGSIZE. Not an issue on other platforms and not an issue for the not-connected case on Windows. The fix to handle WSAEMSGSIZE is very simple: ??? http://cr.openjdk.java.net/~alanb/8053479/webrev/ -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jan 15 10:44:07 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Jan 2020 11:44:07 +0100 Subject: 8053479: (dc) DatagramChannel.read() throws exception instead of discarding data when buffer too small In-Reply-To: <6a48c2cd-d235-da9c-afe3-206997107df1@oracle.com> References: <6a48c2cd-d235-da9c-afe3-206997107df1@oracle.com> Message-ID: <364d3c1e-d962-bb75-64bc-f03c61284701@oracle.com> Looks good to me (although you probably want a review from someone more knowledgeable in the area). Nit: src/java.base/windows/native/libnio/ch/DatagramDispatcher.c L70 indentation looks off by a space In the test the randomization of the byte array doesn't seem instrumental to what's being tested. Maybe preferable to just fill the buffer with some (constant?) value and drop the @randomness tag. /Claes On 2020-01-15 10:04, Alan Bateman wrote: > If the DatagramChannel receive or read methods are called with a buffer > that has fewer bytes remaining that is required for the datagram then > the remainder is silently discarded. This scenario isn't handled > correctly on Windows when the channel's socket is connected because the > implementation doesn't handle WSAEMSGSIZE. Not an issue on other > platforms and not an issue for the not-connected case on Windows. The > fix to handle WSAEMSGSIZE is very simple: > http://cr.openjdk.java.net/~alanb/8053479/webrev/ > > -Alan. From Alan.Bateman at oracle.com Wed Jan 15 11:33:07 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jan 2020 11:33:07 +0000 Subject: 8053479: (dc) DatagramChannel.read() throws exception instead of discarding data when buffer too small In-Reply-To: <364d3c1e-d962-bb75-64bc-f03c61284701@oracle.com> References: <6a48c2cd-d235-da9c-afe3-206997107df1@oracle.com> <364d3c1e-d962-bb75-64bc-f03c61284701@oracle.com> Message-ID: <1165e7eb-52d2-012c-10ae-1147d49c9024@oracle.com> On 15/01/2020 10:44, Claes Redestad wrote: > Looks good to me (although you probably want a review from someone > more knowledgeable in the area). > > Nit: src/java.base/windows/native/libnio/ch/DatagramDispatcher.c L70 > indentation looks off by a space > > In the test the randomization of the byte array doesn't seem > instrumental to what's being tested. Maybe preferable to just fill the > buffer with some (constant?) value and drop the @randomness tag. Thanks for looking at it. You are right that the buffer contents don't influence the test but non-zero elements are needed to test that the truncated datagram was read into the buffer (or buffers in the case of the scattering read). The only reason it used Random was because of other tests in this area, probably should move away from that. I've updated it in-place to just cycle through the byte values: -??????? Random rand = new Random(); -??????? rand.nextBytes(buffer.array()); +??????? IntStream.range(0, size).forEach(i -> buffer.put((byte)i)); +??????? buffer.flip(); -Alan From chris.hegarty at oracle.com Thu Jan 16 11:45:22 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Jan 2020 11:45:22 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket In-Reply-To: <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> References: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> Message-ID: <34DB98E1-5268-4BBD-9192-A2F24C8D2B0C@oracle.com> > On 14 Jan 2020, at 19:23, Alan Bateman wrote: > > ... > Here's the updated webrev that changes oldImpl to be final. > http://cr.openjdk.java.net/~alanb/8236925/2/webrev/ Generally, I agree with updating the socket adapter to support multicast. It will certainly help with future work in this area. The instanceof checks in the constructors highlight that there is an abstraction missing here - to support creating a custom MulticastSocket implementation. If / When DatagramSocketImpl is deprecated, the advise will likely be to subclass MulticastSocket if one wants to provide a custom implementation. I believe that this cannot be done efficiently with the current API - and that is the issue that this change is running into that results in the instanceof checks in the constructors. I'm not suggesting adding an overloaded constructor that takes a DatagramSocketImpl. I don't believe that that is the right solution here, but I do think that we need to solve the general problem, then this change could use whatever solution is arrived at. -Chris. From Alan.Bateman at oracle.com Thu Jan 16 12:10:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2020 12:10:08 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket In-Reply-To: <34DB98E1-5268-4BBD-9192-A2F24C8D2B0C@oracle.com> References: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> <34DB98E1-5268-4BBD-9192-A2F24C8D2B0C@oracle.com> Message-ID: On 16/01/2020 11:45, Chris Hegarty wrote: > : > Generally, I agree with updating the socket adapter to support > multicast. It will certainly help with future work in this area. > > The instanceof checks in the constructors highlight that there is an > abstraction missing here - to support creating a custom MulticastSocket > implementation. If / When DatagramSocketImpl is deprecated, the advise > will likely be to subclass MulticastSocket if one wants to provide a > custom implementation. I believe that this cannot be done efficiently > with the current API - and that is the issue that this change is running > into that results in the instanceof checks in the constructors. The main API issues date back to choices made in JDK 1.0 but it's not clear to me that it's worth trying to fix them now. The extensibility could have been looked in JDK 1.4 when the protected constructor was added but even then, it's not clear that there was any interest in completely different implementations outside of the JDK. So if someone really wants to this now then they could create a DatagramSocketImpl and use the factory method to set it system-wide. I don't think we've ever seen anyone do that, maybe because that mechanism is very under specified, maybe because it would require accessing the internal representation of FileDescriptor and DatagramPacket. If that mechanism is deprecated and eventually removed (which is probably the right thing to do) then the only choice would be to extend and override all methods. Yes, I agree the check for the sub-class is ugly. The legacy implementation also has to check if it's a MulticastSocket so that the right impl is chosen. -Alan From chris.hegarty at oracle.com Thu Jan 16 12:42:51 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Jan 2020 12:42:51 +0000 Subject: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket In-Reply-To: References: <2f37a5d1-cb61-b84b-b4f2-9d204f0c2a83@oracle.com> <4cb5ab30-9c32-1214-fbf3-3e3df3a383da@oracle.com> <34DB98E1-5268-4BBD-9192-A2F24C8D2B0C@oracle.com> Message-ID: > On 16 Jan 2020, at 12:10, Alan Bateman wrote: > > On 16/01/2020 11:45, Chris Hegarty wrote: >> : >> Generally, I agree with updating the socket adapter to support >> multicast. It will certainly help with future work in this area. >> >> The instanceof checks in the constructors highlight that there is an >> abstraction missing here - to support creating a custom MulticastSocket >> implementation. If / When DatagramSocketImpl is deprecated, the advise >> will likely be to subclass MulticastSocket if one wants to provide a >> custom implementation. I believe that this cannot be done efficiently >> with the current API - and that is the issue that this change is running >> into that results in the instanceof checks in the constructors. > The main API issues date back to choices made in JDK 1.0 but it's not clear to me that it's worth trying to fix them now. The extensibility point of these APIs is DatagramSocketImpl, which was probably a reasonable design choice back in 1995. > The extensibility could have been looked in JDK 1.4 when the protected constructor was added but even then, Again, it appears that the design choice for significant extensibility is through the DatagramSocketImpl - not withstanding several oversights regarding compatible evolution of the decoupled socket types and the impl type. > it's not clear that there was any interest in completely different implementations outside of the JDK. True, but if DatagramSocketImpl is degraded, then there should be a viable alternative. > So if someone really wants to this now then they could create a DatagramSocketImpl and use the factory method to set it system-wide. I don't think we've ever seen anyone do that, maybe because that mechanism is very under specified, maybe because it would require accessing the internal representation of FileDescriptor and DatagramPacket. If that mechanism is deprecated and eventually removed (which is probably the right thing to do) then the only choice would be to extend and override all methods. Agreed. And then one runs straight into the same issue that is resulting in the instanceof checks - how can MulticastSocket be extended without triggering the creation of a built-in implementation? I'm saying that it is not (easily?) possible with the current API - hence the ugly instanceof some-internal-type checks (which non-JDK code cannot do). > Yes, I agree the check for the sub-class is ugly. The legacy implementation also has to check if it's a MulticastSocket so that the right impl is chosen. It's selecting an implementation based on its own known public API hierarchy, which seems reasonable. My intention is to highlight the missing design abstraction with the MulticastSocket API ( as I see it when grok'ing the instanceof checks), rather than getting in the way of this particular change, so I have filed a separate issue to track that [1]. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8237352 Evaluate how to write a custom MulticastSocket without using DatagramSocketImpl From brian.burkhalter at oracle.com Thu Jan 23 00:20:24 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 22 Jan 2020 16:20:24 -0800 Subject: [14-testbug] 8225471: Test utility jdk.test.lib.util.FileUtils.areAllMountPointsAccessible needs to tolerate duplicates Message-ID: <5DAD3E2E-6D98-4CCB-98D6-A8364FC236A1@oracle.com> To at least provisionally fix [1] so as not to fail java/nio/file/FileStore/Basic.java on misconfigured systems, the patch [2] is proposed. This affects non-Windows systems only. As in the previous version, the FileStore enumeration test is skipped if the ?df? command hangs a spawned process which is indicative of a network problem. In this version the FileStore enumeration test will also be skipped if any two lines of the ?df? output are equal. In the previous version a RuntimeException would be thrown if two consecutive lines of the ?df" output were equal and so the test would fail. This patch would remove that failure mode. Issue [3] is on file to perform further investigation of better handling of duplicate mount points at a later time. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8225471 [2] http://cr.openjdk.java.net/~bpb/8225471/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8225461 From Alan.Bateman at oracle.com Thu Jan 23 13:03:03 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Jan 2020 13:03:03 +0000 Subject: [14-testbug] 8225471: Test utility jdk.test.lib.util.FileUtils.areAllMountPointsAccessible needs to tolerate duplicates In-Reply-To: <5DAD3E2E-6D98-4CCB-98D6-A8364FC236A1@oracle.com> References: <5DAD3E2E-6D98-4CCB-98D6-A8364FC236A1@oracle.com> Message-ID: On 23/01/2020 00:20, Brian Burkhalter wrote: > To at least provisionally fix [1] so as not to fail java/nio/file/FileStore/Basic.java on misconfigured systems, the patch [2] is proposed. This affects non-Windows systems only. As in the previous version, the FileStore enumeration test is skipped if the ?df? command hangs a spawned process which is indicative of a network problem. In this version the FileStore enumeration test will also be skipped if any two lines of the ?df? output are equal. In the previous version a RuntimeException would be thrown if two consecutive lines of the ?df" output were equal and so the test would fail. This patch would remove that failure mode. Issue [3] is on file to perform further investigation of better handling of duplicate mount points at a later time. > This looks okay to me. -Alan From akashche at redhat.com Fri Jan 24 10:59:36 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Fri, 24 Jan 2020 10:59:36 +0000 Subject: [11u] RFR: 8216472: (se) Stack overflow during selection operation leads to crash (win) Message-ID: Hi, Please review the backport of JDK-8216472 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8216472 Original review thread: https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006684.html Original review thread (continuation): https://mail.openjdk.java.net/pipermail/nio-dev/2019-November/006777.html Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e 11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8216472/webrev.00/ Please note, that original change, besides moving structs off the stack, additionally removes the logic for the case, when select() call returns SOCKET_ERROR: - starting here: https://hg.openjdk.java.net/jdk/jdk/rev/6bc29ebe053e#l2.58 - explanation (point 1 there): https://mail.openjdk.java.net/pipermail/nio-dev/2019-October/006708.html To stay on the safe side with LTS versions, this 11u backport keeps select() failure logic intact and allocates the space for 6 fd_set structs (instead of 3 in original change). It is proposed to have the change added to 11u in this "fix only" form. And, if necessary, to remove select() failure logic in a follow-up change. Testing: 11u change in this form was included with Red Hat 11.0.6-windows release and passed usual release testing. -- -Alex From brian.burkhalter at oracle.com Fri Jan 24 22:21:53 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 24 Jan 2020 14:21:53 -0800 Subject: [15] 8220816: Files.createDirectory should make it more obvious that it fails when the directory already exists Message-ID: Please review this minor change [1] to address [2]. If it looks worthwhile to address then a CSR will be filed. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8220816/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8220816 From lance.andersen at oracle.com Fri Jan 24 22:46:31 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 24 Jan 2020 17:46:31 -0500 Subject: [15] 8220816: Files.createDirectory should make it more obvious that it fails when the directory already exists In-Reply-To: References: Message-ID: <41B79245-1BB3-44B6-BD22-690109D56EB0@oracle.com> Hi Brian, I understand what you are trying to clarify but I think it is still needs some wordsmithing: ?????? failing if the directory already exists. ????????? The exception is thrown if the entry specified for ?dir? exists so the entry could be a file or a directory Perhaps something along the lines of: ?An exception will be thrown if the specified Path already exists? Or something like that as that will cover the case of a file or directory. HTH BEst Lance > On Jan 24, 2020, at 5:21 PM, Brian Burkhalter wrote: > > Please review this minor change [1] to address [2]. If it looks worthwhile to address then a CSR will be filed. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8220816/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8220816 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From Alan.Bateman at oracle.com Mon Jan 27 13:27:06 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Jan 2020 13:27:06 +0000 Subject: [15] 8220816: Files.createDirectory should make it more obvious that it fails when the directory already exists In-Reply-To: References: Message-ID: On 24/01/2020 22:21, Brian Burkhalter wrote: > Please review this minor change [1] to address [2]. If it looks worthwhile to address then a CSR will be filed. If I read this correctly you've just changed the first line of the javadoc to add "if the directory already exists".? That probably should say "file or directory" as it may be a non-directory file. I agree with tweaking the description for when FileAlreadyExistsException is thrown but if will require a similar change, for consistency reasons, to the other methods that are specified to throw this exception. -Alan From brian.burkhalter at oracle.com Wed Jan 29 18:22:40 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 Jan 2020 10:22:40 -0800 Subject: 8237514: Spec Clarification - ByteBuffer::alignmentOffset Spec Message-ID: <9353E4DF-8E96-441A-BAB7-11ABDA3D0B92@oracle.com> This patch [1] is proposed for [2] which follows from the fix for [3] concerning the ByteBufffer.alignmentOffset() specification. In particular this adds a precondition, value <= index, on the first identity and attempts to improve the verbiage of the specification in general. Some code is added to the test to verify the identities. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8237514/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8237514 [3] https://bugs.openjdk.java.net/browse/JDK-8230665 From brian.burkhalter at oracle.com Wed Jan 29 23:49:46 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 Jan 2020 15:49:46 -0800 Subject: 8219014: (bf) Add absolute bulk put methods which accept a source Buffer Message-ID: <5F6F4823-8B99-48DB-9B7A-44CF2A3DADBD@oracle.com> Please consider this prototype fix [1] for [2]. The other potential method $Type$Buffer put(int index, $Type$Buffer src) {} mentioned in the issue description is not included here so as to avoid mixing relative bulk (for src) and absolute bulk (for this) operations, i.e., not having either buffer change state. The proposed method therefore simply is the equivalent of replacing the array parameter $type$[] of $Type$Buffer.put(int, $type$[], int, int) with a $Type$Buffer. More performant implementations specific to heap and direct buffers are intentionally omitted at this time but will be added later if this concept moves forward. One potentially problematic behavior in the proposed method is allowing overlapping source and target ranges when the source and target buffers are the same buffer. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8219014/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8219014 From jai.forums2013 at gmail.com Thu Jan 30 14:15:11 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 30 Jan 2020 19:45:11 +0530 Subject: JDK-8225507 - ZipFileSystem swallows IOExceptions Message-ID: <015c2df8-0acd-80a1-76e3-17465e4eac8e@gmail.com> In context of https://bugs.openjdk.java.net/browse/JDK-8225507 As noted by the reporter in that issue, it appears that there are couple of places in jdk.nio.zipfs.ZipFileSystem#sync (private method) where IOException(s) are caught and swallowed (like here[1]) without being propagated back. The comment on those lines seems to state that it's intentional, but looking at the history of that code, it appears to have been there since the beginning. So, is it still valid to catch the whole IOException in those blocks and ignore them? Shouldn't those invalid entries cause the exception to be propagated back? This sync method happens to be called (only) in the close() method, so propagating this exception would cause the close() to fail (with genuine issue), which shouldn't be a problem, isn't it? [1] https://hg.openjdk.java.net/jdk/jdk/file/0f53754d8577/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#l1752 -Jaikiran From Alan.Bateman at oracle.com Thu Jan 30 14:45:53 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2020 14:45:53 +0000 Subject: JDK-8225507 - ZipFileSystem swallows IOExceptions In-Reply-To: <015c2df8-0acd-80a1-76e3-17465e4eac8e@gmail.com> References: <015c2df8-0acd-80a1-76e3-17465e4eac8e@gmail.com> Message-ID: On 30/01/2020 14:15, Jaikiran Pai wrote: > In context of https://bugs.openjdk.java.net/browse/JDK-8225507 > > As noted by the reporter in that issue, it appears that there are couple > of places in jdk.nio.zipfs.ZipFileSystem#sync (private method) where > IOException(s) are caught and swallowed (like here[1]) without being > propagated back. The comment on those lines seems to state that it's > intentional, but looking at the history of that code, it appears to have > been there since the beginning. This need careful examination. The zipfs provider has its roots as a demo to exercise the file system provider mechanism and it's possible that these issues date back to then. -Alan From paul.sandoz at oracle.com Thu Jan 30 17:01:18 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Jan 2020 09:01:18 -0800 Subject: 8237514: Spec Clarification - ByteBuffer::alignmentOffset Spec In-Reply-To: <9353E4DF-8E96-441A-BAB7-11ABDA3D0B92@oracle.com> References: <9353E4DF-8E96-441A-BAB7-11ABDA3D0B92@oracle.com> Message-ID: <42843D95-7821-4800-BFD5-1C7791C4BDFE@oracle.com> Hi, Looks good. I hope we can lay this one to rest now :-) Paul. > On Jan 29, 2020, at 10:22 AM, Brian Burkhalter wrote: > > This patch [1] is proposed for [2] which follows from the fix for [3] concerning the ByteBufffer.alignmentOffset() specification. In particular this adds a precondition, value <= index, on the first identity and attempts to improve the verbiage of the specification in general. Some code is added to the test to verify the identities. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8237514/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8237514 > [3] https://bugs.openjdk.java.net/browse/JDK-8230665 From Alan.Bateman at oracle.com Thu Jan 30 17:10:43 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Jan 2020 17:10:43 +0000 Subject: 8237514: Spec Clarification - ByteBuffer::alignmentOffset Spec In-Reply-To: <42843D95-7821-4800-BFD5-1C7791C4BDFE@oracle.com> References: <9353E4DF-8E96-441A-BAB7-11ABDA3D0B92@oracle.com> <42843D95-7821-4800-BFD5-1C7791C4BDFE@oracle.com> Message-ID: <837a508f-1ba0-7d95-15a0-593c4ae90637@oracle.com> On 30/01/2020 17:01, Paul Sandoz wrote: > Hi, > > Looks good. I hope we can lay this one to rest now :-) > > I agree, I think the spec is complete now and the additional test coverage is good. Brian - the webrev is against jdk/jdk14, the bug fixVersion says "tbd". I don't think this is super critical for 14 but docs and test changes are allowed in RDP2. -Alan From jai.forums2013 at gmail.com Fri Jan 31 06:32:55 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 31 Jan 2020 12:02:55 +0530 Subject: RFR: JDK-8225507: (zipfs): No space left on device not thrown with ZipFileSystem Message-ID: <50746bf1-1d46-a0de-b9b5-2fc1aaaa5c7e@gmail.com> Initial discussion about this was done here https://mail.openjdk.java.net/pipermail/nio-dev/2020-January/007014.html I looked into this in a bit more detail. The first place where this IOException is caught and swallowed involves the following code: try { ??? if (e.type == Entry.COPY) { ??????? // entry copy: the only thing changed is the "name" ??????? // and "nlen" in LOC header, so we update/rewrite the ??????? // LOC in new file and simply copy the rest (data and ??????? // ext) without enflating/deflating from the old zip ??????? // file LOC entry. ??????? if (buf == null) ??????????? buf = new byte[8192]; ??????? written += copyLOCEntry(e, true, os, written, buf); ??? } else {????????????????????????? // NEW, FILECH or CEN ??????? e.locoff = written; ??????? written += e.writeLOC(os);??? // write loc header ??????? written += writeEntry(e, os); ??? } ??? elist.add(e); } catch (IOException x) { ??? x.printStackTrace();??? // skip any in-accurate entry } In this, the copyLOCEntry(...), the writeLOC(...) and the writeEntry(...) methods can potentially throw the IOException. Looking at each of these methods, ??? - The copyLOCEntry throws an IOException if it fails to write out data to the OutputStream. It additionally throws a ZipException (which is an IOException) if it fails to read a LOC. ??? - The Entry#writeLOC method takes a OutputStream and writes out LOC data to that stream and can potentially throw an IOException if the writes to the stream fail. ??? - The writeEntry method writes out the actual data to the OutputStream and uses the "transferTo" API. Additionally this method also deletes (any) temp file that might have been created for holding the "Entry" content. Either of these cases can throw an IOException. So in all these above 3 methods, the potential IOException(s) are all genuine issue that I think should propagate back. The only one that I'm unsure is the case in writeEntry, where it does a Files.delete(e.file) where e.file is any temporary file that was created previously to hold on to the entry data. Should any IOException on this line propagate back? Perhaps it should, or else it would potentially leave the temp file (containing the actual data) around without the user knowing that it got left behind. The other place where the IOException gets swallowed is this block: try { ??? if (buf == null) ??????? buf = new byte[8192]; ??? written += copyLOCEntry(e, false, os, written, buf); ??? elist.add(e); } catch (IOException x) { ??? x.printStackTrace();??? // skip any wrong entry } In this case the only potential call which can trigger the IOException is the copyLOCEntry, which is actually the same method that we analyzed above. So overall, I think propagating these IOException(s) should be fine since they expose any real underlying issue. I've created a webrev which includes this change and is placed here[1]. If the idea to propagate this exception back and the above analysis seems right, can I get a review and a sponsor for the patch please? Given the nature of this issue, I couldn't think of any easy and consistent test case to add for this change. However, I have ran the test/jdk/jdk/nio/ jtreg tests and they have allowed passed: jtreg -jdk:build/macosx-x86_64-server-release/images/jdk test/jdk/jdk/nio/ Test results: passed: 21 [1] https://cr.openjdk.java.net/~jpai/webrev/8225507/1/webrev/ -Jaikiran From jai.forums2013 at gmail.com Fri Jan 31 06:34:30 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 31 Jan 2020 12:04:30 +0530 Subject: JDK-8225507 - ZipFileSystem swallows IOExceptions In-Reply-To: References: <015c2df8-0acd-80a1-76e3-17465e4eac8e@gmail.com> Message-ID: <128bcf85-1c4e-d6f7-6488-ae68ea404154@gmail.com> Hello Alan, On 30/01/20 8:15 pm, Alan Bateman wrote: > On 30/01/2020 14:15, Jaikiran Pai wrote: >> In context of https://bugs.openjdk.java.net/browse/JDK-8225507 >> >> As noted by the reporter in that issue, it appears that there are couple >> of places in jdk.nio.zipfs.ZipFileSystem#sync (private method) where >> IOException(s) are caught and swallowed (like here[1]) without being >> propagated back. The comment on those lines seems to state that it's >> intentional, but looking at the history of that code, it appears to have >> been there since the beginning. > This need careful examination. The zipfs provider has its roots as a > demo to exercise the file system provider mechanism and it's possible > that these issues date back to then. Thank you for this input. I have done a bit more detailed analysis of this and opened an official RFR thread here https://mail.openjdk.java.net/pipermail/nio-dev/2020-January/007017.html -Jaikiran