From clanger at openjdk.org  Tue Aug  1 07:39:49 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 07:39:49 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX
In-Reply-To: <uLRrdcs2VzSEk_6jmaJsExXMG3jzXUToTfcUzvUMIWo=.e84128c2-938b-4e5a-bdf4-1f4dfc70ca55@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <BZ29JtKZkuE4xYm_9P37LNIBr0vhyZrD8GgPgoGPYe4=.a2932495-4a1a-4c52-9fa3-8e8aa8a02b10@github.com>
 <1Z0ZRusTwhyQFpuriQOAF_o67P-SuyBj18gnoZPnHSY=.02d2c9c0-56c6-4357-816c-917bdcab1282@github.com>
 <uLRrdcs2VzSEk_6jmaJsExXMG3jzXUToTfcUzvUMIWo=.e84128c2-938b-4e5a-bdf4-1f4dfc70ca55@github.com>
Message-ID: <SSkq93VqFkUlZRdBDE1ob2HjKhfslPuX4Z09oYPiK28=.ed3523c0-cf0b-4897-a536-f9266a91a4ad@github.com>

On Mon, 31 Jul 2023 19:56:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > We should probably add them here, too.
> 
> java/nio/channels/DatagramChannel/SendReceiveMaxSize.java doesn't do multicasting but maybe it is excluded on that platform for some other reason? There are several DatagramChannel tests that do exercise multicast and I suspect they will fail on platforms that don't allow dual IPv4/IPv6 sockets to join IPv4 multicast groups.

I checked. SendReceiveMaxSize times out, probably for some other reason. So it should not be excluded here. But AfterDisconnect fails due to the IPv4/IPv6 issue, so this fits here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15074#issuecomment-1659738268

From duke at openjdk.org  Tue Aug  1 08:19:54 2023
From: duke at openjdk.org (Thomas Obermeier)
Date: Tue, 1 Aug 2023 08:19:54 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v2]
In-Reply-To: <HCt57ZixenStpruFesPFkS1pmHCqTOCniZlId2OxLPQ=.03e66382-adb5-412b-b267-f4ceb411b8bd@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <HCt57ZixenStpruFesPFkS1pmHCqTOCniZlId2OxLPQ=.03e66382-adb5-412b-b267-f4ceb411b8bd@github.com>
Message-ID: <GnQntw-jfro9M2ttmcOCi5bQKoCbaAaP8vOVpmhjJ7o=.69c3a78f-989f-44bc-9227-dd939c6a48be@github.com>

On Mon, 31 Jul 2023 09:32:18 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

>> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.
>
> Thomas Obermeier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807

I can confirm this and will add DatagramChannel soon. SendReceiveMaxSize never returns from a native call to recvfrom...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15074#issuecomment-1659805770

From duke at openjdk.org  Tue Aug  1 08:32:07 2023
From: duke at openjdk.org (Thomas Obermeier)
Date: Tue, 1 Aug 2023 08:32:07 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v3]
In-Reply-To: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
Message-ID: <8tTarp8GaajV7FeR2W4sOFthz2KeiP5LjDwE2CL2x2k=.83143fdb-5bf0-4bf1-812b-341f87001b55@github.com>

> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.

Thomas Obermeier has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-1
 - Update ProblemList.txt: exclude DatagramChannel/AfterDisconnect for 8308807 aix-ppc64
 - Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807
 - Merge branch 'master' into patch-1
 - Update ProblemList.txt exclude MulticastSocket tests for AIX
 - Update ProblemList.txt exclude java/foreign/TestByteBuffer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15074/files
  - new: https://git.openjdk.org/jdk/pull/15074/files/0fe3eaec..b322c25c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15074&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15074&range=01-02

  Stats: 5735 lines in 166 files changed: 2564 ins; 1652 del; 1519 mod
  Patch: https://git.openjdk.org/jdk/pull/15074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15074/head:pull/15074

PR: https://git.openjdk.org/jdk/pull/15074

From djelinski1 at gmail.com  Tue Aug  1 08:39:26 2023
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Tue, 1 Aug 2023 10:39:26 +0200
Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On
 Windows
In-Reply-To: <BYAPR21MB13015DF3AAD8A15A2951972DE106A@BYAPR21MB1301.namprd21.prod.outlook.com>
References: <BYAPR21MB13016CB97B7AB10282AC8284E14EA@BYAPR21MB1301.namprd21.prod.outlook.com>
 <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com>
 <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com>
 <bc2e3790-21bf-dc7a-c95b-0ffb11be8860@oracle.com>
 <BYAPR21MB1301DAC766A234D7B707B54CE14DA@BYAPR21MB1301.namprd21.prod.outlook.com>
 <bc68fd94-137b-0193-1a87-4c9228e396ef@oracle.com>
 <BYAPR21MB13018A2D91378EA279E2F1BCE152A@BYAPR21MB1301.namprd21.prod.outlook.com>
 <CAMrH03Jfk0nNSAzfEmJFDYOU=siqDegPob5qN_0W7GxuVXKgUw@mail.gmail.com>
 <BYAPR21MB1301A4C44CEF8679B1A45D48E150A@BYAPR21MB1301.namprd21.prod.outlook.com>
 <BYAPR21MB13015DF3AAD8A15A2951972DE106A@BYAPR21MB1301.namprd21.prod.outlook.com>
Message-ID: <CAMrH03Lu8=XfX_9awyKgMV_eHT8RCp5amxXhaaes82HzirrN2w@mail.gmail.com>

Hi Terry,
IMO this change is a very reasonable candidate for backporting.

Here's the guideline for backporting, if you're interested in doing that:
https://wiki.openjdk.org/display/JDKUpdates/How+to+contribute+or+backport+a+fix

Regards,
Daniel

pt., 28 lip 2023 o 22:51 Terry Chow (Simba Technologies Inc)
<v-terrychow at microsoft.com> napisa?(a):
>
> Hi all,
>
> I was wondering if there was any chance in the future that this patch would be backported to the LTS versions of the JDK.
>
> Thanks,
> Terry
> ________________________________
> From: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>
> Sent: June 7, 2023 7:00 PM
> To: Daniel Jeli?ski <djelinski1 at gmail.com>
> Cc: Daniel Fuchs <daniel.fuchs at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
> Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows
>
> Hi Daniel Jeli?ski,
>
> Thanks for pointing that out. I completely overlooked that doc page. That definitely does look like the best way to conform to how things currently are.
>
> There shouldn't be any protest from my team on waiting out older Windows versions (I'll need to double check though).
>
> Thanks,
> Terry
> ________________________________
> From: Daniel Jeli?ski <djelinski1 at gmail.com>
> Sent: June 7, 2023 5:48 AM
> To: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>
> Cc: Daniel Fuchs <daniel.fuchs at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
> Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows
>
> [You don't often get email from djelinski1 at gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> FWIW, TCP_KEEPIDLE and TCP_KEEPINTVL are available on Windows,
> starting with Windows 10, version 1709:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fwinsock%2Fipproto-tcp-socket-options&data=05%7C01%7Cv-terrychow%40microsoft.com%7C0dbf70ca1ce047e8370408db675584b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638217389237258798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JVQxjufRqw84LssZX%2BmRNRxf8tH3OEriTzmWc5tSE8E%3D&reserved=0
>
> Apparently TCP_KEEPCNT is available too. Can we use these options and
> wait for older Windows versions to go out of support?
> Regards,
> Daniel
>
> ?r., 7 cze 2023 o 00:43 Terry Chow (Simba Technologies Inc)
> <v-terrychow at microsoft.com> napisa?(a):
> >
> > Hi Daniel,
> >
> > That sounds good. I like the idea of using a system property to override the defaults just in case. For the starting default values, 2hrs and 1s for idle time and interval time respectively are the officially documented defaults. So, we could start with these.
> >
> > Just to reiterate, to start off with the prototype:
> >
> > Persist default values at the socket level in either SocketImpl or NIOSocketImpl
> > Allow default values to be overridden through system properties
> > Starting default values for idle time and interval time will be 2hrs and 1s
> >
> > Let me know if that's acceptable or if there's more to add.
> >
> > Thanks,
> > Terry
> > ________________________________
> > From: Daniel Fuchs <daniel.fuchs at oracle.com>
> > Sent: June 6, 2023 4:22 AM
> > To: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
> > Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows
> >
> > [You don't often get email from daniel.fuchs at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Terry,
> >
> > I'm not sure what would be a good default value, but it could
> > possibly be controlled by a system property allowing to override
> > whatever we pick.
> >
> > best regards,
> >
> > -- daniel
> >
> >
> > On 05/06/2023 20:52, Terry Chow (Simba Technologies Inc) wrote:
> > > Hi Alan and Daniel,
> > >
> > > Agreed, having Windows support the keepalive options as it's done on
> > > other platforms would be the best. But, lobbying them for that change
> > > would be extremely difficult as it would be very significant change that
> > > impacts the whole platform.
> > >
> > > What defaults values do you guys have in mind? I'm still hesitating on
> > > persisting default values because the default values can vary between
> > > machines.
> > >
> > > Thanks,
> > > Terry
> > > ------------------------------------------------------------------------
> > > *From:* Alan Bateman <Alan.Bateman at oracle.com>
> > > *Sent:* June 4, 2023 7:32 AM
> > > *To:* Daniel Fuchs <daniel.fuchs at oracle.com>; Terry Chow (Simba
> > > Technologies Inc) <v-terrychow at microsoft.com>; net-dev at openjdk.org
> > > <net-dev at openjdk.org>
> > > *Subject:* [EXTERNAL] Re: Support for Keepalive Extended Socket Options
> > > On Windows
> > > [You don't often get email from alan.bateman at oracle.com. Learn why this
> > > is important at https://aka.ms/LearnAboutSenderIdentification
> > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!ACWV5N9M2RV99hQ!L3ZqYRNNOoxRi17MfA-Xuhn96mbJFGf8N9hRRT_fKwRroiRBdo_QNCcfm6-S-qa3FXTquasM6y3tpVE_ac_Dl3MS7A%24&data=05%7C01%7Cv-terrychow%40microsoft.com%7C0dbf70ca1ce047e8370408db675584b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638217389237258798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RaTlqhm2zVXIT2ilG046bBUvd7LTOBIxLbVldHq%2BhVQ%3D&reserved=0> ]
> > >
> > > On 04/06/2023 10:49, Daniel Fuchs wrote:
> > >> Hi,
> > >>
> > >> Could we maybe cache the values in the SocketImpl/NIOSocketImpl
> > >> implementation?
> > >>
> > >> IIRC we do something like that for SO_TIMEOUT already, since this
> > >> is handled at NIO level.
> > >>
> > >> If we know the default value then setting one (when the other is
> > >> not set) could set it with the supplied value for the one, and
> > >> the default (or cached value) for the other?
> > >>
> > >> Get would then return the cached value (or possibly default
> > >> value if not set?)
> > >>
> > >> We could also potentially set some sensible defaults when creating
> > >> the socket.
> > >>
> > > Yes, this is what I was suggesting in PR14232 too but it will likely be
> > > a disruptive change. It can be prototyped at least, then we can see how
> > > we could turn it into something that is maintainable. The best outcome
> > > would of course be for Windows to expose the socket options in the same
> > > way as Linux, macOS and others.
> > >
> > > -Alan
> >

From alanb at openjdk.org  Tue Aug  1 10:35:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Aug 2023 10:35:53 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX
In-Reply-To: <SSkq93VqFkUlZRdBDE1ob2HjKhfslPuX4Z09oYPiK28=.ed3523c0-cf0b-4897-a536-f9266a91a4ad@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <BZ29JtKZkuE4xYm_9P37LNIBr0vhyZrD8GgPgoGPYe4=.a2932495-4a1a-4c52-9fa3-8e8aa8a02b10@github.com>
 <1Z0ZRusTwhyQFpuriQOAF_o67P-SuyBj18gnoZPnHSY=.02d2c9c0-56c6-4357-816c-917bdcab1282@github.com>
 <uLRrdcs2VzSEk_6jmaJsExXMG3jzXUToTfcUzvUMIWo=.e84128c2-938b-4e5a-bdf4-1f4dfc70ca55@github.com>
 <SSkq93VqFkUlZRdBDE1ob2HjKhfslPuX4Z09oYPiK28=.ed3523c0-cf0b-4897-a536-f9266a91a4ad@github.com>
Message-ID: <k_1uRw6Z6Sm9CNUD0DhnZXbEMvUHYPKygPgBSXBUEBg=.266a1a3f-9fc4-4fe0-add7-3792da629a08@github.com>

On Tue, 1 Aug 2023 07:36:58 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I checked. SendReceiveMaxSize times out, probably for some other reason. So it should not be excluded here. But AfterDisconnect fails due to the IPv4/IPv6 issue, so this fits here.

That's fine. The tests that I expected to see listed are tests such as BasicMulticastTests, MulticastSendReceiveTests, AdaptorMulticasting and several others but maybe they are passing on this platform.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15074#issuecomment-1660037508

From clanger at openjdk.org  Tue Aug  1 13:46:47 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 13:46:47 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v3]
In-Reply-To: <TzfmTpJEmq6APn8YUNusQvAiJLP7JM7GjyOdPVJtDDE=.59149734-682f-42e9-88c4-97a168669b67@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <K4hg0F1rjwjcGvtGK9RcnG3CK4Uz9PBYfKO5HeiMUd8=.72826d2a-1beb-41d4-9484-f1cf170efb2c@github.com>
 <AyYujnoklGwODGZX9tNDSp-hwl9Iy1gSMI5tYLEl5Dk=.55666e11-5dce-4ef0-b399-9d82ec3b841b@github.com>
 <KLVdgb-HdwEAWrWwcEzNRV2BAa6AwgfPmSjA1jpxGOI=.4647de72-34c6-405a-a8f0-a5bec553008a@github.com>
 <YRJi5AF4aLVcoVRtjVveLC6Dh5tpciGIAsdjaoipDCw=.7a644c38-a76e-45fe-aa4f-87ee0d4ee94c@github.com>
 <TzfmTpJEmq6APn8YUNusQvAiJLP7JM7GjyOdPVJtDDE=.59149734-682f-42e9-88c4-97a168669b67@github.com>
Message-ID: <BvTiCsAZToPY7MjYPyUSzdHewwyNK7gsWROfnneIy2Q=.f9861a20-c868-4271-871f-d9434a72b96d@github.com>

On Mon, 31 Jul 2023 11:05:04 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> I don't have a string opinion either way. I think the main thing is that I suspect you'll need to exclude more tests as there are several tests for DatagramChannel that join multicast groups and some of these likely assume they can join an IPv4 multicast group when cases where the DatagramChannel is created with the no-arg open method (and IPv6 is enabled) or with the IPV6 protocol family.
>
> I've created https://bugs.openjdk.org/browse/JDK-8313404 to extract the fix for jdk_foreign from this PR. It's cleaner, also for backporting, although it incurs some process overhead.

As discussed, please remove this part of the change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15074#discussion_r1280668894

From duke at openjdk.org  Tue Aug  1 13:55:30 2023
From: duke at openjdk.org (Thomas Obermeier)
Date: Tue, 1 Aug 2023 13:55:30 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v4]
In-Reply-To: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
Message-ID: <a4qMggw2fZE54F9GDD7ToNmCIM9HO-O_qEGsA0hSCb0=.a0431b93-efe9-4949-b6f2-e3948b6c954f@github.com>

> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.

Thomas Obermeier has updated the pull request incrementally with one additional commit since the last revision:

  Update ProblemList.txt restore bad hunk java/foreign to have it repaired in deticated PR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15074/files
  - new: https://git.openjdk.org/jdk/pull/15074/files/b322c25c..84c6ef5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15074&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15074&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15074/head:pull/15074

PR: https://git.openjdk.org/jdk/pull/15074

From duke at openjdk.org  Tue Aug  1 14:06:12 2023
From: duke at openjdk.org (Thomas Obermeier)
Date: Tue, 1 Aug 2023 14:06:12 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v5]
In-Reply-To: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
Message-ID: <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>

> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.

Thomas Obermeier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into patch-1
 - Update ProblemList.txt restore bad hunk java/foreign to have it repaired in deticated PR
 - Merge branch 'openjdk:master' into patch-1
 - Update ProblemList.txt: exclude DatagramChannel/AfterDisconnect for 8308807 aix-ppc64
 - Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807
 - Merge branch 'master' into patch-1
 - Update ProblemList.txt exclude MulticastSocket tests for AIX
 - Update ProblemList.txt exclude java/foreign/TestByteBuffer

-------------

Changes: https://git.openjdk.org/jdk/pull/15074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15074&range=04
  Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15074/head:pull/15074

PR: https://git.openjdk.org/jdk/pull/15074

From clanger at openjdk.org  Tue Aug  1 14:33:53 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 14:33:53 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v5]
In-Reply-To: <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
Message-ID: <2nE5JgMyInCj29MGFBle72pzVH0JgNCN6OQ9VCTL-_w=.cffe845d-7c50-4f02-a1d8-4baf9f30d296@github.com>

On Tue, 1 Aug 2023 14:06:12 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

>> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.
>
> Thomas Obermeier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt restore bad hunk java/foreign to have it repaired in deticated PR
>  - Merge branch 'openjdk:master' into patch-1
>  - Update ProblemList.txt: exclude DatagramChannel/AfterDisconnect for 8308807 aix-ppc64
>  - Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt exclude MulticastSocket tests for AIX
>  - Update ProblemList.txt exclude java/foreign/TestByteBuffer

Looks good now.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15074#pullrequestreview-1557154668

From duke at openjdk.org  Tue Aug  1 14:48:53 2023
From: duke at openjdk.org (Michael Felt)
Date: Tue, 1 Aug 2023 14:48:53 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v5]
In-Reply-To: <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
Message-ID: <3MF3jfAiF79xskNaN5d7Qv3kSs9-Ao7nQuzHhClf2Xs=.a9b8dc0c-f10e-46b1-819d-6b10c5192e56@github.com>

On Tue, 1 Aug 2023 14:06:12 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

>> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.
>
> Thomas Obermeier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt restore bad hunk java/foreign to have it repaired in deticated PR
>  - Merge branch 'openjdk:master' into patch-1
>  - Update ProblemList.txt: exclude DatagramChannel/AfterDisconnect for 8308807 aix-ppc64
>  - Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt exclude MulticastSocket tests for AIX
>  - Update ProblemList.txt exclude java/foreign/TestByteBuffer

fyi: iirc, sendmaxsize stuff fails when it exceeds 4G in /tmp, asm by default, that is the size of /tmp on AIX systems configured by the ansible playbooks. There can be other issues - also resolved with the correct AIX settings (iirc, no settings for maxbuf, and max tcp and udp buffer sizes.

imho: correct to include the transfer size tests, but when they became 2x 2.1 G (which becomes 4.2G) - these tests failed until /tmp was increased to 5G.

Unlike many Linux systems, "rootvg" on AIX is several, interdependently sized filesystems.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15074#issuecomment-1660476551

From duke at openjdk.org  Tue Aug  1 15:35:00 2023
From: duke at openjdk.org (Thomas Obermeier)
Date: Tue, 1 Aug 2023 15:35:00 GMT
Subject: Integrated: 8313256: Exclude failing multicast tests on AIX
In-Reply-To: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
Message-ID: <-En0GPJC2MwUw3S7i6TYXzg_t_RJ-lUX6X9EzhsUX_4=.128ef5f2-542c-476c-91b0-32b008f52c1f@github.com>

On Fri, 28 Jul 2023 15:57:50 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.

This pull request has now been integrated.

Changeset: 98a915a5
Author:    Thomas Obermeier <128162199+TOatGithub at users.noreply.github.com>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98a915a54ce62da7cebc1f0ab07dab276291a1d1
Stats:     12 lines in 1 file changed: 6 ins; 0 del; 6 mod

8313256: Exclude failing multicast tests on AIX

Reviewed-by: clanger

-------------

PR: https://git.openjdk.org/jdk/pull/15074

From alanb at openjdk.org  Tue Aug  1 16:39:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Aug 2023 16:39:59 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v5]
In-Reply-To: <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
Message-ID: <NzcJljjT-eQdpDM4feVF87WM2Sb6sQ-uKkhn4A2ePys=.0596c345-56b0-421f-9b9e-c47a22a86324@github.com>

On Tue, 1 Aug 2023 14:06:12 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

>> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.
>
> Thomas Obermeier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt restore bad hunk java/foreign to have it repaired in deticated PR
>  - Merge branch 'openjdk:master' into patch-1
>  - Update ProblemList.txt: exclude DatagramChannel/AfterDisconnect for 8308807 aix-ppc64
>  - Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt exclude MulticastSocket tests for AIX
>  - Update ProblemList.txt exclude java/foreign/TestByteBuffer

I see this has been integrated, were you able to confirm that the DC multicast tests are passing on this platform?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15074#issuecomment-1660696547

From v-terrychow at microsoft.com  Tue Aug  1 16:48:52 2023
From: v-terrychow at microsoft.com (Terry Chow (Simba Technologies Inc))
Date: Tue, 1 Aug 2023 16:48:52 +0000
Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On
 Windows
In-Reply-To: <CAMrH03Lu8=XfX_9awyKgMV_eHT8RCp5amxXhaaes82HzirrN2w@mail.gmail.com>
References: <BYAPR21MB13016CB97B7AB10282AC8284E14EA@BYAPR21MB1301.namprd21.prod.outlook.com>
 <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com>
 <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com>
 <bc2e3790-21bf-dc7a-c95b-0ffb11be8860@oracle.com>
 <BYAPR21MB1301DAC766A234D7B707B54CE14DA@BYAPR21MB1301.namprd21.prod.outlook.com>
 <bc68fd94-137b-0193-1a87-4c9228e396ef@oracle.com>
 <BYAPR21MB13018A2D91378EA279E2F1BCE152A@BYAPR21MB1301.namprd21.prod.outlook.com>
 <CAMrH03Jfk0nNSAzfEmJFDYOU=siqDegPob5qN_0W7GxuVXKgUw@mail.gmail.com>
 <BYAPR21MB1301A4C44CEF8679B1A45D48E150A@BYAPR21MB1301.namprd21.prod.outlook.com>
 <BYAPR21MB13015DF3AAD8A15A2951972DE106A@BYAPR21MB1301.namprd21.prod.outlook.com>
 <CAMrH03Lu8=XfX_9awyKgMV_eHT8RCp5amxXhaaes82HzirrN2w@mail.gmail.com>
Message-ID: <BYAPR21MB130180AA37D404444E929EAFE10AA@BYAPR21MB1301.namprd21.prod.outlook.com>

Thanks for the info Daniel. I'll check out the guidelines linked.

Regards,
Terry
________________________________
From: Daniel Jeli?ski <djelinski1 at gmail.com>
Sent: August 1, 2023 1:39 AM
To: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>
Cc: Daniel Fuchs <daniel.fuchs at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows

Hi Terry,
IMO this change is a very reasonable candidate for backporting.

Here's the guideline for backporting, if you're interested in doing that:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.org%2Fdisplay%2FJDKUpdates%2FHow%2Bto%2Bcontribute%2Bor%2Bbackport%2Ba%2Bfix&data=05%7C01%7Cv-terrychow%40microsoft.com%7Cd7de7e5916f84091562708db926ad811%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638264759832351994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RfWcfV18ULTh7B5CwDB1FzLq4%2B8gf0lSj26cEoW3UhA%3D&reserved=0<https://wiki.openjdk.org/display/JDKUpdates/How+to+contribute+or+backport+a+fix>

Regards,
Daniel

pt., 28 lip 2023 o 22:51 Terry Chow (Simba Technologies Inc)
<v-terrychow at microsoft.com> napisa?(a):
>
> Hi all,
>
> I was wondering if there was any chance in the future that this patch would be backported to the LTS versions of the JDK.
>
> Thanks,
> Terry
> ________________________________
> From: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>
> Sent: June 7, 2023 7:00 PM
> To: Daniel Jeli?ski <djelinski1 at gmail.com>
> Cc: Daniel Fuchs <daniel.fuchs at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
> Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows
>
> Hi Daniel Jeli?ski,
>
> Thanks for pointing that out. I completely overlooked that doc page. That definitely does look like the best way to conform to how things currently are.
>
> There shouldn't be any protest from my team on waiting out older Windows versions (I'll need to double check though).
>
> Thanks,
> Terry
> ________________________________
> From: Daniel Jeli?ski <djelinski1 at gmail.com>
> Sent: June 7, 2023 5:48 AM
> To: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>
> Cc: Daniel Fuchs <daniel.fuchs at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
> Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows
>
> [You don't often get email from djelinski1 at gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> FWIW, TCP_KEEPIDLE and TCP_KEEPINTVL are available on Windows,
> starting with Windows 10, version 1709:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fwinsock%2Fipproto-tcp-socket-options&data=05%7C01%7Cv-terrychow%40microsoft.com%7Cd7de7e5916f84091562708db926ad811%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638264759832351994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=udKDdn55S%2F4sw6hONFC33EV96D4VXEw%2Fbz%2BclRWIw0c%3D&reserved=0<https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-tcp-socket-options>
>
> Apparently TCP_KEEPCNT is available too. Can we use these options and
> wait for older Windows versions to go out of support?
> Regards,
> Daniel
>
> ?r., 7 cze 2023 o 00:43 Terry Chow (Simba Technologies Inc)
> <v-terrychow at microsoft.com> napisa?(a):
> >
> > Hi Daniel,
> >
> > That sounds good. I like the idea of using a system property to override the defaults just in case. For the starting default values, 2hrs and 1s for idle time and interval time respectively are the officially documented defaults. So, we could start with these.
> >
> > Just to reiterate, to start off with the prototype:
> >
> > Persist default values at the socket level in either SocketImpl or NIOSocketImpl
> > Allow default values to be overridden through system properties
> > Starting default values for idle time and interval time will be 2hrs and 1s
> >
> > Let me know if that's acceptable or if there's more to add.
> >
> > Thanks,
> > Terry
> > ________________________________
> > From: Daniel Fuchs <daniel.fuchs at oracle.com>
> > Sent: June 6, 2023 4:22 AM
> > To: Terry Chow (Simba Technologies Inc) <v-terrychow at microsoft.com>; Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.org <net-dev at openjdk.org>
> > Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows
> >
> > [You don't often get email from daniel.fuchs at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Terry,
> >
> > I'm not sure what would be a good default value, but it could
> > possibly be controlled by a system property allowing to override
> > whatever we pick.
> >
> > best regards,
> >
> > -- daniel
> >
> >
> > On 05/06/2023 20:52, Terry Chow (Simba Technologies Inc) wrote:
> > > Hi Alan and Daniel,
> > >
> > > Agreed, having Windows support the keepalive options as it's done on
> > > other platforms would be the best. But, lobbying them for that change
> > > would be extremely difficult as it would be very significant change that
> > > impacts the whole platform.
> > >
> > > What defaults values do you guys have in mind? I'm still hesitating on
> > > persisting default values because the default values can vary between
> > > machines.
> > >
> > > Thanks,
> > > Terry
> > > ------------------------------------------------------------------------
> > > *From:* Alan Bateman <Alan.Bateman at oracle.com>
> > > *Sent:* June 4, 2023 7:32 AM
> > > *To:* Daniel Fuchs <daniel.fuchs at oracle.com>; Terry Chow (Simba
> > > Technologies Inc) <v-terrychow at microsoft.com>; net-dev at openjdk.org
> > > <net-dev at openjdk.org>
> > > *Subject:* [EXTERNAL] Re: Support for Keepalive Extended Socket Options
> > > On Windows
> > > [You don't often get email from alan.bateman at oracle.com. Learn why this
> > > is important at https://aka.ms/LearnAboutSenderIdentification
> > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!ACWV5N9M2RV99hQ!L3ZqYRNNOoxRi17MfA-Xuhn96mbJFGf8N9hRRT_fKwRroiRBdo_QNCcfm6-S-qa3FXTquasM6y3tpVE_ac_Dl3MS7A%24&data=05%7C01%7Cv-terrychow%40microsoft.com%7Cd7de7e5916f84091562708db926ad811%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638264759832351994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HtMUGDpy8G1B4vMZItPjJJ18lJhst4wcmmQ74DYRwOY%3D&reserved=0<https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!ACWV5N9M2RV99hQ!L3ZqYRNNOoxRi17MfA-Xuhn96mbJFGf8N9hRRT_fKwRroiRBdo_QNCcfm6-S-qa3FXTquasM6y3tpVE_ac_Dl3MS7A$>> ]
> > >
> > > On 04/06/2023 10:49, Daniel Fuchs wrote:
> > >> Hi,
> > >>
> > >> Could we maybe cache the values in the SocketImpl/NIOSocketImpl
> > >> implementation?
> > >>
> > >> IIRC we do something like that for SO_TIMEOUT already, since this
> > >> is handled at NIO level.
> > >>
> > >> If we know the default value then setting one (when the other is
> > >> not set) could set it with the supplied value for the one, and
> > >> the default (or cached value) for the other?
> > >>
> > >> Get would then return the cached value (or possibly default
> > >> value if not set?)
> > >>
> > >> We could also potentially set some sensible defaults when creating
> > >> the socket.
> > >>
> > > Yes, this is what I was suggesting in PR14232 too but it will likely be
> > > a disruptive change. It can be prototyped at least, then we can see how
> > > we could turn it into something that is maintainable. The best outcome
> > > would of course be for Windows to expose the socket options in the same
> > > way as Linux, macOS and others.
> > >
> > > -Alan
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230801/965a7504/attachment-0001.htm>

From clanger at openjdk.org  Tue Aug  1 22:19:16 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 22:19:16 GMT
Subject: [jdk21] RFR: 8313256: Exclude failing multicast tests on AIX
Message-ID: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>

Hi all,

This pull request contains a backport of [JDK-8313256](https://bugs.openjdk.org/browse/JDK-8313256), commit [98a915a5](https://github.com/openjdk/jdk/commit/98a915a54ce62da7cebc1f0ab07dab276291a1d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Thomas Obermeier on 1 Aug 2023 and was reviewed by Christoph Langer.

These are test exclusions for AIX only, so suitable for RDP2 rules.

Thanks!

-------------

Commit messages:
 - Backport 98a915a54ce62da7cebc1f0ab07dab276291a1d1

Changes: https://git.openjdk.org/jdk21/pull/156/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313256
  Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk21/pull/156.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/156/head:pull/156

PR: https://git.openjdk.org/jdk21/pull/156

From clanger at openjdk.org  Tue Aug  1 22:24:57 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 22:24:57 GMT
Subject: RFR: 8313256: Exclude failing multicast tests on AIX [v5]
In-Reply-To: <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
References: <2FMM-O9G8H5Zm_APluCNOGZvC6ZFAFnE3glYG4nfyO4=.1cf33847-6d99-4f82-bf08-8ffabfb3b9c6@github.com>
 <Cs2OLQmHc0v0tdeFPrMdjw7TGMqMEh1ypu1LF9yvmHI=.f7362631-c593-4388-9981-b8cfdd2aaece@github.com>
Message-ID: <dgOg9ip6QbLiInS2G-IvN-f0AvhlFgwhF21n8k10CCs=.52f27bbd-15c5-4028-ba32-37474f07192f@github.com>

On Tue, 1 Aug 2023 14:06:12 GMT, Thomas Obermeier <duke at openjdk.org> wrote:

>> exclude multicast and related tests on AIX mentioned in https://bugs.openjdk.org/browse/JDK-8308807 until this is fixed.
>
> Thomas Obermeier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt restore bad hunk java/foreign to have it repaired in deticated PR
>  - Merge branch 'openjdk:master' into patch-1
>  - Update ProblemList.txt: exclude DatagramChannel/AfterDisconnect for 8308807 aix-ppc64
>  - Update ProblemList.txt AcceptInheritHandle erroneously added to 8308807
>  - Merge branch 'master' into patch-1
>  - Update ProblemList.txt exclude MulticastSocket tests for AIX
>  - Update ProblemList.txt exclude java/foreign/TestByteBuffer

Yes, the tests that we didn't exclude here seem to work. There are a few network related tests still excluded on AIX in SAP's test system but these seem to have different symptoms. We're working on analyzing these and if necessary report the issues in JBS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15074#issuecomment-1661177187

From mbaesken at openjdk.org  Wed Aug  2 07:18:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 2 Aug 2023 07:18:55 GMT
Subject: [jdk21] RFR: 8313256: Exclude failing multicast tests on AIX
In-Reply-To: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>
References: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>
Message-ID: <DTQ-Y39k_Jjp-5JtbIJ1cNwvGgApNwKBy2G5Le6rT-o=.1cc6abe4-2402-4d19-8af6-8c009cb6f9ac@github.com>

On Tue, 1 Aug 2023 19:29:26 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8313256](https://bugs.openjdk.org/browse/JDK-8313256), commit [98a915a5](https://github.com/openjdk/jdk/commit/98a915a54ce62da7cebc1f0ab07dab276291a1d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Thomas Obermeier on 1 Aug 2023 and was reviewed by Christoph Langer.
> 
> These are test exclusions for AIX only, so suitable for RDP2 rules.
> 
> Thanks!

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/156#pullrequestreview-1558354130

From clanger at openjdk.org  Wed Aug  2 07:35:54 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 2 Aug 2023 07:35:54 GMT
Subject: [jdk21] RFR: 8313256: Exclude failing multicast tests on AIX
In-Reply-To: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>
References: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>
Message-ID: <-VE_OMnpuubrynNNYoR3m_kNmtQxCK4jzNzM1qd8vno=.1aa03ae5-9cec-400f-a1e1-d91b3d62f96f@github.com>

On Tue, 1 Aug 2023 19:29:26 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8313256](https://bugs.openjdk.org/browse/JDK-8313256), commit [98a915a5](https://github.com/openjdk/jdk/commit/98a915a54ce62da7cebc1f0ab07dab276291a1d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Thomas Obermeier on 1 Aug 2023 and was reviewed by Christoph Langer.
> 
> These are test exclusions for AIX only, so suitable for RDP2 rules.
> 
> Thanks!

trivial.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/156#issuecomment-1661659013

From clanger at openjdk.org  Wed Aug  2 07:35:54 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 2 Aug 2023 07:35:54 GMT
Subject: [jdk21] Integrated: 8313256: Exclude failing multicast tests on AIX
In-Reply-To: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>
References: <wUwRfhQj8AiPeX6ittZwdKOLqtiMCGllJ9zdz79019U=.5c07ed24-23cb-4f5f-be1a-15560571988f@github.com>
Message-ID: <Dgbo8E5Uz03ceYNyaxnRztZSbIQnfRKrz9aXuip3Oc4=.6214da06-254d-4585-9ae9-e8f77d4b939c@github.com>

On Tue, 1 Aug 2023 19:29:26 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8313256](https://bugs.openjdk.org/browse/JDK-8313256), commit [98a915a5](https://github.com/openjdk/jdk/commit/98a915a54ce62da7cebc1f0ab07dab276291a1d1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Thomas Obermeier on 1 Aug 2023 and was reviewed by Christoph Langer.
> 
> These are test exclusions for AIX only, so suitable for RDP2 rules.
> 
> Thanks!

This pull request has now been integrated.

Changeset: c3519d0e
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/c3519d0e53fcf3e6a787791402f0cffb1b22956a
Stats:     12 lines in 1 file changed: 6 ins; 0 del; 6 mod

8313256: Exclude failing multicast tests on AIX

Reviewed-by: mbaesken
Backport-of: 98a915a54ce62da7cebc1f0ab07dab276291a1d1

-------------

PR: https://git.openjdk.org/jdk21/pull/156

From tprinzing at openjdk.org  Wed Aug  2 18:22:53 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 2 Aug 2023 18:22:53 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

I believe this has all requested changes or has separate bug reports to address changes yet needing to be made.
https://bugs.openjdk.org/browse/JDK-8310979  - better exception handling
https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation
https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops

This request has been patiently waiting for approval for a long time!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1662726848

From alanb at openjdk.org  Wed Aug  2 20:12:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Aug 2023 20:12:51 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
Message-ID: <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>

On Wed, 2 Aug 2023 18:19:27 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> I believe this has all requested changes or has separate bug reports to address changes yet needing to be made. https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
> 
> This request has been patiently waiting for approval for a long time!

I plan to come back to this soon, been busy with other things.  It's good to have JBS issues created for the next steps. I assume you can start to prepare the changes for the next steps so that all the pieces can go into the same release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1662903292

From egahlin at openjdk.org  Wed Aug  2 21:12:44 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 2 Aug 2023 21:12:44 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <IbeWAyReO6cvEgMinyffb6vRGkTlw73TotYrwulG7Nw=.11f9df4e-a3b7-4de5-b31d-12ad704a16dc@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

Looks good as far as I can tell. I would perhaps name the checkForCommit(...) method commitEvent(...) to make it more clear that it writes the event, but it's not a big thing.

-------------

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1559847776

From jpai at openjdk.org  Thu Aug  3 07:43:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 07:43:25 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip address
 if reverse lookup fails
Message-ID: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>

Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.

This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

-------------

Commit messages:
 - 8313239: InetAddress.getCanonicalHostName may return ip address if reverse lookup fails

Changes: https://git.openjdk.org/jdk/pull/15134/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313239
  Stats: 20 lines in 1 file changed: 9 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From dfuchs at openjdk.org  Thu Aug  3 11:42:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Aug 2023 11:42:29 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <f1uji2yQNvnkV5WPd9_lcQgdg1QPQs2EI6x1msuwm6A=.5a9b1b20-6289-4b48-9677-90ba2aa463d4@github.com>

On Thu, 3 Aug 2023 07:35:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

src/java.base/share/classes/java/net/InetAddress.java line 806:

> 804:      *          of the IP address if either the operation is not allowed by the security check
> 805:      *          or the system-wide resolver wasn't able to determine the fully qualified domain
> 806:      *          name for the IP address.

Re-reading this, I wonder if a better wording would be:

Suggestion:

     * @return  the fully qualified domain name for this IP address. 
     *          If either the operation is not allowed by the security check
     *          or the system-wide resolver wasn't able to determine the fully qualified domain
     *          name for the IP address, the textual representation of the IP address is returned instead.


Just a suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1283074334

From duke at openjdk.org  Thu Aug  3 11:43:36 2023
From: duke at openjdk.org (Deepa Kumari)
Date: Thu, 3 Aug 2023 11:43:36 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <-6rjVxKJKaCis7qu8jwSTxqsqXtGtrvpd4hY-JA3TZ0=.2a9ba8ab-8c14-48eb-a35d-3b3c150740f9@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <Bbmrnkn3boAVs4Y3flqeHVOavktxAX2hIoU_eAX6z68=.1394bff7-52c7-4b4d-94a5-3e58e58e0bd2@github.com>
 <Gozvi5lCWDMWxzAxed79Qz0EMclbyPDYjccyzarCNhk=.eae248e4-d990-45d9-aa71-0f5da7253a5f@github.com>
 <G8JGBTQkuDyYM6O0WHmBQXL4KpHWb44BueqENfR9q9g=.d9639991-9b30-44d2-872c-4392fa8c8671@github.com>
 <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com>
 <mRk_D4IlAIBINmnOJwXjWPMJsDFRbTgKMFeNvp2Ujw0=.a4dda300-06db-4904-b307-3d5e6d886731@github.com>
 <-6rjVxKJKaCis7qu8jwSTxqsqXtGtrvpd4hY-JA3TZ0=.2a9ba8ab-8c14-48eb-a35d-3b3c150740f9@github.com>
Message-ID: <nrfXk_fFhl-fb6q9mKmS6RyoSPgjFfe3Qm_5Da1v0ME=.0f867df2-2cef-4db2-a6ed-59c46e6b2312@github.com>

On Wed, 21 Jun 2023 15:45:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> IIUC what @deepa181 is saying, it looks like the "IPv4 socket being unable to join an IPv4 multicast group" problems surfaced when we moved away from PlainDatagramSocketImpl in JDK 17? Probably because the delegate created does not factor in the ProtocolFamily and though we started with attempting to have an "IPv4 multicast socket join an IPv4 group", we end up trying to have an "IPv4/IPv6 dual-stack socket (the delegate) join an IPv4 group" which AIX doesn't permit.
>> 
>> IIRC It has never been possible to create a non-dual `MulticastSocket` / `DatagramSocket` without setting the property `-Djava.net.preferIPv4Stack=true`. The possibility to select a protocol family independently of this property is only available with `DatagramChannel`.
>
>> IIRC It has never been possible to create a non-dual `MulticastSocket` / `DatagramSocket` without setting the property `-Djava.net.preferIPv4Stack=true`. The possibility to select a protocol family independently of this property is only available with `DatagramChannel`.
> 
> Right now, Net.canIPv6SocketJoinIPv4Group() returns false on AIX so it will never attempt to join an IPv4 multicast group when the socket is IPv6.  The old DatagamSocketImpl didn't have an eager check, which makes me wonder what AIX supports, it's not clear!

Hi @AlanBateman , 

 I ran the Jtreg tests on **jdk17** and observed  the following tests passed unexpectedly when I set the **VM_OPTIONS to `-Djdk.net.usePlainDatagramSocketImpl=true`**

1. java/net/MulticastSocket/B6427403.java
2. java/net/MulticastSocket/NoLoopbackPackets.java
3. java/net/MulticastSocket/SetLoopbackMode.java
4. java/net/MulticastSocket/Test.java

I am curious about how setting the `jdk.net.usePlainDatagramSocketImpl` property impacts their behavior. I would like to understand why they pass with this configuration and whether it has any implications.

Could you please share your insights on this matter? I appreciate your assistance in understanding this behavior and ensuring the correctness of the tests.

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1663829993

From alanb at openjdk.org  Thu Aug  3 12:09:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Aug 2023 12:09:36 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <nrfXk_fFhl-fb6q9mKmS6RyoSPgjFfe3Qm_5Da1v0ME=.0f867df2-2cef-4db2-a6ed-59c46e6b2312@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <Bbmrnkn3boAVs4Y3flqeHVOavktxAX2hIoU_eAX6z68=.1394bff7-52c7-4b4d-94a5-3e58e58e0bd2@github.com>
 <Gozvi5lCWDMWxzAxed79Qz0EMclbyPDYjccyzarCNhk=.eae248e4-d990-45d9-aa71-0f5da7253a5f@github.com>
 <G8JGBTQkuDyYM6O0WHmBQXL4KpHWb44BueqENfR9q9g=.d9639991-9b30-44d2-872c-4392fa8c8671@github.com>
 <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com>
 <mRk_D4IlAIBINmnOJwXjWPMJsDFRbTgKMFeNvp2Ujw0=.a4dda300-06db-4904-b307-3d5e6d886731@github.com>
 <-6rjVxKJKaCis7qu8jwSTxqsqXtGtrvpd4hY-JA3TZ0=.2a9ba8ab-8c14-48eb-a35d-3b3c150740f9@github.com>
 <nrfXk_fFhl-fb6q9mKmS6RyoSPgjFfe3Qm_5Da1v0ME=.0f867df2-2cef-4db2-a6ed-59c46e6b2312@github.com>
Message-ID: <mHvibPipb0IQ8OZCWl38xw1d6VenJNwccDN4-Oh0HkA=.7d521288-a0b0-49aa-87dc-9bd2464d1343@github.com>

On Thu, 3 Aug 2023 11:41:08 GMT, Deepa Kumari <duke at openjdk.org> wrote:

> I am curious about how setting the `jdk.net.usePlainDatagramSocketImpl` property impacts their behavior. I would like to understand why they pass with this configuration and whether it has any implications.
> 
> Could you please share your insights on this matter? I appreciate your assistance in understanding this behavior and ensuring the correctness of the tests.

I think this issue needs an authoritative summary on what AIX supports and doesn't support. The observations reported conflict with some of the comments so I don't think I can say definitely if there are code or test changes required. 

For a long time, Net.canJoin6WithIPv4Group() has returned "false" on AIX so there is no attempt to join IPv4 multicast groups with a dual IPv4/IPv6 socket. DatagramChannel has supported multicasting since JDK 7 (2011) so if there were issues or test failures on AIX then surely they would have been noticed before now, or maybe all the test were excluded, or maybe the testing was done with IPv6 disabled.

The old DatagramSocketImpl implementation didn't have a setting/configuration to say if a dual IPv4/IPv6 socket could join an IPv4 multicast group, it just attempted it. Your results suggests that it works, which is surprising. Does AIX have the equivalent of strace to trace system calls? It might be useful to confirm that the socket is actually IPv6 and that it joining IPv4 multicast groups.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1663863113

From jpai at openjdk.org  Thu Aug  3 12:14:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:14:08 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v2]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <vIXoqggC8KldXBeXP4j5wtIHHKFa1tEyU5ONq6XGSh0=.e3215a93-a99a-4b58-bb48-022de9838a3f@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's review suggestion
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/bc599f05..9f214513

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From jpai at openjdk.org  Thu Aug  3 12:14:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:14:08 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v2]
In-Reply-To: <f1uji2yQNvnkV5WPd9_lcQgdg1QPQs2EI6x1msuwm6A=.5a9b1b20-6289-4b48-9677-90ba2aa463d4@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <f1uji2yQNvnkV5WPd9_lcQgdg1QPQs2EI6x1msuwm6A=.5a9b1b20-6289-4b48-9677-90ba2aa463d4@github.com>
Message-ID: <1FR6rvvTMvn-7AXX8V-LzcpUeU4BobV-6z6nVjKT-tw=.748b8fae-0adb-4082-a821-02e9fb6044bc@github.com>

On Thu, 3 Aug 2023 11:38:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Daniel's review suggestion
>>   
>>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>
> src/java.base/share/classes/java/net/InetAddress.java line 806:
> 
>> 804:      *          of the IP address if either the operation is not allowed by the security check
>> 805:      *          or the system-wide resolver wasn't able to determine the fully qualified domain
>> 806:      *          name for the IP address.
> 
> Re-reading this, I wonder if a better wording would be:
> 
> Suggestion:
> 
>      * @return  the fully qualified domain name for this IP address. 
>      *          If either the operation is not allowed by the security check
>      *          or the system-wide resolver wasn't able to determine the fully qualified domain
>      *          name for the IP address, the textual representation of the IP address is returned instead.
> 
> 
> Just a suggestion.

The suggested change sounds fine to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1283110669

From jpai at openjdk.org  Thu Aug  3 12:19:04 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:19:04 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v3]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - remove space char
 - update the private method javadoc too and minor line length change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/9f214513..c8098d0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=01-02

  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From alanb at openjdk.org  Thu Aug  3 12:26:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Aug 2023 12:26:35 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v3]
In-Reply-To: <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>
Message-ID: <2-rCJXNpt6m27UvQy3Tcc-TGAc0GVVL1cCTYHsCgZ-4=.90793e06-bf14-43e0-9f0f-840707017052@github.com>

On Thu, 3 Aug 2023 12:19:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove space char
>  - update the private method javadoc too and minor line length change

src/java.base/share/classes/java/net/InetAddress.java line 791:

> 789:      * {@linkplain InetAddress#getAddress() IP address} using the system-wide
> 790:      * {@linkplain InetAddressResolver resolver}. This is a best effort method,
> 791:      * meaning we may not be able to return the fully qualified domain name; in

I think you'll need to replace "we" with "it" here. It may also be useful to expand this sentence a bit, maybe with an example of why it may fail. 

I also wonder (and I'm in two minds on this) is if this method should include an impNote to say what it actually does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1283126500

From jpai at openjdk.org  Thu Aug  3 12:34:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:34:49 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v4]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <gt4fSv1hr6BTOT3TTMTF4-Rrce8HvvRs3Kury28kCOw=.4456d0b2-9791-4d3c-9855-32152eb819ed@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's review - minor tweak to the javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/c8098d0b..e5a29aca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From jpai at openjdk.org  Thu Aug  3 12:37:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:37:33 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v3]
In-Reply-To: <2-rCJXNpt6m27UvQy3Tcc-TGAc0GVVL1cCTYHsCgZ-4=.90793e06-bf14-43e0-9f0f-840707017052@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>
 <2-rCJXNpt6m27UvQy3Tcc-TGAc0GVVL1cCTYHsCgZ-4=.90793e06-bf14-43e0-9f0f-840707017052@github.com>
Message-ID: <YSjZ0KORug3RX-S1_qxQ8-DQznJgX10leonK8QGSAxE=.4dcfc8f6-ad2f-476d-998c-62520a0ab57c@github.com>

On Thu, 3 Aug 2023 12:23:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove space char
>>  - update the private method javadoc too and minor line length change
>
> src/java.base/share/classes/java/net/InetAddress.java line 791:
> 
>> 789:      * {@linkplain InetAddress#getAddress() IP address} using the system-wide
>> 790:      * {@linkplain InetAddressResolver resolver}. This is a best effort method,
>> 791:      * meaning we may not be able to return the fully qualified domain name; in
> 
> I think you'll need to replace "we" with "it" here. It may also be useful to expand this sentence a bit, maybe with an example of why it may fail. 
> 
> I also wonder (and I'm in two minds on this) is if this method should include an impNote to say what it actually does.

Hello Alan,

> I also wonder (and I'm in two minds on this) is if this method should include an impNote to say what it actually does.

I'm guessing that you are thinking of having the implNote state that a reverse name lookup will be performed by this method using the system-wide resolver. Right now, the `getHostName()` says this:


* <p>If this InetAddress was created with a host name,
     * this host name will be remembered and returned;
     * otherwise, a reverse name lookup will be performed
     * and the result will be returned based on the system
     * configured resolver. If a lookup of the name service
     * is required, call
     * {@link #getCanonicalHostName() getCanonicalHostName}.


I think we could update the `getCanonicalName()` to mention the reverse name lookup. However, I'm unsure if it should be an `implNote` or just formal API javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1283138876

From jpai at openjdk.org  Thu Aug  3 12:56:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:56:59 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  more clarification of the semantics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/e5a29aca..9ff86180

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=03-04

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From jpai at openjdk.org  Thu Aug  3 12:56:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Aug 2023 12:56:59 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v3]
In-Reply-To: <YSjZ0KORug3RX-S1_qxQ8-DQznJgX10leonK8QGSAxE=.4dcfc8f6-ad2f-476d-998c-62520a0ab57c@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>
 <2-rCJXNpt6m27UvQy3Tcc-TGAc0GVVL1cCTYHsCgZ-4=.90793e06-bf14-43e0-9f0f-840707017052@github.com>
 <YSjZ0KORug3RX-S1_qxQ8-DQznJgX10leonK8QGSAxE=.4dcfc8f6-ad2f-476d-998c-62520a0ab57c@github.com>
Message-ID: <mFTbEf4PozRbAX0rOFORXMxTZgfVPcAQhSiYm1Nra08=.bb313bbb-c106-461e-8aec-68a3db9326a3@github.com>

On Thu, 3 Aug 2023 12:34:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/InetAddress.java line 791:
>> 
>>> 789:      * {@linkplain InetAddress#getAddress() IP address} using the system-wide
>>> 790:      * {@linkplain InetAddressResolver resolver}. This is a best effort method,
>>> 791:      * meaning we may not be able to return the fully qualified domain name; in
>> 
>> I think you'll need to replace "we" with "it" here. It may also be useful to expand this sentence a bit, maybe with an example of why it may fail. 
>> 
>> I also wonder (and I'm in two minds on this) is if this method should include an impNote to say what it actually does.
>
> Hello Alan,
> 
>> I also wonder (and I'm in two minds on this) is if this method should include an impNote to say what it actually does.
> 
> I'm guessing that you are thinking of having the implNote state that a reverse name lookup will be performed by this method using the system-wide resolver. Right now, the `getHostName()` says this:
> 
> 
> * <p>If this InetAddress was created with a host name,
>      * this host name will be remembered and returned;
>      * otherwise, a reverse name lookup will be performed
>      * and the result will be returned based on the system
>      * configured resolver. If a lookup of the name service
>      * is required, call
>      * {@link #getCanonicalHostName() getCanonicalHostName}.
> 
> 
> I think we could update the `getCanonicalName()` to mention the reverse name lookup. However, I'm unsure if it should be an `implNote` or just formal API javadoc.

I have now updated the PR to add a few more details on what this method does and why it might fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1283158724

From dfuchs at openjdk.org  Thu Aug  3 14:42:32 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Aug 2023 14:42:32 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
Message-ID: <HQENOohDIcu-1tS-nyZaKkCszye8aD-vimFSONK3HAw=.ec6e8ef5-4049-46b7-b3fe-ff4ff67b5384@github.com>

On Thu, 3 Aug 2023 12:56:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more clarification of the semantics

The updated verbiage looks much better to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15134#pullrequestreview-1561261883

From alanb at openjdk.org  Thu Aug  3 18:22:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Aug 2023 18:22:31 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v3]
In-Reply-To: <mFTbEf4PozRbAX0rOFORXMxTZgfVPcAQhSiYm1Nra08=.bb313bbb-c106-461e-8aec-68a3db9326a3@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>
 <2-rCJXNpt6m27UvQy3Tcc-TGAc0GVVL1cCTYHsCgZ-4=.90793e06-bf14-43e0-9f0f-840707017052@github.com>
 <YSjZ0KORug3RX-S1_qxQ8-DQznJgX10leonK8QGSAxE=.4dcfc8f6-ad2f-476d-998c-62520a0ab57c@github.com>
 <mFTbEf4PozRbAX0rOFORXMxTZgfVPcAQhSiYm1Nra08=.bb313bbb-c106-461e-8aec-68a3db9326a3@github.com>
Message-ID: <rPZ6u18uwloKudXYzqNxTTIwUxWqhiQNthUsGzlgjw8=.f2399380-99dc-45d6-a016-a0850ad3b62e@github.com>

On Thu, 3 Aug 2023 12:51:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Alan,
>> 
>>> I also wonder (and I'm in two minds on this) is if this method should include an impNote to say what it actually does.
>> 
>> I'm guessing that you are thinking of having the implNote state that a reverse name lookup will be performed by this method using the system-wide resolver. Right now, the `getHostName()` says this:
>> 
>> 
>> * <p>If this InetAddress was created with a host name,
>>      * this host name will be remembered and returned;
>>      * otherwise, a reverse name lookup will be performed
>>      * and the result will be returned based on the system
>>      * configured resolver. If a lookup of the name service
>>      * is required, call
>>      * {@link #getCanonicalHostName() getCanonicalHostName}.
>> 
>> 
>> I think we could update the `getCanonicalName()` to mention the reverse name lookup. However, I'm unsure if it should be an `implNote` or just formal API javadoc.
>
> I have now updated the PR to add a few more details on what this method does and why it might fail.

> I'm guessing that you are thinking of having the implNote state that a reverse name lookup will be performed by this method using the system-wide resolver. 

I was thinking more about the caching and attempting the lookup only on first usage.  So my comment was wondering out loud if we should note this behavior in an implNote.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1283562643

From jpai at openjdk.org  Fri Aug  4 08:06:38 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Aug 2023 08:06:38 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v3]
In-Reply-To: <rPZ6u18uwloKudXYzqNxTTIwUxWqhiQNthUsGzlgjw8=.f2399380-99dc-45d6-a016-a0850ad3b62e@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <Hr36t-wkAqDIhVC5H0jv1WKIVu-LIewxIrraBjZPvvQ=.cf2cdbb5-4f30-43bd-bfb8-74dabe74cd81@github.com>
 <2-rCJXNpt6m27UvQy3Tcc-TGAc0GVVL1cCTYHsCgZ-4=.90793e06-bf14-43e0-9f0f-840707017052@github.com>
 <YSjZ0KORug3RX-S1_qxQ8-DQznJgX10leonK8QGSAxE=.4dcfc8f6-ad2f-476d-998c-62520a0ab57c@github.com>
 <mFTbEf4PozRbAX0rOFORXMxTZgfVPcAQhSiYm1Nra08=.bb313bbb-c106-461e-8aec-68a3db9326a3@github.com>
 <rPZ6u18uwloKudXYzqNxTTIwUxWqhiQNthUsGzlgjw8=.f2399380-99dc-45d6-a016-a0850ad3b62e@github.com>
Message-ID: <VCURoj30U6KDba_tbkqiaHjP1aUmHMwNU6WDh2LHEOI=.1c5f5808-d9d9-4c84-be41-14fa4af82078@github.com>

On Thu, 3 Aug 2023 18:20:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I was thinking more about the caching and attempting the lookup only on first usage.

If we do have to make a mention of that, then I think we would have to probably change the implementation to actually do the lookup only on first usage. Right now, the `canonicalHostName` field isn't `volatile` and there isn't any construct in place which will ensure that multiple concurrent calls to this method will ensure only one lookup happens. It's harmless in the current form, but if we add an `implNote` about this, then I think we would have to make it actually behave that way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1284116547

From aefimov at openjdk.org  Fri Aug  4 11:14:34 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 4 Aug 2023 11:14:34 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
Message-ID: <BeRauTL1oAWVg5UoxG38ggyYIseDjS8IP_EA4leKrw8=.fdb8a9a3-7fb0-4eee-a18e-508b7271940e@github.com>

On Thu, 3 Aug 2023 12:56:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more clarification of the semantics

src/java.base/share/classes/java/net/InetAddress.java line 825:

> 823: 
> 824:     /**
> 825:      * Returns the fully qualified domain for this address.

Both `getHostName` and `getCanonicalHostName` talk about `fully qualified domain name`, and how the system-wide resolver  is used to determine it. But [InetAddressResolver.lookupByAddress](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/spi/InetAddressResolver.html#lookupByAddress(byte%5B%5D)) talks about host name, maybe it should be updated to use FQDN term?

`name` is missing here: `fully qualified domain` -> `fully qualified domain name`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1284293370

From jpai at openjdk.org  Fri Aug  4 13:01:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Aug 2023 13:01:00 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v6]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <3oymNM7ox-5zZa0LBHnLilLsfKIU0UPPdFtbOOJWjKQ=.051facc7-7859-4c35-8c2c-6cd5b3680430@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Aleksei's review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/9ff86180..c9c3ba8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From jpai at openjdk.org  Fri Aug  4 13:01:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 4 Aug 2023 13:01:00 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <BeRauTL1oAWVg5UoxG38ggyYIseDjS8IP_EA4leKrw8=.fdb8a9a3-7fb0-4eee-a18e-508b7271940e@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
 <BeRauTL1oAWVg5UoxG38ggyYIseDjS8IP_EA4leKrw8=.fdb8a9a3-7fb0-4eee-a18e-508b7271940e@github.com>
Message-ID: <IWxkaVD9wiWmOgdtMLEw0KaesoHVGkuZX_oKKqv0RSQ=.dca939d0-642f-4a62-a36e-6d982b5f855e@github.com>

On Fri, 4 Aug 2023 11:12:00 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more clarification of the semantics
>
> src/java.base/share/classes/java/net/InetAddress.java line 825:
> 
>> 823: 
>> 824:     /**
>> 825:      * Returns the fully qualified domain for this address.
> 
> Both `getHostName` and `getCanonicalHostName` talk about `fully qualified domain name`, and how the system-wide resolver  is used to determine it. But [InetAddressResolver.lookupByAddress](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/spi/InetAddressResolver.html#lookupByAddress(byte%5B%5D)) talks about host name, maybe it should be updated to use FQDN term?
> 
> `name` is missing here: `fully qualified domain` -> `fully qualified domain name`

Hello Aleksei,

> But [InetAddressResolver.lookupByAddress](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/spi/InetAddressResolver.html#lookupByAddress(byte%5B%5D)) talks about host name, maybe it should be updated to use FQDN term?

Should we address that in this PR or a separate one?

> name is missing here: fully qualified domain -> fully qualified domain name

Good catch. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1284386316

From aefimov at openjdk.org  Fri Aug  4 15:14:32 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 4 Aug 2023 15:14:32 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <IWxkaVD9wiWmOgdtMLEw0KaesoHVGkuZX_oKKqv0RSQ=.dca939d0-642f-4a62-a36e-6d982b5f855e@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
 <BeRauTL1oAWVg5UoxG38ggyYIseDjS8IP_EA4leKrw8=.fdb8a9a3-7fb0-4eee-a18e-508b7271940e@github.com>
 <IWxkaVD9wiWmOgdtMLEw0KaesoHVGkuZX_oKKqv0RSQ=.dca939d0-642f-4a62-a36e-6d982b5f855e@github.com>
Message-ID: <YidTuZdBtcephuA5LwbdXiTRStjl0IdM4-YdV2nBCm4=.f3fae750-706f-429b-987d-5ae42692db37@github.com>

On Fri, 4 Aug 2023 12:54:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Should we address that in this PR or a separate one?

I'm good with both, but having it as a separate PR might require an additional CSR if docs modifications alter the semantics:

> Q: If the text of the javadoc of a public exported API is changing, is a CSR request needed?
> A: A CSR request is required if the specification of a public exported API. Not all javadoc updates are specification changes. For example, typo fixes and rephrasings that do not alter the semantics of the API in question do not require CSR review.

[[CSR FAQ]](https://wiki.openjdk.org/display/csr/CSR+FAQs)

> Good catch. Fixed.

Thank you

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1284546070

From aturbanov at openjdk.org  Sun Aug  6 13:50:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 6 Aug 2023 13:50:41 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
Message-ID: <59ZEL6zQy8mj2QsiilDF-jkZnQbSTwcZsU6n1DgCMIk=.31c2ea26-3650-4199-8d21-3739e25f13f9@github.com>

On Thu, 25 May 2023 07:14:19 GMT, Deepa Kumari <duke at openjdk.org> wrote:

> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
> 
> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
> 
> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
> 
> 
> 
> 
> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)

src/java.base/share/classes/sun/nio/ch/SelectorProviderImpl.java line 58:

> 56: 
> 57:     public DatagramChannel openUninterruptibleDatagramChannel(ProtocolFamily family) throws IOException {
> 58:     if(family == null)

Suggestion:

    if (family == null)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14142#discussion_r1285221577

From jpai at openjdk.org  Tue Aug  8 11:43:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Aug 2023 11:43:33 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <YidTuZdBtcephuA5LwbdXiTRStjl0IdM4-YdV2nBCm4=.f3fae750-706f-429b-987d-5ae42692db37@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
 <BeRauTL1oAWVg5UoxG38ggyYIseDjS8IP_EA4leKrw8=.fdb8a9a3-7fb0-4eee-a18e-508b7271940e@github.com>
 <IWxkaVD9wiWmOgdtMLEw0KaesoHVGkuZX_oKKqv0RSQ=.dca939d0-642f-4a62-a36e-6d982b5f855e@github.com>
 <YidTuZdBtcephuA5LwbdXiTRStjl0IdM4-YdV2nBCm4=.f3fae750-706f-429b-987d-5ae42692db37@github.com>
Message-ID: <YCU9kbxkIow9kxB4UX77mXacOlgL0qX-4EE-tPr7WwQ=.50a9e729-eceb-4780-898d-4e808ebc00d6@github.com>

On Fri, 4 Aug 2023 15:11:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Hello Aleksei,
>> 
>>> But [InetAddressResolver.lookupByAddress](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/net/spi/InetAddressResolver.html#lookupByAddress(byte%5B%5D)) talks about host name, maybe it should be updated to use FQDN term?
>> 
>> Should we address that in this PR or a separate one?
>> 
>>> name is missing here: fully qualified domain -> fully qualified domain name
>> 
>> Good catch. Fixed.
>
>> Should we address that in this PR or a separate one?
> 
> I'm good with both, but having it as a separate PR might require an additional CSR if docs modifications alter the semantics:
> 
>> Q: If the text of the javadoc of a public exported API is changing, is a CSR request needed?
>> A: A CSR request is required if the specification of a public exported API. Not all javadoc updates are specification changes. For example, typo fixes and rephrasings that do not alter the semantics of the API in question do not require CSR review.
> 
> [[CSR FAQ]](https://wiki.openjdk.org/display/csr/CSR+FAQs)
> 
>> Good catch. Fixed.
> 
> Thank you

I spoke to Aleksei about the InetAddressResolver javadoc and whether it should be updated in this PR. We agreed that we will take it up separately. I've created https://bugs.openjdk.org/browse/JDK-8313947 to track that discussion.

The PR in the current state has all other reviews implemented and I've updated and finalized the CSR with the text that's in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1286995588

From aturbanov at openjdk.org  Tue Aug  8 11:48:38 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Aug 2023 11:48:38 GMT
Subject: RFR: 8313948: Remove unnecessary static fields
 defaultUpper/defaultLower in sun.net.PortConfig
Message-ID: <rggZbzoJSxPXUuz4iPp9zLAQUt5DMcf6vZ38irK8LQg=.4ffac523-a21e-43bc-b9ab-fe408bb6b285@github.com>

Fields can be converted to local variables in <clinit>

-------------

Commit messages:
 - [PATCH] Remove unnecessary static fields defaultUpper/defaultLower in sun.net.PortConfig

Changes: https://git.openjdk.org/jdk/pull/14950/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14950&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313948
  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14950.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14950/head:pull/14950

PR: https://git.openjdk.org/jdk/pull/14950

From aefimov at openjdk.org  Tue Aug  8 13:02:33 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 8 Aug 2023 13:02:33 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v6]
In-Reply-To: <3oymNM7ox-5zZa0LBHnLilLsfKIU0UPPdFtbOOJWjKQ=.051facc7-7859-4c35-8c2c-6cd5b3680430@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <3oymNM7ox-5zZa0LBHnLilLsfKIU0UPPdFtbOOJWjKQ=.051facc7-7859-4c35-8c2c-6cd5b3680430@github.com>
Message-ID: <NGjIodSFJlaXiHQiAZRRjqxv88pzaQDCRLWc2yIIc9A=.75cd523e-6dc9-4e33-a0ff-5106dc3a11ab@github.com>

On Fri, 4 Aug 2023 13:01:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aleksei's review

Marked as reviewed by aefimov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15134#pullrequestreview-1567245044

From aefimov at openjdk.org  Tue Aug  8 13:02:34 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 8 Aug 2023 13:02:34 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v5]
In-Reply-To: <YCU9kbxkIow9kxB4UX77mXacOlgL0qX-4EE-tPr7WwQ=.50a9e729-eceb-4780-898d-4e808ebc00d6@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <y5mLFGkxlxgW2rYdZMdFBjhco2IAKiBPXhHTd5rVTFA=.36c414e3-6372-432f-aeda-70232b0033d2@github.com>
 <BeRauTL1oAWVg5UoxG38ggyYIseDjS8IP_EA4leKrw8=.fdb8a9a3-7fb0-4eee-a18e-508b7271940e@github.com>
 <IWxkaVD9wiWmOgdtMLEw0KaesoHVGkuZX_oKKqv0RSQ=.dca939d0-642f-4a62-a36e-6d982b5f855e@github.com>
 <YidTuZdBtcephuA5LwbdXiTRStjl0IdM4-YdV2nBCm4=.f3fae750-706f-429b-987d-5ae42692db37@github.com>
 <YCU9kbxkIow9kxB4UX77mXacOlgL0qX-4EE-tPr7WwQ=.50a9e729-eceb-4780-898d-4e808ebc00d6@github.com>
Message-ID: <GBbw7keH-qrq2qXZftPfDQaex1uhVu9EJE-wYCVorcA=.74f3c06d-eb8a-4093-96c4-4636d18e1d82@github.com>

On Tue, 8 Aug 2023 11:40:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> Should we address that in this PR or a separate one?
>> 
>> I'm good with both, but having it as a separate PR might require an additional CSR if docs modifications alter the semantics:
>> 
>>> Q: If the text of the javadoc of a public exported API is changing, is a CSR request needed?
>>> A: A CSR request is required if the specification of a public exported API. Not all javadoc updates are specification changes. For example, typo fixes and rephrasings that do not alter the semantics of the API in question do not require CSR review.
>> 
>> [[CSR FAQ]](https://wiki.openjdk.org/display/csr/CSR+FAQs)
>> 
>>> Good catch. Fixed.
>> 
>> Thank you
>
> I spoke to Aleksei about the InetAddressResolver javadoc and whether it should be updated in this PR. We agreed that we will take it up separately. I've created https://bugs.openjdk.org/browse/JDK-8313947 to track that discussion.
> 
> The PR in the current state has all other reviews implemented and I've updated and finalized the CSR with the text that's in this PR.

Thanks for creating a separate bug to track terms used in the `InetAddressResolver` and `InetAddress` classes. This PR looks good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287083474

From alanb at openjdk.org  Tue Aug  8 13:14:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Aug 2023 13:14:34 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v6]
In-Reply-To: <3oymNM7ox-5zZa0LBHnLilLsfKIU0UPPdFtbOOJWjKQ=.051facc7-7859-4c35-8c2c-6cd5b3680430@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <3oymNM7ox-5zZa0LBHnLilLsfKIU0UPPdFtbOOJWjKQ=.051facc7-7859-4c35-8c2c-6cd5b3680430@github.com>
Message-ID: <E18DRIwRpIM3bkb3IHzbGhehFDvxW-WKQ_L8lUp3kUw=.4205cc5f-b0bb-438e-9c1c-01b3757cd248@github.com>

On Fri, 4 Aug 2023 13:01:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aleksei's review

src/java.base/share/classes/java/net/InetAddress.java line 792:

> 790:      * {@linkplain InetAddressResolver resolver}.
> 791:      *
> 792:      * <p>The system-wide resolver will be used to do a reverse name lookup of the IP address.

The wording in this paragraph seems a bit different to getHostName and I think we should try to use the same terms in both methods if possible, e.g. getHostName talks about the "system configured resolver" where here it uses "system-wide resolve". We have have "used" vs. "performed". So maybe look at the methods again as I think we should be a bit more consistent with the wording if we can.

src/java.base/share/classes/java/net/InetAddress.java line 796:

> 794:      * service. In such cases, where the resolver isn't able to determine the fully qualified
> 795:      * domain name, this method returns the {@linkplain #getHostAddress() textual representation}
> 796:      * of the IP address.

I think it would be better to say that the lookup can fail for many reasons that include the host not being registered with the name service. 

A suggestion for "In such cases .." is to say "f the resolve is unable to determine ...". I think that would be a bit easer to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287096421
PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287098493

From jpai at openjdk.org  Tue Aug  8 14:31:16 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Aug 2023 14:31:16 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v7]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Alan's suggestion - better wording
 - Alan's suggestion - consistency for "system configured" vs "system-wide"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/c9c3ba8b..06fef8d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=05-06

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From jpai at openjdk.org  Tue Aug  8 14:31:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Aug 2023 14:31:22 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v6]
In-Reply-To: <E18DRIwRpIM3bkb3IHzbGhehFDvxW-WKQ_L8lUp3kUw=.4205cc5f-b0bb-438e-9c1c-01b3757cd248@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <3oymNM7ox-5zZa0LBHnLilLsfKIU0UPPdFtbOOJWjKQ=.051facc7-7859-4c35-8c2c-6cd5b3680430@github.com>
 <E18DRIwRpIM3bkb3IHzbGhehFDvxW-WKQ_L8lUp3kUw=.4205cc5f-b0bb-438e-9c1c-01b3757cd248@github.com>
Message-ID: <AR9726VSutKh8YZxxvFpRCQ-0QIdzTZ46wzyNNJ4FlM=.5ea1005c-b6d4-4272-9147-250ac44e5b77@github.com>

On Tue, 8 Aug 2023 13:09:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksei's review
>
> src/java.base/share/classes/java/net/InetAddress.java line 792:
> 
>> 790:      * {@linkplain InetAddressResolver resolver}.
>> 791:      *
>> 792:      * <p>The system-wide resolver will be used to do a reverse name lookup of the IP address.
> 
> The wording in this paragraph seems a bit different to getHostName and I think we should try to use the same terms in both methods if possible, e.g. getHostName talks about the "system configured resolver" where here it uses "system-wide resolve". We have have "used" vs. "performed". So maybe look at the methods again as I think we should be a bit more consistent with the wording if we can.

Hello Alan, except for a couple of places in `InetAddress` javadoc, the rest of the javadoc (and code comments) in `InetAddress` use the term system-wide resolver instead of system configured resolver. Furthermore, the java.net.spi.InetAddressResolver itself uses the system-wide resolver term. So I've now updated these two places in InetAddress to replace the use of "system configured resolver" to "system-wide resolver".

> src/java.base/share/classes/java/net/InetAddress.java line 796:
> 
>> 794:      * service. In such cases, where the resolver isn't able to determine the fully qualified
>> 795:      * domain name, this method returns the {@linkplain #getHostAddress() textual representation}
>> 796:      * of the IP address.
> 
> I think it would be better to say that the lookup can fail for many reasons that include the host not being registered with the name service. 
> 
> A suggestion for "In such cases .." is to say "f the resolve is unable to determine ...". I think that would be a bit easer to read.

That sounds good. I've updated the PR to use this suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287206805
PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1287207810

From dfuchs at openjdk.org  Wed Aug  9 09:54:28 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 9 Aug 2023 09:54:28 GMT
Subject: RFR: 8313948: Remove unnecessary static fields
 defaultUpper/defaultLower in sun.net.PortConfig
In-Reply-To: <rggZbzoJSxPXUuz4iPp9zLAQUt5DMcf6vZ38irK8LQg=.4ffac523-a21e-43bc-b9ab-fe408bb6b285@github.com>
References: <rggZbzoJSxPXUuz4iPp9zLAQUt5DMcf6vZ38irK8LQg=.4ffac523-a21e-43bc-b9ab-fe408bb6b285@github.com>
Message-ID: <91vWL1L_W_6ozy2jHMxMx7H4aOOm1uxXvL0ofdGYclE=.1e35b289-2baa-4498-b2ee-c9552d8c67b7@github.com>

On Thu, 20 Jul 2023 09:51:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Static fields `defaultUpper`/`defaultLower` can be converted to local variables in `<clinit>`.

LGTM. Just to be on the safe side I ran tier2 and tests where green.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14950#pullrequestreview-1569152187

From alanb at openjdk.org  Wed Aug  9 14:33:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Aug 2023 14:33:38 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v7]
In-Reply-To: <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
Message-ID: <8leNvdG2zDhL5Y1PfIC5wKg3zzQSo3h4TYQ2zX2-Cso=.bfe2eaa2-7768-49b0-91ca-8c84f2a600cb@github.com>

On Tue, 8 Aug 2023 14:31:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alan's suggestion - better wording
>  - Alan's suggestion - consistency for "system configured" vs "system-wide"

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15134#pullrequestreview-1569732493

From michaelm at openjdk.org  Wed Aug  9 17:23:29 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Aug 2023 17:23:29 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v7]
In-Reply-To: <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
Message-ID: <0KgbOUWWZ0u3wdwItsGwL1yXRKEtARCI_mhbzCLa9gI=.53370f0c-3a1a-43a1-8c25-508bea6bade8@github.com>

On Tue, 8 Aug 2023 14:31:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alan's suggestion - better wording
>  - Alan's suggestion - consistency for "system configured" vs "system-wide"

src/java.base/share/classes/java/net/InetAddress.java line 825:

> 823: 
> 824:     /**
> 825:      * Returns the fully qualified domain name for this address.

Maybe in the followup issue we could change "this address" to "the given address" considering it's a static method. It's not part of the spec regardless, so only a minor nit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1288915204

From jpai at openjdk.org  Thu Aug 10 06:24:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Aug 2023 06:24:33 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v8]
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <uJFo9PRd9A-304pZWb9jiHfkUMvEth_WUoqwxerBkzw=.46878885-7901-456f-9b18-c85374b21c48@github.com>

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Michael's review suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15134/files
  - new: https://git.openjdk.org/jdk/pull/15134/files/06fef8d8..9427d870

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15134&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15134/head:pull/15134

PR: https://git.openjdk.org/jdk/pull/15134

From jpai at openjdk.org  Thu Aug 10 06:24:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Aug 2023 06:24:59 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v7]
In-Reply-To: <0KgbOUWWZ0u3wdwItsGwL1yXRKEtARCI_mhbzCLa9gI=.53370f0c-3a1a-43a1-8c25-508bea6bade8@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
 <0KgbOUWWZ0u3wdwItsGwL1yXRKEtARCI_mhbzCLa9gI=.53370f0c-3a1a-43a1-8c25-508bea6bade8@github.com>
Message-ID: <Bm4HX29eYqNXVWQb-D8tFv8SDAiPIlFTgjLAd0pMPjY=.ab4fda95-4145-42f1-8392-1ebe46c860d0@github.com>

On Wed, 9 Aug 2023 17:01:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Alan's suggestion - better wording
>>  - Alan's suggestion - consistency for "system configured" vs "system-wide"
>
> src/java.base/share/classes/java/net/InetAddress.java line 825:
> 
>> 823: 
>> 824:     /**
>> 825:      * Returns the fully qualified domain name for this address.
> 
> Maybe in the followup issue we could change "this address" to "the given address" considering it's a static method. It's not part of the spec regardless, so only a minor nit.

Hello Michael, that's a good catch. I've now pushed an update in this PR which fixes that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15134#discussion_r1289594769

From jpai at openjdk.org  Thu Aug 10 06:24:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Aug 2023 06:24:58 GMT
Subject: RFR: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails [v7]
In-Reply-To: <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
 <OW5y7T7s2BtA6tmvyW8BZpWN8xM_BLMbnsg9aWR4FZ4=.09aa83b7-8452-4a5e-9fa2-af81b89b5f2d@github.com>
Message-ID: <wNzR7epqayUhWuAJ170eKPH6JVOQXDuZ6hBtHlSK_8E=.fe1af475-7e66-469d-965a-39fc55db8221@github.com>

On Tue, 8 Aug 2023 14:31:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
>> 
>> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alan's suggestion - better wording
>  - Alan's suggestion - consistency for "system configured" vs "system-wide"

Thank you everyone for the reviews. The CSR for this change has been approved and all review comments have been implemented. I'll go ahead and integrate this later today.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15134#issuecomment-1672606677

From jpai at openjdk.org  Thu Aug 10 10:24:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Aug 2023 10:24:32 GMT
Subject: Integrated: 8313239: InetAddress.getCanonicalHostName may return ip
 address if reverse lookup fails
In-Reply-To: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
References: <nouWBkEDWErUgWVCmegt23_zqCkunxxG8GciPYcN81M=.e5690e10-ffc2-42e1-a412-c2299e62e03b@github.com>
Message-ID: <eEFy-92HyHRy9hmG_cm5Lk6d212_5aEtedX4w4f213Q=.7d121306-9707-4386-a42d-7148d40be5c8@github.com>

On Thu, 3 Aug 2023 07:35:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the javadoc of `java.net.InetAddress.getCanonicalHostName()` method to clarify its semantics? This addresses https://bugs.openjdk.org/browse/JDK-8313239.
> 
> This a javadoc only change and the documentation is updated to match the current implementation. A CSR will be drafted for this change.

This pull request has now been integrated.

Changeset: 0cb9ab04
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cb9ab04f4c408bce7c4bc0e028fa9d4959abd79
Stats:     29 lines in 1 file changed: 14 ins; 4 del; 11 mod

8313239: InetAddress.getCanonicalHostName may return ip address if reverse lookup fails

Reviewed-by: dfuchs, aefimov, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15134

From dfuchs at openjdk.org  Fri Aug 11 13:43:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Aug 2023 13:43:29 GMT
Subject: RFR: 8314136: Test java/net/httpclient/CancelRequestTest.java failed:
 WARNING: tracker for HttpClientImpl(42) has outstanding operations
Message-ID: <qPVghKdlx2KJ7fWKMykWaIA4rrkZKMzBEqMvHPweRPg=.8cbfefca-5fc1-4828-b6cb-38698bc41aff@github.com>

Please find here a patch for a very rare intermittent failure observed in CancelRequestTest.

The fact that the number of pending requests hasn't been decremented leads me to think that completable future returned by sendAsync (called from send) hasn't been fully completed. That is, the dependent actions registered by sendAsync have not been run within the timeout waiting for the number of pending requests to reach 0.

The fix is to call cf.get() again after calling cf.cancel(), and increase the timeout waiting for cleanup in testPostInterrupt.
client.close() is also called at the end of each test method to reclaim resources earlier

-------------

Commit messages:
 - 8314136

Changes: https://git.openjdk.org/jdk/pull/15249/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314136
  Stats: 47 lines in 2 files changed: 15 ins; 8 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15249/head:pull/15249

PR: https://git.openjdk.org/jdk/pull/15249

From aturbanov at openjdk.org  Mon Aug 14 07:26:28 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 14 Aug 2023 07:26:28 GMT
Subject: Integrated: 8313948: Remove unnecessary static fields
 defaultUpper/defaultLower in sun.net.PortConfig
In-Reply-To: <rggZbzoJSxPXUuz4iPp9zLAQUt5DMcf6vZ38irK8LQg=.4ffac523-a21e-43bc-b9ab-fe408bb6b285@github.com>
References: <rggZbzoJSxPXUuz4iPp9zLAQUt5DMcf6vZ38irK8LQg=.4ffac523-a21e-43bc-b9ab-fe408bb6b285@github.com>
Message-ID: <pu4DIh57p-gUPy3QtsKLyNg3q2cWfd9zXOEhA3Widig=.50451156-ba54-40c6-bba3-51e102cbab32@github.com>

On Thu, 20 Jul 2023 09:51:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Static fields `defaultUpper`/`defaultLower` can be converted to local variables in `<clinit>`.

This pull request has now been integrated.

Changeset: 6bbcef53
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bbcef53154e6b669ef53e01eb95bc1b568dc0c6
Stats:     4 lines in 1 file changed: 2 ins; 1 del; 1 mod

8313948: Remove unnecessary static fields defaultUpper/defaultLower in sun.net.PortConfig

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/14950

From mbaesken at openjdk.org  Mon Aug 14 08:10:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Aug 2023 08:10:59 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
Message-ID: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>

Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
Some examples :
Events::log_dll_message for hs-err files reporting
JFR event NativeLibraryLoad
There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information

Offer an interface (e.g. jvm.cpp) to support this.

-------------

Commit messages:
 - JDK-8313764

Changes: https://git.openjdk.org/jdk/pull/15264/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313764
  Stats: 150 lines in 7 files changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264

PR: https://git.openjdk.org/jdk/pull/15264

From alanb at openjdk.org  Mon Aug 14 09:06:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Aug 2023 09:06:33 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <J70jXfotDv8W6TlxAcOvaeFbqWQZApDdqVcNd1oOuUg=.d2d3334f-0eeb-4e04-af73-05e00f47cf7a@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Having dlopen usages in non-core native libraries such as such as libsctp, libawt_xawt, ... have their dlopen usages compiled to use dlopen_ext in libjvm introduces questionable coupling that I think requires broader discussion. For the JFR NativeLibraryLoad event then I suppose there is a discussion on whether events for statically or dynamically loaded libs is interesting or not as there isn't a corresponding System.loadLibrary or SymbolLookup.libraryLookup. JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1676938047

From mbaesken at openjdk.org  Mon Aug 14 10:21:00 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Aug 2023 10:21:00 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <X453xaUIPaOuRuCqTo9o-q0yI2Hdk3ujtmd0umpgkco=.be63945d-6506-43b6-9f4c-d980492b303e@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Hi Alan,

> JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports.

yes this is of course AIX specific.  However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in  os::dll_load   calls to  SymbolEngine::recalc_search_path();
However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1677045118

From jpai at openjdk.org  Mon Aug 14 10:21:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 14 Aug 2023 10:21:29 GMT
Subject: RFR: 8314136: Test java/net/httpclient/CancelRequestTest.java
 failed: WARNING: tracker for HttpClientImpl(42) has outstanding operations
In-Reply-To: <qPVghKdlx2KJ7fWKMykWaIA4rrkZKMzBEqMvHPweRPg=.8cbfefca-5fc1-4828-b6cb-38698bc41aff@github.com>
References: <qPVghKdlx2KJ7fWKMykWaIA4rrkZKMzBEqMvHPweRPg=.8cbfefca-5fc1-4828-b6cb-38698bc41aff@github.com>
Message-ID: <fGDM3RhMFMU6XVANufjq4gFqIgECOi4Zj55hA0G5QtE=.b5cc0ca1-32c6-44fd-af21-0840507967bf@github.com>

On Fri, 11 Aug 2023 13:24:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a patch for a very rare intermittent failure observed in CancelRequestTest.
> 
> The fact that the number of pending requests hasn't been decremented leads me to think that completable future returned by sendAsync (called from send) hasn't been fully completed. That is, the dependent actions registered by sendAsync have not been run within the timeout waiting for the number of pending requests to reach 0.
> 
> The fix is to call cf.get() again after calling cf.cancel(), and increase the timeout waiting for cleanup in testPostInterrupt.
> client.close() is also called at the end of each test method to reclaim resources earlier

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 941:

> 939:                     // cleanup dependant actions to execute
> 940:                     // this should throw a CancellationException
> 941:                     cf.get();

Hello Daniel,
I'm a bit surprised that calling `get()` on a `cancel()`ed `CompletableFuture` does indeed "wait" and doesn't immediately throw a `CancellationException`. The javadoc of `CompletableFuture#get()` says:

>  @throws CancellationException if this future was cancelled

but looking at the implementation of that method, it doesn't seem to immediately throw a `CancellationException`.

If adding this get() does indeed wait for the dependent actions, then I think that's a good thing to do. However, if this is indeed the expected semantics of these APIs, then it might also mean that we might have to start looking for other similar places and the code might start becoming complicated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15249#discussion_r1293261138

From dfuchs at openjdk.org  Mon Aug 14 11:21:32 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Aug 2023 11:21:32 GMT
Subject: RFR: 8314136: Test java/net/httpclient/CancelRequestTest.java
 failed: WARNING: tracker for HttpClientImpl(42) has outstanding operations
In-Reply-To: <fGDM3RhMFMU6XVANufjq4gFqIgECOi4Zj55hA0G5QtE=.b5cc0ca1-32c6-44fd-af21-0840507967bf@github.com>
References: <qPVghKdlx2KJ7fWKMykWaIA4rrkZKMzBEqMvHPweRPg=.8cbfefca-5fc1-4828-b6cb-38698bc41aff@github.com>
 <fGDM3RhMFMU6XVANufjq4gFqIgECOi4Zj55hA0G5QtE=.b5cc0ca1-32c6-44fd-af21-0840507967bf@github.com>
Message-ID: <DXb1KfoqZfdp6SnNxM6GglLgWlKDgucC809fX9xiYzs=.875cf1b4-2999-4dcd-a723-051ace8a5c57@github.com>

On Mon, 14 Aug 2023 10:00:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please find here a patch for a very rare intermittent failure observed in CancelRequestTest.
>> 
>> The fact that the number of pending requests hasn't been decremented leads me to think that completable future returned by sendAsync (called from send) hasn't been fully completed. That is, the dependent actions registered by sendAsync have not been run within the timeout waiting for the number of pending requests to reach 0.
>> 
>> The fix is to call cf.get() again after calling cf.cancel(), and increase the timeout waiting for cleanup in testPostInterrupt.
>> client.close() is also called at the end of each test method to reclaim resources earlier
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 941:
> 
>> 939:                     // cleanup dependant actions to execute
>> 940:                     // this should throw a CancellationException
>> 941:                     cf.get();
> 
> Hello Daniel,
> I'm a bit surprised that calling `get()` on a `cancel()`ed `CompletableFuture` does indeed "wait" and doesn't immediately throw a `CancellationException`. The javadoc of `CompletableFuture#get()` says:
> 
>>  @throws CancellationException if this future was cancelled
> 
> but looking at the implementation of that method, it doesn't seem to immediately throw a `CancellationException`.
> 
> If adding this get() does indeed wait for the dependent actions, then I think that's a good thing to do. However, if this is indeed the expected semantics of these APIs, then it might also mean that we might have to start looking for other similar places and the code might start becoming complicated.

Yes, I think you're right. I was thinking about that over the weekend and I don't think calling `get()` here will achieve anything, since the future should already be completed with a cancelletion exception by the time we call get(). If we wanted to wait for the dependent actions to complete what we would need to do is actually cancel the `mexCf` (and not the head of the chain) and wait for the cancellation exception to trickle up. That's not how we implemented MinimalFuture::cancel however, and getting it to do that is more complex than it looks. The way we specified cancel as a best effort allows the cancellation to continue in the backround after returning, so it's actually only an issue for the test where we need to take that into account. I believe what happened with this test failure is that we were on a busy CPU and simply did not wait long enough. So I might just drop the changes to `HttpClientImpl` out of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15249#discussion_r1293324396

From prr at openjdk.org  Mon Aug 14 20:42:07 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 14 Aug 2023 20:42:07 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <IJSqm24JaP77kYP_UgPL7Kvf8wPLDn3NqM8k52FkEnI=.0d121538-024a-46f0-9bc1-9ba05a4549f7@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

I don't see why we need this .. 
The desktop module has a LOT of calls to dlopen() .. I wasn't sure why you were only interested in two of them.
I suspect because there's #ifdef AIX blocks in both of these files that do AIX-specific things for the dlopen .. but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ? 

And I'd prefer that if anything is done that whatever you need to do be entirely within that #ifdef AIX block and so not affect anything else.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678026889

From mbaesken at openjdk.org  Tue Aug 15 07:43:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Aug 2023 07:43:23 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <AEryJxVLekumt8z5_vuefEui0ItIi2cGZE3uA-Kh-_I=.23057281-1e7c-47b1-b769-adef5ff57958@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Hi Phil, yes there are of course more call sites of dlopen in the JDK C codebase.
I could cover them too, if this is wished.

> . but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ?

The lib cache update ` LoadedLibraries::reload();`   is  AIX specific;  the UL and JFR events are cross platform.

( Btw. in our proprietary JVM we have this approach for many years )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678538226

From alanb at openjdk.org  Tue Aug 15 08:06:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 08:06:08 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com>
Message-ID: <vOnYiqdjTcH05Nt-yjqWux_XAiU7RcFBB3--e1W5dTo=.cabbf243-2b21-414b-92c9-5ad9882daea3@github.com>

On Wed, 12 Jul 2023 15:06:36 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert StreamTokenizer.java

Now that the incompatible change to StreamTokenizer is dropped from this change then I assume the rest can be reviewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1678560892

From aturbanov at openjdk.org  Tue Aug 15 09:41:31 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Aug 2023 09:41:31 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www
Message-ID: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>

A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.

-------------

Commit messages:
 - [PATCH] Make fields final in sun.net.www
 - [PATCH] Make fields final in sun.net.www

Changes: https://git.openjdk.org/jdk/pull/14977/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314261
  Stats: 58 lines in 13 files changed: 3 ins; 8 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/14977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14977/head:pull/14977

PR: https://git.openjdk.org/jdk/pull/14977

From aturbanov at openjdk.org  Tue Aug 15 10:13:38 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Aug 2023 10:13:38 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v2]
In-Reply-To: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
Message-ID: <ue0lsNuUoHLV0AmFlR14FxDoCPF_6C_QWBAWUbmFQP8=.eefad467-b2df-4f15-affa-5471ae431a35@github.com>

> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into final_fields_sun.net.www
 - [PATCH] Make fields final in sun.net.www
   
   more finals
 - [PATCH] Make fields final in sun.net.www

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14977/files
  - new: https://git.openjdk.org/jdk/pull/14977/files/79c8452c..91eba7be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=00-01

  Stats: 47356 lines in 1325 files changed: 21260 ins; 17780 del; 8316 mod
  Patch: https://git.openjdk.org/jdk/pull/14977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14977/head:pull/14977

PR: https://git.openjdk.org/jdk/pull/14977

From duke at openjdk.org  Tue Aug 15 10:48:29 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 15 Aug 2023 10:48:29 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
 - Revert StreamTokenizer.java
 - Update DateTimeFormatterBuilder
 - Avoid locale-sensitive case conversions in java.base

-------------

Changes: https://git.openjdk.org/jdk/pull/14763/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=02
  Stats: 44 lines in 11 files changed: 6 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14763/head:pull/14763

PR: https://git.openjdk.org/jdk/pull/14763

From duke at openjdk.org  Tue Aug 15 10:52:12 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 15 Aug 2023 10:52:12 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
Message-ID: <zczFY6mqas1UTn5bALJo_1UcszkBCFjVOIkTA03UV80=.6e7cd119-1354-4683-852e-1dcabd8fff39@github.com>

On Tue, 15 Aug 2023 10:48:29 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
>  - Revert StreamTokenizer.java
>  - Update DateTimeFormatterBuilder
>  - Avoid locale-sensitive case conversions in java.base

I updated this PR to resolve the merge conflict. Now it is waiting to be reviewed again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1678743922

From aturbanov at openjdk.org  Tue Aug 15 11:29:45 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Aug 2023 11:29:45 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v3]
In-Reply-To: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
Message-ID: <GYNLjHKlipjGziz656C9vGIQn5wsN2D-w3LPVJmKLPU=.522be4c0-7309-4ffb-8a0f-f32479af17de@github.com>

> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8314261: Make fields final in sun.net.www

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14977/files
  - new: https://git.openjdk.org/jdk/pull/14977/files/91eba7be..cad2811a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14977/head:pull/14977

PR: https://git.openjdk.org/jdk/pull/14977

From redestad at openjdk.org  Tue Aug 15 11:48:07 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 15 Aug 2023 11:48:07 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v3]
In-Reply-To: <GYNLjHKlipjGziz656C9vGIQn5wsN2D-w3LPVJmKLPU=.522be4c0-7309-4ffb-8a0f-f32479af17de@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <GYNLjHKlipjGziz656C9vGIQn5wsN2D-w3LPVJmKLPU=.522be4c0-7309-4ffb-8a0f-f32479af17de@github.com>
Message-ID: <-72SzX0sstjbgFJjwKwFouNpYYSfpjbPoh0eAcOBIbc=.aa8876ad-fe7d-4e68-af38-6c6afd75bfbe@github.com>

On Tue, 15 Aug 2023 11:29:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314261: Make fields final in sun.net.www

Looks good to me.

src/java.base/share/classes/sun/net/www/MimeTable.java line 48:

> 46: 
> 47:     /** Keyed by content type, returns MimeEntries */
> 48:     private final Hashtable<String, MimeEntry> entries = new Hashtable<>();

Drive-by observation: These two `Hashtable`s can be changed to `HashMap` since every method that uses them is `synchronized`, making the implicit synchronization from `Hashtable` redundant.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14977#pullrequestreview-1578390240
PR Review Comment: https://git.openjdk.org/jdk/pull/14977#discussion_r1294482151

From aturbanov at openjdk.org  Tue Aug 15 15:16:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Aug 2023 15:16:46 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v4]
In-Reply-To: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
Message-ID: <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>

> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8314261: Make fields final in sun.net.www
  
  fix B5045306 test failure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14977/files
  - new: https://git.openjdk.org/jdk/pull/14977/files/cad2811a..b0ad815a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14977/head:pull/14977

PR: https://git.openjdk.org/jdk/pull/14977

From cushon at openjdk.org  Tue Aug 15 22:50:13 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 15 Aug 2023 22:50:13 GMT
Subject: RFR: 8313356: Improve address selection in sun.net.NetworkClient
In-Reply-To: <UyKK6cJjqDiMMGqPrZ42gAnpNf_MDdT3yfIpwEXW9-k=.bc4f5f0f-48e6-4e30-a25e-65380e55ee4f@github.com>
References: <J8BFB7poYBXAd1BnSc-NMyVSvHWTxdMvbp_L6wKr2do=.87b2d641-8c70-4f75-ae0f-f12a7cc82315@github.com>
 <UyKK6cJjqDiMMGqPrZ42gAnpNf_MDdT3yfIpwEXW9-k=.bc4f5f0f-48e6-4e30-a25e-65380e55ee4f@github.com>
Message-ID: <E7xe381UEJV3Ofs1VbRIQjhJZ4YG07Vg6Y5Dppxh0Pc=.a6a3a63b-d906-4174-93a0-0de663a3fe6b@github.com>

On Sat, 29 Jul 2023 12:11:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this fix for [JDK-8313356](https://bugs.openjdk.org/browse/JDK-8313356), which improves address selection in `sun.net.NetworkClient` to consider all addresses returned by `InetAddress.getAllByName` instead of only connecting to the first one.
>> 
>> This follows the approach described in [JDK-8170568](https://bugs.openjdk.org/browse/JDK-8170568).
>
> The is a significant change to long standing behavior and will require discussion/consensus. It's probably a bit premature to create a PR without discussion on how it may be observed by existing deployments when the connection to the first address cannot be established. It also interacts with the "connect timeout", either changing its semantics or requiring adjustment for second/subsequent attempts. There is also the question on whether it would be better to focus on newer HTTP client rather than trying to get the legacy HTTP and HTTPS protocol handlers to support this.

@AlanBateman thanks for the comment, those are excellent points. I wasn't familiar with some of the history with JDK-8170568 when I opened this. I left a comment in https://bugs.openjdk.org/browse/JDK-8170568, and I am going to drop this PR for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15078#issuecomment-1679726389

From cushon at openjdk.org  Tue Aug 15 22:50:15 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 15 Aug 2023 22:50:15 GMT
Subject: Withdrawn: 8313356: Improve address selection in sun.net.NetworkClient
In-Reply-To: <J8BFB7poYBXAd1BnSc-NMyVSvHWTxdMvbp_L6wKr2do=.87b2d641-8c70-4f75-ae0f-f12a7cc82315@github.com>
References: <J8BFB7poYBXAd1BnSc-NMyVSvHWTxdMvbp_L6wKr2do=.87b2d641-8c70-4f75-ae0f-f12a7cc82315@github.com>
Message-ID: <zVHCIyENtnvf83WsQqisCxPP0dFbHkWL3enM2s-Lx8c=.fbbd3660-ca36-4e1c-9939-66ceb5819b58@github.com>

On Fri, 28 Jul 2023 22:37:00 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please review this fix for [JDK-8313356](https://bugs.openjdk.org/browse/JDK-8313356), which improves address selection in `sun.net.NetworkClient` to consider all addresses returned by `InetAddress.getAllByName` instead of only connecting to the first one.
> 
> This follows the approach described in [JDK-8170568](https://bugs.openjdk.org/browse/JDK-8170568).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15078

From jpai at openjdk.org  Wed Aug 16 07:24:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Aug 2023 07:24:11 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v4]
In-Reply-To: <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
Message-ID: <qnfrA3D2uco1HDw4RqAkq4BYeKAiOzFirNGNoQg3F_I=.3af559f7-d975-4a31-8041-55911eb75bd3@github.com>

On Tue, 15 Aug 2023 15:16:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314261: Make fields final in sun.net.www
>   
>   fix B5045306 test failure

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 107:

> 105:     // retryPostProp is true by default so as to preserve behavior
> 106:     // from previous releases.
> 107:     private static final boolean retryPostProp;

At first sight the changes to `retryPostProp` and `keepAliveProp` appear to change the default values here. However, the `static` block of this class does set these two properties to default to `true` when the corresponding system properties aren't set. So this change is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14977#discussion_r1295480984

From jpai at openjdk.org  Wed Aug 16 07:33:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Aug 2023 07:33:08 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v4]
In-Reply-To: <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
Message-ID: <fGJt0hBngG5lzSdcINcE30eRWyl8x7vZRNUOTT-piTQ=.68228df7-ca19-4439-9935-c58c75ab1972@github.com>

On Tue, 15 Aug 2023 15:16:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314261: Make fields final in sun.net.www
>   
>   fix B5045306 test failure

Looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14977#pullrequestreview-1579970960

From aturbanov at openjdk.org  Wed Aug 16 07:52:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Aug 2023 07:52:09 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v4]
In-Reply-To: <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
Message-ID: <RwyZNiq4So0sjsFRsBpqtdJA5pBkWrhhGNjeeKRILmc=.f82f6aee-a293-4c52-ab65-e3e89045f799@github.com>

On Tue, 15 Aug 2023 15:16:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314261: Make fields final in sun.net.www
>   
>   fix B5045306 test failure

src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java line 63:

> 61:     /* the chunk size we use */
> 62:     private final int preferredChunkDataSize;
> 63:     private final int preferedHeaderSize;

Is it a typo `prefered` ?
Other fields use `preferred` prefix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14977#discussion_r1295510868

From dclarke at openjdk.org  Wed Aug 16 12:29:29 2023
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 16 Aug 2023 12:29:29 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations
Message-ID: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>

Currently `ResponsePublisher` occasionally fails due to unreleased resources.
Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.

I ran tiers 1-3 and everything is passing

-------------

Commit messages:
 - ensure clients close to avoid intermittent failure from outstanding operations

Changes: https://git.openjdk.org/jdk/pull/15307/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311792
  Stats: 58 lines in 1 file changed: 58 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15307/head:pull/15307

PR: https://git.openjdk.org/jdk/pull/15307

From duke at openjdk.org  Wed Aug 16 16:37:11 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 16 Aug 2023 16:37:11 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
Message-ID: <jvAsRly2wVraXzyVSLNxGjo6kU8ufm3_thqsNSF95rw=.263b32a3-bb35-4fa1-b396-bbf9ea607a9a@github.com>

On Tue, 15 Aug 2023 10:48:29 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
>  - Revert StreamTokenizer.java
>  - Update DateTimeFormatterBuilder
>  - Avoid locale-sensitive case conversions in java.base

Can someone review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1680928752

From naoto at openjdk.org  Wed Aug 16 17:20:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Aug 2023 17:20:11 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
Message-ID: <wQ4x9r4AcBEtbfKQaDxJULNtVaveGaYeVpm4S4nw3VA=.47707fbf-7814-4fde-bb87-838b4c15442a@github.com>

On Tue, 15 Aug 2023 10:48:29 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
>  - Revert StreamTokenizer.java
>  - Update DateTimeFormatterBuilder
>  - Avoid locale-sensitive case conversions in java.base

LGTM. Thanks for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14763#pullrequestreview-1581093609

From duke at openjdk.org  Wed Aug 16 17:40:15 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 16 Aug 2023 17:40:15 GMT
Subject: Integrated: 8311943: Cleanup usages of toLowerCase() and toUpperCase()
 in java.base
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <Q0AnhgkR0kliEpGrfWEeGi0qnr7-pmRd743_VPnS7H0=.dff23974-4a71-43af-bd6a-5228562b24ca@github.com>

On Mon, 3 Jul 2023 20:53:34 GMT, Glavo <duke at openjdk.org> wrote:

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

This pull request has now been integrated.

Changeset: b32d6411
Author:    Glavo <zjx001202 at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b32d6411c406608ba5f7d60bfb8d935adb876564
Stats:     44 lines in 11 files changed: 6 ins; 0 del; 38 mod

8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14763

From jpai at openjdk.org  Thu Aug 17 01:19:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Aug 2023 01:19:32 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v4]
In-Reply-To: <RwyZNiq4So0sjsFRsBpqtdJA5pBkWrhhGNjeeKRILmc=.f82f6aee-a293-4c52-ab65-e3e89045f799@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <fJnoDy_4jTCizSOZB5XKQ7wK4i33Fkk2lpXCmqreHvw=.2f2cafbf-4122-4921-9fb0-76330949535d@github.com>
 <RwyZNiq4So0sjsFRsBpqtdJA5pBkWrhhGNjeeKRILmc=.f82f6aee-a293-4c52-ab65-e3e89045f799@github.com>
Message-ID: <52rSQbacmCVTHoepaSGbiNPPBkeDI2fGyz6YzDD3ytI=.ea94cd0d-94c9-4d50-8c83-692860d84f74@github.com>

On Wed, 16 Aug 2023 07:49:40 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8314261: Make fields final in sun.net.www
>>   
>>   fix B5045306 test failure
>
> src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java line 63:
> 
>> 61:     /* the chunk size we use */
>> 62:     private final int preferredChunkDataSize;
>> 63:     private final int preferedHeaderSize;
> 
> Is it a typo `prefered` ?
> Other fields use `preferred` prefix.

Hello Andrey, I don't have a strong preference. However, like you note, the other fields are using double `r` and we are anyway in this area changing that code, so I think it's OK to rename this field to use double `r` too. Furthermore, there's no similarly named getter for this field, so changing this field doesn't cause any other impact.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14977#discussion_r1296576908

From vtewari at openjdk.org  Thu Aug 17 03:28:25 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 17 Aug 2023 03:28:25 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <FAyRrk4IiCJmikWZ2QBxfGz6yOYH4JWqWrweSLt1EWA=.03bed6bd-08fa-41e5-bf85-09d46e6ee32e@github.com>

On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

@dfuch can you please review this PR ?.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14810#issuecomment-1681553649

From aturbanov at openjdk.org  Thu Aug 17 06:51:03 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 17 Aug 2023 06:51:03 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v5]
In-Reply-To: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
Message-ID: <IHFCsUB4pi504DFHneDR5loDwZFR9QrU4B48lKlYpbo=.0f1e3d0b-9bd1-48ef-b8e9-974818758cc5@github.com>

> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8314261: Make fields final in sun.net.www
  
  rename preferedHeaderSize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14977/files
  - new: https://git.openjdk.org/jdk/pull/14977/files/b0ad815a..772a42ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14977&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14977/head:pull/14977

PR: https://git.openjdk.org/jdk/pull/14977

From jpai at openjdk.org  Thu Aug 17 06:58:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Aug 2023 06:58:28 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v5]
In-Reply-To: <IHFCsUB4pi504DFHneDR5loDwZFR9QrU4B48lKlYpbo=.0f1e3d0b-9bd1-48ef-b8e9-974818758cc5@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <IHFCsUB4pi504DFHneDR5loDwZFR9QrU4B48lKlYpbo=.0f1e3d0b-9bd1-48ef-b8e9-974818758cc5@github.com>
Message-ID: <NJ6kRHV4O67JxcTSpkfMonJovMheJEukXG2DY-lyPIQ=.b547c455-a025-4964-bc13-91757ef58b6a@github.com>

On Thu, 17 Aug 2023 06:51:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314261: Make fields final in sun.net.www
>   
>   rename preferedHeaderSize

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14977#pullrequestreview-1581905100

From dfuchs at openjdk.org  Thu Aug 17 10:33:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Aug 2023 10:33:27 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <ttIUobZeLxudEhxjMq0Y6qwo_VZqTz0Hfjot0BLzyPg=.2552f3d0-8ee6-4552-b171-14719d617aea@github.com>

On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

Hi Vyom, sorry I had forgotten about this. In principle the fix looks good but the new test has some stability issue. It fails intermittently (and frequently) when run in the CI:

java.lang.AssertionError: expected [1] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:907)
	at org.testng.Assert.assertEquals(Assert.java:917)
	at HttpInputStreamAvailableTest.test(HttpInputStreamAvailableTest.java:103)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1570)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14810#issuecomment-1682039647

From dfuchs at openjdk.org  Thu Aug 17 10:45:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Aug 2023 10:45:27 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <HhPGjyD6AsPTx1dRp0Lu0c2e6JO8SiPak8EBvwXR_uo=.9ad1857b-5346-4e24-9879-c79f1e20cda5@github.com>

On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

test/jdk/java/net/httpclient/HttpInputStreamAvailableTest.java line 103:

> 101:             // If you use HttpURLConnection, then in.available() will return
> 102:             // different value.
> 103:             assertEquals(ZERO, in.available());

I don't think this assertion makes much sense. If the response contains some data then some might be available already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14810#discussion_r1297042678

From dfuchs at openjdk.org  Thu Aug 17 10:52:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Aug 2023 10:52:29 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <dsJbbA7O-57CSgGi43vO7Luq49DlYmefNCuPrB2sQ6c=.34c215a4-046a-4733-be2c-1e456beeb375@github.com>

On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/HttpInputStreamAvailableTest.java line 29:

> 27:  * @summary HttpResponseInputStream.available() returns 1 on empty stream
> 28:  * @library /test/lib /test/jdk/java/net/httpclient/lib
> 29:  * @run testng/othervm HttpInputStreamAvailableTest

Could we use `junit/othervm` here

test/jdk/java/net/httpclient/HttpInputStreamAvailableTest.java line 50:

> 48: import org.testng.annotations.AfterTest;
> 49: import org.testng.annotations.BeforeTest;
> 50: import static org.testng.Assert.assertEquals;

Could you use jupiter annotation instead?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14810#pullrequestreview-1582348653
PR Review Comment: https://git.openjdk.org/jdk/pull/14810#discussion_r1297049287
PR Review Comment: https://git.openjdk.org/jdk/pull/14810#discussion_r1297048561

From dfuchs at openjdk.org  Thu Aug 17 13:51:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Aug 2023 13:51:27 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream
In-Reply-To: <HhPGjyD6AsPTx1dRp0Lu0c2e6JO8SiPak8EBvwXR_uo=.9ad1857b-5346-4e24-9879-c79f1e20cda5@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
 <HhPGjyD6AsPTx1dRp0Lu0c2e6JO8SiPak8EBvwXR_uo=.9ad1857b-5346-4e24-9879-c79f1e20cda5@github.com>
Message-ID: <ngvAWtjVCuFppeEdnBJaXm_KKFcmtn-A2BxiJvKMDBU=.8e5340f8-aaab-432f-b092-495ce2da8de5@github.com>

On Thu, 17 Aug 2023 10:42:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.
>
> test/jdk/java/net/httpclient/HttpInputStreamAvailableTest.java line 103:
> 
>> 101:             // If you use HttpURLConnection, then in.available() will return
>> 102:             // different value.
>> 103:             assertEquals(ZERO, in.available());
> 
> I don't think this assertion makes much sense. If the response contains some data then some might be available already.

If this assertion removed the test passes reliably in the CI. Also note that converting the test to junit would "fix" the issue with the assertion parameters being reversed: 

- in testng:  assertXxx(actual, expected)
- in junit:      assertXxx(expected, actual)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14810#discussion_r1297250675

From dfuchs at openjdk.org  Thu Aug 17 17:39:28 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 17 Aug 2023 17:39:28 GMT
Subject: RFR: 8314261: Make fields final in sun.net.www [v5]
In-Reply-To: <IHFCsUB4pi504DFHneDR5loDwZFR9QrU4B48lKlYpbo=.0f1e3d0b-9bd1-48ef-b8e9-974818758cc5@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
 <IHFCsUB4pi504DFHneDR5loDwZFR9QrU4B48lKlYpbo=.0f1e3d0b-9bd1-48ef-b8e9-974818758cc5@github.com>
Message-ID: <Td3hyEIh_vNAOc_tULb1j7xN_Ay4wSUQgTKhAFxX9xI=.1527175e-219b-46e1-859e-6ed364febe0f@github.com>

On Thu, 17 Aug 2023 06:51:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314261: Make fields final in sun.net.www
>   
>   rename preferedHeaderSize

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14977#pullrequestreview-1583141825

From aturbanov at openjdk.org  Thu Aug 17 17:56:35 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 17 Aug 2023 17:56:35 GMT
Subject: Integrated: 8314261: Make fields final in sun.net.www
In-Reply-To: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
References: <uNKzaDWTzmOSlQVigc7Q-DM-0pKw6IwTc2XbgdCQEy0=.c3a5b64c-0aab-46ad-822c-3bd690634446@github.com>
Message-ID: <7E1yE3aAzBZbE0DpbNWDIHAyJdbcGWHziEgY3AHF4eY=.8490cedd-3926-4f6b-a855-8bc7288915eb@github.com>

On Fri, 21 Jul 2023 16:44:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `sun.net.www` package have non-final fields which could easily be marked `final`.

This pull request has now been integrated.

Changeset: a8ab3be3
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8ab3be371ab84ad768d9788a1e7a8d1bb833426
Stats:     63 lines in 13 files changed: 3 ins; 8 del; 52 mod

8314261: Make fields final in sun.net.www

Reviewed-by: redestad, jpai, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/14977

From vtewari at openjdk.org  Fri Aug 18 03:40:43 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 18 Aug 2023 03:40:43 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream [v2]
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <y0ter7hwDwqYgGgV8rWCAvN9APmwQm_sMPvKmXgPUIE=.81e294ee-a0eb-4983-9c83-09c90a98113d@github.com>

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:

  converted the test to junit and removed the one assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14810/files
  - new: https://git.openjdk.org/jdk/pull/14810/files/5e6cb9ce..a4a6eaff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14810&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14810&range=00-01

  Stats: 13 lines in 1 file changed: 2 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14810/head:pull/14810

PR: https://git.openjdk.org/jdk/pull/14810

From mbaesken at openjdk.org  Fri Aug 18 07:00:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Aug 2023 07:00:55 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine
Message-ID: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>

Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

-------------

Commit messages:
 - JDK-8314517

Changes: https://git.openjdk.org/jdk/pull/15341/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15341&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314517
  Stats: 90 lines in 6 files changed: 33 ins; 1 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/15341.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15341/head:pull/15341

PR: https://git.openjdk.org/jdk/pull/15341

From mdoerr at openjdk.org  Fri Aug 18 08:27:24 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 18 Aug 2023 08:27:24 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine
In-Reply-To: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
Message-ID: <pIcHhzUpY26GxTiN5H0HfWP8cOGS-x6fPGHxFXSdotM=.b312ea09-4a5d-4e71-bd98-ee43ec52d651@github.com>

On Fri, 18 Aug 2023 06:53:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

Looks reasonable.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15341#pullrequestreview-1584097547

From lucy at openjdk.org  Fri Aug 18 13:27:33 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 18 Aug 2023 13:27:33 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine
In-Reply-To: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
Message-ID: <AcUyz2Ucn9sAvQXqc7_iPXkTRhhbkWSftFomsYDE0UI=.79044a30-614e-4cc8-acfa-d1d8009e22f8@github.com>

On Fri, 18 Aug 2023 06:53:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

LGTM.
Testing IPV6 only if it is available for sure makes sense.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15341#pullrequestreview-1584566330

From jpai at openjdk.org  Mon Aug 21 07:38:27 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Aug 2023 07:38:27 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine
In-Reply-To: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
Message-ID: <xizJ0CUm1kyuiKp2EFnkvWS9feM7RZLaisF4z6ef5II=.a0db27ed-7903-45d4-b342-5b9406aed6e6@github.com>

On Fri, 18 Aug 2023 06:53:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

I've added a trivial review comment about one of the test method changes. Other than that, these changes look OK to me.

test/jdk/java/net/InetAddress/HostsFileOrderingTest.java line 91:

> 89:     @Test
> 90:     public void testOrdering() throws Exception {
> 91:         if (IPSupport.hasIPv6()) {

Hello Matthias, unlike changes to some other tests, this skips the entire test method if there's no IPv6 support. So perhaps add a System.out message that this test is skipped? I checked if `testng` has `assumeTrue` kind of API like junit, but I couldn't find any, so just returning by printing a System.out message might be enough.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15341#pullrequestreview-1586377503
PR Review Comment: https://git.openjdk.org/jdk/pull/15341#discussion_r1299719669

From dfuchs at openjdk.org  Mon Aug 21 08:29:32 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Aug 2023 08:29:32 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream [v2]
In-Reply-To: <y0ter7hwDwqYgGgV8rWCAvN9APmwQm_sMPvKmXgPUIE=.81e294ee-a0eb-4983-9c83-09c90a98113d@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
 <y0ter7hwDwqYgGgV8rWCAvN9APmwQm_sMPvKmXgPUIE=.81e294ee-a0eb-4983-9c83-09c90a98113d@github.com>
Message-ID: <8hZgy32NvGc2zj9O5KefjpG6PzOTLAliL0PSkS9HNgQ=.44706d15-9bfd-464f-977b-43d7d9a085f6@github.com>

On Fri, 18 Aug 2023 03:40:43 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   converted the test to junit and removed the one assert

Marked as reviewed by dfuchs (Reviewer).

test/jdk/java/net/httpclient/HttpInputStreamAvailableTest.java line 103:

> 101:         try ( InputStream in = response.body()) {
> 102:             in.readNBytes(2);
> 103:             assertEquals(TEST_MESSAGE.length() - 2, in.available());

It could be good to put a comment before this assert to say:
Suggestion:

            // this is not guaranteed, but a failure here would be surprising
            assertEquals(TEST_MESSAGE.length() - 2, in.available());

-------------

PR Review: https://git.openjdk.org/jdk/pull/14810#pullrequestreview-1586478532
PR Review Comment: https://git.openjdk.org/jdk/pull/14810#discussion_r1299784700

From Shruthi.Shruthi1 at ibm.com  Mon Aug 21 16:28:26 2023
From: Shruthi.Shruthi1 at ibm.com (Shruthi Shruthi1)
Date: Mon, 21 Aug 2023 16:28:26 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11
Message-ID: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>

Problem Description :
Customer has reported an issue , hang in preClose() method.

Analysis & Observation :
The preClose() method internally calls the dup2() system call. If there is a dup2() call on a file descriptor on a thread while another thread is blocked in a read/write operation on the same file descriptor, then the dup2() call is known to hang. Currently, preClose() experiences a hang because we call dup2() before killing the reader/writer thread(s).

Suggested Solution:
The solution is to first kill the reader/writer thread(s) and then do the preClose() sequence. This reordering in the different channel implementations resolves the customer problem as per the testing.

// wait for any outstanding read to complete
        if (blocking) {
            synchronized (stateLock) {
                assert state == ST_CLOSING;
                long th = thread;
                if (th != 0) {
                    nd.preClose(fd);
                    NativeThread.signal(th);

The above code is changed to

 // wait for any outstanding read to complete
        if (blocking) {
            synchronized (stateLock) {
                assert state == ST_CLOSING;
                long th = thread;
                if (th != 0) {
                    NativeThread.signal(th);
                    nd.preClose(fd);

Releases:
OpenJDK11 & OpenJDK17 the issue is seen. In OpenJDK21 the issue is not seen.

Next steps:
We want to take the above mentioned fix to OpenJDK but unfortunately we are seeing the below issue.
* The customer has confirmed that the issue is not reproducible in OpenJDK dev branch
* We have not been successful in creating a java reproducer even after spending a considerable amount of time.

Please review and suggest if the above understanding is right and we shall take the fix to OpenJDK17 and backport to OpenJDK11.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230821/4ebd31ba/attachment-0001.htm>

From Alan.Bateman at oracle.com  Mon Aug 21 17:25:22 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 21 Aug 2023 18:25:22 +0100
Subject: Suggestion needed to port the fix to JDK17 and JDK11
In-Reply-To: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>
References: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>
Message-ID: <6943e055-70f1-207a-547a-ba0ff7c784d0@oracle.com>

On 21/08/2023 17:28, Shruthi Shruthi1 wrote:
>
> The preClose() method internally calls the dup2() system call. If 
> there is a dup2() call on a file descriptor on a thread while another 
> thread is blocked in a read/write operation on the same file 
> descriptor, then the dup2() call is known to hang. Currently, 
> preClose() experiences a hang because we call dup2() before killing 
> the reader/writer thread(s).
>
The JDK has a lot of tests for async close so if dup2 is hanging then I 
would expect at least some test failure. Which operating system (and 
version) is still happening on? Do you know SO_LINGER has been enabled?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230821/b28abb01/attachment.htm>

From dfuchs at openjdk.org  Mon Aug 21 17:35:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Aug 2023 17:35:26 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine
In-Reply-To: <xizJ0CUm1kyuiKp2EFnkvWS9feM7RZLaisF4z6ef5II=.a0db27ed-7903-45d4-b342-5b9406aed6e6@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
 <xizJ0CUm1kyuiKp2EFnkvWS9feM7RZLaisF4z6ef5II=.a0db27ed-7903-45d4-b342-5b9406aed6e6@github.com>
Message-ID: <sebETzQBEHRdr3DjloGLfVFXHHJVjTciS8_tUQM885A=.8b707785-7447-4a5e-b4d6-2f1267ded850@github.com>

On Mon, 21 Aug 2023 07:35:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).
>
> test/jdk/java/net/InetAddress/HostsFileOrderingTest.java line 91:
> 
>> 89:     @Test
>> 90:     public void testOrdering() throws Exception {
>> 91:         if (IPSupport.hasIPv6()) {
> 
> Hello Matthias, unlike changes to some other tests, this skips the entire test method if there's no IPv6 support. So perhaps add a System.out message that this test is skipped? I checked if `testng` has `assumeTrue` kind of API like junit, but I couldn't find any, so just returning by printing a System.out message might be enough.

Some of the test runs should work whether the machine has IPv6 or not. Maybe this test should be more selective with respect to when the test should be skipped. For instance at line 47-48: 

 * @run testng/othervm -Djdk.net.hosts.file=TestHostsFile.txt
 * -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false HostsFileOrderingTest

well - that should work - and only return IPv4 addresses.

On second thought - I suspect it's `getExpectedAddressesArray()` that should be fixed to take into account IPSupport.hasIPv6() instead of doing it here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15341#discussion_r1300440236

From alanb at openjdk.org  Tue Aug 22 07:34:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:34:28 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
 <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
Message-ID: <iSZjmtstOLnRKJVOgiHuPS9vkQ644LbZ3T3LvGGekQw=.56dde62e-6ada-4cf7-86c8-dbb62bc6636e@github.com>

On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops

Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687630491

From alanb at openjdk.org  Tue Aug 22 07:41:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:32 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <FSLy1lu91T20fxp7TbB9D7WMcdHJMK_wAn12SIT7k4U=.e300f883-4749-451f-a0f2-c6f4df25801f@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

Overall, it's good to move away from the "faraway instrumentation". Looks forward to the next steps to get to a more complete solution.

src/java.base/share/classes/java/net/Socket.java line 44:

> 42: import java.util.Collections;
> 43: 
> 44: 

Minor nit, I assume this additional blank line is left over from a previous iteration.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 465:

> 463:     public long read(ByteBuffer[] dsts, int offset, int length)
> 464:         throws IOException
> 465:     {

The supporting methods for read (beginRead, endRead, throwConnectionReset, ...) are declared before the read methods. It's probably best to put the implRead before the read too so that all the supporting methods are together. Same thing with the write methods.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1588627786
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301134829
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301144638

From alanb at openjdk.org  Tue Aug 22 07:41:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:34 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <EAJkf3t-7yNk3CRvC2oRsjW5dJ1-ZX-hODYy2ShdQHE=.51608e32-7dff-4c92-aaf3-5d25c62943a5@github.com>
 <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>
Message-ID: <Kc9gmGZY4EW0-j0vaYgOjQTS1lqJ5cgIBJ5XerGgrJA=.4e571964-e702-43ee-a1ab-5d76d7726c7d@github.com>

On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> An exception event will be emitted. The event is disabled by default, but there is ongoing work on a throttling mechanism, so it can be always-on.

Good, I think the exception cases are probably the most interesting for this area when it comes to troubleshooting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687636801

From alanb at openjdk.org  Tue Aug 22 07:41:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:38 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>
 <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>
Message-ID: <dHY_YlyH_mN3TaYO-ZzBtyqTEAs7vSlc8_L8_MsGXgU=.e071811b-a84d-4c31-89b6-3cadc4048ef3@github.com>

On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>>  - Merge branch 'master' into JDK-8308995
>>    
>>    # Conflicts:
>>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>>    whitespace.
>>  - some changes from review.
>>    
>>    read0() to implRead()
>>    write0() to implWrite()
>>    trailing whitespace
>>  - fix copyright date
>>  - Added micro benchmark to measure socket event overhead.
>>  - Some changes from review.
>>    
>>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>>    a reverse lookup when fetching the hostname of the remote address.
>>  - remove unnecessary cast
>>  - 8308995: Update Network IO JFR events to be static mirror events
>
> src/java.base/share/classes/java/net/Socket.java line 1133:
> 
>> 1131:                 return parent.getSoTimeout();
>> 1132:             } catch (Throwable t) {
>> 1133:                 // ignored - avoiding exceptions in jfr event data gathering
> 
> This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away.

Were you able to find out what the timeout is used for?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301136108

From alanb at openjdk.org  Tue Aug 22 07:41:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:40 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <Oo5AYrlXuEwsLMkgfJbQFu9H7g9_1-ng1CfncdLAHeg=.e763b44c-a1b8-4fef-acda-828f24004726@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com>
 <Oo5AYrlXuEwsLMkgfJbQFu9H7g9_1-ng1CfncdLAHeg=.e763b44c-a1b8-4fef-acda-828f24004726@github.com>
Message-ID: <gl6QI9nlAksm-F9VUnBVKfaBFhVF8bIXfM_ICUEFe5o=.812ee61d-6aa0-4846-8bdf-1a74ea1fa467@github.com>

On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>> 
>>> 406:     @Override
>>> 407:     public int read(ByteBuffer buf) throws IOException {
>>> 408:         if (!SocketReadEvent.enabled()) {
>> 
>> The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR.
>
> I've created https://bugs.openjdk.org/browse/JDK-8310978 to drive the future PR to support the missing code paths

Thanks, it's a reminder that the existing SocketXXX events are incomplete and/or not much I/O done with the socket adaptors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301143720

From mbaesken at openjdk.org  Tue Aug 22 07:53:12 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Aug 2023 07:53:12 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine [v2]
In-Reply-To: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
Message-ID: <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>

> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust HostsFileOrderingTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15341/files
  - new: https://git.openjdk.org/jdk/pull/15341/files/2d5986e0..28205984

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15341&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15341&range=00-01

  Stats: 14 lines in 1 file changed: 3 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15341.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15341/head:pull/15341

PR: https://git.openjdk.org/jdk/pull/15341

From mbaesken at openjdk.org  Tue Aug 22 07:54:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Aug 2023 07:54:28 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine
In-Reply-To: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
Message-ID: <GrS6fK6ecUWMeUpIH1hRBIcACs-bz_oXn073L2k4y7g=.3b8e3876-aedd-4115-9ee6-b5296fee5fc2@github.com>

On Fri, 18 Aug 2023 06:53:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

Hi Daniel and Jaikiran, I adjusted the HostsFileOrderingTest.java  a bit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15341#issuecomment-1687658377

From egahlin at openjdk.org  Tue Aug 22 08:49:32 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 22 Aug 2023 08:49:32 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <Trwkx7ogqkLlKpCq8w-t7er1ZMlGpfJrQcnMzaLtnsA=.961a8a75-a60a-438b-bb27-6455b7907b09@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

The stack trace will start in the incorrect method, i.e checkForCommit, when a utility method is used. This is probably something we will have to fix anyway. I filed an issue for that: https://bugs.openjdk.org/browse/JDK-8314745

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687749717

From prappo at openjdk.org  Tue Aug 22 08:50:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 08:50:07 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
Message-ID: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>

Please review this simple PR.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15382/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15382&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314738
  Stats: 124 lines in 28 files changed: 0 ins; 116 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15382.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15382/head:pull/15382

PR: https://git.openjdk.org/jdk/pull/15382

From alanb at openjdk.org  Tue Aug 22 08:59:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 08:59:33 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <Ncr3pmGdmtjDBiLKzwriKKDymN4IBVjq38jt1xdlFOA=.c51d2e8e-c653-455e-bef9-7d54c5beb13f@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

One other thing is that the comments in Socket.SocketInputStream and Socket.SocketOutputStream where it has "This class is instrumented by Java Flight Recorder (JFR) to get socket I/O events" can be removed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687765868

From albertattard at gmail.com  Tue Aug 22 12:03:09 2023
From: albertattard at gmail.com (Albert Attard)
Date: Tue, 22 Aug 2023 14:03:09 +0200
Subject: Possible Typo
Message-ID: <CABfnnZNmEP8_dkgST69ek0FNGB1yNro09KnJzvX5nD1UbH7-vQ@mail.gmail.com>

Hello Folks.

Is there a typo in the example shown in
https://openjdk.org/groups/net/httpclient/intro.html?

HttpClient client = HttpClient.newBuilder()
      .version(Version.HTTP_2)
      .followRedirects(Redirect.SAME_PROTOCOL)
      .proxy(ProxySelector.of(new InetSocketAddress("www-proxy.com", 8080)))
      .authenticator(Authenticator.getDefault())
      .build();

I believe that the enum value SAME_PROTOCOL was replaced by NORMAL (Java Doc
<https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Redirect.html>
).

With kind regards,
Albert Attard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230822/0bcdc327/attachment.htm>

From mr at openjdk.org  Tue Aug 22 12:28:29 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 22 Aug 2023 12:28:29 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

Removing `@revised` tags is not a substantive change, so I wouldn?t update the copyright year as you have in some of these files.

Otherwise, this looks fine.

-------------

Marked as reviewed by mr (Lead).

PR Review: https://git.openjdk.org/jdk/pull/15382#pullrequestreview-1589309922

From prappo at openjdk.org  Tue Aug 22 12:28:30 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 12:28:30 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
 <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>
Message-ID: <SDiBPiBgNy7goDvyA_QproyjabPlsLoKDVaK_LUXfME=.05456201-40e8-4e38-b544-c81f9491d21a@github.com>

On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> I wouldn?t update the copyright year as you have in some of these files.

I was taught to do it every time when I change a file. Would you like me to revert those changes to copyright years in this case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688086627

From mr at openjdk.org  Tue Aug 22 12:40:27 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 22 Aug 2023 12:40:27 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <zt4wRlDz8gCkuOvuI-b_2CJ29LVQgsD4tUm7QhBNoHM=.e4306c1b-4a54-46ff-a76c-91418bdca95c@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

You can leave the copyright years as-is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688104170

From prappo at openjdk.org  Tue Aug 22 13:05:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 13:05:38 GMT
Subject: Integrated: 8314738: Remove all occurrences of and support for
 @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <DoB0QHugB2TSmS92E-93jBcsldiwg0_Bhsiusb6oMwo=.4e630be5-9b9a-4d1f-9434-62dffa8900e7@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

This pull request has now been integrated.

Changeset: f39fc0aa
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a
Stats:     124 lines in 28 files changed: 0 ins; 116 del; 8 mod

8314738: Remove all occurrences of and support for @revised

Reviewed-by: mr

-------------

PR: https://git.openjdk.org/jdk/pull/15382

From dfuchs at openjdk.org  Tue Aug 22 14:07:47 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Aug 2023 14:07:47 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine [v2]
In-Reply-To: <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
 <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
Message-ID: <vCQIAH6B-HvJ1D1v-6pHNRS_SYtEy8ZFoIu9dxc-Exw=.e5381a03-fa12-4078-b812-3b86d046d5c6@github.com>

On Tue, 22 Aug 2023 07:53:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust HostsFileOrderingTest

Hi Matthias, this looks much better. Let me give it whirl on the CI to double check there's not unexpected side effects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15341#issuecomment-1688216507

From mbaesken at openjdk.org  Tue Aug 22 14:18:52 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Aug 2023 14:18:52 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine [v2]
In-Reply-To: <vCQIAH6B-HvJ1D1v-6pHNRS_SYtEy8ZFoIu9dxc-Exw=.e5381a03-fa12-4078-b812-3b86d046d5c6@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
 <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
 <vCQIAH6B-HvJ1D1v-6pHNRS_SYtEy8ZFoIu9dxc-Exw=.e5381a03-fa12-4078-b812-3b86d046d5c6@github.com>
Message-ID: <7BNasY3hqnhsN71Bxb7dt99KYsrXqJlmZhDBvjkOJ6w=.48c84e1c-30c6-461e-9501-e7120f107ed2@github.com>

On Tue, 22 Aug 2023 13:43:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Matthias, this looks much better. Let me give it whirl on the CI to double check there's not unexpected side effects.

Sounds good, thanks !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15341#issuecomment-1688253917

From daniel.fuchs at oracle.com  Tue Aug 22 17:40:14 2023
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 22 Aug 2023 18:40:14 +0100
Subject: Possible Typo
In-Reply-To: <CABfnnZNmEP8_dkgST69ek0FNGB1yNro09KnJzvX5nD1UbH7-vQ@mail.gmail.com>
References: <CABfnnZNmEP8_dkgST69ek0FNGB1yNro09KnJzvX5nD1UbH7-vQ@mail.gmail.com>
Message-ID: <77f82cdc-6e8b-5894-e638-778f6fe8c970@oracle.com>

Hi Albert,

Thank you for spotting this.

I have updated the example, it should now show:
Redirect.NORMAL (you may have to refresh your browser
cache to see it).

best regards,

-- daniel


On 22/08/2023 13:03, Albert Attard wrote:
> Hello Folks.
> 
> Is there a typo in the example shown in 
> https://openjdk.org/groups/net/httpclient/intro.html 
> <https://openjdk.org/groups/net/httpclient/intro.html>?
> 
> HttpClient client = HttpClient.newBuilder()
>  ? ? ? .version(Version.HTTP_2)
>  ? ? ? .followRedirects(Redirect.SAME_PROTOCOL)
>  ? ? ? .proxy(ProxySelector.of(new InetSocketAddress("www-proxy.com 
> <http://www-proxy.com>", 8080)))
>  ? ? ? .authenticator(Authenticator.getDefault())
>  ? ? ? .build();
> 
> I believe that the enum value SAME_PROTOCOL was replaced by NORMAL (Java 
> Doc 
> <https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Redirect.html>).
> 
> With kind regards,
> Albert Attard


From duke at openjdk.org  Tue Aug 22 20:02:50 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 22 Aug 2023 20:02:50 GMT
Subject: RFR: 8314774: Optimize URLEncoder
Message-ID: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>

I mainly made these optimizations:

* Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
* Implement a fast path for UTF-8.

In addition to improving performance, these optimizations also reduce temporary objects:

* It no longer allocates any object when there are no characters in the URL that need to be encoded;
* The initial size of StringBuilder is larger to avoid expansion as much as possible;
* For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.

The results of the `URLEncodeDecode` benchmark:


Before:
Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op

After:
Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op


I also updated the tests to add more test cases.

-------------

Commit messages:
 - fix checkstyle
 - Remove CASE_DIFF
 - update SurrogatePairs test
 - fix SurrogatePairs test
 - update SurrogatePairs test
 - fix Decoder test
 - fix encode surrogate pair
 - fix comment
 - Optimize URLEncoder

Changes: https://git.openjdk.org/jdk/pull/15354/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314774
  Stats: 237 lines in 2 files changed: 99 ins; 74 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From zcai at openjdk.org  Tue Aug 22 20:02:51 2023
From: zcai at openjdk.org (Zixian Cai)
Date: Tue, 22 Aug 2023 20:02:51 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <hHxPU5tpaSpgZHcHVMo3cmwvMGpWIm9Sb0L0IASbSYU=.9bf1b41e-acda-4021-bccf-a08c09c361bf@github.com>

On Sat, 19 Aug 2023 20:57:27 GMT, Glavo <duke at openjdk.org> wrote:

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Please use https://bugs.openjdk.org/browse/JDK-8314774

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1688318492

From jpai at openjdk.org  Wed Aug 23 09:09:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Aug 2023 09:09:12 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <irj2tM2leGRCnkszPLOw0uKv5x8dKXTrh-QMbHnVCTw=.527852c9-aa47-4baf-acbd-9becfc665fc6@github.com>

On Sat, 19 Aug 2023 20:57:27 GMT, Glavo <duke at openjdk.org> wrote:

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Hello Glavo, for changes like these, I think it would be more productive and useful to create a mailing list discussion first to provide some context on why this change is needed and gathering inputs from people familiar with this code on whether this change is necessary and worth it. Such discussions will then give the Reviewers some context and inputs on what needs to be considered in these changes and to what extent the changes should be done in the code.

With the proposed changes in this PR which touches the character encoding handling and such, I think this will need a very thorough review keeping aside the performance aspects. I don't have enough experience of this class to know if it's worth doing this amount of change for any kind of performance improvements which may not be visible outside of micro benchmarks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1689424850

From mbaesken at openjdk.org  Wed Aug 23 09:09:43 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 09:09:43 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine [v2]
In-Reply-To: <7BNasY3hqnhsN71Bxb7dt99KYsrXqJlmZhDBvjkOJ6w=.48c84e1c-30c6-461e-9501-e7120f107ed2@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
 <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
 <vCQIAH6B-HvJ1D1v-6pHNRS_SYtEy8ZFoIu9dxc-Exw=.e5381a03-fa12-4078-b812-3b86d046d5c6@github.com>
 <7BNasY3hqnhsN71Bxb7dt99KYsrXqJlmZhDBvjkOJ6w=.48c84e1c-30c6-461e-9501-e7120f107ed2@github.com>
Message-ID: <WXLkHBJ25Wy5-ECrpPtyu5tGT1W-5HErnHY-DGIo2W4=.a2e83bbe-42ff-4248-855b-bb9ac3342735@github.com>

On Tue, 22 Aug 2023 14:04:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Matthias, this looks much better. Let me give it whirl on the CI to double check there's not unexpected side effects.

The latest version worked nicely in our tests; any issues seen in your CI ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15341#issuecomment-1689457812

From jpai at openjdk.org  Wed Aug 23 09:10:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Aug 2023 09:10:01 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations
In-Reply-To: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
Message-ID: <U_606TLgkW8wryIrOYsMT8DFbKCeyFRZLkwceLKSJEo=.510e4956-c093-4261-9f3b-0409afe461f5@github.com>

On Wed, 16 Aug 2023 12:23:27 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
> 
> I ran tiers 1-3 and everything is passing

test/jdk/java/net/httpclient/ResponsePublisher.java line 498:

> 496:     // we use the ReferenceTracker API rather than HttpClient::close here,
> 497:     // because these tests inject faults by throwing inside callbacks, which
> 498:     // is more likely to get HttpClient::close wedged until jtreg times out.

Is this comment and the decision to not use `HttpClient.close()` in this test relevant to this test case? In `AbstractThrowingPublishers`, which is where this comment initially resided like you note in the PR description, I think it was relevant. I haven't thoroughly looked at the tests in this `ResponsePublisher` test, so unsure if we can't/shouldn't use `HttpClient.close()` in these test methods.

test/jdk/java/net/httpclient/ResponsePublisher.java line 506:

> 504:         System.out.println(now() + "waiting for client to shutdown: " + tracker.getName());
> 505:         System.err.println(now() + "waiting for client to shutdown: " + tracker.getName());
> 506:         var error = TRACKER.check(tracker, 10000);

Hello Darragh, 10 seconds looks a bit too large, even if it's the max time to wait. Before this change the graceDelayms was 500 milli seconds. So this appears to be a big jump. Perhaps we should start with something like 2 or 5 seconds (an arbitrary number, I admit)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15307#discussion_r1302575954
PR Review Comment: https://git.openjdk.org/jdk/pull/15307#discussion_r1302573457

From vtewari at openjdk.org  Wed Aug 23 09:15:18 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 23 Aug 2023 09:15:18 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream [v3]
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <Ds74sdpdWFznypinq6Mlxgpbj5yAK1T-K7v3FAQ1L1Q=.1f34bf1a-657e-4ae9-9b85-128a7f951c02@github.com>

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:

  added the comment before assert in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14810/files
  - new: https://git.openjdk.org/jdk/pull/14810/files/a4a6eaff..17b98c71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14810&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14810&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14810/head:pull/14810

PR: https://git.openjdk.org/jdk/pull/14810

From aturbanov at openjdk.org  Wed Aug 23 10:37:15 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 23 Aug 2023 10:37:15 GMT
Subject: RFR: 8314877: Make fields final in 'java.net' package
Message-ID: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>

A few classes in `java.net` package have non-final fields which could easily be marked `final`.

-------------

Commit messages:
 - [PATCH]: Make fields final java.net

Changes: https://git.openjdk.org/jdk/pull/15358/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15358&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314877
  Stats: 31 lines in 10 files changed: 3 ins; 7 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/15358.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15358/head:pull/15358

PR: https://git.openjdk.org/jdk/pull/15358

From stsypanov at openjdk.org  Wed Aug 23 10:37:17 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 23 Aug 2023 10:37:17 GMT
Subject: RFR: 8314877: Make fields final in 'java.net' package
In-Reply-To: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
References: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
Message-ID: <nzk_ABImhHnhkJHBNTFD7rykzdV1KJXJLCeIEhrdTvs=.80a90800-4dac-423e-882b-762c92fb2ec2@github.com>

On Mon, 21 Aug 2023 08:47:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `java.net` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/java/net/SocketPermission.java line 238:

> 236: 
> 237:     // true if the sun.net.trustNameService system property is set
> 238:     private static final boolean trustNameService = GetBooleanAction.privilegedGetProperty("sun.net.trustNameService");

Nice!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15358#discussion_r1301105001

From alanb at openjdk.org  Wed Aug 23 10:43:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Aug 2023 10:43:25 GMT
Subject: RFR: 8314877: Make fields final in 'java.net' package
In-Reply-To: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
References: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
Message-ID: <YWji_zNqiY-fC0jGkCRz4PwSK8VoXYXdBMYmspOg3AA=.89628fae-2c5c-47b8-aafa-f851e4f7da4a@github.com>

On Mon, 21 Aug 2023 08:47:11 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `java.net` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/java/net/URL.java line 1592:

> 1590:      * A table of protocol handlers.
> 1591:      */
> 1592:     static final Hashtable<String,URLStreamHandler> handlers = new Hashtable<>();

Can you check if this can also be changed to be private?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15358#discussion_r1302829784

From dfuchs at openjdk.org  Wed Aug 23 10:47:32 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 10:47:32 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine [v2]
In-Reply-To: <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
 <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
Message-ID: <2Usp61B7q29GdYdCRZGZY3nx0aI7bweqtkgy3hD8T9Y=.b6300a1c-95e8-4f69-ad5b-7422de37eacd@github.com>

On Tue, 22 Aug 2023 07:53:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust HostsFileOrderingTest

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15341#pullrequestreview-1591299345

From mbaesken at openjdk.org  Wed Aug 23 10:47:33 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 10:47:33 GMT
Subject: RFR: JDK-8314517: some tests fail in case ipv6 is disabled on the
 machine [v2]
In-Reply-To: <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
 <RJWVsvkS6Lr0fRS-2gFk2bEMHhypFS6WWhVCjDBU2ZU=.64aa4aa2-1721-46c9-ae1a-ad162bbc9587@github.com>
Message-ID: <bNaE4PU26WWH-NM5TJNkqQ0fvHlZkhkhW8xfFq5c6tg=.dd09a74f-8c54-4961-98d4-ecc4040792c4@github.com>

On Tue, 22 Aug 2023 07:53:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust HostsFileOrderingTest

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15341#issuecomment-1689730345

From mbaesken at openjdk.org  Wed Aug 23 10:47:34 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 10:47:34 GMT
Subject: Integrated: JDK-8314517: some tests fail in case ipv6 is disabled on
 the machine
In-Reply-To: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
References: <S2c2mG8pxByDud6GgPU0zmWMs2bJgajNZwhifGwGI_M=.9d16a1d7-7bef-46f1-a6ff-492c66d75a1f@github.com>
Message-ID: <oYpENFPT49QEfwoUzTo_0SkbcL_DPPrNaLWXRO1m5xU=.3d2ebb08-c0f9-438e-bb69-a24499cc1d82@github.com>

On Fri, 18 Aug 2023 06:53:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Some jtreg tests fail with ipv6 disabled on the machine, this should be improved in the tests (e.g. by using IPSupport.hasIPv6() ).

This pull request has now been integrated.

Changeset: 703817d2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/703817d21f6fd8b24cc670695625dfdb09d3592c
Stats:     82 lines in 6 files changed: 34 ins; 1 del; 47 mod

8314517: some tests fail in case ipv6 is disabled on the machine

Reviewed-by: mdoerr, lucy, jpai, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/15341

From aturbanov at openjdk.org  Wed Aug 23 11:04:14 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 23 Aug 2023 11:04:14 GMT
Subject: RFR: 8314877: Make fields final in 'java.net' package [v2]
In-Reply-To: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
References: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
Message-ID: <hfTuXkVOgWK_kK1QyD9ykowsDtxwaQtwLXYQVwLA4YA=.09dd0227-dfd6-4150-b18d-e88cf533f3ba@github.com>

> A few classes in `java.net` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8314877: Make fields final in 'java.net' package
  
  make java.net.URL.handlers private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15358/files
  - new: https://git.openjdk.org/jdk/pull/15358/files/bd4c9f45..74636379

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15358&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15358&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15358.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15358/head:pull/15358

PR: https://git.openjdk.org/jdk/pull/15358

From aturbanov at openjdk.org  Wed Aug 23 11:04:16 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 23 Aug 2023 11:04:16 GMT
Subject: RFR: 8314877: Make fields final in 'java.net' package [v2]
In-Reply-To: <YWji_zNqiY-fC0jGkCRz4PwSK8VoXYXdBMYmspOg3AA=.89628fae-2c5c-47b8-aafa-f851e4f7da4a@github.com>
References: <e89SYtKChebDACFkeIX_Z4Tgge14r7HMEejLvIiPqvI=.2531e866-23d1-480c-bb16-78545e55f943@github.com>
 <YWji_zNqiY-fC0jGkCRz4PwSK8VoXYXdBMYmspOg3AA=.89628fae-2c5c-47b8-aafa-f851e4f7da4a@github.com>
Message-ID: <tc9X9Uosrzn8Dxdrd-byGXVAoetOP4fto1jorETDfRQ=.565eb6f2-a82c-4e44-8d94-2a5485871312@github.com>

On Wed, 23 Aug 2023 10:40:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8314877: Make fields final in 'java.net' package
>>   
>>   make java.net.URL.handlers private
>
> src/java.base/share/classes/java/net/URL.java line 1592:
> 
>> 1590:      * A table of protocol handlers.
>> 1591:      */
>> 1592:     static final Hashtable<String,URLStreamHandler> handlers = new Hashtable<>();
> 
> Can you check if this can also be changed to be private?

sure. Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15358#discussion_r1302847949

From mdoerr at openjdk.org  Wed Aug 23 12:29:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 23 Aug 2023 12:29:20 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <kbn_Q8G0vVnfxfa-aWmiA7DQ72AFzcH3yrdmOtq7mjg=.24439595-7f1c-46ba-b297-e473e8fe7c20@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Please check windows-aarch64 build error: unresolved external symbol dlopen_ext

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1689871700

From mbaesken at openjdk.org  Wed Aug 23 15:18:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 15:18:03 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  windows aarch64 build issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15264/files
  - new: https://git.openjdk.org/jdk/pull/15264/files/94e25ad7..9ceec5e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264

PR: https://git.openjdk.org/jdk/pull/15264

From Shruthi.Shruthi1 at ibm.com  Wed Aug 23 14:16:47 2023
From: Shruthi.Shruthi1 at ibm.com (Shruthi Shruthi1)
Date: Wed, 23 Aug 2023 14:16:47 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11
In-Reply-To: <6943e055-70f1-207a-547a-ba0ff7c784d0@oracle.com>
References: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <6943e055-70f1-207a-547a-ba0ff7c784d0@oracle.com>
Message-ID: <SJ0PR15MB4663715DCC2734DB0A73BA19CC1CA@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan.,

We are seeing the issue in AIX 7.2 and Java 11.0.11+9. And SO_LINGER is not enabled.

Thanks
Shruthi
________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Monday, August 21, 2023 10:55 PM
To: Shruthi Shruthi1 <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen1 <smoinud1 at in.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11

On 21/08/2023 17:?28, Shruthi Shruthi1 wrote: The preClose() method internally calls the dup2() system call. If there is a dup2() call on a file descriptor on a thread while another thread is blocked in a read/write operation on the same file
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2c-hA57_IBmaGoYbOIuFrV0W1Mt2z4xvKmBMvyO9s1eaEYOakuP3J5zp-ErdZEe6ZklbgGeI1NRiu0ViTVBKh8YiNf1gKcorswcLMw$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd
On 21/08/2023 17:28, Shruthi Shruthi1 wrote:

The preClose() method internally calls the dup2() system call. If there is a dup2() call on a file descriptor on a thread while another thread is blocked in a read/write operation on the same file descriptor, then the dup2() call is known to hang. Currently, preClose() experiences a hang because we call dup2() before killing the reader/writer thread(s).

The JDK has a lot of tests for async close so if dup2 is hanging then I would expect at least some test failure. Which operating system (and version) is still happening on? Do you know SO_LINGER has been enabled?

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230823/1e2b5ed7/attachment.htm>

From dfuchs at openjdk.org  Wed Aug 23 15:58:24 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 15:58:24 GMT
Subject: RFR: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream [v3]
In-Reply-To: <Ds74sdpdWFznypinq6Mlxgpbj5yAK1T-K7v3FAQ1L1Q=.1f34bf1a-657e-4ae9-9b85-128a7f951c02@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
 <Ds74sdpdWFznypinq6Mlxgpbj5yAK1T-K7v3FAQ1L1Q=.1f34bf1a-657e-4ae9-9b85-128a7f951c02@github.com>
Message-ID: <62L0IL_VGd1QZ_f0CrDcPXmjMrSM9-Web6_JyRdMq_Y=.b4e7be26-514d-4271-8eb8-b17715a53201@github.com>

On Wed, 23 Aug 2023 09:15:18 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added the comment before assert in test

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14810#pullrequestreview-1591927069

From dfuchs at openjdk.org  Wed Aug 23 16:41:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 16:41:23 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations
In-Reply-To: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
Message-ID: <UQhT3fVo417JudvRyMGQ8Xv0uLhPeMmgp4zCARIYpOw=.b0f90266-5dba-4a99-aa3c-45e62b07dca9@github.com>

On Wed, 16 Aug 2023 12:23:27 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
> 
> I ran tiers 1-3 and everything is passing

test/jdk/java/net/httpclient/ResponsePublisher.java line 498:

> 496:     // we use the ReferenceTracker API rather than HttpClient::close here,
> 497:     // because these tests inject faults by throwing inside callbacks, which
> 498:     // is more likely to get HttpClient::close wedged until jtreg times out.

No, we do not inject faults here.

Suggestion:

    // Wait for the client to be garbage collected.
    // we use the ReferenceTracker API rather than HttpClient::close here,
    // because we want to get some diagnosis if a client doesn't release
    // its resources and terminates as expected

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15307#discussion_r1303281595

From dfuchs at openjdk.org  Wed Aug 23 16:41:24 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 16:41:24 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations
In-Reply-To: <U_606TLgkW8wryIrOYsMT8DFbKCeyFRZLkwceLKSJEo=.510e4956-c093-4261-9f3b-0409afe461f5@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
 <U_606TLgkW8wryIrOYsMT8DFbKCeyFRZLkwceLKSJEo=.510e4956-c093-4261-9f3b-0409afe461f5@github.com>
Message-ID: <Z1VrcbjNjto5m5afU9bq0NgDvAXcRFRH6JdDnzHcY4g=.3b2e4344-461b-4a2e-98eb-d3ecd7dbe548@github.com>

On Wed, 23 Aug 2023 07:05:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
>> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
>> 
>> I ran tiers 1-3 and everything is passing
>
> test/jdk/java/net/httpclient/ResponsePublisher.java line 506:
> 
>> 504:         System.out.println(now() + "waiting for client to shutdown: " + tracker.getName());
>> 505:         System.err.println(now() + "waiting for client to shutdown: " + tracker.getName());
>> 506:         var error = TRACKER.check(tracker, 10000);
> 
> Hello Darragh, 10 seconds looks a bit too large, even if it's the max time to wait. Before this change the graceDelayms was 500 milli seconds. So this appears to be a big jump. Perhaps we should start with something like 2 or 5 seconds (an arbitrary number, I admit)?

It shouldn't take 10 seconds for the client to shutdown, so it shouldn't matter that we use a large timeout. I we used HttpClient::close() we would wait forever (that is - we would wait for as long as it takes).
I believe 500ms to wait for the GC to kick in was a bit optimistic for cases where the machine is overloaded by other tasks. Waiting for a client to be gc'ed or closed until we create the next one should help, as it will ensure there are no lingering resources waiting to be released. 
The advantage of using close() is that it is much cleaner and simpler. The disadvantage is that if it fails in timeout there, you have no clue about what prevented close() to finish. In opposition the tracker will provide diagnosis if the client fails to close in the imparted delay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15307#discussion_r1303276612

From duke at openjdk.org  Wed Aug 23 17:06:24 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 23 Aug 2023 17:06:24 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <irj2tM2leGRCnkszPLOw0uKv5x8dKXTrh-QMbHnVCTw=.527852c9-aa47-4baf-acbd-9becfc665fc6@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <irj2tM2leGRCnkszPLOw0uKv5x8dKXTrh-QMbHnVCTw=.527852c9-aa47-4baf-acbd-9becfc665fc6@github.com>
Message-ID: <hq5PbLCreOeJw5xnxrGdt_m6FhP2DXC4X0HMWDAlrDY=.e6c5b56e-ec1c-4ac0-992f-60e8589364f3@github.com>

On Wed, 23 Aug 2023 07:22:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Glavo, for changes like these, I think it would be more productive and useful to create a mailing list discussion first to provide some context on why this change is needed and gathering inputs from people familiar with this code on whether this change is necessary and worth it. Such discussions will then give the Reviewers some context and inputs on what needs to be considered in these changes and to what extent the changes should be done in the code.

I see. Thank you for your suggestion.

> I don't have enough experience of this class to know if it's worth doing this amount of change for any kind of performance improvements which may not be visible outside of micro benchmarks.

I know it's usually not a performance bottleneck, so the main goal of this PR is to reduce temporary object allocations.

I noticed that this method is called quite frequently in our code, and it is also used in popular frameworks such as spring. I want to minimize GC pressure by minimizing unnecessary temporary objects.

Since that method almost always uses UTF-8, I think it's worth providing a fast path for UTF-8. If it is too difficult to review, then I will try to optimize it in other ways.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1690322671

From dfuchs at openjdk.org  Wed Aug 23 18:54:22 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 18:54:22 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>

On Sat, 19 Aug 2023 20:57:27 GMT, Glavo <duke at openjdk.org> wrote:

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

The fast path that just returns the given string if ASCII-only and no encoding looks simple enough. I don't particularly like the idea of embedding the logic of encoding UTF-8 into that class though, that increases the complexity significantly, and Charset encoders are there for that. Also I don't understand the reason for changing BitSet into a boolean array - that seems gratuitous?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1690474419

From duke at openjdk.org  Wed Aug 23 23:58:28 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 23 Aug 2023 23:58:28 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>
Message-ID: <75Y3LmjHqfpHx3zAWGk1fUeK4oHd0KZriJwl9h2FOLw=.6d8b7e6d-ceda-4175-a4ed-bc1890800024@github.com>

On Wed, 23 Aug 2023 18:51:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>  I don't particularly like the idea of embedding the logic of encoding UTF-8 into that class though, that increases the complexity significantly, and Charset encoders are there for that.

Unfortunately, the `CharsetEncoder` is too generic. Due to our knowledge of UTF-8, implementing it inline eliminates unnecessary temporary objects. There are already some places that do this, such as `String`.

I'm thinking we might be able to extract this logic into a static helper class.


public class UTF8EncodeUtils {
    public static boolean isSingleByte(char c) { return c < 0x80; }

    public static boolean isDoubleBytes(char c) { return c < 0x800; }

    public static int encodeDoubleBytes(char c) {
        byte b0 = (byte) (0xc0 | (c >> 6));
        byte b1 = (byte) (0x80 | (c & 0x3f));
        return ((b0 & 0xff) << 8) | b1;
    }

    public static int encodeThreeBytes(char c) {
        byte b0 = (byte) (0xe0 | c >> 12);
        byte b1 = (byte) (0x80 | c >> 6 & 0x3f);
        byte b2 = (byte) (0x80 | c & 0x3f);
        return ((b0 & 0xff) << 16) | ((b1 & 0xff) << 8) | b2;
    }

    public static int encodeCodePoint(int uc) {
        byte b0 = (byte) (0xf0 | ((uc >> 18)));
        byte b1 = (byte) (0x80 | ((uc >> 12) & 0x3f));
        byte b2 = (byte) (0x80 | ((uc >> 6) & 0x3f));
        byte b3 = (byte) (0x80 | (uc & 0x3f));
        return ((b0 & 0xff) << 24) | ((b1 & 0xff) << 16) | ((b2 & 0xff) << 8) | b3;
    }
}


We can use this helper class to reimplement `String` and the UTF-8 `CharsetEncoder` (after we make sure it has no overhead), then use it to implement more UTF-8 fast paths.

I've also been doing some work on `OutputStreamWriter` recently. By implementing a fast path for UTF-8, there are over 20x speedups in some cases. I think maybe we can get exciting improvements in more places.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1690789474

From duke at openjdk.org  Thu Aug 24 00:04:25 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 00:04:25 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>
Message-ID: <5FtqcKtrfnRbp-mdQnIeuXwr5tV1j3jy1lh0j-VYUUE=.da02dc58-cac9-4c59-a65d-9994c90ec4d4@github.com>

On Wed, 23 Aug 2023 18:51:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Also I don't understand the reason for changing BitSet into a boolean array - that seems gratuitous?

I observed a throughput improvement of 7%~10% after switching from `BitSet` to `boolean[]`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1690793620

From duke at openjdk.org  Thu Aug 24 01:28:21 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 01:28:21 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v2]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <oWsp3EPhXari6EqkCSO7kTjLDc6cL5Eg44QDGauCrDo=.c84ed021-2fc2-467d-883b-29589b3a3fd8@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  UTF8EncodeUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/6eea3ea8..03b11276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=00-01

  Stats: 121 lines in 2 files changed: 109 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From duke at openjdk.org  Thu Aug 24 01:33:45 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 01:33:45 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v3]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <O3UzZbUnMSmG-8GIHoO79a0IsORnsZq4aKIrCVqINdg=.7d2aeb15-e7b6-4bdf-945d-7329d8453f7a@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  fix test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/03b11276..5385a1ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From duke at openjdk.org  Thu Aug 24 01:53:04 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 01:53:04 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v4]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <9exNoh2FUgQh7vE2woX-lO6JBgGs9N5iFueSySrRrNM=.3546c092-2936-404e-8cc4-f61b7cc85097@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Use byte[] in UTF8EncodeUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/5385a1ab..d8b94dd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=02-03

  Stats: 121 lines in 2 files changed: 0 ins; 9 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From duke at openjdk.org  Thu Aug 24 02:15:58 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 02:15:58 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v5]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <16036HIfvbT4Jyw-ySDonVDFSHU0ugVbNsidXV1xC3o=.3f6c3971-8b5a-463c-b217-2e6d407249d7@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Add @ForceInline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/d8b94dd0..92d93c02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From duke at openjdk.org  Thu Aug 24 02:23:05 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 02:23:05 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v6]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <l1ePv-TYzgH8KBV97OHGj6KL4xq4yNPq8Rg3umWJLxg=.7fcda5f3-dcb5-4508-b4bc-acfc9fe1e882@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Add final modifier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/92d93c02..82626c92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=04-05

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From duke at openjdk.org  Thu Aug 24 02:25:30 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 02:25:30 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v5]
In-Reply-To: <16036HIfvbT4Jyw-ySDonVDFSHU0ugVbNsidXV1xC3o=.3f6c3971-8b5a-463c-b217-2e6d407249d7@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <16036HIfvbT4Jyw-ySDonVDFSHU0ugVbNsidXV1xC3o=.3f6c3971-8b5a-463c-b217-2e6d407249d7@github.com>
Message-ID: <2tUrFPfrxLoA3enuEjZDq7g06H2SS0kxg7TPkn0OJZM=.a86d4c43-0b0b-44df-8550-c671700b50d3@github.com>

On Thu, 24 Aug 2023 02:15:58 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline

I will extract the logic of encoding UTF-8 to `UTF8EncodeUtils`, and then rerun the benchmark:


Baseline:
Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.580 ? 0.008  ms/op

Inline UTF-8 encoding:
Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.546 ? 0.016  ms/op

Use UTF8EncodeUtils:
Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.581 ? 0.064  ms/op


Using `UTF8EncodeUtils` is approximately 1% slower, which is acceptable. I hope to use this utility class in more places in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1690891780

From mbaesken at openjdk.org  Thu Aug 24 07:29:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 07:29:25 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <kbn_Q8G0vVnfxfa-aWmiA7DQ72AFzcH3yrdmOtq7mjg=.24439595-7f1c-46ba-b297-e473e8fe7c20@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <kbn_Q8G0vVnfxfa-aWmiA7DQ72AFzcH3yrdmOtq7mjg=.24439595-7f1c-46ba-b297-e473e8fe7c20@github.com>
Message-ID: <3Z3DhL13S8nSO7g4EaiOmCxTAZERbtP-GlDzlHW-d34=.3a8a9c47-b3e6-4b7c-afac-567ab81f47c8@github.com>

On Wed, 23 Aug 2023 12:26:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Please check windows-aarch64 build error: unresolved external symbol dlopen_ext

Hi Martin, thanks !  I did a small adjustment, now the windows aarch64 build works.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1691148432

From Alan.Bateman at oracle.com  Thu Aug 24 07:46:26 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Aug 2023 08:46:26 +0100
Subject: Suggestion needed to port the fix to JDK17 and JDK11
In-Reply-To: <SJ0PR15MB4663715DCC2734DB0A73BA19CC1CA@SJ0PR15MB4663.namprd15.prod.outlook.com>
References: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <6943e055-70f1-207a-547a-ba0ff7c784d0@oracle.com>
 <SJ0PR15MB4663715DCC2734DB0A73BA19CC1CA@SJ0PR15MB4663.namprd15.prod.outlook.com>
Message-ID: <4b90ccda-5660-04f4-544d-bf9f940c1d27@oracle.com>

On 23/08/2023 15:16, Shruthi Shruthi1 wrote:
> Hi Alan.,
>
> We are seeing the issue in AIX 7.2 and Java 11.0.11+9. And SO_LINGER 
> is not enabled.

There's not much to go on here. A starting point would be to see if the 
nio/channels tests are passing on this operating system. There are 
several tests that exercise async close. If there is OS issue then it 
might happen with the async close of Socket too.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230824/8ec330c3/attachment.htm>

From dfuchs at openjdk.org  Thu Aug 24 09:50:39 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Aug 2023 09:50:39 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v6]
In-Reply-To: <l1ePv-TYzgH8KBV97OHGj6KL4xq4yNPq8Rg3umWJLxg=.7fcda5f3-dcb5-4508-b4bc-acfc9fe1e882@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <l1ePv-TYzgH8KBV97OHGj6KL4xq4yNPq8Rg3umWJLxg=.7fcda5f3-dcb5-4508-b4bc-acfc9fe1e882@github.com>
Message-ID: <-lGA7wl9-PcgJu3RrjRCeS2MhVFYxZ3Ss9Qmj1oFxmE=.a7ea40ea-c2f2-4d7e-be9b-cb4b0b742cfd@github.com>

On Thu, 24 Aug 2023 02:23:05 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add final modifier

I am not sure the added complexity is worth the gain. It's fine for String to have special knowledge of UTF-8 but I don't think we want that to bleed all over the place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691360427

From redestad at openjdk.org  Thu Aug 24 09:50:40 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Aug 2023 09:50:40 GMT
Subject: RFR: 8314774: Optimize URLEncoder
In-Reply-To: <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <yt7uBxIkgGIF-7-OCUZ1r3Z0mUjwR2DwjVVs1WSzVi0=.16fdd983-ec67-4b2a-ab8e-422c461040b5@github.com>
Message-ID: <BClpHkQflHBxcWnu4p6zaPsd6-J5WZPsxlE_nFPqPwk=.f6e1770d-4df4-4e22-a824-eca83b2ab657@github.com>

On Wed, 23 Aug 2023 18:51:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The fast path that just returns the given string if ASCII-only and no encoding looks simple enough. I don't particularly like the idea of embedding the logic of encoding UTF-8 into that class though, that increases the complexity significantly, and Charset encoders are there for that. Also I don't understand the reason for changing BitSet into a boolean array - that seems gratuitous?

A perhaps key difference for performance between the `BitSet` and the `boolean[]` in this code is that the latter is `static final @Stable` and thus easy to optimize for the JIT. The `words` array held by a `BitSet` is neither `final` nor `@Stable` so the JIT likely needs to keep a few extra checks around every access.

An interesting experiment would be to instead model this as a `ConstantBitSet` with a `final @Stable` internal array. This could get most (or all?) of the benefit, keeping things at a higher abstraction level and allow for some reuse. Retaining the compactness of `BitSet`s is nice too, though that might not be very important for constant bit sets.

API would need to be worked out but something like add a public method `BitSet::asConstant` and hiding away the details might be a good starting point:

public BitSet asConstant() {
  return new ConstantBitSet(this);
}

private static class ConstantBitSet extends BitSet {
  private @Stable final long[] words;
  private ConstantBitSet(BitSet bitSet) {
    words = Arrays.copyOf(bitSet.words);
  }
  // override all BitSet methods, make mutating methods throw (IllegalStateException?) 
  // -- for a public API perhaps extract an interface
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691364488

From redestad at openjdk.org  Thu Aug 24 10:08:27 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Aug 2023 10:08:27 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v6]
In-Reply-To: <-lGA7wl9-PcgJu3RrjRCeS2MhVFYxZ3Ss9Qmj1oFxmE=.a7ea40ea-c2f2-4d7e-be9b-cb4b0b742cfd@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <l1ePv-TYzgH8KBV97OHGj6KL4xq4yNPq8Rg3umWJLxg=.7fcda5f3-dcb5-4508-b4bc-acfc9fe1e882@github.com>
 <-lGA7wl9-PcgJu3RrjRCeS2MhVFYxZ3Ss9Qmj1oFxmE=.a7ea40ea-c2f2-4d7e-be9b-cb4b0b742cfd@github.com>
Message-ID: <C4cIWLet9ZlT2sauqA6DFR_hjRygatt3KBpcYQlpUmM=.46130b79-ef3b-42c0-acf8-b4995afa3c95@github.com>

On Thu, 24 Aug 2023 09:44:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I am not sure the added complexity is worth the gain. It's fine for String to have special knowledge of UTF-8 but I don't think we want that to bleed all over the place.

While I lean towards being wary, I think there are definitely things in here that is worth pursuing. 

For example it seems profitable to avoid allocating and appending to a `StringBuilder` for the case where we end up returning the original `String`, so perhaps this would be better implemented using a fast-path loop:

```diff --git a/src/java.base/share/classes/java/net/URLEncoder.java b/src/java.base/share/classes/java/net/URLEncoder.java
index 1b5ff1cae26..e1ded633133 100644
--- a/src/java.base/share/classes/java/net/URLEncoder.java
+++ b/src/java.base/share/classes/java/net/URLEncoder.java
@@ -219,19 +219,28 @@ public static String encode(String s, String enc)
     public static String encode(String s, Charset charset) {
         Objects.requireNonNull(charset, "charset");

-        boolean needToChange = false;
+        int i = 0;
+        while (i < s.length()) {
+            char c = s.charAt(i);
+            if (!DONT_NEED_ENCODING.get(c) || c == ' ') { // perhaps add another BitSet that has also has ' ' 
+                break;
+            } else {
+                i++;
+            }
+        }
+        if (i >= s.length()) {
+            return s;
+        }
         StringBuilder out = new StringBuilder(s.length());
+        out.append(s, 0, i);
         CharArrayWriter charArrayWriter = new CharArrayWriter();

-        for (int i = 0; i < s.length();) {
+        while (i < s.length()) {
             int c = s.charAt(i);
-            //System.out.println("Examining character: " + c);
             if (DONT_NEED_ENCODING.get(c)) {
                 if (c == ' ') {
                     c = '+';
-                    needToChange = true;
                 }
-                //System.out.println("Storing: " + c);
                 out.append((char)c);
                 i++;
             } else {
@@ -290,10 +299,9 @@ public static String encode(String s, Charset charset) {
                     out.append(ch);
                 }
                 charArrayWriter.reset();
-                needToChange = true;
             }
         }

-        return (needToChange? out.toString() : s);
+        return out.toString();
     }
 }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691390826

From duke at openjdk.org  Thu Aug 24 10:17:01 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 10:17:01 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v7]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <RWKrfa0Zq5IyjKkAF-nbDhoF5w0MczWZl4W95GrxlVE=.f7a99bf4-8874-41af-9d46-c691e7bcf967@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Update UTF8EncodeUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/82626c92..08dc3a6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=05-06

  Stats: 12 lines in 2 files changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From duke at openjdk.org  Thu Aug 24 10:24:29 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 10:24:29 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v7]
In-Reply-To: <RWKrfa0Zq5IyjKkAF-nbDhoF5w0MczWZl4W95GrxlVE=.f7a99bf4-8874-41af-9d46-c691e7bcf967@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <RWKrfa0Zq5IyjKkAF-nbDhoF5w0MczWZl4W95GrxlVE=.f7a99bf4-8874-41af-9d46-c691e7bcf967@github.com>
Message-ID: <_q8DnJvIOvGTYHPArd_KLJstLHskk_hPUjH8D43ovJg=.d6a332f2-01ad-4452-a84d-7ab03553b655@github.com>

On Thu, 24 Aug 2023 10:17:01 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update UTF8EncodeUtils

If the UTF-8 fast path is too complex for this PR, I will temporarily abandon this part of the changes and keep the general optimizations in this PR.

As far as encoding UTF-8 goes, I agree that this logic shouldn't be hardcoded in many places. I'm trying to extract this logic into a utility class ([UTF8EncodeUtils.java](https://github.com/openjdk/jdk/blob/08dc3a6ad69d50c62455d3e8823f548bb18e04a2/src/java.base/share/classes/jdk/internal/util/UTF8EncodeUtils.java)). Maybe it should be split into a separate PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691414850

From dclarke at openjdk.org  Thu Aug 24 10:25:57 2023
From: dclarke at openjdk.org (Darragh Clarke)
Date: Thu, 24 Aug 2023 10:25:57 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations [v2]
In-Reply-To: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
Message-ID: <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>

> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
> 
> I ran tiers 1-3 and everything is passing

Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/net/httpclient/ResponsePublisher.java
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15307/files
  - new: https://git.openjdk.org/jdk/pull/15307/files/91b3a009..06a67462

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15307&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15307&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15307/head:pull/15307

PR: https://git.openjdk.org/jdk/pull/15307

From dfuchs at openjdk.org  Thu Aug 24 10:28:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Aug 2023 10:28:27 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v6]
In-Reply-To: <C4cIWLet9ZlT2sauqA6DFR_hjRygatt3KBpcYQlpUmM=.46130b79-ef3b-42c0-acf8-b4995afa3c95@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <l1ePv-TYzgH8KBV97OHGj6KL4xq4yNPq8Rg3umWJLxg=.7fcda5f3-dcb5-4508-b4bc-acfc9fe1e882@github.com>
 <-lGA7wl9-PcgJu3RrjRCeS2MhVFYxZ3Ss9Qmj1oFxmE=.a7ea40ea-c2f2-4d7e-be9b-cb4b0b742cfd@github.com>
 <C4cIWLet9ZlT2sauqA6DFR_hjRygatt3KBpcYQlpUmM=.46130b79-ef3b-42c0-acf8-b4995afa3c95@github.com>
Message-ID: <H6QvVbY6FUScjuS2WTyryn7toz-U9-0A2GK8Q6fdEiQ=.4a65d43a-b910-419e-8d56-6ed2ff30d76d@github.com>

On Thu, 24 Aug 2023 10:05:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> While I lean towards being wary, I think there are definitely things in here that is worth pursuing.
> 
> For example it seems profitable to avoid allocating and appending to a `StringBuilder` for the case where we end up returning the original `String`, so perhaps this would be better implemented using a fast-path loop:

Yes that's what I was trying to say in my first comment. I would be fine with keeping that part of the proposed changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691419336

From dfuchs at openjdk.org  Thu Aug 24 10:31:30 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Aug 2023 10:31:30 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations [v2]
In-Reply-To: <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
 <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>
Message-ID: <S9YuDBRFtCPJIt0WTxkrmCGxA-lFO4cTMbWvf5b7KyU=.f1a5c0af-edb9-49da-9f3d-434d50ff55a8@github.com>

On Thu, 24 Aug 2023 10:25:57 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
>> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
>> 
>> I ran tiers 1-3 and everything is passing
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/net/httpclient/ResponsePublisher.java
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

LGTM. Please make sure the changed test passes reliably in the CI before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15307#pullrequestreview-1593280666

From duke at openjdk.org  Thu Aug 24 10:38:57 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 10:38:57 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v8]
In-Reply-To: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
Message-ID: <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>

> I mainly made these optimizations:
> 
> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
> * Implement a fast path for UTF-8.
> 
> In addition to improving performance, these optimizations also reduce temporary objects:
> 
> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
> 
> The results of the `URLEncodeDecode` benchmark:
> 
> 
> Before:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
> 
> After:
> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
> 
> 
> I also updated the tests to add more test cases.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  Remove UTF-8 fast path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15354/files
  - new: https://git.openjdk.org/jdk/pull/15354/files/08dc3a6a..071f48d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15354&range=06-07

  Stats: 192 lines in 2 files changed: 18 ins; 171 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15354/head:pull/15354

PR: https://git.openjdk.org/jdk/pull/15354

From redestad at openjdk.org  Thu Aug 24 10:38:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Aug 2023 10:38:58 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v7]
In-Reply-To: <RWKrfa0Zq5IyjKkAF-nbDhoF5w0MczWZl4W95GrxlVE=.f7a99bf4-8874-41af-9d46-c691e7bcf967@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <RWKrfa0Zq5IyjKkAF-nbDhoF5w0MczWZl4W95GrxlVE=.f7a99bf4-8874-41af-9d46-c691e7bcf967@github.com>
Message-ID: <lIo5cSEHpzJlAvktFD49LJPvgtyqIPjCpr6SKNbLirY=.3f2a1e30-9beb-4af0-b9d1-54d0a80670b9@github.com>

On Thu, 24 Aug 2023 10:17:01 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update UTF8EncodeUtils

I think scaling back this PR to deal mainly with the non-allocating generic fast-path and splitting off other changes, including the UTF-8 fast path, into one or more follow-up PRs would be good. Keep test and benchmark changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691426998

From duke at openjdk.org  Thu Aug 24 10:47:37 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 24 Aug 2023 10:47:37 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v8]
In-Reply-To: <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
Message-ID: <Ug1nZd9iskYUGKEyEea85hYvfuo2Op43KgeHfOMbTUo=.550e321d-bef1-4485-96f9-cab278b37d6b@github.com>

On Thu, 24 Aug 2023 10:38:57 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UTF-8 fast path

I've removed the UTF-8 fast path and this is the JMH result now:


Baseline:
Benchmark                                          (count)  (maxLength)  (mySeed)  Mode  Cnt        Score   Error   Units
URLEncodeDecode.testEncodeUTF8                        1024         1024         3  avgt   15        5.582 ? 0.009   ms/op
URLEncodeDecode.testEncodeUTF8:gc.alloc.rate          1024         1024         3  avgt   15     1439.974 ? 2.386  MB/sec
URLEncodeDecode.testEncodeUTF8:gc.alloc.rate.norm     1024         1024         3  avgt   15  8429374.434 ? 0.239    B/op
URLEncodeDecode.testEncodeUTF8:gc.count               1024         1024         3  avgt   15        6.000          counts
URLEncodeDecode.testEncodeUTF8:gc.time                1024         1024         3  avgt   15        9.000              ms

This PR:
Benchmark                                          (count)  (maxLength)  (mySeed)  Mode  Cnt        Score    Error   Units
URLEncodeDecode.testEncodeUTF8                        1024         1024         3  avgt   15        4.452 ?  0.092   ms/op
URLEncodeDecode.testEncodeUTF8:gc.alloc.rate          1024         1024         3  avgt   15     1702.963 ? 35.595  MB/sec
URLEncodeDecode.testEncodeUTF8:gc.alloc.rate.norm     1024         1024         3  avgt   15  7949307.100 ?  0.721    B/op
URLEncodeDecode.testEncodeUTF8:gc.count               1024         1024         3  avgt   15      120.000           counts
URLEncodeDecode.testEncodeUTF8:gc.time                1024         1024         3  avgt   15      125.000               ms


This PR now has about a 25% performance increase and a 5% reduction in memory allocation in the `URLEncodeDecode` benchmark.

Well, that doesn't seem like a significant improvement, so I initially wanted to submit it with the UTF-8 fast path, which would significantly reduce memory allocations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691443610

From jpai at openjdk.org  Thu Aug 24 11:41:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Aug 2023 11:41:28 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations [v2]
In-Reply-To: <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
 <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>
Message-ID: <aDrICHIG__H00of89YbQgLogj5T9lD5CuvvX4Juarnw=.c555f71a-c305-434d-9435-c53dafd38115@github.com>

On Thu, 24 Aug 2023 10:25:57 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
>> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
>> 
>> I ran tiers 1-3 and everything is passing
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/net/httpclient/ResponsePublisher.java
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15307#pullrequestreview-1593390764

From jpai at openjdk.org  Thu Aug 24 11:41:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Aug 2023 11:41:30 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations [v2]
In-Reply-To: <Z1VrcbjNjto5m5afU9bq0NgDvAXcRFRH6JdDnzHcY4g=.3b2e4344-461b-4a2e-98eb-d3ecd7dbe548@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
 <U_606TLgkW8wryIrOYsMT8DFbKCeyFRZLkwceLKSJEo=.510e4956-c093-4261-9f3b-0409afe461f5@github.com>
 <Z1VrcbjNjto5m5afU9bq0NgDvAXcRFRH6JdDnzHcY4g=.3b2e4344-461b-4a2e-98eb-d3ecd7dbe548@github.com>
Message-ID: <QaOe195X6fZkj6VO-qc8EnfWiwPoWg9tqx-8lm8odo4=.252048ea-8d07-4298-b046-826e29790c8e@github.com>

On Wed, 23 Aug 2023 16:32:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>The advantage of using close() is that it is much cleaner and simpler. The disadvantage is that if it fails in timeout there, you have no clue about what prevented close() to finish. In opposition the tracker will provide diagnosis if the client fails to close in the imparted delay.

That sounds reasonable to me. The changes look fine in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15307#discussion_r1304196554

From redestad at openjdk.org  Thu Aug 24 12:14:27 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Aug 2023 12:14:27 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v8]
In-Reply-To: <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
Message-ID: <lJcrzCk_ZeZGaPnYSa8tceH87S2zBkLv6WJZgeTaIgY=.52de705b-e756-4091-8193-cd997703a11f@github.com>

On Thu, 24 Aug 2023 10:38:57 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UTF-8 fast path

Does your benchmark test a healthy mix of strings? Some that need encoding, some that don't (perhaps mostly weighted so that most inputs need encoding only in the latter half - which is common since protocol+host seldom needs encoding) 

For strings that don't need encoding at all this optimization alone should get you close to the numbers for the full thing.

The heuristic to size the sb could perhaps discount chars we copy 1:1 to reduce allocation pressure (`i + ((s.length() - i) << 1)`)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1691559924

From vtewari at openjdk.org  Thu Aug 24 15:49:41 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 24 Aug 2023 15:49:41 GMT
Subject: Integrated: 8306040: HttpResponseInputStream.available() returns 1 on
 empty stream
In-Reply-To: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
References: <ou0kUoERaJekSJNZIj10wfIdeqixjMZCZCU74J9VhcY=.ff9fe981-664c-4d30-9a5d-af971a5b838e@github.com>
Message-ID: <YFImtDnA7HGaHQlmWuBeBesxFzCfSkrO2CRoAIDOCQk=.e8b1f2d3-d1ed-4d1e-945e-ffba9488a635@github.com>

On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Please review the code change for [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden "available" method of "HttpResponseInputStream" we are returning 1 after exploring all the code path.

This pull request has now been integrated.

Changeset: acaab6fd
Author:    Vyom Tewari <vtewari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acaab6fd74f507bb6b18167505d88e505bdf24bd
Stats:     163 lines in 2 files changed: 161 ins; 0 del; 2 mod

8306040: HttpResponseInputStream.available() returns 1 on empty stream

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/14810

From redestad at openjdk.org  Thu Aug 24 23:18:09 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Aug 2023 23:18:09 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v8]
In-Reply-To: <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
Message-ID: <_gJuJhghFpuX30i_s7TY64681yjpZqmMnQqf_AnpZMk=.b440b057-3961-4325-9222-28ca7c4d0f93@github.com>

On Thu, 24 Aug 2023 10:38:57 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UTF-8 fast path

I took a look at the `URLEncodeDecode` micro and noticed that it was generating strings with a lot of encoding required, and seemingly doing so by accident: most of the tokens are not set as a quick read of the code would say.

I patch this up like so, letting a random subset of strings be generated with chars that need encoding but most being plain:

```diff --git a/test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java b/test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java
index 1bd98f9ed52..6b4ea3aaaca 100644
--- a/test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java
+++ b/test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java
@@ -37,6 +37,8 @@

 import java.io.UnsupportedEncodingException;
 import java.net.URLDecoder;
+import java.nio.charset.StandardCharsets;
+import java.util.Arrays;
 import java.util.Random;
 import java.util.concurrent.TimeUnit;

@@ -66,22 +68,22 @@ public class URLEncodeDecode {

     @Setup
     public void setupStrings() {
-        char[] tokens = new char[((int) 'Z' - (int) 'A' + 1) + ((int) 'z' - (int) 'a' + 1) + ((int) '9' - (int) '1' + 1) + 5];
+        char[] tokens = new char[((int) 'Z' - (int) 'A' + 1) + ((int) 'z' - (int) 'a' + 1) + ((int) '9' - (int) '0' + 1) + 4];
         int n = 0;
-        tokens[n++] = '0';
-        for (int i = (int) '1'; i <= (int) '9'; i++) {
+        for (int i = (int) '0'; i <= (int) '9'; i++) {
             tokens[n++] = (char) i;
         }
         for (int i = (int) 'A'; i <= (int) 'Z'; i++) {
             tokens[n++] = (char) i;
         }
-        for (int i = (int) 'a'; i <= (int) '<'; i++) {
+        for (int i = (int) 'a'; i <= (int) 'z'; i++) {
             tokens[n++] = (char) i;
         }
         tokens[n++] = '-';
         tokens[n++] = '_';
         tokens[n++] = '.';
         tokens[n++] = '*';
+        System.out.println(Arrays.toString(tokens));

         Random r = new Random(mySeed);
         testStringsEncode = new String[count];
@@ -89,10 +91,15 @@ public void setupStrings() {
         toStrings = new String[count];
         for (int i = 0; i < count; i++) {
             int l = r.nextInt(maxLength);
+            boolean needEncoding = r.nextInt(100) <= 15;
             StringBuilder sb = new StringBuilder();
             for (int j = 0; j < l; j++) {
                 int c = r.nextInt(tokens.length);
-                sb.append(tokens[c]);
+                if (needEncoding && r.nextInt(100) <= 3) {
+                    sb.append('[');
+                } else {
+                    sb.append(tokens[c]);
+                }
             }
             testStringsEncode[i] = sb.toString();
         }
@@ -115,14 +122,14 @@ public void setupStrings() {
     @Benchmark
     public void testEncodeUTF8(Blackhole bh) throws UnsupportedEncodingException {
         for (String s : testStringsEncode) {
-            bh.consume(java.net.URLEncoder.encode(s, "UTF-8"));
+            bh.consume(java.net.URLEncoder.encode(s, StandardCharsets.UTF_8));
         }
     }

     @Benchmark
     public void testDecodeUTF8(Blackhole bh) throws UnsupportedEncodingException {
         for (String s : testStringsDecode) {
-            bh.consume(URLDecoder.decode(s, "UTF-8"));
+            bh.consume(URLDecoder.decode(s, StandardCharsets.UTF_8));
         }
     }


With this a simple no-encoding-needed fast-path is enough to give a 3x speedup and a 50% allocation reduction:

Name                           (count) (maxLength) (mySeed) Cnt  Base   Error   Test   Error  Unit  Diff%
URLEncodeDecode.testEncodeUTF8    1024        1024        3  15 2.862 ? 0.395  1.068 ? 0.028 ms/op  62.7% (p = 0.000*)


URLEncodeDecode.testEncodeUTF8:?gc.alloc.rate.norm                  1024         1024         3  avgt   15  1072598.651 ?  12806.440    B/op
URLEncodeDecode.testEncodeUTF8:?gc.alloc.rate.norm                  1024         1024         3  avgt   15  492086.107 ?   1751.752    B/op


Fixing the microbenchmark of course means we don't do as much actual encoding, downplaying the cost and the potential win. What balance is realistic is a good question, but the unfixed micro only saw strings that need encoding and more than 40% of the chars in those strings needed a triple-char encoding which is extremely skewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1692531267

From alanb at openjdk.org  Sat Aug 26 13:44:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Aug 2023 13:44:08 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <X453xaUIPaOuRuCqTo9o-q0yI2Hdk3ujtmd0umpgkco=.be63945d-6506-43b6-9f4c-d980492b303e@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <X453xaUIPaOuRuCqTo9o-q0yI2Hdk3ujtmd0umpgkco=.be63945d-6506-43b6-9f4c-d980492b303e@github.com>
Message-ID: <yzYVji84WvFQd7ZyxtZam5pnTN2GRHYcqR5vG72aedc=.e9195274-1bea-4823-ac1b-bd897eae4020@github.com>

On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files.

Right now, you've got concerns/objections from two potential reviewers so it would be better to see if there are other options to help the error logs on AIX.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694344116

From dholmes at openjdk.org  Mon Aug 28 02:29:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Aug 2023 02:29:18 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <VdNeGwdmluvTB-MxwQz5UAUGXhw6NoN3YkuKQp5yqLU=.d208acdc-4441-4ba8-beb8-560d7f535311@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is  far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues.

I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694907802

From mbaesken at openjdk.org  Mon Aug 28 07:05:13 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Aug 2023 07:05:13 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <VdNeGwdmluvTB-MxwQz5UAUGXhw6NoN3YkuKQp5yqLU=.d208acdc-4441-4ba8-beb8-560d7f535311@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
 <VdNeGwdmluvTB-MxwQz5UAUGXhw6NoN3YkuKQp5yqLU=.d208acdc-4441-4ba8-beb8-560d7f535311@github.com>
Message-ID: <SnM2uIIiFvqw2u72KsdhluvTYNXmqdETub-k1DQvmVc=.e0aa1c9d-acf6-4b71-bd6e-f291c54942c6@github.com>

On Mon, 28 Aug 2023 02:26:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues.
> 
> I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading.


Hi David, so would you prefer to call into 'os::dll_load' (probably you meant that) instead ?  That would indeed make the coding smaller and less 'messy' .
However 'os::dll_load' has no flags parameter but uses a default, have to check if this might be a problem ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1695142975

From Shruthi.Shruthi1 at ibm.com  Mon Aug 28 05:32:57 2023
From: Shruthi.Shruthi1 at ibm.com (Shruthi Shruthi1)
Date: Mon, 28 Aug 2023 05:32:57 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11
In-Reply-To: <4b90ccda-5660-04f4-544d-bf9f940c1d27@oracle.com>
References: <SJ0PR15MB4663DE072EA4731968DC979ECC1EA@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <6943e055-70f1-207a-547a-ba0ff7c784d0@oracle.com>
 <SJ0PR15MB4663715DCC2734DB0A73BA19CC1CA@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <4b90ccda-5660-04f4-544d-bf9f940c1d27@oracle.com>
Message-ID: <SJ0PR15MB4663FA8EBE047F5DC21A4997CCE0A@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan.,

Thanks for the suggestion. We are looking into these test cases and will get back on the results

Thanks
Shruthi
________________________________
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Thursday, August 24, 2023 1:16 PM
To: Shruthi Shruthi1 <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen1 <smoinud1 at in.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11

On 23/08/2023 15:?16, Shruthi Shruthi1 wrote: Hi Alan.?, We are seeing the issue in AIX 7.?2 and Java 11.?0.?11+9. And SO_LINGER is not enabled. There's not much to go on here. A starting point would be to see if the nio/channels tests are passing
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!2c-hSP9fQNPwMAYbeEGFjcU2NHnBhmlfjpkEeeKXyBD9eNKbCrozoi4Ezk1kwBG8z84SFfVoJQF61v-W9dNo82UWwvv7QcOuAEV9AQ$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd
On 23/08/2023 15:16, Shruthi Shruthi1 wrote:
Hi Alan.,

We are seeing the issue in AIX 7.2 and Java 11.0.11+9. And SO_LINGER is not enabled.

There's not much to go on here. A starting point would be to see if the nio/channels tests are passing on this operating system. There are several tests that exercise async close. If there is OS issue then it might happen with the async close of Socket too.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20230828/c3d593f2/attachment.htm>

From dclarke at openjdk.org  Mon Aug 28 10:06:17 2023
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 28 Aug 2023 10:06:17 GMT
Subject: RFR: JDK-8311792: java/net/httpclient/ResponsePublisher.java fails
 intermittently with AssertionError: Found some outstanding operations [v2]
In-Reply-To: <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
 <Lf_jDa2JeGNlL7mU-Rksdbe19yKIJnDEagW_EVVXR54=.5b0dc589-36ff-4104-8295-72d279c33b96@github.com>
Message-ID: <_Pro04UoaCNt8DU4DffyK9NWtUvHnc9p9xQnerPrS4w=.542fe314-e788-4610-8687-0333049dce8b@github.com>

On Thu, 24 Aug 2023 10:25:57 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
>> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
>> 
>> I ran tiers 1-3 and everything is passing
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/net/httpclient/ResponsePublisher.java
>   
>   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

I reran the tests and everything is passing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15307#issuecomment-1695403919

From dclarke at openjdk.org  Mon Aug 28 10:06:19 2023
From: dclarke at openjdk.org (Darragh Clarke)
Date: Mon, 28 Aug 2023 10:06:19 GMT
Subject: Integrated: JDK-8311792: java/net/httpclient/ResponsePublisher.java
 fails intermittently with AssertionError: Found some outstanding operations
In-Reply-To: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
References: <wQOeTbsZtV1mxcxmPTye4hseSfD_lcgaMI14ik83Ebs=.71d0f7c8-bd67-4e95-8b7d-f04aa8e70373@github.com>
Message-ID: <FNKZsMoZ6eETPx_K-bsGPt4Bk15ZLe5vhAQpSz9ByZE=.ba98142b-1ead-47b1-b78a-e44a2d05a2c9@github.com>

On Wed, 16 Aug 2023 12:23:27 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently `ResponsePublisher` occasionally fails due to unreleased resources.
> Updated test based on [AbstractThrowingPushPromises](https://github.com/openjdk/jdk/blob/b80001de0c0aeedeb412430660a4727fc26be98b/test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java#L343) to ensure that non-shared clients get closed before further iterations run, this should limit the max number of clients that remain alive during the test.
> 
> I ran tiers 1-3 and everything is passing

This pull request has now been integrated.

Changeset: 1664e793
Author:    Darragh Clarke <dclarke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1664e793eb725d6328751657d5718df96175da29
Stats:     58 lines in 1 file changed: 58 ins; 0 del; 0 mod

8311792: java/net/httpclient/ResponsePublisher.java fails intermittently with AssertionError: Found some outstanding operations

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15307

From redestad at openjdk.org  Mon Aug 28 13:42:37 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 28 Aug 2023 13:42:37 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark
Message-ID: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>

The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.

This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.

#15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:


Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)


A potential future improvement would be to extend test data with varying amounts of surrogate pairs, e.g. Chinese or emojis

-------------

Commit messages:
 - 8315098: Improve URLEncodeDecode microbenchmark

Changes: https://git.openjdk.org/jdk/pull/15448/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15448&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315098
  Stats: 48 lines in 1 file changed: 23 ins; 2 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/15448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15448/head:pull/15448

PR: https://git.openjdk.org/jdk/pull/15448

From redestad at openjdk.org  Mon Aug 28 13:43:12 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 28 Aug 2023 13:43:12 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v8]
In-Reply-To: <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
Message-ID: <od8SdKDPRlj1Q563wKMPg0J0mnf795Y7tOJv3ovTSnk=.58bfd151-3b22-495f-833f-e00d171a1e39@github.com>

On Thu, 24 Aug 2023 10:38:57 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UTF-8 fast path

I've opened a PR to improve the OpenJDK `URLEncodeDecode` microbenchmark to better capture real-world mixed scenarios. While the microbenchmark can be improved further to include inputs with high code points and surrogate pairs I think this fixes a few glaring issues with the current benchmark (which only tests strings with a lot of `'\u000`` control characters) and should help guide optimization efforts better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1695721273

From vtewari at openjdk.org  Wed Aug 30 09:30:30 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 30 Aug 2023 09:30:30 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream
Message-ID: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>

With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 

After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.

The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 

Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.

-------------

Commit messages:
 - 8314978: Multiple server call from connection failing with expect100 in getOutputStream

Changes: https://git.openjdk.org/jdk/pull/15483/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15483&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314978
  Stats: 257 lines in 2 files changed: 257 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15483.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15483/head:pull/15483

PR: https://git.openjdk.org/jdk/pull/15483

From ecaspole at openjdk.org  Wed Aug 30 13:24:08 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 30 Aug 2023 13:24:08 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark
In-Reply-To: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
Message-ID: <As4jwd47KEMTAdVFmGDaM9dbd9wsGHy0Nd0D-1ebR_Y=.333746f6-0cc9-4705-b7d1-0fd156bc2a11@github.com>

On Mon, 28 Aug 2023 13:33:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
> 
> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
> 
> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
> 
> 
> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
> 
> 
> A potential future improvement would be to extend test data with varying amounts of surrogate pairs, e.g....

Looks good, more clear to read with explicit encodeTokens.

-------------

Marked as reviewed by ecaspole (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15448#pullrequestreview-1602700006

From dfuchs at openjdk.org  Wed Aug 30 13:48:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Aug 2023 13:48:10 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark
In-Reply-To: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
Message-ID: <FpAqaOTFUj_0iB2CAHnxwjfVI0W0ey-MnCCDRNzvXd4=.d3d3062e-3d91-43db-918e-e5de4f232079@github.com>

On Mon, 28 Aug 2023 13:33:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
> 
> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
> 
> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
> 
> 
> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
> 
> 
> A potential future improvement would be to extend test data with varying amounts of surrogate pairs, e.g....

Thanks for improving this microbenchmark Claes. Changes look good to me. Using 1024 strings  should ensure that at least some of them have some characters that need to be encoded/decoded.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15448#pullrequestreview-1602752757

From redestad at openjdk.org  Wed Aug 30 14:08:31 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 30 Aug 2023 14:08:31 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v2]
In-Reply-To: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
Message-ID: <Ai-LfjdqGpcDPvP9T2J7pcVq5l5RgQrSOutkzeIlgcQ=.1cf7cb69-4c6b-4c98-91ee-fc8878feab6c@github.com>

> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
> 
> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
> 
> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
> 
> 
> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
> 
> 
> A potential future improvement would be to extend test data with varying amounts of surrogate pairs, e.g....

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup (unused import, unnecessary casts)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15448/files
  - new: https://git.openjdk.org/jdk/pull/15448/files/0d28ef05..6706826a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15448&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15448&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15448/head:pull/15448

PR: https://git.openjdk.org/jdk/pull/15448

From dfuchs at openjdk.org  Wed Aug 30 14:14:11 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Aug 2023 14:14:11 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v2]
In-Reply-To: <Ai-LfjdqGpcDPvP9T2J7pcVq5l5RgQrSOutkzeIlgcQ=.1cf7cb69-4c6b-4c98-91ee-fc8878feab6c@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <Ai-LfjdqGpcDPvP9T2J7pcVq5l5RgQrSOutkzeIlgcQ=.1cf7cb69-4c6b-4c98-91ee-fc8878feab6c@github.com>
Message-ID: <2TJ_if6pibmFtm0LUC4H1IMq83EZXxV7gLbS9E79Uio=.05b3d4ed-c8b2-4571-ad49-b0e04168c73e@github.com>

On Wed, 30 Aug 2023 14:08:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
>> 
>> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
>> 
>> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
>> 
>> 
>> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
>> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
>> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
>> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
>> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
>> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
>> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
>> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
>> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
>> 
>> 
>> A potential future improvement would be to extend test data...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup (unused import, unnecessary casts)

Marked as reviewed by dfuchs (Reviewer).

Idle musing: I wonder if it would be useful to print on System.out how many strings actually have no encoded chars?
Just to get a rough feeling on whether the percentage values were actually respected.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15448#pullrequestreview-1602811091
PR Comment: https://git.openjdk.org/jdk/pull/15448#issuecomment-1699262691

From redestad at openjdk.org  Wed Aug 30 15:28:39 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 30 Aug 2023 15:28:39 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v2]
In-Reply-To: <2TJ_if6pibmFtm0LUC4H1IMq83EZXxV7gLbS9E79Uio=.05b3d4ed-c8b2-4571-ad49-b0e04168c73e@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <Ai-LfjdqGpcDPvP9T2J7pcVq5l5RgQrSOutkzeIlgcQ=.1cf7cb69-4c6b-4c98-91ee-fc8878feab6c@github.com>
 <2TJ_if6pibmFtm0LUC4H1IMq83EZXxV7gLbS9E79Uio=.05b3d4ed-c8b2-4571-ad49-b0e04168c73e@github.com>
Message-ID: <YEdrIK-rDceGyCW7VglOKWyq1PeAgwAz9SRktl9IezY=.d546ac61-f6c0-4520-bca3-46539fb00dbc@github.com>

On Wed, 30 Aug 2023 14:09:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Idle musing: I wonder if it would be useful to print on System.out how many strings actually have no encoded chars? Just to get a rough feeling on whether the percentage values were actually respected.

Good call, since I had gotten the distribution wrong for decode with `unchanged` set to a value like 75 by recalculating `needDecoding` for every char. Also improved the precision for `unchanged == 0`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15448#issuecomment-1699391212

From redestad at openjdk.org  Wed Aug 30 15:28:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 30 Aug 2023 15:28:22 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
Message-ID: <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>

> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
> 
> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
> 
> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
> 
> 
> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
> 
> 
> A potential future improvement would be to extend test data with varying amounts of surrogate pairs, e.g....

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15448/files
  - new: https://git.openjdk.org/jdk/pull/15448/files/6706826a..665666a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15448&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15448&range=01-02

  Stats: 64 lines in 1 file changed: 49 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15448/head:pull/15448

PR: https://git.openjdk.org/jdk/pull/15448

From dfuchs at openjdk.org  Wed Aug 30 15:36:12 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Aug 2023 15:36:12 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
Message-ID: <H_5FmJua6JNttQADI_rS4vZ63C0558v8eWP1AMDRrg0=.b4d663a3-5132-4f28-97a3-191a126fe354@github.com>

On Wed, 30 Aug 2023 15:28:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
>> 
>> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
>> 
>> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
>> 
>> 
>> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
>> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
>> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
>> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
>> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
>> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
>> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
>> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
>> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
>> 
>> 
>> A potential future improvement would be to extend test data...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15448#pullrequestreview-1602982600

From duke at openjdk.org  Wed Aug 30 15:36:13 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 30 Aug 2023 15:36:13 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
Message-ID: <PpV01ReTbidrxBAYkMFYJbHMLASrFXe-0rGrGmbVTWc=.96a305b0-ae7e-4893-a1a4-da30898d359e@github.com>

On Wed, 30 Aug 2023 15:28:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
>> 
>> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
>> 
>> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
>> 
>> 
>> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
>> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
>> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
>> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
>> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
>> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
>> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
>> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
>> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
>> 
>> 
>> A potential future improvement would be to extend test data...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution

test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java line 86:

> 84:         tokens[n++] = '*';
> 85: 
> 86:         Random r = new Random(mySeed);

SplittableRandom allow to have perfectly reproducible sequences

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1310465025

From duke at openjdk.org  Wed Aug 30 15:40:14 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 30 Aug 2023 15:40:14 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
Message-ID: <YnPRffIb0NC_SterwOTSax7VyytBlcZ7DZ-WCBSn8Cs=.2232d4aa-6b7a-4be9-a995-f89c134ec533@github.com>

On Wed, 30 Aug 2023 15:28:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The `URLEncodeDecode` microbenchmark accidentally generates strings with a lot of `'\u0000'` chars, heavily skewing towards strings that need to be encoded in a rather unrealistic what. To be more realistic the benchmark should test a mix of inputs.
>> 
>> This patch fixes these inadvertent cases, and sets up the benchmark for a healthier mix by default - adding controls to allow testing some mixed scenarios.
>> 
>> #15354 explore a few optimizations to `URLEncoder`, but due the nature of this microbenchmark a trivial fast-path scan for chars that need no encoding shows underwhelming results. With the modifications to this benchmark then a simple fast-path to `URLEncode.encode` shows a decent win when some or all the inputs remain unchanged:
>> 
>> 
>> Name                           (encodeChars) (maxLength) (unchanged) Cnt  Base   Error   Test   Error  Unit  Diff%
>> URLEncodeDecode.testDecodeUTF8             6        1024           0  15 3,307 ? 0,507  3,010 ? 0,048 ms/op   9,0% (p = 0,030 )
>> URLEncodeDecode.testDecodeUTF8             6        1024          75  15 2,296 ? 0,003  2,313 ? 0,017 ms/op  -0,7% (p = 0,001*)
>> URLEncodeDecode.testDecodeUTF8             6        1024         100  15 0,812 ? 0,010  0,819 ? 0,017 ms/op  -0,8% (p = 0,201 )
>> URLEncodeDecode.testDecodeUTF8            35        1024           0  15 6,909 ? 0,065  7,192 ? 0,415 ms/op  -4,1% (p = 0,014 )
>> URLEncodeDecode.testDecodeUTF8            35        1024          75  15 3,346 ? 0,206  3,320 ? 0,270 ms/op   0,8% (p = 0,753 )
>> URLEncodeDecode.testDecodeUTF8            35        1024         100  15 0,794 ? 0,034  0,818 ? 0,015 ms/op  -3,0% (p = 0,016 )
>> URLEncodeDecode.testEncodeUTF8             6        1024           0  15 2,434 ? 0,019  2,579 ? 0,120 ms/op  -6,0% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024          75  15 1,764 ? 0,014  0,937 ? 0,012 ms/op  46,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8             6        1024         100  15 1,227 ? 0,008  0,401 ? 0,001 ms/op  67,4% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024           0  15 6,177 ? 0,062  6,057 ? 0,199 ms/op   1,9% (p = 0,029 )
>> URLEncodeDecode.testEncodeUTF8            35        1024          75  15 2,716 ? 0,023  1,876 ? 0,012 ms/op  30,9% (p = 0,000*)
>> URLEncodeDecode.testEncodeUTF8            35        1024         100  15 1,220 ? 0,003  0,401 ? 0,001 ms/op  67,2% (p = 0,000*)
>> 
>> 
>> A potential future improvement would be to extend test data...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution

test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java line 180:

> 178:     @Benchmark
> 179:     public void testEncodeUTF8(Blackhole bh) throws UnsupportedEncodingException {
> 180:         for (String s : testStringsEncode) {

The consume is pretty cheap with compiler assisted blackholes, but can still overall be too noisy with small 's'

Worth running perfasm and see what it says and/or reading put of the encoded value and extract some property to accumulate in the for loop. And see if is less costy.

Another point instead is related loop unrolling/strip mining; safepoint polls can create additional random noise depending how much loop unrolling is excercized (Vs the cost of encoding): it worth to enforce a specific unrolling level or disabling it as a whole, too, to get more stable results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1310470873

From redestad at openjdk.org  Wed Aug 30 15:46:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 30 Aug 2023 15:46:13 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <PpV01ReTbidrxBAYkMFYJbHMLASrFXe-0rGrGmbVTWc=.96a305b0-ae7e-4893-a1a4-da30898d359e@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
 <PpV01ReTbidrxBAYkMFYJbHMLASrFXe-0rGrGmbVTWc=.96a305b0-ae7e-4893-a1a4-da30898d359e@github.com>
Message-ID: <WtSbViH_mGpzuqCfHKxNhiri7uYj8DbobB7EVg-mdQc=.fe16a8bb-4fc7-441b-b872-d7dc1e940116@github.com>

On Wed, 30 Aug 2023 15:33:01 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution
>
> test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java line 86:
> 
>> 84:         tokens[n++] = '*';
>> 85: 
>> 86:         Random r = new Random(mySeed);
> 
> SplittableRandom allow to have perfectly reproducible sequences

Care to elaborate? `Random` with an explicit seed should be more than enough to have perfectly reproducible sequences for our case (`SplittableRandom` uses a different algorithm by default with a longer period, but I can't see how this'd be relevant to this case.)


 * If two instances of {@code Random} are created with the same
 * seed, and the same sequence of method calls is made for each, they
 * will generate and return identical sequences of numbers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1310479054

From duke at openjdk.org  Wed Aug 30 15:55:14 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 30 Aug 2023 15:55:14 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <H4gYQkOWQfNi2R6PbS3ocVPD3tBOLb9WJSPudFFPJQU=.544bc804-f47c-4505-9247-2c0af1d6d4e9@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
 <PpV01ReTbidrxBAYkMFYJbHMLASrFXe-0rGrGmbVTWc=.96a305b0-ae7e-4893-a1a4-da30898d359e@github.com>
 <WtSbViH_mGpzuqCfHKxNhiri7uYj8DbobB7EVg-mdQc=.fe16a8bb-4fc7-441b-b872-d7dc1e940116@github.com>
 <H4gYQkOWQfNi2R6PbS3ocVPD3tBOLb9WJSPudFFPJQU=.544bc804-f47c-4505-9247-2c0af1d6d4e9@github.com>
Message-ID: <IRg5riBRy_bubwpbDiFardqisJADUxQA4uEUBLS4WhQ=.9ce4cbd5-026b-407e-be0c-c300d531ac15@github.com>

On Wed, 30 Aug 2023 15:51:06 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Care to elaborate? `Random` with an explicit seed should be more than enough to have perfectly reproducible sequences for our case (`SplittableRandom` uses a different algorithm by default with a longer period, but I can't see how this'd be relevant to this case.)
>> 
>> 
>>  * If two instances of {@code Random} are created with the same
>>  * seed, and the same sequence of method calls is made for each, they
>>  * will generate and return identical sequences of numbers.
>
> Even with the same seed only with large numbers you get statistically a similar distribution,m (not the same values, but the javadoc said differently which is quite surprising to me!), but splittable random is actually producing the same exact sequences. You care about confusing branch predictors here I suppose (or the JIT, maybe too) but not to add noise or variance with fewer samples nor you are interested to the security part of it (cause random use the chaos generated securely by the OS/HW iirc).

I have to check in my notes why I used splittable rmd and will update this thread :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1310491098

From duke at openjdk.org  Wed Aug 30 15:55:13 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 30 Aug 2023 15:55:13 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <WtSbViH_mGpzuqCfHKxNhiri7uYj8DbobB7EVg-mdQc=.fe16a8bb-4fc7-441b-b872-d7dc1e940116@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
 <PpV01ReTbidrxBAYkMFYJbHMLASrFXe-0rGrGmbVTWc=.96a305b0-ae7e-4893-a1a4-da30898d359e@github.com>
 <WtSbViH_mGpzuqCfHKxNhiri7uYj8DbobB7EVg-mdQc=.fe16a8bb-4fc7-441b-b872-d7dc1e940116@github.com>
Message-ID: <H4gYQkOWQfNi2R6PbS3ocVPD3tBOLb9WJSPudFFPJQU=.544bc804-f47c-4505-9247-2c0af1d6d4e9@github.com>

On Wed, 30 Aug 2023 15:43:13 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java line 86:
>> 
>>> 84:         tokens[n++] = '*';
>>> 85: 
>>> 86:         Random r = new Random(mySeed);
>> 
>> SplittableRandom allow to have perfectly reproducible sequences
>
> Care to elaborate? `Random` with an explicit seed should be more than enough to have perfectly reproducible sequences for our case (`SplittableRandom` uses a different algorithm by default with a longer period, but I can't see how this'd be relevant to this case.)
> 
> 
>  * If two instances of {@code Random} are created with the same
>  * seed, and the same sequence of method calls is made for each, they
>  * will generate and return identical sequences of numbers.

Even with the same seed only with large numbers you get statistically a similar distribution,m (not the same values, but the javadoc said differently which is quite surprising to me!), but splittable random is actually producing the same exact sequences. You care about confusing branch predictors here I suppose (or the JIT, maybe too) but not to add noise or variance with fewer samples nor you are interested to the security part of it (cause random use the chaos generated securely by the OS/HW iirc).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1310489744

From duke at openjdk.org  Wed Aug 30 16:00:13 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 30 Aug 2023 16:00:13 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <IRg5riBRy_bubwpbDiFardqisJADUxQA4uEUBLS4WhQ=.9ce4cbd5-026b-407e-be0c-c300d531ac15@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
 <PpV01ReTbidrxBAYkMFYJbHMLASrFXe-0rGrGmbVTWc=.96a305b0-ae7e-4893-a1a4-da30898d359e@github.com>
 <WtSbViH_mGpzuqCfHKxNhiri7uYj8DbobB7EVg-mdQc=.fe16a8bb-4fc7-441b-b872-d7dc1e940116@github.com>
 <H4gYQkOWQfNi2R6PbS3ocVPD3tBOLb9WJSPudFFPJQU=.544bc804-f47c-4505-9247-2c0af1d6d4e9@github.com>
 <IRg5riBRy_bubwpbDiFardqisJADUxQA4uEUBLS4WhQ=.9ce4cbd5-026b-407e-be0c-c300d531ac15@github.com>
Message-ID: <s73PV9Z15JS1pdpCN8XX5Z5JFNBpFsmdg1b47Vq1XHM=.ae2b352f-d43b-46b5-a982-38e2abe58c9d@github.com>

On Wed, 30 Aug 2023 15:52:06 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Even with the same seed only with large numbers you get statistically a similar distribution,m (not the same values, but the javadoc said differently which is quite surprising to me!), but splittable random is actually producing the same exact sequences. You care about confusing branch predictors here I suppose (or the JIT, maybe too) but not to add noise or variance with fewer samples nor you are interested to the security part of it (cause random use the chaos generated securely by the OS/HW iirc).
>
> I have to check in my notes why I used splittable rmd and will update this thread :)

Ok it seems I am using it by habits (so weird). So I can retire this comment unless I got something better to add on this :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1310498068

From djelinski at openjdk.org  Thu Aug 31 08:30:22 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 31 Aug 2023 08:30:22 GMT
Subject: RFR: 8315436: HttpsServer does not send TLS alerts
Message-ID: <0BfMUtD1a7WtP3lx7_FAHo7vL5tcxtBqynIZka81M3A=.13d5bcfd-e5d3-4176-8bc3-e5db5b5cfea3@github.com>

Please review this patch that ensures that alerts produced by `wrap` are sent to the peer.

When a fatal alert is produced by a `wrap` call, the returned status is `CLOSED`, but some bytes are produced in the destination buffer. These bytes need to be sent to the client.

The new test verifies this fix; without the fix the test fails with:

javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake

With the fix the test passes; the exception thrown is :

javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version

Existing tier1-3 tests continue to pass.

-------------

Commit messages:
 - Update copyright
 - Send TLS alerts

Changes: https://git.openjdk.org/jdk/pull/15505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15505&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315436
  Stats: 112 lines in 2 files changed: 110 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15505/head:pull/15505

PR: https://git.openjdk.org/jdk/pull/15505

From redestad at openjdk.org  Thu Aug 31 09:15:06 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 31 Aug 2023 09:15:06 GMT
Subject: RFR: 8315098: Improve URLEncodeDecode microbenchmark [v3]
In-Reply-To: <YnPRffIb0NC_SterwOTSax7VyytBlcZ7DZ-WCBSn8Cs=.2232d4aa-6b7a-4be9-a995-f89c134ec533@github.com>
References: <_vaBnfezAdadYiPS0sJFDtkZ7f7A8DXBAh5Vep-JN4U=.75c24f2b-7abb-49ef-a455-36f594bc8b18@github.com>
 <AJFCla0byCW3JyVMZ-Arm-Ial7sme710ekWUmiwUybA=.28b43242-b40a-4e41-9b0c-83dad11e395e@github.com>
 <YnPRffIb0NC_SterwOTSax7VyytBlcZ7DZ-WCBSn8Cs=.2232d4aa-6b7a-4be9-a995-f89c134ec533@github.com>
Message-ID: <B8z5tZ-ih7IvOGX1OVrsYI8aV_VqqCZGL503PoATuCo=.b706ad4e-d21d-4002-bd0e-e8ee08f7081b@github.com>

On Wed, 30 Aug 2023 15:37:18 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print out distribution of generated strings, improve precision at extremes (short strings, very low percentages), fix issue with decodable not getting the expected distribution
>
> test/micro/org/openjdk/bench/java/net/URLEncodeDecode.java line 180:
> 
>> 178:     @Benchmark
>> 179:     public void testEncodeUTF8(Blackhole bh) throws UnsupportedEncodingException {
>> 180:         for (String s : testStringsEncode) {
> 
> The consume is pretty cheap with compiler assisted blackholes, but can still overall be too noisy with small 's'
> 
> Worth running perfasm and see what it says and/or reading out of the encoded value and extract some property to accumulate in the for loop (sum.od length?) and see if is less costy/noisy.
> 
> Another point instead is related loop unrolling/strip mining; safepoint polls can create additional random noise depending how much loop unrolling is excercized (Vs the cost of encoding): it worth to enforce a specific unrolling level or disabling it as a whole, too, to get more stable results.

I think these are all valid concerns and it's a worthwhile endeavor to discuss and try and improve how we benchmark loops (or more specifically variable inputs). However I think this is out of scope for this improvement - which is mainly about correctness of data and making sure we're testing the right thing - and ought to be discussed and experimented with separately. If you don't strongly disagree I will integrate this so we can move ahead with other work in this area (#15354 for starters)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15448#discussion_r1311337979

From redestad at openjdk.org  Thu Aug 31 10:31:02 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 31 Aug 2023 10:31:02 GMT
Subject: RFR: 8314774: Optimize URLEncoder [v8]
In-Reply-To: <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
References: <JYOiDwxlvsI9XYGPW3Y5LEs-9r6jH7og2Z1Qh7imWlk=.03e017f4-8e6b-4264-a4db-43452ec87459@github.com>
 <9MDKUqWiUcXdnSXhTPwuE7WdMfPakY9jSC-zZY3xNeA=.b01178e5-8543-4a83-aaf0-f91a7b9b9675@github.com>
Message-ID: <b-cj90br1TXbT_f7T5TZQKeVQHu45Vn90XZxS1WUbCM=.de8139e1-7870-4bda-8b5b-8179093dee2d@github.com>

On Thu, 24 Aug 2023 10:38:57 GMT, Glavo <duke at openjdk.org> wrote:

>> I mainly made these optimizations:
>> 
>> * Avoid allocating `StringBuilder` when there are no characters in the URL that need to be encoded;
>> * Implement a fast path for UTF-8.
>> 
>> In addition to improving performance, these optimizations also reduce temporary objects:
>> 
>> * It no longer allocates any object when there are no characters in the URL that need to be encoded;
>> * The initial size of StringBuilder is larger to avoid expansion as much as possible;
>> * For UTF-8, the temporary `CharArrayWriter`, strings and byte arrays are no longer needed.
>> 
>> The results of the `URLEncodeDecode` benchmark:
>> 
>> 
>> Before:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  5.587 ? 0.010  ms/op
>> 
>> After:
>> Benchmark                       (count)  (maxLength)  (mySeed)  Mode  Cnt  Score   Error  Units
>> URLEncodeDecode.testEncodeUTF8     1024         1024         3  avgt   15  3.582 ? 0.054  ms/op
>> 
>> 
>> I also updated the tests to add more test cases.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove UTF-8 fast path

@minborg has a prototype for a immutable `BitSet` here: #15493. Early evaluation shows we can get a better speed-up using that than from replacing the `BitSet` with a `@Stable boolean[128]` that you're doing in this PR. 

So while it was a very helpful experiment -- which showed a performance issue with mutable `BitSet`s --  I think we want to roll back the various changes to `DONT_NEED_ENCODING` in this PR. Or wait until #15493 is done and use the ability to make a `BitSet` immutable (and easily constant-foldable).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15354#issuecomment-1700780003

From dfuchs at openjdk.org  Thu Aug 31 11:27:02 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 31 Aug 2023 11:27:02 GMT
Subject: RFR: 8315436: HttpsServer does not send TLS alerts
In-Reply-To: <0BfMUtD1a7WtP3lx7_FAHo7vL5tcxtBqynIZka81M3A=.13d5bcfd-e5d3-4176-8bc3-e5db5b5cfea3@github.com>
References: <0BfMUtD1a7WtP3lx7_FAHo7vL5tcxtBqynIZka81M3A=.13d5bcfd-e5d3-4176-8bc3-e5db5b5cfea3@github.com>
Message-ID: <0NETOW_kFCyYgxfi8olEUS36idBunTi9tXqC2yCuqb0=.818f313b-d26f-453d-8c25-fd8f4303e3de@github.com>

On Thu, 31 Aug 2023 06:57:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that ensures that alerts produced by `wrap` are sent to the peer.
> 
> When a fatal alert is produced by a `wrap` call, the returned status is `CLOSED`, but some bytes are produced in the destination buffer. These bytes need to be sent to the client.
> 
> The new test verifies this fix; without the fix the test fails with:
> 
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> 
> With the fix the test passes; the exception thrown is :
> 
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 
> Existing tier1-3 tests continue to pass.

Looks good.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15505#pullrequestreview-1604538949

From michaelm at openjdk.org  Thu Aug 31 11:30:59 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 31 Aug 2023 11:30:59 GMT
Subject: RFR: 8315436: HttpsServer does not send TLS alerts
In-Reply-To: <0BfMUtD1a7WtP3lx7_FAHo7vL5tcxtBqynIZka81M3A=.13d5bcfd-e5d3-4176-8bc3-e5db5b5cfea3@github.com>
References: <0BfMUtD1a7WtP3lx7_FAHo7vL5tcxtBqynIZka81M3A=.13d5bcfd-e5d3-4176-8bc3-e5db5b5cfea3@github.com>
Message-ID: <DYExRHRjuMONp1nwuVZox3ZsHyPQDYSpBi8SDnmNmEc=.059fc782-2930-4c94-bd92-e5d932459e21@github.com>

On Thu, 31 Aug 2023 06:57:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this patch that ensures that alerts produced by `wrap` are sent to the peer.
> 
> When a fatal alert is produced by a `wrap` call, the returned status is `CLOSED`, but some bytes are produced in the destination buffer. These bytes need to be sent to the client.
> 
> The new test verifies this fix; without the fix the test fails with:
> 
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> 
> With the fix the test passes; the exception thrown is :
> 
> javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
> 
> Existing tier1-3 tests continue to pass.

Good catch

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15505#pullrequestreview-1604544042

From djelinski at openjdk.org  Thu Aug 31 19:12:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 31 Aug 2023 19:12:08 GMT
Subject: RFR: 8314978: Multiple server call from connection failing with
 expect100 in getOutputStream
In-Reply-To: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
References: <f0kF49PDsz43Mo_IoQH3nI3u5m7hP30LmwklWjx9RX4=.2fb4cee7-63d2-40e0-8ed3-c6306f9e95ed@github.com>
Message-ID: <QIk0C89w6mzptOSZ-PWpUEP5AkCRPZQGhuJMIs5sV_Q=.fbebc2d4-ad0f-4851-8a47-cf851066dad2@github.com>

On Wed, 30 Aug 2023 09:23:34 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> With the current implementation of HttpURLConnection  if server rejects the  ?Expect 100-continue? then there will be ?java.net.ProtocolException? will be thrown from 'expect100Continue()' method. 
> 
> After the exception thrown, If we call any other method on the same instance (ex getHeaderField(), or getHeaderFields()). They will internally call getOuputStream() which invokes writeRequests(), which make the actual server call.
> 
> The code change will sets the existing variable ?rememberedException? when there is exception and getOutputStream0() will re-throw ?rememberedException?  if the ?rememberedException? is not null. 
> 
> Note: getOutputStream0() also call?s  ?expect100Continue()?  if ?expectContinue? is true.

Looks reasonable.

test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpect100Test.java line 70:

> 68: 
> 69:     @Test
> 70:     public void test() throws Exception {

Looks like it could be a parameterized test: with/without `Expect: 100-continue`, with `200` / `417` response. Either that, or add more descriptive names for the test methods.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15483#pullrequestreview-1605500559
PR Review Comment: https://git.openjdk.org/jdk/pull/15483#discussion_r1312082426