On Mon, 15 Feb 2021 18:30:58 GMT, Julia Boes wrote:
> This change removes sun.net.www.MimeLauncher, a package-private class that is
> no longer used.
>
> The sun.net.www package is exported to java.net.http and jdk.jartool. The
> only public access point to a MimeLauncher instance is
> sun.ne
On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote:
> In another bug this question from me was answered by Alan Bateman :
>
> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I
> started to wonder what happens to the allocated memory in the same file in
> handleSen
On Wed, 17 Feb 2021 10:30:45 GMT, Chris Hegarty wrote:
>> In another bug this question from me was answered by Alan Bateman :
>>
>> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I
>> started to wonder what happens to the allocated memory in the same file in
>> handleS
On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote:
> In another bug this question from me was answered by Alan Bateman :
>
> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I
> started to wonder what happens to the allocated memory in the same file in
> handleSen
On Wed, 17 Feb 2021 07:20:27 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8260366?
>
> The issue relates to the concurrent classloading of
> `sun.net.ext.ExtendedSocketOptions` and `j
On Wed, 17 Feb 2021 13:05:03 GMT, Daniel Fuchs wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8260366?
>>
>> The issue relates to the concurrent classloading of
>> `sun.net.ext.ExtendedSocketOptions` a
On Wed, 17 Feb 2021 12:51:06 GMT, Alan Bateman wrote:
>> In another bug this question from me was answered by Alan Bateman :
>>
>> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I
>> started to wonder what happens to the allocated memory in the same file in
>> handleSe
On Wed, 17 Feb 2021 13:19:13 GMT, Matthias Baesken wrote:
>> The changes looks okay to me. I see Chris has created JDK-8261881 to setup
>> the cleanup.
>
> Hi Alan and Chris, thanks for the reviews.
Looks like I cannot integrate it, even after changing the title!?
Is this a bug?
-
On Wed, 17 Feb 2021 13:27:13 GMT, Matthias Baesken wrote:
>> Hi Alan and Chris, thanks for the reviews.
>
> Looks like I cannot integrate it, even after changing the title!?
> Is this a bug?
Here's the jcheck failure:
https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270
-
On Wed, 17 Feb 2021 13:09:27 GMT, Daniel Fuchs wrote:
> Since the test should be fast, I'd also advise to stick several identical
> @run lines (maybe e.g. 5 of them) to increase the probability of the deadlock
> to happen...
Done. The PR has been updated to run this test multiple times now.
-
On Wed, 17 Feb 2021 13:11:23 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Incorporate the review suggestion to run the test multiple times to
>> improve the chances of reproducing any pote
On Wed, 17 Feb 2021 13:37:19 GMT, Jaikiran Pai wrote:
>> Since the test should be fast, I'd also advise to stick several identical
>> @run lines (maybe e.g. 5 of them) to increase the probability of the
>> deadlock to happen...
>
>> Since the test should be fast, I'd also advise to stick severa
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8260366?
>
> The issue relates to the concurrent classloading of
> `sun.net.ext.ExtendedSocketOptions` and `jdk.net.ExtendedSocketOptions`
> leading to a deadlock.
On Wed, 17 Feb 2021 13:36:17 GMT, Alan Bateman wrote:
>> Looks like I cannot integrate it, even after changing the title!?
>> Is this a bug?
>
> Here's the jcheck failure:
> https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270
As pointed out by Alan: It seems like a space is m
On Wed, 17 Feb 2021 13:36:17 GMT, Alan Bateman wrote:
> Here's the jcheck failure:
> https://github.com/openjdk/jdk/pull/2586/checks?check_run_id=1918880270
Hi Alan , I am aware of the jcheck message.
It claims : "The commit message does not reference any issue. "
I adjusted now the for the 3 or
On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote:
> In another bug this question from me was answered by Alan Bateman :
>
> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I
> started to wonder what happens to the allocated memory in the same file in
> handleSen
On Wed, 17 Feb 2021 13:43:14 GMT, Daniel Fuchs wrote:
> As pointed out by Alan: It seems like a space is missing after the colon in
> the PR title
lets give it a try. Thanks !
-
PR: https://git.openjdk.java.net/jdk/pull/2586
Non-static classes hold a link to their parent classes, which in many cases can
be avoided.
-
Commit messages:
- 8261880: Change nested classes in java.base to static nested classes where
possible
Changes: https://git.openjdk.java.net/jdk/pull/2589/files
Webrev: https://webrevs.o
On Tue, 16 Feb 2021 14:30:58 GMT, Сергей Цыпанов
wrote:
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line
192:
> 190:
> 191: /* Placeholder class for DelegatingMet
On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/share/classes/java/lang/invoke/
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
Сергей Цыпанов has updated the pull request incrementally with one additional
commit since the last revision:
8261880: Remove static from declarations of Holder nested classes
-
Chang
On Wed, 17 Feb 2021 16:32:39 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java
>> line 192:
>>
>>> 190:
>>> 191: /* Placeholder class for DelegatingMethodHandles generated ahead
>>> of time */
>>> 192: static final class Holder {}
On Wed, 17 Feb 2021 13:36:18 GMT, Jaikiran Pai wrote:
>> Hi Jaikiran,
>>
>> Thanks for taking a go at this one.
>>
>> At a glance - the proposed fix seems reasonable to me. It would be good to
>> have another pair of eyes (and analysis) on this though. Some issues with
>> the test.
>
> Hello
On Wed, 17 Feb 2021 16:35:02 GMT, liach
wrote:
>> I'll just revert them
>
> For static methods, since in java language you cannot declare static method
> in instance inner classes, I'd say making them static makes more sense
> language-wise. Also making them static reduces compiler synthetic i
On Wed, 17 Feb 2021 17:24:50 GMT, Claes Redestad wrote:
>> For static methods, since in java language you cannot declare static method
>> in instance inner classes, I'd say making them static makes more sense
>> language-wise. Also making them static reduces compiler synthetic instance
>> fiel
On Wed, 17 Feb 2021 13:42:57 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8260366?
>>
>> The issue relates to the concurrent classloading of
>> `sun.net.ext.ExtendedSocketOptions` a
On Wed, 17 Feb 2021 16:47:51 GMT, Vyom Mani Tewari
wrote:
> Changes looks OK to me, any specific reason for removing "final" specifier
> from "getInstance" & "register" methods ?.
Hello Vyom, thank you for the review. Since those two methods are `static`, the
`final` was redundant on them and
On Wed, 17 Feb 2021 20:01:17 GMT, Andrey Turbanov
wrote:
>> Jaikiran Pai has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Incorporate the review suggestion to run the test multiple times to
>> improve the chances of reproducing any
On Thu, 18 Feb 2021 01:06:50 GMT, Jaikiran Pai wrote:
> > Changes looks OK to me, any specific reason for removing "final" specifier
> > from "getInstance" & "register" methods ?.
>
> Hello Vyom, thank you for the review. Since those two methods are `static`,
> the `final` was redundant on the
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8260366?
>
> The issue relates to the concurrent classloading of
> `sun.net.ext.ExtendedSocketOptions` and `jdk.net.ExtendedSocketOptions`
> leading to a deadlock.
On Thu, 18 Feb 2021 04:31:56 GMT, Vyom Mani Tewari
wrote:
> What about improving the test little bit, your test wants to load both
> classes at the same time. Please have a look on modified test.
Hello Vyom, I think that's a good suggestion to use a latch for deciding when
to trigger the clas
On Thu, 18 Feb 2021 01:08:30 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java line 171:
>>
>>> 169:
>>> 170: public static ExtendedSocketOptions getInstance() {
>>> 171: if (instance != null) {
>>
>> May be it's worth to avoid reading `
On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes wrote:
>> 8080272 Refactor I/O stream copying to use
>> InputStream.transferTo/readAllBytes and Files.copy
>
> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall -
> have they been addressed?
> https://github.com/openjdk/jdk/pu
On Thu, 18 Feb 2021 07:03:07 GMT, Andrey Turbanov
wrote:
>> Hello @turbanoff, do you mean why read it twice - once here and once inside
>> the `synchronized` block?
>
> Yes. Once here and once inside `synchronized` block.
> Reading `volatile` fields cost _something_ on some architectures, so I
34 matches
Mail list logo
