From mark.reinhold at oracle.com  Thu Oct  1 16:32:15 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 01 Oct 2020 09:32:15 -0700
Subject: JEP proposed to target JDK 16: 386: Alpine Linux Port
In-Reply-To: <20200918195829.D02EA3C2260@eggemoggin.niobe.net>
References: <20200918195829.D02EA3C2260@eggemoggin.niobe.net>
Message-ID: <20201001093215.31131604@eggemoggin.niobe.net>

2020/9/18 12:58:29 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   386: Alpine Linux Port
>        https://openjdk.java.net/jeps/386
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:00 UTC on Friday, 25 September, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From goetz.lindenmaier at sap.com  Thu Oct  1 21:06:35 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 1 Oct 2020 21:06:35 +0000
Subject: RFR: 8180514: TestPrintMdo.java test fails with
 -XX:-TieredCompilation
In-Reply-To: <qQxhDqrSmBwlXTDydenPTUVZqLpMX-ZINZxiruUCSFY=.2d3595dc-ff01-4b5d-816e-6dae355d03f3@github.com>
References: <Y5JJlsM4bpzmiGRjV9pYQFb3xkGWJ1c-lgHIq98Rb84=.c7896982-6e52-4733-b899-e2370f190764@github.com>
 <qQxhDqrSmBwlXTDydenPTUVZqLpMX-ZINZxiruUCSFY=.2d3595dc-ff01-4b5d-816e-6dae355d03f3@github.com>
Message-ID: <AM4PR0202MB296465C75C1B06A1E809E45AEC300@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

Please open up a dummy copy JBS issue without confidential 
information if you fix a closed, internal Oracle bug.
I missed this before, I only saw it is closed when 
this was pushed today.

It is really annoying to still see closed bugs.
I had hoped skara would help to avoid this.

Please find a way to fix this, so it does not happen 
all the time!

Best regards,
  Goetz

> -----Original Message-----
> From: serviceability-dev <serviceability-dev-retn at openjdk.java.net> On
> Behalf Of Leonid Mesnik
> Sent: Thursday, October 1, 2020 12:58 AM
> To: serviceability-dev at openjdk.java.net
> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
> TieredCompilation
> 
> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik <lmesnik at openjdk.org>
> wrote:
> 
> > Test fails with -XX:+TieredCompilation because j.l.Object hasn't been used
> enough time to trigger compilation. So it
> 
> The bug is closed because contain some confidential info. So I explained
> issue and fix in this PR description.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/447

From jesper.wilhelmsson at oracle.com  Thu Oct  1 21:35:28 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 1 Oct 2020 23:35:28 +0200
Subject: RFR: 8180514: TestPrintMdo.java test fails with
 -XX:-TieredCompilation
In-Reply-To: <AM4PR0202MB296465C75C1B06A1E809E45AEC300@AM4PR0202MB2964.eurprd02.prod.outlook.com>
References: <Y5JJlsM4bpzmiGRjV9pYQFb3xkGWJ1c-lgHIq98Rb84=.c7896982-6e52-4733-b899-e2370f190764@github.com>
 <qQxhDqrSmBwlXTDydenPTUVZqLpMX-ZINZxiruUCSFY=.2d3595dc-ff01-4b5d-816e-6dae355d03f3@github.com>
 <AM4PR0202MB296465C75C1B06A1E809E45AEC300@AM4PR0202MB2964.eurprd02.prod.outlook.com>
Message-ID: <9F94AE3A-9E54-49D9-BEB0-CC9AA3FF8491@oracle.com>

I filed https://bugs.openjdk.java.net/browse/SKARA-752 to encourage the Skara team to have the bots check this before allowing integration.
/Jesper

> On 1 Oct 2020, at 23:06, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> Please open up a dummy copy JBS issue without confidential
> information if you fix a closed, internal Oracle bug.
> I missed this before, I only saw it is closed when
> this was pushed today.
> 
> It is really annoying to still see closed bugs.
> I had hoped skara would help to avoid this.
> 
> Please find a way to fix this, so it does not happen
> all the time!
> 
> Best regards,
>  Goetz
> 
>> -----Original Message-----
>> From: serviceability-dev <serviceability-dev-retn at openjdk.java.net> On
>> Behalf Of Leonid Mesnik
>> Sent: Thursday, October 1, 2020 12:58 AM
>> To: serviceability-dev at openjdk.java.net
>> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
>> TieredCompilation
>> 
>> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik <lmesnik at openjdk.org>
>> wrote:
>> 
>>> Test fails with -XX:+TieredCompilation because j.l.Object hasn't been used
>> enough time to trigger compilation. So it
>> 
>> The bug is closed because contain some confidential info. So I explained
>> issue and fix in this PR description.
>> 
>> -------------
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/447


From goetz.lindenmaier at sap.com  Fri Oct  2 05:41:46 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 2 Oct 2020 05:41:46 +0000
Subject: RFR: 8180514: TestPrintMdo.java test fails with
 -XX:-TieredCompilation
In-Reply-To: <9F94AE3A-9E54-49D9-BEB0-CC9AA3FF8491@oracle.com>
References: <Y5JJlsM4bpzmiGRjV9pYQFb3xkGWJ1c-lgHIq98Rb84=.c7896982-6e52-4733-b899-e2370f190764@github.com>
 <qQxhDqrSmBwlXTDydenPTUVZqLpMX-ZINZxiruUCSFY=.2d3595dc-ff01-4b5d-816e-6dae355d03f3@github.com>
 <AM4PR0202MB296465C75C1B06A1E809E45AEC300@AM4PR0202MB2964.eurprd02.prod.outlook.com>
 <9F94AE3A-9E54-49D9-BEB0-CC9AA3FF8491@oracle.com>
Message-ID: <AM4PR0202MB2964070FA6F5B25A334043C8EC310@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi Jesper, 

Thanks for opening that issue, if this is implemented
it will help a lot!

Best regards,
  Goetz.

> -----Original Message-----
> From: Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>
> Sent: Thursday, October 1, 2020 11:35 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Leonid Mesnik <lmesnik at openjdk.java.net>; serviceability-
> dev at openjdk.java.net; jdk-dev at openjdk.java.net
> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
> TieredCompilation
> 
> I filed https://bugs.openjdk.java.net/browse/SKARA-752 to encourage the
> Skara team to have the bots check this before allowing integration.
> /Jesper
> 
> > On 1 Oct 2020, at 23:06, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> wrote:
> >
> > Hi,
> >
> > Please open up a dummy copy JBS issue without confidential
> > information if you fix a closed, internal Oracle bug.
> > I missed this before, I only saw it is closed when
> > this was pushed today.
> >
> > It is really annoying to still see closed bugs.
> > I had hoped skara would help to avoid this.
> >
> > Please find a way to fix this, so it does not happen
> > all the time!
> >
> > Best regards,
> >  Goetz
> >
> >> -----Original Message-----
> >> From: serviceability-dev <serviceability-dev-retn at openjdk.java.net> On
> >> Behalf Of Leonid Mesnik
> >> Sent: Thursday, October 1, 2020 12:58 AM
> >> To: serviceability-dev at openjdk.java.net
> >> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
> >> TieredCompilation
> >>
> >> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik
> <lmesnik at openjdk.org>
> >> wrote:
> >>
> >>> Test fails with -XX:+TieredCompilation because j.l.Object hasn't been
> used
> >> enough time to trigger compilation. So it
> >>
> >> The bug is closed because contain some confidential info. So I explained
> >> issue and fix in this PR description.
> >>
> >> -------------
> >>
> >> PR: https://git.openjdk.java.net/jdk/pull/447


From robin.westberg at oracle.com  Fri Oct  2 13:41:45 2020
From: robin.westberg at oracle.com (Robin Westberg)
Date: Fri, 2 Oct 2020 15:41:45 +0200
Subject: Status of GitHub automatic tier1 testing
Message-ID: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>

Hi all,

As you may have noticed when pushing changes to your personal forks recently, GitHub will now automatically trigger basic tier1 testing on the supported platforms (currently Linux, Windows and macOS, all x64). If all goes well you may not even notice it as it defaults to sending a notification only if anything should fail.

However, please note that the first version of this automatic test execution contained a problem that could cause it to not detect failing test cases. I know there have been a few test errors that have gone by unnoticed due to this for which I?m sorry. The good news is that the problem is now fixed starting with https://github.com/openjdk/jdk/commit/7dcdc1fbdd9d5b21253537ee59dd70f4e8f3d002 - so make sure that your branch contains this change if you plan to look at the test results!

Apart from this there are now no known issues with these pre-submit tests, so if you run into any problem, please let me know. If these tests turn out to be reasonably stable and trustworthy, the next step will be to present a summary of the results in the body of PRs to make them more visible.

Best regards,
Robi 

From thomas.schatzl at oracle.com  Fri Oct  2 13:48:50 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 2 Oct 2020 15:48:50 +0200
Subject: Status of GitHub automatic tier1 testing
In-Reply-To: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>
References: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>
Message-ID: <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>

Hi,

On 02.10.20 15:41, Robin Westberg wrote:
> Hi all,
> 
> As you may have noticed when pushing changes to your personal forks recently, GitHub will now automatically trigger basic tier1 testing on the supported platforms (currently Linux, Windows and macOS, all x64). If all goes well you may not even notice it as it defaults to sending a notification only if anything should fail.
> 
> However, please note that the first version of this automatic test execution contained a problem that could cause it to not detect failing test cases. I know there have been a few test errors that have gone by unnoticed due to this for which I?m sorry. The good news is that the problem is now fixed starting with https://github.com/openjdk/jdk/commit/7dcdc1fbdd9d5b21253537ee59dd70f4e8f3d002 - so make sure that your branch contains this change if you plan to look at the test results!
> 
> Apart from this there are now no known issues with these pre-submit tests, so if you run into any problem, please let me know. If these tests turn out to be reasonably stable and trustworthy, the next step will be to present a summary of the results in the body of PRs to make them more visible.
> 
> Best regards,
> Robi
> 

   thanks for your effort.

I would like to ask for a way to opt out - the public personal may 
receive unfinished work that may not even compile in a lot of cases. So 
this pre-checking seems like a waste of cpu time in a lot of cases and 
another notification I do not want in my inbox.

After the fifth or so a day I'll probably just ignore it anyway.

Also there are a significant amount of pushes that are done just fixing 
a typo in a comment or such, again wasting time.

I can somewhat understand such testing for different situations.

Thanks,
   Thomas

From thomas.schatzl at oracle.com  Fri Oct  2 14:02:57 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 2 Oct 2020 16:02:57 +0200
Subject: Status of GitHub automatic tier1 testing
In-Reply-To: <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
References: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>
 <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
Message-ID: <286b56c9-e213-c8e1-6afa-b460c284a187@oracle.com>

Hi again,

   just to clarify my statements:

On 02.10.20 15:48, Thomas Schatzl wrote:
> Hi,
> 
> On 02.10.20 15:41, Robin Westberg wrote:
>> Hi all,
>>
>> As you may have noticed when pushing changes to your personal forks 
>> recently, GitHub will now automatically trigger basic tier1 testing on 
>> the supported platforms (currently Linux, Windows and macOS, all x64). 
>> If all goes well you may not even notice it as it defaults to sending 
>> a notification only if anything should fail.
>>
>> However, please note that the first version of this automatic test 
>> execution contained a problem that could cause it to not detect 
>> failing test cases. I know there have been a few test errors that have 
>> gone by unnoticed due to this for which I?m sorry. The good news is 
>> that the problem is now fixed starting with 
>> https://github.com/openjdk/jdk/commit/7dcdc1fbdd9d5b21253537ee59dd70f4e8f3d002 
>> - so make sure that your branch contains this change if you plan to 
>> look at the test results!
>>
>> Apart from this there are now no known issues with these pre-submit 
>> tests, so if you run into any problem, please let me know. If these 
>> tests turn out to be reasonably stable and trustworthy, the next step 
>> will be to present a summary of the results in the body of PRs to make 
>> them more visible.
>>
>> Best regards,
>> Robi
>>
> 
>  ? thanks for your effort.
> 
> I would like to ask for a way to opt out - the public personal may 
> receive unfinished work that may not even compile in a lot of cases. So 
> this pre-checking seems like a waste of cpu time in a lot of cases and 
> another notification I do not want in my inbox.
> 
> After the fifth or so a day I'll probably just ignore it anyway.
> 
> Also there are a significant amount of pushes that are done just fixing 
> a typo in a comment or such, again wasting time.

That particularly tends to happen a lot when I do the final check for a 
draft PR. I tend to keep the public personal fork fairly clean and only 
push when I am ready to create a draft PR.

But I also know a few personal openjdk forks that seem to do all of 
their development in the open and potentially push their work at the end 
of the day in whatever state it is (idk really, but I do that in a 
private repo).

They will just get annoyed by unnecessary emails (and it really just 
wastes cpu time).

> 
> I can somewhat understand such testing for different situations.
> 
Eg. when publishing a PR, or maybe changing a fork that has a published 
PR. Or before integration with the option to override due to unrelated 
failures.

Thanks,
   Thomas

From robin.westberg at oracle.com  Fri Oct  2 14:03:14 2020
From: robin.westberg at oracle.com (Robin Westberg)
Date: Fri, 2 Oct 2020 16:03:14 +0200
Subject: Status of GitHub automatic tier1 testing
In-Reply-To: <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
References: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>
 <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
Message-ID: <E14632C1-A68C-4F2F-9B80-3D1DD9CD6345@oracle.com>

Hi Thomas,

> On 2 Oct 2020, at 15:48, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> On 02.10.20 15:41, Robin Westberg wrote:
>> Hi all,
>> As you may have noticed when pushing changes to your personal forks recently, GitHub will now automatically trigger basic tier1 testing on the supported platforms (currently Linux, Windows and macOS, all x64). If all goes well you may not even notice it as it defaults to sending a notification only if anything should fail.
>> However, please note that the first version of this automatic test execution contained a problem that could cause it to not detect failing test cases. I know there have been a few test errors that have gone by unnoticed due to this for which I?m sorry. The good news is that the problem is now fixed starting with https://github.com/openjdk/jdk/commit/7dcdc1fbdd9d5b21253537ee59dd70f4e8f3d002 - so make sure that your branch contains this change if you plan to look at the test results!
>> Apart from this there are now no known issues with these pre-submit tests, so if you run into any problem, please let me know. If these tests turn out to be reasonably stable and trustworthy, the next step will be to present a summary of the results in the body of PRs to make them more visible.
>> Best regards,
>> Robi
> 
>  thanks for your effort.
> 
> I would like to ask for a way to opt out - the public personal may receive unfinished work that may not even compile in a lot of cases. So this pre-checking seems like a waste of cpu time in a lot of cases and another notification I do not want in my inbox.
> 
> After the fifth or so a day I'll probably just ignore it anyway.
> 
> Also there are a significant amount of pushes that are done just fixing a typo in a comment or such, again wasting time.
> 
> I can somewhat understand such testing for different situations.

Certainly, depending on how often you push changes, running these tests on every commit may indeed be quite wasteful. Fortunately, it?s possible to opt out in a few different ways! I?m planning to add this information to the Skara wiki soon, but in the meantime, here are your current options:

1) Disable GitHub Actions completely for your fork - https://github.com/<your_github_id>/jdk/settings/actions and select Disable.

2) Only run automatic testing for branches that start with ?submit/? - in this way you can trigger tests on selected branches from the command line with something like this:

$ git push origin mybranch:submit/test_of_my_branch

To enable this mode of operation, go to https://github.com/<your_github_id>/jdk/settings/secrets and click on ?New secret?. Enter the name ?JDK_SUBMIT_FILTER? and set the value to a non-empty random string, perhaps ?yes, enable this?.

3) Only run automatic testing on a subset of available platforms to improve execution time. To enable this mode of operation, see #2, but instead create a secret named ?JDK_SUBMIT_PLATFORMS? with a value like ?Linux x64? or ?macOS x64, Windows x64?.

I guess my recommendation would be #2 to begin with, in case you want to retain the ability to execute these tests manually on occasion.

Best regards,
Robin
> 
> Thanks,
>  Thomas


From kevin.rushforth at oracle.com  Fri Oct  2 14:04:43 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 2 Oct 2020 07:04:43 -0700
Subject: Status of GitHub automatic tier1 testing
In-Reply-To: <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
References: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>
 <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
Message-ID: <ab065099-c798-05b0-c523-edd73096dcb7@oracle.com>

Isn't this only run if the branch you push to has an open pull request? 
The way I had imagined this working, is that it would run the test as 
soon as you create a PR (even a Draft PR).

If it actually runs a build and tier 1 tests on every push to any branch 
of everyone's personal fork, then it might be better to make it an 
explicit "opt in".

-- Kevin


On 10/2/2020 6:48 AM, Thomas Schatzl wrote:
> Hi,
>
> On 02.10.20 15:41, Robin Westberg wrote:
>> Hi all,
>>
>> As you may have noticed when pushing changes to your personal forks 
>> recently, GitHub will now automatically trigger basic tier1 testing 
>> on the supported platforms (currently Linux, Windows and macOS, all 
>> x64). If all goes well you may not even notice it as it defaults to 
>> sending a notification only if anything should fail.
>>
>> However, please note that the first version of this automatic test 
>> execution contained a problem that could cause it to not detect 
>> failing test cases. I know there have been a few test errors that 
>> have gone by unnoticed due to this for which I?m sorry. The good news 
>> is that the problem is now fixed starting with 
>> https://github.com/openjdk/jdk/commit/7dcdc1fbdd9d5b21253537ee59dd70f4e8f3d002 
>> - so make sure that your branch contains this change if you plan to 
>> look at the test results!
>>
>> Apart from this there are now no known issues with these pre-submit 
>> tests, so if you run into any problem, please let me know. If these 
>> tests turn out to be reasonably stable and trustworthy, the next step 
>> will be to present a summary of the results in the body of PRs to 
>> make them more visible.
>>
>> Best regards,
>> Robi
>>
>
> ? thanks for your effort.
>
> I would like to ask for a way to opt out - the public personal may 
> receive unfinished work that may not even compile in a lot of cases. 
> So this pre-checking seems like a waste of cpu time in a lot of cases 
> and another notification I do not want in my inbox.
>
> After the fifth or so a day I'll probably just ignore it anyway.
>
> Also there are a significant amount of pushes that are done just 
> fixing a typo in a comment or such, again wasting time.
>
> I can somewhat understand such testing for different situations.
>
> Thanks,
> ? Thomas


From david.holmes at oracle.com  Fri Oct  2 15:18:42 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 3 Oct 2020 01:18:42 +1000
Subject: Status of GitHub automatic tier1 testing
In-Reply-To: <ab065099-c798-05b0-c523-edd73096dcb7@oracle.com>
References: <CFC85911-04C7-4D64-B7C4-B94A918415FF@oracle.com>
 <e0d8b2c3-68a2-56e1-08f6-a632cc54e5bf@oracle.com>
 <ab065099-c798-05b0-c523-edd73096dcb7@oracle.com>
Message-ID: <b3d5f5c9-210e-7f23-981e-7e6a2aaf93a6@oracle.com>

On 3/10/2020 12:04 am, Kevin Rushforth wrote:
> Isn't this only run if the branch you push to has an open pull request? 
> The way I had imagined this working, is that it would run the test as 
> soon as you create a PR (even a Draft PR).
> 
> If it actually runs a build and tier 1 tests on every push to any branch 
> of everyone's personal fork, then it might be better to make it an 
> explicit "opt in".

I would agree that opt-in would seem a much better proposition - and I 
have to wonder what resources are available to run these tests in github?

Cheers,
David

> -- Kevin
> 
> 
> On 10/2/2020 6:48 AM, Thomas Schatzl wrote:
>> Hi,
>>
>> On 02.10.20 15:41, Robin Westberg wrote:
>>> Hi all,
>>>
>>> As you may have noticed when pushing changes to your personal forks 
>>> recently, GitHub will now automatically trigger basic tier1 testing 
>>> on the supported platforms (currently Linux, Windows and macOS, all 
>>> x64). If all goes well you may not even notice it as it defaults to 
>>> sending a notification only if anything should fail.
>>>
>>> However, please note that the first version of this automatic test 
>>> execution contained a problem that could cause it to not detect 
>>> failing test cases. I know there have been a few test errors that 
>>> have gone by unnoticed due to this for which I?m sorry. The good news 
>>> is that the problem is now fixed starting with 
>>> https://github.com/openjdk/jdk/commit/7dcdc1fbdd9d5b21253537ee59dd70f4e8f3d002 
>>> - so make sure that your branch contains this change if you plan to 
>>> look at the test results!
>>>
>>> Apart from this there are now no known issues with these pre-submit 
>>> tests, so if you run into any problem, please let me know. If these 
>>> tests turn out to be reasonably stable and trustworthy, the next step 
>>> will be to present a summary of the results in the body of PRs to 
>>> make them more visible.
>>>
>>> Best regards,
>>> Robi
>>>
>>
>> ? thanks for your effort.
>>
>> I would like to ask for a way to opt out - the public personal may 
>> receive unfinished work that may not even compile in a lot of cases. 
>> So this pre-checking seems like a waste of cpu time in a lot of cases 
>> and another notification I do not want in my inbox.
>>
>> After the fifth or so a day I'll probably just ignore it anyway.
>>
>> Also there are a significant amount of pushes that are done just 
>> fixing a typo in a comment or such, again wasting time.
>>
>> I can somewhat understand such testing for different situations.
>>
>> Thanks,
>> ? Thomas
> 

From mark.reinhold at oracle.com  Fri Oct  2 18:16:58 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 02 Oct 2020 11:16:58 -0700
Subject: JEP proposed to target JDK 16: 376: ZGC: Concurrent Thread-Stack
 Processing
In-Reply-To: <20200924193059.4342B3C2F40@eggemoggin.niobe.net>
References: <20200924193059.4342B3C2F40@eggemoggin.niobe.net>
Message-ID: <20201002111658.29624552@eggemoggin.niobe.net>

2020/9/24 12:30:59 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   376: ZGC: Concurrent Thread-Stack Processing
>        https://openjdk.java.net/jeps/376
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:00 UTC on Thursday, 1 October, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From mark.reinhold at oracle.com  Fri Oct  2 18:22:31 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 02 Oct 2020 11:22:31 -0700
Subject: JEP proposed to target JDK 16: 388: Windows/AArch64 Port
In-Reply-To: <20200924203309.738093C2F5C@eggemoggin.niobe.net>
References: <20200924203309.738093C2F5C@eggemoggin.niobe.net>
Message-ID: <20201002112231.186958027@eggemoggin.niobe.net>

2020/9/24 13:33:09 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   388: Windows/AArch64 Port
>        https://openjdk.java.net/jeps/388
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:00 UTC on Thursday, 1 October, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From christoph.langer at sap.com  Sun Oct  4 10:49:57 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 4 Oct 2020 10:49:57 +0000
Subject: CFV: New JDK Reviewer: Bob Vandette
In-Reply-To: <3d0852ed-01fe-2e8d-95a7-044f458703b1@oracle.com>
References: <3d0852ed-01fe-2e8d-95a7-044f458703b1@oracle.com>
Message-ID: <AM4PR02MB31383CA734A447CBCAAE4C128A0F0@AM4PR02MB3138.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-retn at openjdk.java.net> On Behalf Of Harold Seigel
> Sent: Freitag, 25. September 2020 15:54
> To: jdk-dev at openjdk.java.net
> Subject: CFV: New JDK Reviewer: Bob Vandette
> 
> Hi,
> 
> I hereby nominate Bob Vandette (bobv) to JDK Reviewer.
> 
> Bob is a member of the Java Team at Oracle and contributed 100+ changes
> to the JDK project [1].
> 
> In addition to several smaller enhancements in the Hotspot runtime area,
> Bob has lead, worked on and contributed to several large enhancements to
> the Java platform that span the entire JDK code base including:
> 
> 1. Broadening the architectures and platforms that Java can execute on
> such as IA64, ARM32, AArch64, PPC including Embedded and Mobile devices.
> 
> 2. Creator of Java SE Embedded
> 
> 3. Compact Profiles
> 
> 4. Container support for Java including changes to Hotspot VM and the
> addition of the JDK Metrics API.
> 
> Votes are due by 09:00 UTC, October 9th, 2020.
> 
> Only current JDK Reviewers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Best regards,
> 
> Harold
> 
> [1]
> http://hg.openjdk.java.net/jdk/jdk/search/?rev=desc%28%22bob.vandette
> %40oracle.com%22%29%20or%20author%28bobv%29&revcount=200
> 
> [2] http://openjdk.java.net/census
> 
> [3] http://openjdk.java.net/bylaws#lazy-consensus


From shade at redhat.com  Mon Oct  5 07:44:38 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Oct 2020 09:44:38 +0200
Subject: JDK-8161684
Message-ID: <42b26c9f-336a-0d7c-64f8-1af4ab777364@redhat.com>

Hi,

Could anyone please see if JDK-8161684 can be opened?
   https://bugs.openjdk.java.net/browse/JDK-8161684

It seems to be a simple hunk:
   https://github.com/openjdk/jdk/commit/c02b75705fa2ffe9825f65d6dd671a0e7ea473ef

I would like to backport it to at least 11u to enable -XX:+VerifyOops testing there, but having the 
non-public issue makes the backporting red tape more tedious than it can be.

-- 
Thanks,
-Aleksey


From jesper.wilhelmsson at oracle.com  Mon Oct  5 12:48:18 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 5 Oct 2020 14:48:18 +0200
Subject: JDK-8161684
In-Reply-To: <42b26c9f-336a-0d7c-64f8-1af4ab777364@redhat.com>
References: <42b26c9f-336a-0d7c-64f8-1af4ab777364@redhat.com>
Message-ID: <FDDA0BEB-8489-4FEF-BC1B-DA4E4A491243@oracle.com>



> On 5 Oct 2020, at 09:44, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Hi,
> 
> Could anyone please see if JDK-8161684 can be opened?
>  https://bugs.openjdk.java.net/browse/JDK-8161684

Fixed.
/Jesper

> 
> It seems to be a simple hunk:
>  https://github.com/openjdk/jdk/commit/c02b75705fa2ffe9825f65d6dd671a0e7ea473ef
> 
> I would like to backport it to at least 11u to enable -XX:+VerifyOops testing there, but having the non-public issue makes the backporting red tape more tedious than it can be.
> 
> --
> Thanks,
> -Aleksey
> 


From shade at redhat.com  Mon Oct  5 17:15:45 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 5 Oct 2020 19:15:45 +0200
Subject: JDK-8161684
In-Reply-To: <FDDA0BEB-8489-4FEF-BC1B-DA4E4A491243@oracle.com>
References: <42b26c9f-336a-0d7c-64f8-1af4ab777364@redhat.com>
 <FDDA0BEB-8489-4FEF-BC1B-DA4E4A491243@oracle.com>
Message-ID: <ff919590-477b-51b9-818c-6a79c4e226bf@redhat.com>

On 10/5/20 2:48 PM, Jesper Wilhelmsson wrote:
>> On 5 Oct 2020, at 09:44, Aleksey Shipilev <shade at redhat.com> wrote:
>> Could anyone please see if JDK-8161684 can be opened?
>>   https://bugs.openjdk.java.net/browse/JDK-8161684
> 
> Fixed.
> /Jesper

Thank you!

-- 
-Aleksey


From joe.darcy at oracle.com  Tue Oct  6 03:19:41 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 5 Oct 2020 20:19:41 -0700
Subject: Looking ahead: allow sufficient review time for CSRs before JDK 16
 ramp down 1
Message-ID: <112ecb92-141a-b961-c057-7c9ef0ce44d7@oracle.com>

Hello,

Looking ahead, there are approximately 10 weeks until JDK 16 ramp down 1 
in mid-December 2020.

This email is an advanced reminder to factor in sufficient review time 
for any projects needing CSRs before getting pushed into JDK 16. Large 
projects, including JEPs, should often use the two-phase CSR process 
(https://wiki.openjdk.java.net/display/csr/Main) rather than the 
one-phase process. The nominal SLA for each CSR phase is one week. To 
accommodate the possibility of needing to respond to feedback from the 
CSR review, I recommend a large project plan for at least three weeks of 
CSR review time ahead of a planned integration date.

Cheers,

-Joe
CSR Lead


From andrew_m_leonard at uk.ibm.com  Tue Oct  6 07:34:23 2020
From: andrew_m_leonard at uk.ibm.com (Andrew Leonard)
Date: Tue, 6 Oct 2020 08:34:23 +0100
Subject: Changing maillist subscription email address?
Message-ID: <OF3FA20FF9.88C3373A-ON002585F9.002902E5-802585F9.002999D9@notes.na.collabserv.com>

Hi,
I have moved company and I am trying to update my maillist subscriptions 
Address to my new address, however the "Changing your jdk-dev membership 
information" field to change to a "new address" does not seem to work, I 
do not get a confirmation email to my new email. Has anyone tried this 
recently? or know how to resolve please? Do I actually need to 
re-subscribe with my new email maybe?
I have a limited time while my IBM email is still active..
Many Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
internet email: andrew_m_leonard at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From david.holmes at oracle.com  Tue Oct  6 07:38:37 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 6 Oct 2020 17:38:37 +1000
Subject: Changing maillist subscription email address?
In-Reply-To: <OF3FA20FF9.88C3373A-ON002585F9.002902E5-802585F9.002999D9@notes.na.collabserv.com>
References: <OF3FA20FF9.88C3373A-ON002585F9.002902E5-802585F9.002999D9@notes.na.collabserv.com>
Message-ID: <ce3016b1-2a8d-7448-8176-a8354dd4beaf@oracle.com>

Hi Andrew,

Seems like a question for web-discuss - cc'd.

Cheers,
David

On 6/10/2020 5:34 pm, Andrew Leonard wrote:
> Hi,
> I have moved company and I am trying to update my maillist subscriptions
> Address to my new address, however the "Changing your jdk-dev membership
> information" field to change to a "new address" does not seem to work, I
> do not get a confirmation email to my new email. Has anyone tried this
> recently? or know how to resolve please? Do I actually need to
> re-subscribe with my new email maybe?
> I have a limited time while my IBM email is still active..
> Many Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 

From mark.reinhold at oracle.com  Tue Oct  6 16:35:31 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue,  6 Oct 2020 09:35:31 -0700 (PDT)
Subject: New candidate JEP: 394: Pattern Matching for instanceof
Message-ID: <20201006163531.D62283C46CC@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/394

- Mark

From thomas.schatzl at oracle.com  Thu Oct  8 09:35:14 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 8 Oct 2020 11:35:14 +0200
Subject: New JDK Committer: Ivan Walulya
Message-ID: <fcaaf6cd-42d7-df4d-50b1-af5a31b750b3@oracle.com>

Hi all,


Hi,

I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.

Ivan has been contributing to the OpenJDK project since February 2020.

He already contributed 14 fixes to the JDK project [3], ranging from 
small fixes to quite tricky fixes and changes to G1 prediction heuristics.

Votes are due by 12:00 UTC October 16th, 2020.

Only current JDK Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this
mailing list.

For Lazy Consensus voting instructions, see [2].

Best regards,
   Thomas

-
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/bylaws#lazy-consensus
[3] $ git log --oneline --author "Ivan Walulya"

86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
Remark/Cleanup  pauses
4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
pause times in calculation
63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
region selection within a gc
553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
queue iteration on max_gc_time pause time
31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
-XX:LargePageSizeInBytes
59521b03894 8209162: Page size selection does not always select optimal 
page size
5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
expansion_amount even when at full capacity
d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
double linkedlist any more
f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
the estimated free regions before
25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
with parallel gc
edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
41f962d7845 8232689: Remove ParCompactionManager::Action enum
6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
logging



From thomas.schatzl at oracle.com  Thu Oct  8 09:36:36 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 8 Oct 2020 11:36:36 +0200
Subject: New JDK Committer: Ivan Walulya
In-Reply-To: <fcaaf6cd-42d7-df4d-50b1-af5a31b750b3@oracle.com>
References: <fcaaf6cd-42d7-df4d-50b1-af5a31b750b3@oracle.com>
Message-ID: <5461693b-5521-97e7-7333-50fbf48345b7@oracle.com>

Vote: yes

On 08.10.20 11:35, Thomas Schatzl wrote:
> Hi all,
> 
> 
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 16th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 


From thomas.schatzl at oracle.com  Thu Oct  8 09:38:18 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 8 Oct 2020 11:38:18 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
Message-ID: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>

Hi,

I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.

Ivan has been contributing to the OpenJDK project since February 2020.

He already contributed 14 fixes to the JDK project [3], ranging from 
small fixes to quite tricky fixes and changes to G1 prediction heuristics.

Votes are due by 12:00 UTC October 23th, 2020.

Only current JDK Committers [1] are eligible to vote on this
nomination. Votes must be cast in the open by replying to this
mailing list.

For Lazy Consensus voting instructions, see [2].

Best regards,
   Thomas

-
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/bylaws#lazy-consensus
[3] $ git log --oneline --author "Ivan Walulya"

86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
Remark/Cleanup  pauses
4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
pause times in calculation
63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
region selection within a gc
553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
queue iteration on max_gc_time pause time
31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
-XX:LargePageSizeInBytes
59521b03894 8209162: Page size selection does not always select optimal 
page size
5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
expansion_amount even when at full capacity
d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
double linkedlist any more
f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
the estimated free regions before
25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
with parallel gc
edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
41f962d7845 8232689: Remove ParCompactionManager::Action enum
6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
logging



From thomas.schatzl at oracle.com  Thu Oct  8 09:39:17 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 8 Oct 2020 11:39:17 +0200
Subject: New JDK Committer: Ivan Walulya
In-Reply-To: <5461693b-5521-97e7-7333-50fbf48345b7@oracle.com>
References: <fcaaf6cd-42d7-df4d-50b1-af5a31b750b3@oracle.com>
 <5461693b-5521-97e7-7333-50fbf48345b7@oracle.com>
Message-ID: <e99d0264-5c10-f60b-bf35-89216d13b3ab@oracle.com>

Hi again,

   I messed up with the voting end date in this nomination. Please use 
the new thread (with: Fixed voting end date) to vote.

Thanks,
   Thomas

On 08.10.20 11:36, Thomas Schatzl wrote:
> Vote: yes
> 
> On 08.10.20 11:35, Thomas Schatzl wrote:
>> Hi all,
>>
>>
>> Hi,
>>
>> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
>>
>> Ivan has been contributing to the OpenJDK project since February 2020.
>>
>> He already contributed 14 fixes to the JDK project [3], ranging from 
>> small fixes to quite tricky fixes and changes to G1 prediction 
>> heuristics.
>>
>> Votes are due by 12:00 UTC October 16th, 2020.
>>
>> Only current JDK Committers [1] are eligible to vote on this
>> nomination. Votes must be cast in the open by replying to this
>> mailing list.
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Best regards,
>> ?? Thomas
>>
>> -
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/bylaws#lazy-consensus
>> [3] $ git log --oneline --author "Ivan Walulya"
>>
>> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
>> Remark/Cleanup? pauses
>> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses 
>> wrong pause times in calculation
>> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
>> region selection within a gc
>> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
>> queue iteration on max_gc_time pause time
>> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
>> -XX:LargePageSizeInBytes
>> 59521b03894 8209162: Page size selection does not always select 
>> optimal page size
>> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
>> expansion_amount even when at full capacity
>> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be 
>> a double linkedlist any more
>> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
>> the estimated free regions before
>> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated 
>> correctly
>> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
>> with parallel gc
>> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
>> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
>> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into 
>> unified logging
>>
>>
> 


From thomas.schatzl at oracle.com  Thu Oct  8 09:39:32 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 8 Oct 2020 11:39:32 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <6bfd87d8-7798-c8ab-d4b7-ed87484436bb@oracle.com>

Vote: yes

Thomas

On 08.10.20 11:38, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 


From erik.helin at oracle.com  Thu Oct  8 10:02:25 2020
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 8 Oct 2020 12:02:25 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <87d78f13-32ae-3cca-3048-eab7faf2cc79@oracle.com>

Vote: yes

Thanks,
Erik

On 10/8/20 11:38 AM, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From stefan.karlsson at oracle.com  Thu Oct  8 10:20:16 2020
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 8 Oct 2020 12:20:16 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <e42dc29e-00ee-24df-0397-db54755cb72f@oracle.com>

Vote: yes

StefanK

On 2020-10-08 11:38, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From benjamin.john.evans at gmail.com  Thu Oct  8 10:50:19 2020
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Thu, 8 Oct 2020 12:50:19 +0200
Subject: TZUpdater broken against 2020b update?
Message-ID: <CABKW8RiqnJabeQJGTZZfiWNE2=AsvJsYemeBLx09YvUWXaBxQA@mail.gmail.com>

Hi,

We've just tried to run the TZUpdater tool against the 2020b update
and it's failing with:

Using file:///bad-time/tzdata2020b.tar.gz as source for tzdata bundle.
Source directory does not contain source file: pacificnew

The file in 2020a seems to suggest that pacificnew is obsolete so is
it possible that the problem is that they have decided to finally
remove it with 2020b?

Sorry for spamming the list - but there's no obvious place to report
problems from https://www.oracle.com/java/technologies/javase/tzupdater-readme.html

Thanks,

Ben

From coleen.phillimore at oracle.com  Thu Oct  8 11:36:29 2020
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 8 Oct 2020 07:36:29 -0400
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <5c98b483-932f-234e-8500-0eb5750f9d8e@oracle.com>

Vote: yes

On 10/8/20 5:38 AM, Thomas Schatzl wrote:
> Hi,
>
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
>
> Ivan has been contributing to the OpenJDK project since February 2020.
>
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction 
> heuristics.
>
> Votes are due by 12:00 UTC October 23th, 2020.
>
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Best regards,
> ? Thomas
>
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
>
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses 
> wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select 
> optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be 
> a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated 
> correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into 
> unified logging
>
>


From harold.seigel at oracle.com  Thu Oct  8 13:22:46 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Thu, 8 Oct 2020 09:22:46 -0400
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <68d1b2f5-4e58-41de-e883-1eb8dfc63e99@oracle.com>

Vote: yes.

Harold

On 10/8/2020 5:38 AM, Thomas Schatzl wrote:
> Hi,
>
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
>
> Ivan has been contributing to the OpenJDK project since February 2020.
>
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction 
> heuristics.
>
> Votes are due by 12:00 UTC October 23th, 2020.
>
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Best regards,
> ? Thomas
>
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
>
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses 
> wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select 
> optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be 
> a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated 
> correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into 
> unified logging
>
>

From balchandra.vaidya at oracle.com  Thu Oct  8 14:11:25 2020
From: balchandra.vaidya at oracle.com (Balchandra Vaidya)
Date: Thu, 8 Oct 2020 19:41:25 +0530
Subject: TZUpdater broken against 2020b update?
In-Reply-To: <48464DE3-5D44-444D-9B91-892C753D0539@oracle.com>
References: <CABKW8RiqnJabeQJGTZZfiWNE2=AsvJsYemeBLx09YvUWXaBxQA@mail.gmail.com>
 <48464DE3-5D44-444D-9B91-892C753D0539@oracle.com>
Message-ID: <9ce0f873-3b58-aaf7-5298-5b131f15f329@oracle.com>


Hi Ben,

 ? Here is the bug id: https://bugs.openjdk.java.net/browse/JDK-8254240

Regards,
Balchandra

>
>> *From: *Ben Evans <benjamin.john.evans at gmail.com 
>> <mailto:benjamin.john.evans at gmail.com>>
>> *Subject: **TZUpdater broken against 2020b update?*
>> *Date: *October 8, 2020 at 3:50:19 AM PDT
>> *To: *jdk-dev <jdk-dev at openjdk.java.net 
>> <mailto:jdk-dev at openjdk.java.net>>
>>
>> Hi,
>>
>> We've just tried to run the TZUpdater tool against the 2020b update
>> and it's failing with:
>>
>> Using file:///bad-time/tzdata2020b.tar.gz as source for tzdata bundle.
>> Source directory does not contain source file: pacificnew
>>
>> The file in 2020a seems to suggest that pacificnew is obsolete so is
>> it possible that the problem is that they have decided to finally
>> remove it with 2020b?
>>
>> Sorry for spamming the list - but there's no obvious place to report
>> problems from 
>> https://www.oracle.com/java/technologies/javase/tzupdater-readme.html
>>
>> Thanks,
>>
>> Ben
>


From lois.foltan at oracle.com  Thu Oct  8 14:25:34 2020
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 8 Oct 2020 10:25:34 -0400
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <62c4b058-d550-10a7-0950-a60d53443032@oracle.com>

Vote: yes

Lois

On 10/8/2020 5:38 AM, Thomas Schatzl wrote:
> Hi,
>
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
>
> Ivan has been contributing to the OpenJDK project since February 2020.
>
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction 
> heuristics.
>
> Votes are due by 12:00 UTC October 23th, 2020.
>
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Best regards,
> ? Thomas
>
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
>
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses 
> wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select 
> optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be 
> a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated 
> correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into 
> unified logging
>
>


From erik.osterlund at oracle.com  Thu Oct  8 14:29:18 2020
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 8 Oct 2020 16:29:18 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <43c0c592-93e1-5f40-5612-f3acc59097ed@oracle.com>

Vote: yes

/Erik

On 2020-10-08 11:38, Thomas Schatzl wrote:
> Hi,
>
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
>
> Ivan has been contributing to the OpenJDK project since February 2020.
>
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction 
> heuristics.
>
> Votes are due by 12:00 UTC October 23th, 2020.
>
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Best regards,
> ? Thomas
>
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
>
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses 
> wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select 
> optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be 
> a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated 
> correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into 
> unified logging
>
>


From sangheon.kim at oracle.com  Thu Oct  8 15:58:31 2020
From: sangheon.kim at oracle.com (sangheon.kim at oracle.com)
Date: Thu, 8 Oct 2020 08:58:31 -0700
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <06c765d0-496d-2415-a5f5-200722b835d2@oracle.com>

Vote: Yes

Thanks,
Sangheon


On 10/8/20 2:38 AM, Thomas Schatzl wrote:
> Hi,
>
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
>
> Ivan has been contributing to the OpenJDK project since February 2020.
>
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction 
> heuristics.
>
> Votes are due by 12:00 UTC October 23th, 2020.
>
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Best regards,
> ? Thomas
>
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
>
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses 
> wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select 
> optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be 
> a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated 
> correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into 
> unified logging
>
>


From kim.barrett at oracle.com  Thu Oct  8 17:59:11 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Oct 2020 13:59:11 -0400
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <D2E805D9-1291-4E4A-8A2C-C6AAE5092231@oracle.com>

vote: yes

> On Oct 8, 2020, at 5:38 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider Remark/Cleanup  pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified logging



From mikael.vidstedt at oracle.com  Thu Oct  8 20:05:19 2020
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 8 Oct 2020 13:05:19 -0700
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <535192BD-AAD0-4397-B98B-2AC38F031825@oracle.com>


Vote: yes

Cheers,
Mikael

> On Oct 8, 2020, at 2:38 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider Remark/Cleanup  pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified logging
> 
> 


From mark.reinhold at oracle.com  Thu Oct  8 21:36:53 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  8 Oct 2020 14:36:53 -0700 (PDT)
Subject: New candidate JEP: 395: Records
Message-ID: <20201008213653.7BD403C4D6E@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/395

- Mark

From jesper.wilhelmsson at oracle.com  Thu Oct  8 23:11:40 2020
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 9 Oct 2020 01:11:40 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <8B8D5AAC-F20F-4319-9092-649D73A4BBDC@oracle.com>

Vote: Yes
/Jesper

> On 8 Oct 2020, at 11:38, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider Remark/Cleanup  pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified logging
> 
> 


From robin.westberg at oracle.com  Fri Oct  9 06:35:00 2020
From: robin.westberg at oracle.com (Robin Westberg)
Date: Fri, 9 Oct 2020 08:35:00 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <3BD75FC5-86B0-4813-9730-BC7137F76DD4@oracle.com>

Vote: yes

Best regards,
Robin

> On 8 Oct 2020, at 11:38, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider Remark/Cleanup  pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified logging
> 
> 


From harold.seigel at oracle.com  Fri Oct  9 14:03:02 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 9 Oct 2020 10:03:02 -0400
Subject: Result: New JDK Reviewer Bob Vandette
Message-ID: <7316b7f8-6617-3165-ded1-3a52c9342137@oracle.com>

Hi,

Voting for Bob Vandette (bobv) [1] is now closed.

Yes:??? 51
Abstain: 0
Veto:??? 0

According to the Bylaws definition of Lazy Consensus, this sufficient to 
approve the nomination.

Thanks, Harold

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004759.html


From eric.caspole at oracle.com  Fri Oct  9 14:17:47 2020
From: eric.caspole at oracle.com (eric.caspole at oracle.com)
Date: Fri, 9 Oct 2020 10:17:47 -0400
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <d6af39b6-fe9f-110b-b4bf-4e32ac4287d8@oracle.com>

Vote: yes

Eric


On 10/8/20 5:38 AM, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From per.liden at oracle.com  Mon Oct 12 20:50:09 2020
From: per.liden at oracle.com (Per Liden)
Date: Mon, 12 Oct 2020 22:50:09 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <3943a1fd-9987-b3b4-2ce4-c11914a8d189@oracle.com>

Vote: yes

/Per

On 10/8/20 11:38 AM, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From goetz.lindenmaier at sap.com  Tue Oct 13 06:00:44 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 13 Oct 2020 06:00:44 +0000
Subject: Please open up closed change 8233685: Test
 tools/javac/modules/AddLimitMods.java fails
Message-ID: <AM4PR0202MB296487A440C5D77B421CDBFFEC040@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hi,

Changes pushed to jdk should not be closed. 
Jan, could you please open up this change?
Vicente, could you please check in a next review
that the bug is not closed?
If it can not be opened, please open a duplicate
without confidential information before pushing!

Best regards,
  Goetz.

From robbin.ehn at oracle.com  Tue Oct 13 06:15:08 2020
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 13 Oct 2020 08:15:08 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <d49c97c3-c5cf-eaba-6ec3-8c43799b8423@oracle.com>

Vote: yes

/Robbin

On 2020-10-08 11:38, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From mark.reinhold at oracle.com  Wed Oct 14 00:37:33 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 13 Oct 2020 17:37:33 -0700
Subject: Proposed schedule for JDK 16
Message-ID: <20201013173733.880562818@eggemoggin.niobe.net>

With JDK 15 out the door, here?s a proposed schedule for JDK 16:

  2020/12/10  Rampdown Phase One
  2021/01/14  Rampdown Phase Two
  2021/02/04  Initial Release Candidate
  2021/02/18  Final Release Candidate
  2021/03/16  General Availability

The phases are defined in JEP 3 [1].

Comments on this proposal from JDK Committers and Reviewers [2] are
welcome, as are reasoned objections.  If no such objections are raised
by 23:00 UTC next Wednesday, 21 October, or if they?re raised and
satisfactorily answered, then per the JEP 2.0 process proposal [3]
this will be the schedule for JDK 16.

- Mark


[1] https://openjdk.java.net/jeps/3
[2] https://openjdk.java.net/census#jdk
[3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From leo.korinth at oracle.com  Wed Oct 14 12:42:26 2020
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 14 Oct 2020 14:42:26 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <8112ad1b-ebc8-3cdb-90d4-f7ac27994b40@oracle.com>

Vote: yes

/Leo

On 08/10/2020 11:38, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified logging
> 
> 

From jdowland at redhat.com  Mon Oct 12 13:48:51 2020
From: jdowland at redhat.com (Jonathan Dowland)
Date: Mon, 12 Oct 2020 14:48:51 +0100
Subject: markdown source for manpages in the jdk source tree
Message-ID: <20201012134851.g6k6fhdmpw7osa5p@qusp>

Hello,

I was investigating some bugs in manpages in the backports projects
(jdk8u, jdk11) and I was very pleased to discover that the main project
sources had moved to a Pandoc-based generation scheme? in 2018.

I started exploring the feasibility of backporting this to jdk11 (and/or
jdk8u) when I realised that the Markdown sources for the documentation
were not committed at the same time. And as best as I can determine, or
since. However: the *output* of the Pandoc generation process has had
patches applied to them?. (I don't know whether those changes are
reflected in the Markdown sources).

Can anyone tell me please whether this is by accident, or design? And in
either case, are the Markdown sources publically available somewhere, or
could they be?



? git commit 2ddd78e8259652c7c88a5bb7150d7b6ab0e089e2
? e.g. 27c77d3d29184fb052a3803984222ac2ea10a816,
    9ec4001d87fef63d9985747ee4852398c7479889,
    922ba8da30d4ab8007837e40c3e48acf700439ab


Thanks!

-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From david.holmes at oracle.com  Wed Oct 14 22:06:46 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Oct 2020 08:06:46 +1000
Subject: markdown source for manpages in the jdk source tree
In-Reply-To: <20201012134851.g6k6fhdmpw7osa5p@qusp>
References: <20201012134851.g6k6fhdmpw7osa5p@qusp>
Message-ID: <e52f5be2-54f1-c58b-21d7-2117aba070b6@oracle.com>

Hi Jonathon,

On 12/10/2020 11:48 pm, Jonathan Dowland wrote:
> Hello,
> 
> I was investigating some bugs in manpages in the backports projects
> (jdk8u, jdk11) and I was very pleased to discover that the main project
> sources had moved to a Pandoc-based generation scheme? in 2018.
> 
> I started exploring the feasibility of backporting this to jdk11 (and/or
> jdk8u) when I realised that the Markdown sources for the documentation
> were not committed at the same time. And as best as I can determine, or
> since. However: the *output* of the Pandoc generation process has had
> patches applied to them?. (I don't know whether those changes are
> reflected in the Markdown sources).
> 
> Can anyone tell me please whether this is by accident, or design? And in
> either case, are the Markdown sources publically available somewhere, or
> could they be?

The mardown source for the manpages is not currently open-source but is 
maintained by Oracle. That source is used to generate the nroff manpages 
that appear in the OpenJDK repo. That regeneration can happen as changes 
get made, or at the end of the release cycle e.g see:

https://bugs.openjdk.java.net/browse/JDK-8240777

Cheers,
David
-----

> 
> 
> ? git commit 2ddd78e8259652c7c88a5bb7150d7b6ab0e089e2
> ? e.g. 27c77d3d29184fb052a3803984222ac2ea10a816,
>      9ec4001d87fef63d9985747ee4852398c7479889,
>      922ba8da30d4ab8007837e40c3e48acf700439ab
> 
> 
> Thanks!
> 

From david.holmes at oracle.com  Wed Oct 14 22:08:18 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Oct 2020 08:08:18 +1000
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <f99ec532-6dbb-4830-08e0-1a36e390ef23@oracle.com>

Vote: yes

David

On 8/10/2020 7:38 pm, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From jdowland at redhat.com  Mon Oct 19 09:57:43 2020
From: jdowland at redhat.com (Jonathan Dowland)
Date: Mon, 19 Oct 2020 10:57:43 +0100
Subject: markdown source for manpages in the jdk source tree
In-Reply-To: <e52f5be2-54f1-c58b-21d7-2117aba070b6@oracle.com>
References: <20201012134851.g6k6fhdmpw7osa5p@qusp>
 <e52f5be2-54f1-c58b-21d7-2117aba070b6@oracle.com>
Message-ID: <20201019095743.qkicfkp7wi7sgw57@qusp>

Hi David,

Thanks for replying!

On Thu, Oct 15, 2020 at 08:06:46AM +1000, David Holmes wrote:
> The mardown source for the manpages is not currently open-source but is
> maintained by Oracle.

Thanks for confirming. Do you know whether there's any plans for this to
change, or whether a request to Open Source these would have much chance
of being accepted?

Backporting the build-script changes to generate the nroff files is
obviously less appealing without the markdown sources too. Another
advantage (to Oracle, and everyone) of opening the source documents
would be opening the possibility of third parties contributing doc fixes
more easily.


Best wishes,

-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From david.holmes at oracle.com  Tue Oct 20 01:57:52 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 11:57:52 +1000
Subject: markdown source for manpages in the jdk source tree
In-Reply-To: <20201019095743.qkicfkp7wi7sgw57@qusp>
References: <20201012134851.g6k6fhdmpw7osa5p@qusp>
 <e52f5be2-54f1-c58b-21d7-2117aba070b6@oracle.com>
 <20201019095743.qkicfkp7wi7sgw57@qusp>
Message-ID: <95a4af2a-3d4a-d701-cf49-a0d3fb69a264@oracle.com>

Hi Jonathan,

On 19/10/2020 7:57 pm, Jonathan Dowland wrote:
> Hi David,
> 
> Thanks for replying!
> 
> On Thu, Oct 15, 2020 at 08:06:46AM +1000, David Holmes wrote:
>> The mardown source for the manpages is not currently open-source but is
>> maintained by Oracle.
> 
> Thanks for confirming. Do you know whether there's any plans for this to
> change, or whether a request to Open Source these would have much chance
> of being accepted?

We are looking into it, but it may take a while.

> Backporting the build-script changes to generate the nroff files is
> obviously less appealing without the markdown sources too. Another
> advantage (to Oracle, and everyone) of opening the source documents
> would be opening the possibility of third parties contributing doc fixes
> more easily.

Anyone can contribute via the nroff files. We just take any such changes 
and apply them to the markdown sources and regenerate.

Cheers,
David
-----

> 
> Best wishes,
> 

From mark.reinhold at oracle.com  Tue Oct 20 23:08:30 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 20 Oct 2020 16:08:30 -0700 (PDT)
Subject: JEP proposed to target JDK 16: 380: Unix-Domain Socket Channels
Message-ID: <20201020230830.781A33C666F@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  380: Unix-Domain Socket Channels
       https://openjdk.java.net/jeps/380

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 27 October, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Tue Oct 20 23:12:05 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 20 Oct 2020 16:12:05 -0700 (PDT)
Subject: JEP proposed to target JDK 16: 395: Records
Message-ID: <20201020231206.04BC53C6677@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  395: Records
       https://openjdk.java.net/jeps/395

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 27 October, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From stefan.johansson at oracle.com  Wed Oct 21 08:44:33 2020
From: stefan.johansson at oracle.com (stefan.johansson at oracle.com)
Date: Wed, 21 Oct 2020 10:44:33 +0200
Subject: New JDK Committer: Ivan Walulya (Fixed voting end date)
In-Reply-To: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
Message-ID: <1c336a3c-a98f-851d-c9ab-1c5b1c633e24@oracle.com>

Vote: yes

On 2020-10-08 11:38, Thomas Schatzl wrote:
> Hi,
> 
> I hereby nominate Ivan Walulya (iwalulya) to JDK Committer.
> 
> Ivan has been contributing to the OpenJDK project since February 2020.
> 
> He already contributed 14 fixes to the JDK project [3], ranging from 
> small fixes to quite tricky fixes and changes to G1 prediction heuristics.
> 
> Votes are due by 12:00 UTC October 23th, 2020.
> 
> Only current JDK Committers [1] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this
> mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
>  ? Thomas
> 
> -
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> [3] $ git log --oneline --author "Ivan Walulya"
> 
> 86a16400bd9 8244505: G1 pause time ratio calculation does not consider 
> Remark/Cleanup? pauses
> 4ac6934965a 8253232: G1Analytics::compute_pause_time_ratios() uses wrong 
> pause times in calculation
> 63a5a129496 8252658: G1: Do not consider G1HeapWastePercent during 
> region selection within a gc
> 553f3b14974 (tag: jdk-16+14) 8252303: G1MMUTrackerQueue::when_sec skip 
> queue iteration on max_gc_time pause time
> 31479a0d480 8244752: Enable Linux support for multiple huge page sizes 
> -XX:LargePageSizeInBytes
> 59521b03894 8209162: Page size selection does not always select optimal 
> page size
> 5a68ba13395 8240591: G1HeapSizingPolicy attempts to compute 
> expansion_amount even when at full capacity
> d49eb0d9a7a 8240668: G1 list of all PerRegionTable does not have to be a 
> double linkedlist any more
> f0cd9dd5c45 8240592: HeapRegionManager::rebuild_free_list logs 0s for 
> the estimated free regions before
> 25d2db06c42 8240589: OtherRegionsTable::_num_occupied not updated correctly
> 976473690b9 8216975: Using ForceNUMA does not disable adaptive sizing 
> with parallel gc
> edd28610d55 8233220: Space::_par_seq_tasks is unused after CMS removal
> 41f962d7845 8232689: Remove ParCompactionManager::Action enum
> 6f6b4c0ef95 8232686: Turn parallel gc develop tracing flags into unified 
> logging
> 
> 

From mark.reinhold at oracle.com  Fri Oct 23 22:15:25 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 23 Oct 2020 15:15:25 -0700 (PDT)
Subject: JEP proposed to target JDK 16: 392: Packaging Tool
Message-ID: <20201023221525.F3CB83C6F76@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  392: Packaging Tool
       https://openjdk.java.net/jeps/392

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Friday, 30 October, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Fri Oct 23 22:19:30 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 23 Oct 2020 15:19:30 -0700
Subject: Proposed schedule for JDK 16
In-Reply-To: <20201013173733.880562818@eggemoggin.niobe.net>
References: <20201013173733.880562818@eggemoggin.niobe.net>
Message-ID: <20201023151930.411615078@eggemoggin.niobe.net>

2020/10/13 17:37:33 -0700, mark.reinhold at oracle.com:
> With JDK 15 out the door, here?s a proposed schedule for JDK 16:
> 
>   2020/12/10  Rampdown Phase One
>   2021/01/14  Rampdown Phase Two
>   2021/02/04  Initial Release Candidate
>   2021/02/18  Final Release Candidate
>   2021/03/16  General Availability
> 
> The phases are defined in JEP 3 [1].
> 
> Comments on this proposal from JDK Committers and Reviewers [2] are
> welcome, as are reasoned objections.  If no such objections are raised
> by 23:00 UTC next Wednesday, 21 October, or if they?re raised and
> satisfactorily answered, then per the JEP 2.0 process proposal [3]
> this will be the schedule for JDK 16.

Hearing no objections, this is now the schedule for JDK 16.

- Mark

From mark.reinhold at oracle.com  Mon Oct 26 23:14:09 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 26 Oct 2020 16:14:09 -0700 (PDT)
Subject: JEP proposed to target JDK 16: 393: Foreign-Memory Access API (Third
 Incubator)
Message-ID: <20201026231409.733593C72FD@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  393: Foreign-Memory Access API (Third Incubator)
       https://openjdk.java.net/jeps/393

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Monday, 2 November, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From thomas.schatzl at oracle.com  Tue Oct 27 08:55:58 2020
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 27 Oct 2020 09:55:58 +0100
Subject: Result: New JDK Committer: Ivan Walulya
In-Reply-To: <1c336a3c-a98f-851d-c9ab-1c5b1c633e24@oracle.com>
References: <66ebea16-3784-4a17-6840-ebf96d95277d@oracle.com>
 <1c336a3c-a98f-851d-c9ab-1c5b1c633e24@oracle.com>
Message-ID: <d9489a29-7c6b-e548-9acf-b0299df9479f@oracle.com>

Hello,

   voting for Ivan Walulya (iwalulya) [1] is now closed.

Yes: 18
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Best regards,
   Thomas Schatzl

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-October/004840.html

From mark.reinhold at oracle.com  Tue Oct 27 17:34:28 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 27 Oct 2020 10:34:28 -0700 (PDT)
Subject: New candidate JEP: 396: Strongly Encapsulate JDK Internals by Default
Message-ID: <20201027173428.717863C750B@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/396

- Mark

From mark.reinhold at oracle.com  Tue Oct 27 22:51:59 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 27 Oct 2020 15:51:59 -0700 (PDT)
Subject: JEP proposed to target JDK 16: 394: Pattern Matching for instanceof
Message-ID: <20201027225159.4BA4A3C7583@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 16:

  394: Pattern Matching for instanceof
       https://openjdk.java.net/jeps/394

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:59 UTC on Tuesday, 3 November, or if they?re raised
and then satisfactorily answered, then per the JEP 2.0 process proposal
[2] I?ll target this JEP to JDK 16.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Wed Oct 28 16:55:24 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 28 Oct 2020 09:55:24 -0700
Subject: JEP proposed to target JDK 16: 380: Unix-Domain Socket Channels
In-Reply-To: <20201020230830.781A33C666F@eggemoggin.niobe.net>
References: <20201020230830.781A33C666F@eggemoggin.niobe.net>
Message-ID: <20201028095524.587773082@eggemoggin.niobe.net>

2020/10/20 16:08:30 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   380: Unix-Domain Socket Channels
>        https://openjdk.java.net/jeps/380
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Tuesday, 27 October, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From mark.reinhold at oracle.com  Wed Oct 28 16:55:42 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 28 Oct 2020 09:55:42 -0700
Subject: JEP proposed to target JDK 16: 395: Records
In-Reply-To: <20201020231206.04BC53C6677@eggemoggin.niobe.net>
References: <20201020231206.04BC53C6677@eggemoggin.niobe.net>
Message-ID: <20201028095542.823407538@eggemoggin.niobe.net>

2020/10/20 16:12:05 -0700, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   395: Records
>        https://openjdk.java.net/jeps/395
> 
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:59 UTC on Tuesday, 27 October, or if they?re raised
> and then satisfactorily answered, then per the JEP 2.0 process proposal
> [2] I?ll target this JEP to JDK 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From mark.reinhold at oracle.com  Thu Oct 29 23:29:17 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 29 Oct 2020 16:29:17 -0700 (PDT)
Subject: New candidate JEP: 397: Sealed Classes (Second Preview)
Message-ID: <20201029232917.13FB43C7B38@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/397

  Summary: Enhance the Java programming language with sealed classes and
  interfaces. Sealed classes and interfaces restrict which other classes
  or interfaces may extend or implement them.

- Mark

From alanb at openjdk.java.net  Sat Oct 31 15:58:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 31 Oct 2020 15:58:54 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
Message-ID: <IszYOjN7ScHGcDzfZGTxpDByoVKqCTXkce5cCZw0TFA=.23a94c40-59c7-4247-b015-09ac3279de9a@github.com>

On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
> 
> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
> I think we should remove this code as well and the related tests for it.

Please start a discussion on core-libs-dev before proposing this patch.

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

PR: https://git.openjdk.java.net/jdk/pull/978

From kcr at openjdk.java.net  Sat Oct 31 16:12:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 31 Oct 2020 16:12:53 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
 <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>
Message-ID: <v8Porjpc9cWId3vbEY1VF-FeSvtXhfiW-cADU7cN2xY=.68e93fd6-05d8-4bd8-a4c1-2373b1f20122@github.com>

On Sat, 31 Oct 2020 16:09:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
>> 
>> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
>> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
>> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
>> I think we should remove this code as well and the related tests for it.
>
> This will cause a regression in behavior. It will break existing JavaFX applications that do not have a main program. It could also break applications that create or use certain JavaFX objects in the class initializer of their JavaFX application.
> 
> There was [some initial discussion](https://bugs.openjdk.java.net/browse/JDK-8202553?focusedCommentId=14176584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176584) around doing this as a follow-on to the removal of JavaFX from JDK 11, but if it is to be done, it needs to be discussed first. It would need to be done using a process similar to deprecation-for-removal. We would need to make changes in the JDK and/or JavaFX to warn about this in one release, and then remove it in the following. A CSR would be needed for both steps.
> 
> I note that while I disagree with the rationale described in [JDK-8248122](https://bugs.openjdk.java.net/browse/JDK-8248122) for making this change, I am not necessarily opposed to the change itself.

This also needs to be discussed on the openjfx-dev mailing list, since it will have behavioral compatibility implications for JavaFX.

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

PR: https://git.openjdk.java.net/jdk/pull/978

From kcr at openjdk.java.net  Sat Oct 31 16:12:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 31 Oct 2020 16:12:53 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
Message-ID: <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>

On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
> 
> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
> I think we should remove this code as well and the related tests for it.

This will cause a regression in behavior. It will break existing JavaFX applications that do not have a main program. It could also break applications that create or use certain JavaFX objects in the class initializer of their JavaFX application.

There was [some initial discussion](https://bugs.openjdk.java.net/browse/JDK-8202553?focusedCommentId=14176584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176584) around doing this as a follow-on to the removal of JavaFX from JDK 11, but if it is to be done, it needs to be discussed first. It would need to be done using a process similar to deprecation-for-removal. We would need to make changes in the JDK and/or JavaFX to warn about this in one release, and then remove it in the following. A CSR would be needed for both steps.

I note that while I disagree with the rationale described in [JDK-8248122](https://bugs.openjdk.java.net/browse/JDK-8248122) for making this change, I am not necessarily opposed to the change itself.

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

Changes requested by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/978

From prr at openjdk.java.net  Sat Oct 31 20:46:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 31 Oct 2020 20:46:55 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <v8Porjpc9cWId3vbEY1VF-FeSvtXhfiW-cADU7cN2xY=.68e93fd6-05d8-4bd8-a4c1-2373b1f20122@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
 <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>
 <v8Porjpc9cWId3vbEY1VF-FeSvtXhfiW-cADU7cN2xY=.68e93fd6-05d8-4bd8-a4c1-2373b1f20122@github.com>
Message-ID: <k4aYsZ_h6lzHhtGZDDcytO9zT0VOk-wkM6GUmPvzmfg=.e3e28d98-b75a-4a18-8060-84a41d4ba712@github.com>

On Sat, 31 Oct 2020 16:10:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This will cause a regression in behavior. It will break existing JavaFX applications that do not have a main program. It could also break applications that create or use certain JavaFX objects in the class initializer of their JavaFX application.
>> 
>> There was [some initial discussion](https://bugs.openjdk.java.net/browse/JDK-8202553?focusedCommentId=14176584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176584) around doing this as a follow-on to the removal of JavaFX from JDK 11, but if it is to be done, it needs to be discussed first. It would need to be done using a process similar to deprecation-for-removal. We would need to make changes in the JDK and/or JavaFX to warn about this in one release, and then remove it in the following. A CSR would be needed for both steps.
>> 
>> I note that while I disagree with the rationale described in [JDK-8248122](https://bugs.openjdk.java.net/browse/JDK-8248122) for making this change, I am not necessarily opposed to the change itself.
>
> This also needs to be discussed on the openjfx-dev mailing list, since it will have behavioral compatibility implications for JavaFX.

Indeed this is very much of out the blue and the pre-existence of a bug report discussing this does not mean it
has been accepted to be done .. 

And launcher changes need to be done carefully. I would expect them to come from someone who has a long history of contributions in this area and has had extensive discussions with stakeholders before moving on to code ..

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

PR: https://git.openjdk.java.net/jdk/pull/978