From christoph.langer at sap.com Mon Jun 3 06:45:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 3 Jun 2019 06:45:17 +0000 Subject: [11u] RFR (S): 8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize Message-ID: Hi, please help reviewing a backport to OpenJDK 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8139965 11u-webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139965.11u/ The patch did apply, however, it contained changes to testcase test/jdk/com/sun/jndi/ldap/LdapDnsProviderTest.java. The testcase is not part of JDK11u and its backport is also impossible as it belongs to an enhancement with associated CSR for JDK12 (JDK-8160768 [0]). The test update hasn't been part of the original review thread [1], so I think it is ok to go with the change as suggested in the webrev. Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8160768 [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055115.html From goetz.lindenmaier at sap.com Mon Jun 3 07:04:40 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 Jun 2019 07:04:40 +0000 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> Message-ID: Hi Andrew, > >>> Yes, there is some overhead, it does not make things more > >>> simple. You could delegate some tasks. > > But that won't reduce the overhead: all it will do is spread it out. Some simple steps, like switching from 11.0.n to 11.0.n+1 require several people. This is overhead that would go away if all is in one hand. I.e., if I could ping ops for the JBS update, this would save the indirection of asking you to do that. This again might reduce the time the repo is closed, and thus the chance for wrong pushes. > >>> E.g., > >>> * I would volunteer to trigger the update of the JBS version > >>> For 11 whenever needed. > > > > Do you mean the hgupdater changes via ops? I think usually both 8u & 11u > > should be handled at the same time to minimise such updates. > > But how? It's not as if the projects are perfectly synchronized. Sure, > if they happen to need changing at the same time, then we can do so. > > > I'm not > > sure if anyone but the lead would be accepted for such a request. > > I'm sure I can delegate anyone to do it. > > >>> * You could allow to push the version bump without > >>> jdk11u-fix-yes tag. It's obvious we need it. > > > > That makes sense to me, given we have no such approval process for the > > equivalent process of tagging the repository. > > Yes. Thanks. I'll skip the tagging next time. > > I've been thinking about this for 8u too [0] and, as both 8u & 11u allow > > multiple changesets to use the same bug ID, I think keeping such bumps > > under the same bug ID is a better idea than creating numerous bug IDs > > just for version updates. That also elegantly solves the approval > > process issue without the need for exceptional cases. > > > >>> Further, I would propose that we exclude all changes Oracle > >>> pushes to their 11.0.x from the tagging if pushed to > >>> the open 11.0.x (same x!). > >>> They have already been judged to be good for downport by Oracle. > >>> The "Fix Request" comment should be added to the change > >>> nevertheless. This way one can know that a change is being > >>> worked on. Maybe we should note in the bug that it is a downport > >>> that went to Oracle's 11.0.x, so it's clear why it is not tagged. > > > > I strongly disagree with this. It would amount to most of the changes > > not going through the approval process. > > > > I can see that with 11u, in its present state, this may mean a lot of > > rubber stamping of clean backports, because 11u has not diverged much > > from trunk. However, with 8u, the backported patch can frequently be > > quite different, and approval should be of that reviewed patch, not > > based on a decision at Oracle we know nothing about. > > The backported patch, if different from the patch applied at head, > will have to be reviewed. That's when the code walkthrough and the > impact should be assessed. On the other hand, approval says that, in > principle at least, this change is one that we want in the release > branch. > > > I expect, with time, 11u will diverge in a similar way and so the > > approval process will be more involved. I definitely think the solution > > here is more hands on deck, not effectively removing the process altogether. > > > >> Those seem good suggestions to me. I also think that you could > >> extend the group of maintainers, that is, people who can approve > >> backports. Andrew (Hughes) is already listed for 8u but 11u could > >> also use additional approvers. However, if you do that, you should > >> give some rules and criteria that the approvers have to follow. > > Definitely, yes. The thing holding me back from appointing more > maintainers, still, is that I perceive a lack of consensus about the > criteria by which a backport should be judged. I personally would be > strict about this: serious bugs and regressions, plus perhaps some > important performance improvements. However, there seems to be a > general sentiment that we don't want to diverge from Oracle, so some > pretty trivial backports have been approved. Personally I think the approval for one Java version should be in one hand (excluding substitute for absences) to make sure it remains consistent what kind of changes are permitted. If the changes downported by Oracle are excluded from approval, it should not be that many anymore. And developers should be patient to wait for weekly approvals. > To some extent I accept the "don't diverge" reasoning because feature > differences between OpenJDK and Oracle are to be avoided if possible: > we don't want to confuser our users unnecessarily. > > > I'm open to doing 11u as well. I often have to remind myself I can't > > do that one when something comes up for both 8 & 11. I also think we > > should have at least a third maintainer on both projects, ideally > > from outside Red Hat. > > > > The primary things I look at for approval is the potential effect it > > has. Test cases are pretty unproblematic as are arch-specific > > changes coming from those maintaining that architecture. I'm more > > critical of general changes and try to ensure that there's nothing > > in there that will alter API compatibility. > > This is a good start. If we can agree what criteria we should apply > when approving a backport then we can share the maintainer's role. Yes, makes sense. But between maintaining an architecture and altering the API there is a huge gap ... Best regards, Goetz. > > Also, ensuring the correct process is followed ends up being part of > > approval, so e.g. I will ask for a review if one isn't listed and > > seems needed, and other such sanity checks. > > That imposes a strict ordering: review first, then approval. I think > that approval and review can run in parallel: we don't want to fully > review every backport patch twice. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 3 08:52:35 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 3 Jun 2019 09:52:35 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> Message-ID: <95be6814-38b6-52b7-5b88-e7616e4f80ba@redhat.com> On 6/3/19 8:04 AM, Lindenmaier, Goetz wrote: > > Some simple steps, like switching from 11.0.n to 11.0.n+1 require > several people. This is overhead that would go away if all is > in one hand. I.e., if I could ping ops for the JBS update, this > would save the indirection of asking you to do that. This again > might reduce the time the repo is closed, and thus the > chance for wrong pushes. I'm happy with that. >>>> Those seem good suggestions to me. I also think that you could >>>> extend the group of maintainers, that is, people who can approve >>>> backports. Andrew (Hughes) is already listed for 8u but 11u could >>>> also use additional approvers. However, if you do that, you should >>>> give some rules and criteria that the approvers have to follow. >> >> Definitely, yes. The thing holding me back from appointing more >> maintainers, still, is that I perceive a lack of consensus about the >> criteria by which a backport should be judged. I personally would be >> strict about this: serious bugs and regressions, plus perhaps some >> important performance improvements. However, there seems to be a >> general sentiment that we don't want to diverge from Oracle, so some >> pretty trivial backports have been approved. > > Personally I think the approval for one Java version should > be in one hand (excluding substitute for absences) to make > sure it remains consistent what kind of changes are permitted. > If the changes downported by Oracle are excluded from approval, > it should not be that many anymore. > And developers should be patient to wait for weekly approvals. I think I get your point. The problem is that these two goals are in opposition: 1. Preserve stability and prefer safety by minimizing potentially-breaking backport patches. 2. Keep in step with Oracle. I've been favouring 2. There are good reasons for this, in particular that many users are now moving to OpenJDK from Oracle's proprietary binaries, and those users want idenatial behaviour. There's also the guidelines in https://openjdk.java.net/projects/jdk6/: Changes allowable within the Java SE 6 specification may still be rejected for inclusion in OpenJDK 6 if the behavioral compatibility risk is judged as too large. Behavioral compatibility concerns implementation properties of the JDK. Clients of the JDK can knowingly or unknowingly come to rely upon implementation- specification behaviors not guaranteed by the specification and care should be taken to not break such applications needlessly. In contrast, if a change is appropriate for every other JDK release train, it is generally appropriate for OpenJDK 6 too. Examples of such universal changes include security fixes and time zone information updates. With the above caveats, bug fixes in JDK 7 that do not involve specification changes have presumptive validity for OpenJDK 6. That is, by default such fixes are assumed to be applicable to OpenJDK 6, especially if having "soaked" in JDK 7 for a time without incident. >>> I'm open to doing 11u as well. I often have to remind myself I can't >>> do that one when something comes up for both 8 & 11. I also think we >>> should have at least a third maintainer on both projects, ideally >>> from outside Red Hat. >>> >>> The primary things I look at for approval is the potential effect it >>> has. Test cases are pretty unproblematic as are arch-specific >>> changes coming from those maintaining that architecture. I'm more >>> critical of general changes and try to ensure that there's nothing >>> in there that will alter API compatibility. >> >> This is a good start. If we can agree what criteria we should apply >> when approving a backport then we can share the maintainer's role. > > Yes, makes sense. But between maintaining an architecture and > altering the API there is a huge gap ... True, but that's what the CSR process is for. I'd like the guidelines to be clear enough that, for most patches, the decision would be the same regardless of who did the approval. I accept that there are judgment calls to be made sometimes, but these should be based on a common understanding. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From goetz.lindenmaier at sap.com Mon Jun 3 09:56:41 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 Jun 2019 09:56:41 +0000 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <95be6814-38b6-52b7-5b88-e7616e4f80ba@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> <95be6814-38b6-52b7-5b88-e7616e4f80ba@redhat.com> Message-ID: Hi Andrew, > On 6/3/19 8:04 AM, Lindenmaier, Goetz wrote: > > > > Some simple steps, like switching from 11.0.n to 11.0.n+1 require > > several people. This is overhead that would go away if all is > > in one hand. I.e., if I could ping ops for the JBS update, this > > would save the indirection of asking you to do that. This again > > might reduce the time the repo is closed, and thus the > > chance for wrong pushes. > > I'm happy with that. Thanks! > > Personally I think the approval for one Java version should > > be in one hand (excluding substitute for absences) to make > > sure it remains consistent what kind of changes are permitted. > > If the changes downported by Oracle are excluded from approval, > > it should not be that many anymore. > > And developers should be patient to wait for weekly approvals. > > I think I get your point. > > The problem is that these two goals are in opposition: > > 1. Preserve stability and prefer safety by minimizing > potentially-breaking backport patches. > > 2. Keep in step with Oracle. > > I've been favouring 2. There are good reasons for this, in particular > that many users are now moving to OpenJDK from Oracle's proprietary > binaries, and those users want idenatial behaviour. Yes, I also think that all changes Oracle pushes to 11.0.n should be pushed to the open 11.0.n, too. This assures identical behavior, at least open 11 will not stay behind. And I don't think this will affect stability. Oracle is doing a very good job at testing, and we will see potential fixes pushed by them. I rather think this improves stability. Giving this simple rule, we don't need to tag them with jdk11u-fix-request. But we need additional changes. Andrew Hughes mentioned the architecture changes. Other changes might be interesting for the community that Oracle does not downport. For these changes we need the approval via jdk11u-fix-request etc. and we need guidelines. But we first need guidelines for developers what to consider for downporting. If you want to keep open 11 very close to Oracle's 11, these guidelines must be very strict. If you want to allow 11 to evolve past Oracle's 11, they can be less strict. Once we have such guidelines, we can think about the guidelines for delegating the approval process. > There's also the guidelines in https://openjdk.java.net/projects/jdk6/: > > Changes allowable within the Java SE 6 specification may still be > rejected for inclusion in OpenJDK 6 if the behavioral compatibility > risk is judged as too large. Behavioral compatibility concerns > implementation properties of the JDK. Clients of the JDK can > knowingly or unknowingly come to rely upon implementation- > specification behaviors not guaranteed by the specification and > care should be taken to not break such applications needlessly. In > contrast, if a change is appropriate for every other JDK release > train, it is generally appropriate for OpenJDK 6 too. Examples of > such universal changes include security fixes and time zone > information updates. > > With the above caveats, bug fixes in JDK 7 that do not involve > specification changes have presumptive validity for OpenJDK 6. That > is, by default such fixes are assumed to be applicable to OpenJDK > 6, especially if having "soaked" in JDK 7 for a time without > incident. This description makes completely sense to me. Nevertheless, for example JFR is downported to 8, which breaks this rule. And I also think it makes sense to make an exemption for JFR. I guess these are the judgement calls you talk about below. > >>> I'm open to doing 11u as well. I often have to remind myself I can't > >>> do that one when something comes up for both 8 & 11. I also think we > >>> should have at least a third maintainer on both projects, ideally > >>> from outside Red Hat. I would be fine with Andrew Hughes also approving jdk11 changes. > >>> The primary things I look at for approval is the potential effect it > >>> has. Test cases are pretty unproblematic as are arch-specific > >>> changes coming from those maintaining that architecture. I'm more > >>> critical of general changes and try to ensure that there's nothing > >>> in there that will alter API compatibility. > >> > >> This is a good start. If we can agree what criteria we should apply > >> when approving a backport then we can share the maintainer's role. > > > > Yes, makes sense. But between maintaining an architecture and > > altering the API there is a huge gap ... > > True, but that's what the CSR process is for. > > I'd like the guidelines to be clear enough that, for most patches, the > decision would be the same regardless of who did the approval. > I accept that there are judgment calls to be made sometimes, but these > should be based on a common understanding. Best regards, Goetz. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Jun 3 14:49:56 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 3 Jun 2019 15:49:56 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> Message-ID: <50b6a776-0bcc-a3b2-35e7-48e043765a21@redhat.com> On 31/05/2019 18:25, Andrew Haley wrote: > On 5/31/19 5:44 PM, Andrew John Hughes wrote: >> On 30/05/2019 22:56, Langer, Christoph wrote: >>> Hi, >>> >>>>> The level of bureaucratic overhead in these projects is getting absurd. >>>> We're >>>>> going to have to do something about it before we all drown. >>>> >>>> Yes, there is some overhead, it does not make things more >>>> simple. You could delegate some tasks. > > But that won't reduce the overhead: all it will do is spread it out. > >>>> E.g., >>>> * I would volunteer to trigger the update of the JBS version >>>> For 11 whenever needed. >> >> Do you mean the hgupdater changes via ops? I think usually both 8u & 11u >> should be handled at the same time to minimise such updates. > > But how? It's not as if the projects are perfectly synchronized. Sure, > if they happen to need changing at the same time, then we can do so. > Well, rampdown and release are the two points at which changes need to be made, and these are close, if not the same (barring the delay for 8u in this cycle) [0] [1] snip... > > That imposes a strict ordering: review first, then approval. I think > that approval and review can run in parallel: we don't want to fully > review every backport patch twice. > The Oracle process I'm familiar with is sequential: "Additionally the comment should note whether the patch from the JDK Project applies cleanly. If not, the fix MUST be codereviewed in public and a public url to that review MUST be provided in the comment." [2] Under 8u, the approval e-mail used to refer to the review thread. I'm not suggesting reviewing every backport twice, but I also don't see how you can approve something if you don't know what you're approving. Keeping them sequential simplifies the process, because any fix that is approved has then also been reviewed, and so is only waiting on push. If the review begins or continues after approval, you end up with approved bugs that are not yet ready for push. This has been causing confusion for me with our "Approved requests without push" filter [3], with bugs listed in there that weren't even posted for review at one point. I do suspect my perspective may be clouded by the fact I end up doing both review & approval for most 8u patches. The experience may be different if you're looking it with fresh eyes purely from the view of approval. [0] https://wiki.openjdk.java.net/display/jdk8u/Main [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u [2] https://openjdk.java.net/projects/jdk-updates/approval.html [3] https://bugs.openjdk.java.net/browse/JDK-8225065?filter=36427 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Mon Jun 3 17:40:20 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 3 Jun 2019 18:40:20 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <50b6a776-0bcc-a3b2-35e7-48e043765a21@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> <50b6a776-0bcc-a3b2-35e7-48e043765a21@redhat.com> Message-ID: <6d627bba-fcca-d7ef-06f0-c0792d2a25de@redhat.com> On 6/3/19 3:49 PM, Andrew John Hughes wrote: > > > On 31/05/2019 18:25, Andrew Haley wrote: >> On 5/31/19 5:44 PM, Andrew John Hughes wrote: >>> On 30/05/2019 22:56, Langer, Christoph wrote: >>>> Hi, >>>> >>>>>> The level of bureaucratic overhead in these projects is getting absurd. >>>>> We're >>>>>> going to have to do something about it before we all drown. >>>>> >>>>> Yes, there is some overhead, it does not make things more >>>>> simple. You could delegate some tasks. >> >> But that won't reduce the overhead: all it will do is spread it out. >> >>>>> E.g., >>>>> * I would volunteer to trigger the update of the JBS version >>>>> For 11 whenever needed. >>> >>> Do you mean the hgupdater changes via ops? I think usually both 8u & 11u >>> should be handled at the same time to minimise such updates. >> >> But how? It's not as if the projects are perfectly synchronized. Sure, >> if they happen to need changing at the same time, then we can do so. > > Well, rampdown and release are the two points at which changes need to > be made, and these are close, if not the same (barring the delay for 8u > in this cycle) [0] [1] Well, yeah. If the two coincide we can do them together. > snip... > >> >> That imposes a strict ordering: review first, then approval. I think >> that approval and review can run in parallel: we don't want to fully >> review every backport patch twice. > > The Oracle process I'm familiar with is sequential: > > "Additionally the comment should note whether the patch from the JDK > Project applies cleanly. If not, the fix MUST be codereviewed in public > and a public url to that review MUST be provided in the comment." [2] > > Under 8u, the approval e-mail used to refer to the review thread. > > I'm not suggesting reviewing every backport twice, but I also don't see > how you can approve something if you don't know what you're approving. Maybe, but the patch itself has already been reviewed: all you're approving is an already-reviewed patch. So maybe the patch itself is interesting, but maybe not. The question for the approver is whether this patch is worth doing, not whether it's a good patch: we already know it is. > Keeping them sequential simplifies the process, because any fix that is > approved has then also been reviewed, and so is only waiting on push. > > If the review begins or continues after approval, you end up with > approved bugs that are not yet ready for push. This has been causing > confusion for me with our "Approved requests without push" filter [3], > with bugs listed in there that weren't even posted for review at one point. That's a tooling problem IMO. > I do suspect my perspective may be clouded by the fact I end up doing > both review & approval for most 8u patches. I think so. These are different tasks,and having one person doing both at once, essential as a single job, makes a nonsense of the separation. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Jun 3 19:32:38 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 3 Jun 2019 19:32:38 +0000 Subject: [11u] RFR (S): 8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: References: Message-ID: <732941BF-49ED-4F67-8CD9-ED7A2AA77149@amazon.com> I agree, looks fine. Paul ?On 6/2/19, 11:46 PM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi, please help reviewing a backport to OpenJDK 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8139965 11u-webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139965.11u/ The patch did apply, however, it contained changes to testcase test/jdk/com/sun/jndi/ldap/LdapDnsProviderTest.java. The testcase is not part of JDK11u and its backport is also impossible as it belongs to an enhancement with associated CSR for JDK12 (JDK-8160768 [0]). The test update hasn't been part of the original review thread [1], so I think it is ok to go with the change as suggested in the webrev. Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8160768 [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055115.html From christoph.langer at sap.com Tue Jun 4 06:48:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 4 Jun 2019 06:48:39 +0000 Subject: [11u] RFR (S): 8139965: Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <732941BF-49ED-4F67-8CD9-ED7A2AA77149@amazon.com> References: <732941BF-49ED-4F67-8CD9-ED7A2AA77149@amazon.com> Message-ID: Thanks Paul. > -----Original Message----- > From: Hohensee, Paul > Sent: Montag, 3. Juni 2019 21:33 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: Java Core Libs > Subject: Re: [11u] RFR (S): 8139965: Hang seen when using > com.sun.jndi.ldap.search.replyQueueSize > > I agree, looks fine. > > Paul > > ?On 6/2/19, 11:46 PM, "jdk-updates-dev on behalf of Langer, Christoph" updates-dev-bounces at openjdk.java.net on behalf of > christoph.langer at sap.com> wrote: > > Hi, > > please help reviewing a backport to OpenJDK 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139965 > 11u-webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139965.11u/ > > The patch did apply, however, it contained changes to testcase > test/jdk/com/sun/jndi/ldap/LdapDnsProviderTest.java. The testcase is not > part of JDK11u and its backport is also impossible as it belongs to an > enhancement with associated CSR for JDK12 (JDK-8160768 [0]). The test > update hasn't been part of the original review thread [1], so I think it is ok to > go with the change as suggested in the webrev. > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8160768 > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018- > September/055115.html > From gnu.andrew at redhat.com Tue Jun 4 19:40:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 4 Jun 2019 20:40:36 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: <6d627bba-fcca-d7ef-06f0-c0792d2a25de@redhat.com> References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> <50b6a776-0bcc-a3b2-35e7-48e043765a21@redhat.com> <6d627bba-fcca-d7ef-06f0-c0792d2a25de@redhat.com> Message-ID: On 03/06/2019 18:40, Andrew Haley wrote: > On 6/3/19 3:49 PM, Andrew John Hughes wrote: >> > >> snip... >> >>> >>> That imposes a strict ordering: review first, then approval. I think >>> that approval and review can run in parallel: we don't want to fully >>> review every backport patch twice. >> >> The Oracle process I'm familiar with is sequential: >> >> "Additionally the comment should note whether the patch from the JDK >> Project applies cleanly. If not, the fix MUST be codereviewed in public >> and a public url to that review MUST be provided in the comment." [2] >> >> Under 8u, the approval e-mail used to refer to the review thread. >> >> I'm not suggesting reviewing every backport twice, but I also don't see >> how you can approve something if you don't know what you're approving. > > Maybe, but the patch itself has already been reviewed: all you're approving > is an already-reviewed patch. So maybe the patch itself is interesting, but > maybe not. The question for the approver is whether this patch is worth doing, > not whether it's a good patch: we already know it is. If the operations are proceeding sequentially, then yes, the patch has already been reviewed. If you allow approval to take place concurrently, then the review process may still be in progress or may not yet have started. To what extent is approval based on the idea and to what extent on the implementation? A concurrent approval process works if it is just approving the idea, but, in reality, it is the approval of a specific implementation which may differ from the version previously applied to other JDK versions and have different consequences in this new context. As examples, the backporting process may have to make significant alterations to the code changes, so as not to alter public API, or to the build & test changes, due to differences in those systems. The viability of those additional changes depends on the review of the backport, not the original patch. > >> Keeping them sequential simplifies the process, because any fix that is >> approved has then also been reviewed, and so is only waiting on push. >> >> If the review begins or continues after approval, you end up with >> approved bugs that are not yet ready for push. This has been causing >> confusion for me with our "Approved requests without push" filter [3], >> with bugs listed in there that weren't even posted for review at one point. > > That's a tooling problem IMO. > >> I do suspect my perspective may be clouded by the fact I end up doing >> both review & approval for most 8u patches. > > I think so. These are different tasks,and having one person doing both > at once, essential as a single job, makes a nonsense of the > separation. > This may be true, but I don't see an easy solution to either. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From jianglizhou at google.com Wed Jun 5 00:25:35 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 4 Jun 2019 17:25:35 -0700 Subject: redhat-openjdk labels in JIRA In-Reply-To: <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> References: <3487f33a-38ac-20a6-77fc-0156cd9895ea@redhat.com> <0fd14f22-5f2c-226b-6e6e-1518142a3cff@redhat.com> <98772301-3875-4A3D-A093-FBC0267ECD9B@oracle.com> <95c197b2-a3a1-eeb1-c9c3-974256c1e278@redhat.com> <0CC88C1D-CAA8-4CBE-8F22-DD90CA90E700@oracle.com> <1F71119B-868A-4064-B674-C2B36D6914BF@amazon.com> Message-ID: A bit late to the party :-), Google would also like to start tracking bugs/RFEs with "google-interest" label (communicated with Jesper in May) for the following two main purposes: - Backports that we are interested in tracking - Work for contributing into OpenJDK (most likely work would be done by Google in this case) Best regards, Jiangli On Mon, May 20, 2019 at 1:31 PM Hohensee, Paul wrote: > > Amazon would like to get in on the fun too. May we have an amazon-interest label please? :) > > Thanks, > > Paul > > ?On 5/17/19, 8:45 AM, "jdk-updates-dev on behalf of jesper.wilhelmsson at oracle.com" wrote: > > Done. > /Jesper > > > On 17 May 2019, at 16:53, Gil Tene wrote: > > > > Yes. thanks! > > > > Sent from my iPad > > > >> On May 16, 2019, at 11:15 AM, "jesper.wilhelmsson at oracle.com" wrote: > >> > >> The deed is done. > >> > >> Gil, do you want me to change the azul-openjdk labels as well? > >> /Jesper > >> > >>> On 16 May 2019, at 09:46, Aleksey Shipilev wrote: > >>> > >>> On 5/16/19 3:42 AM, jesper.wilhelmsson at oracle.com wrote: > >>>>> On 14 May 2019, at 11:49, Aleksey Shipilev wrote: > >>>>> Yeah, we are fine with bulk renaming "redhat-openjdk" to "redhat-interest". This would require tool > >>>>> adjustment here and there, but no serious process breakages are expected. If Jesper is willing to > >>>>> help us with that, that would be perfect! > >>>> > >>>> I'll run the bulk update tomorrow unless you need to prepare something first. > >>> > >>> No, we don't have to prepare. Please run the bulk updater as you see fit. > >>> > >>> -Aleksey > >>> > >> > > > From gnu.andrew at redhat.com Wed Jun 5 02:41:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 5 Jun 2019 03:41:20 +0100 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <7fde0d06-5c86-6e53-a9d3-8b1d93fdae8f@redhat.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> <7fde0d06-5c86-6e53-a9d3-8b1d93fdae8f@redhat.com> Message-ID: On 03/06/2019 16:25, Andrew John Hughes wrote: > > > On 29/05/2019 18:53, Liu, Xin wrote: >> Thanks. Andrew. >> Let me know if you run into problem. >> >> Thanks, >> --lx >> >> >> ?On 5/29/19, 10:14 AM, "Andrew John Hughes" wrote: >> >> >> >> On 29/05/2019 06:03, Liu, Xin wrote: >> > Hi, Andrew, >> > >> > Thank you to for the feedbacks. In particular, you found the source of changes across multiple repositories! >> > I would rather not pull JDK-8054492. This commit focuses on one thing. >> > >> > Hi, Paul, >> > Andrew has reviewed the following 3 patches. The order matters. >> > I have verified them. Could you check them into 'jdk8u-dev'? >> > >> > 1/3 : https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ >> > 2/3: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev.02/ >> > 3/3: https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ >> > >> > Thanks, >> > --lx >> > >> > >> >> I'll push them for you. It'll give me a final chance to sanity check >> them and also co-ordinate with tagging for b05 today. >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> >> >> > > Thanks. I'm testing a build with 8059575 now before pushing. > > https://bugs.openjdk.java.net/browse/JDK-8222670 does need > jdk8u-fix-request adding, so I can approve. > > Thanks, > All three now pushed. Are you planning to request JDK-8222670 & JDK-8223537 for OpenJDK 11u for consistency? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Wed Jun 5 08:37:50 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 5 Jun 2019 09:37:50 +0100 Subject: jdk11u-dev is now switched to 11.0.5 In-Reply-To: References: <82b7dbfa-6b90-dfb8-496b-4267c47d60de@redhat.com> <34e195bf-9c8b-5133-86a5-b7a374876389@redhat.com> <9559ed45-2226-75fd-4b85-867d1a71895f@redhat.com> <50b6a776-0bcc-a3b2-35e7-48e043765a21@redhat.com> <6d627bba-fcca-d7ef-06f0-c0792d2a25de@redhat.com> Message-ID: <458c6174-7e9b-dd9f-adec-ea3de8bf8d3e@redhat.com> On 6/4/19 8:40 PM, Andrew John Hughes wrote: > > > On 03/06/2019 18:40, Andrew Haley wrote: >> On 6/3/19 3:49 PM, Andrew John Hughes wrote: >>> > >> >>> snip... >>> >>>> >>>> That imposes a strict ordering: review first, then approval. I think >>>> that approval and review can run in parallel: we don't want to fully >>>> review every backport patch twice. >>> >>> The Oracle process I'm familiar with is sequential: >>> >>> "Additionally the comment should note whether the patch from the JDK >>> Project applies cleanly. If not, the fix MUST be codereviewed in public >>> and a public url to that review MUST be provided in the comment." [2] >>> >>> Under 8u, the approval e-mail used to refer to the review thread. >>> >>> I'm not suggesting reviewing every backport twice, but I also don't see >>> how you can approve something if you don't know what you're approving. >> >> Maybe, but the patch itself has already been reviewed: all you're approving >> is an already-reviewed patch. So maybe the patch itself is interesting, but >> maybe not. The question for the approver is whether this patch is worth doing, >> not whether it's a good patch: we already know it is. > > If the operations are proceeding sequentially, then yes, the patch has > already been reviewed. > > If you allow approval to take place concurrently, then the review > process may still be in progress or may not yet have started. > > To what extent is approval based on the idea and to what extent on the > implementation? If it's reviewing the implementation, that's a second review. Which is fine if that's what we want do do. > A concurrent approval process works if it is just approving the > idea, but, in reality, it is the approval of a specific > implementation which may differ from the version previously applied > to other JDK versions and have different consequences in this new > context. > > As examples, the backporting process may have to make significant > alterations to the code changes, so as not to alter public API, or to > the build & test changes, due to differences in those systems. The > viability of those additional changes depends on the review of the > backport, not the original patch. Again, I say: that's what the review process is for. >>> Keeping them sequential simplifies the process, because any fix that is >>> approved has then also been reviewed, and so is only waiting on push. >>> >>> If the review begins or continues after approval, you end up with >>> approved bugs that are not yet ready for push. This has been causing >>> confusion for me with our "Approved requests without push" filter [3], >>> with bugs listed in there that weren't even posted for review at one point. >> >> That's a tooling problem IMO. >> >>> I do suspect my perspective may be clouded by the fact I end up doing >>> both review & approval for most 8u patches. >> >> I think so. These are different tasks,and having one person doing both >> at once, essential as a single job, makes a nonsense of the >> separation. > > This may be true, but I don't see an easy solution to either. Neither do I, but it seems pretty clear to me that the approval process in this case is not actually happening. There's a review, the approval box is ticked, and in it goes. Having said that: is there a problem to solve? Are we allowing broken or inappropriate patches through? I don't think so. If not, we're merely worrying about correctly following a process rather than ensuring the quality of OpenJDK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Jun 5 15:41:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 5 Jun 2019 16:41:12 +0100 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: <48EBAFE5-1981-4C65-9A03-E3B7F3F709FB@amazon.com> References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> <7fde0d06-5c86-6e53-a9d3-8b1d93fdae8f@redhat.com> <48EBAFE5-1981-4C65-9A03-E3B7F3F709FB@amazon.com> Message-ID: On 05/06/2019 06:35, Liu, Xin wrote: > Thanks. I have put jdk11u-fix-request to these 2 bugs. > It should be trivial. I will prepare a webrev for jdk11u. > > Thanks, > --lx > Thanks. 8u is indeed usually the hardest job, so congratulations on getting the fixes in there :) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From xxinliu at amazon.com Wed Jun 5 05:35:30 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 5 Jun 2019 05:35:30 +0000 Subject: [8u] RFR: Backport of JDK-8222670: pathological case of JIT recompilation and code cache bloat In-Reply-To: References: <29367C39-36D1-4D17-BEB0-7B7C9D590435@amazon.com> <7DE1A3A6-4BCA-4C35-B992-08281C7A6C8B@amazon.com> <50f562af-6061-73f9-e974-bb3820022c9b@redhat.com> <8167d8dc-3a13-98ad-079f-a859dbb958d2@redhat.com> <38125AA4-F3B5-4391-AFD9-60222EA8277D@amazon.com> <7fde0d06-5c86-6e53-a9d3-8b1d93fdae8f@redhat.com> Message-ID: <48EBAFE5-1981-4C65-9A03-E3B7F3F709FB@amazon.com> Thanks. I have put jdk11u-fix-request to these 2 bugs. It should be trivial. I will prepare a webrev for jdk11u. Thanks, --lx ?On 6/4/19, 7:42 PM, "Andrew John Hughes" wrote: On 03/06/2019 16:25, Andrew John Hughes wrote: > > > On 29/05/2019 18:53, Liu, Xin wrote: >> Thanks. Andrew. >> Let me know if you run into problem. >> >> Thanks, >> --lx >> >> >> ?On 5/29/19, 10:14 AM, "Andrew John Hughes" wrote: >> >> >> >> On 29/05/2019 06:03, Liu, Xin wrote: >> > Hi, Andrew, >> > >> > Thank you to for the feedbacks. In particular, you found the source of changes across multiple repositories! >> > I would rather not pull JDK-8054492. This commit focuses on one thing. >> > >> > Hi, Paul, >> > Andrew has reviewed the following 3 patches. The order matters. >> > I have verified them. Could you check them into 'jdk8u-dev'? >> > >> > 1/3 : https://cr.openjdk.java.net/~xliu/8059575/webrev.01/ >> > 2/3: https://cr.openjdk.java.net/~xliu/8222670/webrev.8u-dev.02/ >> > 3/3: https://cr.openjdk.java.net/~xliu/8223537/webrev.8u-dev/ >> > >> > Thanks, >> > --lx >> > >> > >> >> I'll push them for you. It'll give me a final chance to sanity check >> them and also co-ordinate with tagging for b05 today. >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> >> >> > > Thanks. I'm testing a build with 8059575 now before pushing. > > https://bugs.openjdk.java.net/browse/JDK-8222670 does need > jdk8u-fix-request adding, so I can approve. > > Thanks, > All three now pushed. Are you planning to request JDK-8222670 & JDK-8223537 for OpenJDK 11u for consistency? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From martin.doerr at sap.com Thu Jun 6 09:35:56 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 6 Jun 2019 09:35:56 +0000 Subject: [11u] RFR (Backport): 8177899: Tests fail due to code cache exhaustion on machines with many cores Message-ID: Hi, we noticed that jdk11u is also affected by https://bugs.openjdk.java.net/browse/JDK-8177899 The VM didn't come up on a SPARC machine due to too high upper limit of compiler threads leading to misconfigured code cache. Unfortunately, the original change does not apply cleanly and needs manual resolution. Original change: http://hg.openjdk.java.net/jdk/jdk/rev/0451e0a2f1f5 My backport: http://cr.openjdk.java.net/~mdoerr/8177899_code_cache/jdk11u/webrev.00/ Here's the complete list of what I had to integrate manually: compile.cpp: Does not apply cleanly because of conflict with JDK-8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Trivial to resolve: Original JDK-8177899 removes this part of JDK-8209594. We just need to take the new line: int size = C2Compiler::initial_code_buffer_size(const_size); compilationPolicy.cpp: Does not apply cleanly because neighboring hunk has changed: JDK-8214206: Fix for JDK-8213419 is broken on 32-bit Just need to insert code manually next to where log2_int was changed to log2_intptr. tieredThresholdPolicy.cpp: Does not apply cleanly because the file was renamed: JDK-8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy Change needs to get applied to simpleThresholdPolicy.cpp instead. Not difficult. Please review. I'm targeting to 11.0.5. Best regards, Martin From tobias.hartmann at oracle.com Tue Jun 11 10:23:09 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 11 Jun 2019 12:23:09 +0200 Subject: [11u] RFR (Backport): 8177899: Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: References: Message-ID: <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com> Hi Martin, this looks good to me. Best regards, Tobias On 06.06.19 11:35, Doerr, Martin wrote: > Hi, > > ? > > we noticed that jdk11u is also affected by > > https://bugs.openjdk.java.net/browse/JDK-8177899 > > ? > > The VM didn?t come up on a SPARC machine due to too high upper limit of compiler threads leading to > misconfigured code cache. > > ? > > Unfortunately, the original change does not apply cleanly and needs manual resolution. > > ? > > Original change: > > http://hg.openjdk.java.net/jdk/jdk/rev/0451e0a2f1f5 > > ? > > My backport: > > http://cr.openjdk.java.net/~mdoerr/8177899_code_cache/jdk11u/webrev.00/ > > ? > > Here?s the complete list of what I had to integrate manually: > > ? > > compile.cpp: Does not apply cleanly because of conflict with > > JDK-8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset > > Trivial to resolve: Original JDK-8177899 removes this part of JDK-8209594. > > We just need to take the new line: int size = C2Compiler::initial_code_buffer_size(const_size); > > ? > > compilationPolicy.cpp: Does not apply cleanly because neighboring hunk has changed: > > JDK-8214206: Fix for JDK-8213419 is broken on 32-bit > > Just need to insert code manually next to where log2_int was changed to log2_intptr. > > ? > > tieredThresholdPolicy.cpp: Does not apply cleanly because the file was renamed: > > JDK-8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy > > Change needs to get applied to simpleThresholdPolicy.cpp instead. Not difficult. > > ? > > Please review. I?m targeting to 11.0.5. > > ? > > Best regards, > > Martin > > ? > From martin.doerr at sap.com Tue Jun 11 10:27:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 11 Jun 2019 10:27:12 +0000 Subject: [11u] RFR (Backport): 8177899: Tests fail due to code cache exhaustion on machines with many cores In-Reply-To: <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com> References: <97caa47e-ca35-45f2-0af4-b417cbbd167d@oracle.com> Message-ID: Hi Tobias, thank you for the review. Best regards, Martin > -----Original Message----- > From: Tobias Hartmann > Sent: Dienstag, 11. Juni 2019 12:23 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net; Lindenmaier, Goetz > ; Schmidt, Lutz ; > Volker Simonis (volker.simonis at gmail.com) > Subject: Re: [11u] RFR (Backport): 8177899: Tests fail due to code cache > exhaustion on machines with many cores > > Hi Martin, > > this looks good to me. > > Best regards, > Tobias > > On 06.06.19 11:35, Doerr, Martin wrote: > > Hi, > > > > > > > > we noticed that jdk11u is also affected by > > > > https://bugs.openjdk.java.net/browse/JDK-8177899 > > > > > > > > The VM didn't come up on a SPARC machine due to too high upper limit of > compiler threads leading to > > misconfigured code cache. > > > > > > > > Unfortunately, the original change does not apply cleanly and needs > manual resolution. > > > > > > > > Original change: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/0451e0a2f1f5 > > > > > > > > My backport: > > > > > http://cr.openjdk.java.net/~mdoerr/8177899_code_cache/jdk11u/webrev.0 > 0/ > > > > > > > > Here's the complete list of what I had to integrate manually: > > > > > > > > compile.cpp: Does not apply cleanly because of conflict with > > > > JDK-8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump > exceeds 8-bit offset > > > > Trivial to resolve: Original JDK-8177899 removes this part of JDK-8209594. > > > > We just need to take the new line: int size = > C2Compiler::initial_code_buffer_size(const_size); > > > > > > > > compilationPolicy.cpp: Does not apply cleanly because neighboring hunk > has changed: > > > > JDK-8214206: Fix for JDK-8213419 is broken on 32-bit > > > > Just need to insert code manually next to where log2_int was changed to > log2_intptr. > > > > > > > > tieredThresholdPolicy.cpp: Does not apply cleanly because the file was > renamed: > > > > JDK-8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy > > > > Change needs to get applied to simpleThresholdPolicy.cpp instead. Not > difficult. > > > > > > > > Please review. I'm targeting to 11.0.5. > > > > > > > > Best regards, > > > > Martin > > > > > > From thomas.stuefe at gmail.com Thu Jun 13 16:29:02 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 13 Jun 2019 18:29:02 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable Message-ID: Hi all, I would like to backport to 11u https://bugs.openjdk.java.net/browse/JDK-8224487. It is a precondition to backport three other fixes surrounding stringStream: - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should not use Resource Area) - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream does not honor size limit) - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal buffer should always be zero terminated) Original RFR discussion: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038208.html Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f Full patch (with 11u corrections): http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable.patch Delta to original patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable-11u-changes.patch The patch disables copy and assignment on outputStream child classes, since this has been a source of errors (unintended sharing of the stream backing buffer between two instances of stringStream, for instance). It fixes all resulting build errors - which mostly indicate real errors. Patch did not apply cleanly since 11u misses some work in the event log Coleen did in 12, and a small change Lutz Schmidt did for the code heap printer. Thanks for the review. Cheers, Thomas From ralf.schmelter at sap.com Fri Jun 14 11:31:48 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Fri, 14 Jun 2019 11:31:48 +0000 Subject: [11u] RFR (S) 8220570: Additional trace when native thread creation fails Message-ID: Please review this backport to OpenJDK 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8220570 orig-change: http://hg.openjdk.java.net/jdk/jdk/rev/a33c42262338 11u-webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8220570/webrev.u11.0/ While the patch applied cleanly, an include was missing in the Linux variant for JDK 11 which was not needed for JDK 13. Best regards, Ralf From goetz.lindenmaier at sap.com Fri Jun 14 11:55:39 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 14 Jun 2019 11:55:39 +0000 Subject: [11u] RFR (S) 8220570: Additional trace when native thread creation fails In-Reply-To: References: Message-ID: Hi Ralf, the change looks good, thanks! Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Schmelter, Ralf > Sent: Freitag, 14. Juni 2019 13:32 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR (S) 8220570: Additional trace when native > thread creation fails > > Please review this backport to OpenJDK 11u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220570 > orig-change: http://hg.openjdk.java.net/jdk/jdk/rev/a33c42262338 > 11u-webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8220570/webrev.u11.0/ > > While the patch applied cleanly, an include was missing in the Linux variant for > JDK 11 which was not needed for JDK 13. > > Best regards, > Ralf > From aph at redhat.com Mon Jun 17 12:49:00 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Jun 2019 13:49:00 +0100 Subject: RFR: 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding Message-ID: <634dff9b-2d9d-f4c4-9179-4ab7cc9deab1@redhat.com> Upstream patch applies with no changes. http://cr.openjdk.java.net/~aph/8225716-2/ OK for jdk11u ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Mon Jun 17 12:53:48 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Jun 2019 14:53:48 +0200 Subject: RFR: 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding In-Reply-To: <634dff9b-2d9d-f4c4-9179-4ab7cc9deab1@redhat.com> References: <634dff9b-2d9d-f4c4-9179-4ab7cc9deab1@redhat.com> Message-ID: On 6/17/19 2:49 PM, Andrew Haley wrote: > Upstream patch applies with no changes. > > http://cr.openjdk.java.net/~aph/8225716-2/ Yes, it is. -- Thanks, -Aleksey From christoph.langer at sap.com Mon Jun 17 15:16:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 Jun 2019 15:16:57 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Michael, I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able to do them. The code level between current JDK11u hotspot and the jdk/jdk repository at the time the patches were pushed (JDK12) has diverged too much. So, it's not a simple resolve and test thing. People with more experience in that area will have to do it. I don't have the required expertise and also no time to dig deeper into it. So, maybe somebody is willing to step up here - otherwise I'm afraid these bugs need to remain unfixed in OpenJDK 11 for the time being. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 20. M?rz 2019 16:13 > To: 'Ioi Lam' > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > Hi Ioi, > > thanks again for the update. I'll take care of these backports then. > > Thanks > Christoph > > > -----Original Message----- > > From: Ioi Lam > > Sent: Dienstag, 19. M?rz 2019 22:38 > > To: Langer, Christoph > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > The 3 issues that I wanted to backport were: > > > > Issue?????? BP-of?? Synopsis > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > allocation failure > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > java.lang.object is redefined by JVMTI agent > > > > They are all backport issues related to CDS with (fixVersion = 11-pool). > > Only the last one is related to JVMTI, but the other 2 are kind of > > serious as well. But due to reassignment, I wasn't able to do the > > backport :-( > > > > Thanks > > - Ioi > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > Hi Ioi, > > > > > > ok, thanks for that information. > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build > > failure after the former one. And what's the 3rd issue? > > > > > > Thanks > > > Christoph > > > > > >> -----Original Message----- > > >> From: Ioi Lam > > >> Sent: Montag, 18. M?rz 2019 19:27 > > >> To: Langer, Christoph > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > >> > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > >> > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > >> assigned engineer for those bugs) so I think it's best for the openjdk > > >> community to pick up these backports. > > >> > > >> Thanks > > >> > > >> - Ioi > > >> > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > >>> Hi Ioi, > > >>> > > >>> I'd like to ping you again on this one. What are your current plans on > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > >> whatever needs to go with it? Ideally you still want to do it, but if not I'd > > >> appreciate if you could let us know. > > >>> Thanks a lot in advance > > >>> Christoph > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: jdk-updates-dev > bounces at openjdk.java.net> > > >> On > > >>>> Behalf Of Ioi Lam > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > >>>> To: jdk-updates-dev at openjdk.java.net > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>> > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to post the > > >>>> requests this week. > > >>>> > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > >>>> > > >>>> Thanks > > >>>> > > >>>> - Ioi > > >>>> > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > >>>>> Hi, > > >>>>> > > >>>>> The fact a downport bug was opened does not matter, > > >>>>> you could still flag jdk11u-fix-request and just push it > > >>>>> if approved. This bug will then be closed as it is flagged 11-pool. > > >>>>> > > >>>>> More gentle it would be to ask Ioi what's going on ... > > >>>>> > > >>>>> Best regards, > > >>>>> Goetz. > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: jdk-updates-dev > >> bounces at openjdk.java.net> > > >>>> On > > >>>>>> Behalf Of Volker Simonis > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > >>>>>> To: Michael Rasmussen > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>>>> > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > >>>>>> wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I was wondering if there are any plans to backport > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > >> been > > >>>>>> created, but don't know if there are any active plans to actually do > it? > > >>>>>> Hi Michael, > > >>>>>> > > >>>>>> I actually don't really understand what this means. Usually, you do > a > > >>>>>> down-port by first requesting it on the original bug by applying a > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > approved > > >>>>>> (by application of a "jdku-fix-yes" tag), the > corresponding > > >>>>>> fix can be pushed to the updates repository. This push > automatically > > >>>>>> triggers the creation of the corresponding backport issue in JBS. > > >>>>>> > > >>>>>> I don't know what it means for the downport process [1] if > > somebody > > >>>>>> (apparently manually) creates a backport issue like > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > >>>>>> > > >>>>>> Regards, > > >>>>>> Volker > > >>>>>> > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > >>>>>> > > >>>>>>> Kind regards > > >>>>>>> /Michael From jianglizhou at google.com Mon Jun 17 23:14:12 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 17 Jun 2019 16:14:12 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Christoph, I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that needs to be backported first, but most can be done cleanly. There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, which I think should be backported to JDK 11 as well. The issue can surface up when the default CDS is used with JVMTI. I'll start from the easy ones first. Best regards, Jiangli On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph wrote: > Hi Michael, > > I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able > to do them. The code level between current JDK11u hotspot and the jdk/jdk > repository at the time the patches were pushed (JDK12) has diverged too > much. So, it's not a simple resolve and test thing. People with more > experience in that area will have to do it. I don't have the required > expertise and also no time to dig deeper into it. > > So, maybe somebody is willing to step up here - otherwise I'm afraid these > bugs need to remain unfixed in OpenJDK 11 for the time being. > > Best regards > Christoph > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Mittwoch, 20. M?rz 2019 16:13 > > To: 'Ioi Lam' > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > Hi Ioi, > > > > thanks again for the update. I'll take care of these backports then. > > > > Thanks > > Christoph > > > > > -----Original Message----- > > > From: Ioi Lam > > > Sent: Dienstag, 19. M?rz 2019 22:38 > > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > > > The 3 issues that I wanted to backport were: > > > > > > Issue BP-of Synopsis > > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > > allocation failure > > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > > java.lang.object is redefined by JVMTI agent > > > > > > They are all backport issues related to CDS with (fixVersion = > 11-pool). > > > Only the last one is related to JVMTI, but the other 2 are kind of > > > serious as well. But due to reassignment, I wasn't able to do the > > > backport :-( > > > > > > Thanks > > > - Ioi > > > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > > Hi Ioi, > > > > > > > > ok, thanks for that information. > > > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a > build > > > failure after the former one. And what's the 3rd issue? > > > > > > > > Thanks > > > > Christoph > > > > > > > >> -----Original Message----- > > > >> From: Ioi Lam > > > >> Sent: Montag, 18. M?rz 2019 19:27 > > > >> To: Langer, Christoph > > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > >> > > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > >> > > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > > >> assigned engineer for those bugs) so I think it's best for the > openjdk > > > >> community to pick up these backports. > > > >> > > > >> Thanks > > > >> > > > >> - Ioi > > > >> > > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > > >>> Hi Ioi, > > > >>> > > > >>> I'd like to ping you again on this one. What are your current > plans on > > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > > >> whatever needs to go with it? Ideally you still want to do it, but > if not I'd > > > >> appreciate if you could let us know. > > > >>> Thanks a lot in advance > > > >>> Christoph > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: jdk-updates-dev > > bounces at openjdk.java.net> > > > >> On > > > >>>> Behalf Of Ioi Lam > > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > > >>>> To: jdk-updates-dev at openjdk.java.net > > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > > >>>> > > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to > post the > > > >>>> requests this week. > > > >>>> > > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > > >>>> > > > >>>> Thanks > > > >>>> > > > >>>> - Ioi > > > >>>> > > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> The fact a downport bug was opened does not matter, > > > >>>>> you could still flag jdk11u-fix-request and just push it > > > >>>>> if approved. This bug will then be closed as it is flagged > 11-pool. > > > >>>>> > > > >>>>> More gentle it would be to ask Ioi what's going on ... > > > >>>>> > > > >>>>> Best regards, > > > >>>>> Goetz. > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: jdk-updates-dev > > >> bounces at openjdk.java.net> > > > >>>> On > > > >>>>>> Behalf Of Volker Simonis > > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > > >>>>>> To: Michael Rasmussen > > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > > >>>>>> > > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > > >>>>>> wrote: > > > >>>>>>> Hi, > > > >>>>>>> > > > >>>>>>> I was wondering if there are any plans to backport > > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > > >> been > > > >>>>>> created, but don't know if there are any active plans to > actually do > > it? > > > >>>>>> Hi Michael, > > > >>>>>> > > > >>>>>> I actually don't really understand what this means. Usually, > you do > > a > > > >>>>>> down-port by first requesting it on the original bug by > applying a > > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > > approved > > > >>>>>> (by application of a "jdku-fix-yes" tag), the > > corresponding > > > >>>>>> fix can be pushed to the updates repository. This push > > automatically > > > >>>>>> triggers the creation of the corresponding backport issue in > JBS. > > > >>>>>> > > > >>>>>> I don't know what it means for the downport process [1] if > > > somebody > > > >>>>>> (apparently manually) creates a backport issue like > > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Volker > > > >>>>>> > > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > > >>>>>> > > > >>>>>>> Kind regards > > > >>>>>>> /Michael > > From goetz.lindenmaier at sap.com Tue Jun 18 06:56:27 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 18 Jun 2019 06:56:27 +0000 Subject: RFR: 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding In-Reply-To: <634dff9b-2d9d-f4c4-9179-4ab7cc9deab1@redhat.com> References: <634dff9b-2d9d-f4c4-9179-4ab7cc9deab1@redhat.com> Message-ID: Looks good! Best, Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Montag, 17. Juni 2019 14:49 > To: jdk-updates-dev at openjdk.java.net > Subject: RFR: 8225716: G1 GC: Undefined behaviour in > G1BlockOffsetTablePart::block_at_or_preceding > > Upstream patch applies with no changes. > > http://cr.openjdk.java.net/~aph/8225716-2/ > > OK for jdk11u ? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Jun 18 08:58:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Jun 2019 08:58:46 +0000 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base Message-ID: Hi, please review the backport of the String.isEmpty() cleanups in java.base. The main reason to bring this down to JDK11u is that it'll ease backporting of later changes which otherwise run into conflicts and won't resolve. Furthermore, the original change is a nice cleanup and improves performance. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Change in jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/8bf9268df0e2 The original patch merely applies (with a little fuzz in some places). There were 4 rejects: src/java.base/share/classes/java/lang/VersionProps.java.template --- VersionProps.java.template +++ VersionProps.java.template @@ -95,7 +95,7 @@ props.put("java.version.date", java_version_date); props.put("java.runtime.version", java_runtime_version); props.put("java.runtime.name", java_runtime_name); - if (VENDOR_VERSION_STRING.length() > 0) + if (!VENDOR_VERSION_STRING.isEmpty()) props.put("java.vendor.version", VENDOR_VERSION_STRING); props.put("java.class.version", CLASSFILE_MAJOR_MINOR); -> manually resolved that to the right location src/java.base/share/classes/java/text/CompactNumberFormat.java -> file does not exist in 11u, so dropping src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java --- CheckMethodAdapter.java +++ CheckMethodAdapter.java @@ -1314,7 +1314,7 @@ * @param message the message to use in case of error. */ static void checkMethodIdentifier(final int version, final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + MUST_NOT_BE_NULL_OR_EMPTY); } if ((version & 0xFFFF) >= Opcodes.V1_5) { @@ -1347,7 +1347,7 @@ * @param message the message to use in case of error. */ static void checkInternalName(final int version, final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + MUST_NOT_BE_NULL_OR_EMPTY); } if (name.charAt(0) == '[') { @@ -1457,7 +1457,7 @@ * @param descriptor the string to be checked. */ static void checkMethodDescriptor(final int version, final String descriptor) { - if (descriptor == null || descriptor.length() == 0) { + if (descriptor == null || descriptor.isEmpty()) { throw new IllegalArgumentException("Invalid method descriptor (must not be null or empty)"); } if (descriptor.charAt(0) != '(' || descriptor.length() < 3) { -> file looks different in 11u due to a missing change. So, modified the right places in the 11u version src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java --- CheckSignatureAdapter.java +++ CheckSignatureAdapter.java @@ -365,7 +365,7 @@ } private void checkClassName(final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + " (must not be null or empty)"); } for (int i = 0; i < name.length(); ++i) { @@ -377,7 +377,7 @@ } private void checkIdentifier(final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + " (must not be null or empty)"); } for (int i = 0; i < name.length(); ++i) { -> file looks different in 11u due to a missing change. So, modified the right places in the 11u version Thanks Christoph From matthias.baesken at sap.com Tue Jun 18 13:15:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Jun 2019 13:15:43 +0000 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: References: Message-ID: Hello Christoph, looks good with the exception of src/java.base/share/classes/jdk/internal/module/Checks.java http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/share/classes/jdk/internal/module/Checks.java.frames.html /** - * Returns {@code true} if the given name is a legal module name. - */ - public static boolean isModuleName(String name) { .... - private static boolean isJavaIdentifier(CharSequence cs) { - if (cs.length() == 0 || RESERVED.contains(cs)) + private static boolean isJavaIdentifier(String str) { + if (str.isEmpty() || RESERVED.contains(str)) ... where I am a bit unsure - should we really remove a method in jdk11 (and change signature of another) ? I know , it is from jdk/internal , but still I have a bad feeling about this . This was probably fine for the higher release but for jdk11 it might be better to keep what we have . Best regards, Matthias From: Langer, Christoph Sent: Dienstag, 18. Juni 2019 10:59 To: jdk-updates-dev at openjdk.java.net Cc: Java Core Libs ; Baesken, Matthias Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base Hi, please review the backport of the String.isEmpty() cleanups in java.base. The main reason to bring this down to JDK11u is that it'll ease backporting of later changes which otherwise run into conflicts and won't resolve. Furthermore, the original change is a nice cleanup and improves performance. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Change in jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/8bf9268df0e2 The original patch merely applies (with a little fuzz in some places). There were 4 rejects: src/java.base/share/classes/java/lang/VersionProps.java.template --- VersionProps.java.template +++ VersionProps.java.template @@ -95,7 +95,7 @@ props.put("java.version.date", java_version_date); props.put("java.runtime.version", java_runtime_version); props.put("java.runtime.name", java_runtime_name); - if (VENDOR_VERSION_STRING.length() > 0) + if (!VENDOR_VERSION_STRING.isEmpty()) props.put("java.vendor.version", VENDOR_VERSION_STRING); props.put("java.class.version", CLASSFILE_MAJOR_MINOR); -> manually resolved that to the right location src/java.base/share/classes/java/text/CompactNumberFormat.java -> file does not exist in 11u, so dropping src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java --- CheckMethodAdapter.java +++ CheckMethodAdapter.java @@ -1314,7 +1314,7 @@ * @param message the message to use in case of error. */ static void checkMethodIdentifier(final int version, final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + MUST_NOT_BE_NULL_OR_EMPTY); } if ((version & 0xFFFF) >= Opcodes.V1_5) { @@ -1347,7 +1347,7 @@ * @param message the message to use in case of error. */ static void checkInternalName(final int version, final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + MUST_NOT_BE_NULL_OR_EMPTY); } if (name.charAt(0) == '[') { @@ -1457,7 +1457,7 @@ * @param descriptor the string to be checked. */ static void checkMethodDescriptor(final int version, final String descriptor) { - if (descriptor == null || descriptor.length() == 0) { + if (descriptor == null || descriptor.isEmpty()) { throw new IllegalArgumentException("Invalid method descriptor (must not be null or empty)"); } if (descriptor.charAt(0) != '(' || descriptor.length() < 3) { -> file looks different in 11u due to a missing change. So, modified the right places in the 11u version src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java --- CheckSignatureAdapter.java +++ CheckSignatureAdapter.java @@ -365,7 +365,7 @@ } private void checkClassName(final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + " (must not be null or empty)"); } for (int i = 0; i < name.length(); ++i) { @@ -377,7 +377,7 @@ } private void checkIdentifier(final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + " (must not be null or empty)"); } for (int i = 0; i < name.length(); ++i) { -> file looks different in 11u due to a missing change. So, modified the right places in the 11u version Thanks Christoph From christoph.langer at sap.com Tue Jun 18 13:20:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Jun 2019 13:20:22 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Jiangli, thanks for taking this over. I tried to pick a few of the dependent fixes but it got too much for me. ?? Best regards Christoph From: Jiangli Zhou Sent: Dienstag, 18. Juni 2019 01:14 To: Langer, Christoph Cc: Michael Rasmussen ; jdk-updates-dev at openjdk.java.net; Ioi Lam Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? Hi Christoph, I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that needs to be backported first, but most can be done cleanly. There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, which I think should be backported to JDK 11 as well. The issue can surface up when the default CDS is used with JVMTI. I'll start from the easy ones first. Best regards, Jiangli On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph > wrote: Hi Michael, I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able to do them. The code level between current JDK11u hotspot and the jdk/jdk repository at the time the patches were pushed (JDK12) has diverged too much. So, it's not a simple resolve and test thing. People with more experience in that area will have to do it. I don't have the required expertise and also no time to dig deeper into it. So, maybe somebody is willing to step up here - otherwise I'm afraid these bugs need to remain unfixed in OpenJDK 11 for the time being. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 20. M?rz 2019 16:13 > To: 'Ioi Lam' > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > Hi Ioi, > > thanks again for the update. I'll take care of these backports then. > > Thanks > Christoph > > > -----Original Message----- > > From: Ioi Lam > > > Sent: Dienstag, 19. M?rz 2019 22:38 > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > The 3 issues that I wanted to backport were: > > > > Issue BP-of Synopsis > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > allocation failure > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > java.lang.object is redefined by JVMTI agent > > > > They are all backport issues related to CDS with (fixVersion = 11-pool). > > Only the last one is related to JVMTI, but the other 2 are kind of > > serious as well. But due to reassignment, I wasn't able to do the > > backport :-( > > > > Thanks > > - Ioi > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > Hi Ioi, > > > > > > ok, thanks for that information. > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build > > failure after the former one. And what's the 3rd issue? > > > > > > Thanks > > > Christoph > > > > > >> -----Original Message----- > > >> From: Ioi Lam > > > >> Sent: Montag, 18. M?rz 2019 19:27 > > >> To: Langer, Christoph > > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > >> > > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > >> > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > >> assigned engineer for those bugs) so I think it's best for the openjdk > > >> community to pick up these backports. > > >> > > >> Thanks > > >> > > >> - Ioi > > >> > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > >>> Hi Ioi, > > >>> > > >>> I'd like to ping you again on this one. What are your current plans on > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > >> whatever needs to go with it? Ideally you still want to do it, but if not I'd > > >> appreciate if you could let us know. > > >>> Thanks a lot in advance > > >>> Christoph > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: jdk-updates-dev > bounces at openjdk.java.net> > > >> On > > >>>> Behalf Of Ioi Lam > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > >>>> To: jdk-updates-dev at openjdk.java.net > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>> > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to post the > > >>>> requests this week. > > >>>> > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > >>>> > > >>>> Thanks > > >>>> > > >>>> - Ioi > > >>>> > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > >>>>> Hi, > > >>>>> > > >>>>> The fact a downport bug was opened does not matter, > > >>>>> you could still flag jdk11u-fix-request and just push it > > >>>>> if approved. This bug will then be closed as it is flagged 11-pool. > > >>>>> > > >>>>> More gentle it would be to ask Ioi what's going on ... > > >>>>> > > >>>>> Best regards, > > >>>>> Goetz. > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: jdk-updates-dev > >> bounces at openjdk.java.net> > > >>>> On > > >>>>>> Behalf Of Volker Simonis > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > >>>>>> To: Michael Rasmussen > > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>>>> > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > >>>>>> > wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I was wondering if there are any plans to backport > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > >> been > > >>>>>> created, but don't know if there are any active plans to actually do > it? > > >>>>>> Hi Michael, > > >>>>>> > > >>>>>> I actually don't really understand what this means. Usually, you do > a > > >>>>>> down-port by first requesting it on the original bug by applying a > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > approved > > >>>>>> (by application of a "jdku-fix-yes" tag), the > corresponding > > >>>>>> fix can be pushed to the updates repository. This push > automatically > > >>>>>> triggers the creation of the corresponding backport issue in JBS. > > >>>>>> > > >>>>>> I don't know what it means for the downport process [1] if > > somebody > > >>>>>> (apparently manually) creates a backport issue like > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > >>>>>> > > >>>>>> Regards, > > >>>>>> Volker > > >>>>>> > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > >>>>>> > > >>>>>>> Kind regards > > >>>>>>> /Michael From jianglizhou at google.com Tue Jun 18 22:25:50 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 18 Jun 2019 15:25:50 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Christoph and others, I did investigations for backporting the JDK-8212200 and JDK-8213250 changes. There are some dependencies on Java object archiving work. The cleanest way to handle the backports is to pull in all the dependencies one by one to OpenJDK 11. It helps minimize the merge changes. It also helps JVM startup time in JDK 11 by pulling in the additional optimizations. Thoughts from anyone? Best regards, Jiangli On Tue, Jun 18, 2019 at 6:20 AM Langer, Christoph wrote: > Hi Jiangli, > > > > thanks for taking this over. I tried to pick a few of the dependent fixes > but it got too much for me. ?? > > > > Best regards > > Christoph > > > > *From:* Jiangli Zhou > *Sent:* Dienstag, 18. Juni 2019 01:14 > *To:* Langer, Christoph > *Cc:* Michael Rasmussen ; > jdk-updates-dev at openjdk.java.net; Ioi Lam > *Subject:* Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > Hi Christoph, > > > > I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that > needs to be backported first, but most can be done cleanly. > > > > There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, which > I think should be backported to JDK 11 as well. The issue can surface up > when the default CDS is used with JVMTI. > > > > I'll start from the easy ones first. > > > > Best regards, > > > > Jiangli > > > > On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > > Hi Michael, > > I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able > to do them. The code level between current JDK11u hotspot and the jdk/jdk > repository at the time the patches were pushed (JDK12) has diverged too > much. So, it's not a simple resolve and test thing. People with more > experience in that area will have to do it. I don't have the required > expertise and also no time to dig deeper into it. > > So, maybe somebody is willing to step up here - otherwise I'm afraid these > bugs need to remain unfixed in OpenJDK 11 for the time being. > > Best regards > Christoph > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Mittwoch, 20. M?rz 2019 16:13 > > To: 'Ioi Lam' > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > Hi Ioi, > > > > thanks again for the update. I'll take care of these backports then. > > > > Thanks > > Christoph > > > > > -----Original Message----- > > > From: Ioi Lam > > > Sent: Dienstag, 19. M?rz 2019 22:38 > > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > > > The 3 issues that I wanted to backport were: > > > > > > Issue BP-of Synopsis > > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > > allocation failure > > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > > java.lang.object is redefined by JVMTI agent > > > > > > They are all backport issues related to CDS with (fixVersion = > 11-pool). > > > Only the last one is related to JVMTI, but the other 2 are kind of > > > serious as well. But due to reassignment, I wasn't able to do the > > > backport :-( > > > > > > Thanks > > > - Ioi > > > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > > Hi Ioi, > > > > > > > > ok, thanks for that information. > > > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a > build > > > failure after the former one. And what's the 3rd issue? > > > > > > > > Thanks > > > > Christoph > > > > > > > >> -----Original Message----- > > > >> From: Ioi Lam > > > >> Sent: Montag, 18. M?rz 2019 19:27 > > > >> To: Langer, Christoph > > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > >> > > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > >> > > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > > >> assigned engineer for those bugs) so I think it's best for the > openjdk > > > >> community to pick up these backports. > > > >> > > > >> Thanks > > > >> > > > >> - Ioi > > > >> > > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > > >>> Hi Ioi, > > > >>> > > > >>> I'd like to ping you again on this one. What are your current > plans on > > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > > >> whatever needs to go with it? Ideally you still want to do it, but > if not I'd > > > >> appreciate if you could let us know. > > > >>> Thanks a lot in advance > > > >>> Christoph > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: jdk-updates-dev > > bounces at openjdk.java.net> > > > >> On > > > >>>> Behalf Of Ioi Lam > > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > > >>>> To: jdk-updates-dev at openjdk.java.net > > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > > >>>> > > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to > post the > > > >>>> requests this week. > > > >>>> > > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > > >>>> > > > >>>> Thanks > > > >>>> > > > >>>> - Ioi > > > >>>> > > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> The fact a downport bug was opened does not matter, > > > >>>>> you could still flag jdk11u-fix-request and just push it > > > >>>>> if approved. This bug will then be closed as it is flagged > 11-pool. > > > >>>>> > > > >>>>> More gentle it would be to ask Ioi what's going on ... > > > >>>>> > > > >>>>> Best regards, > > > >>>>> Goetz. > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: jdk-updates-dev > > >> bounces at openjdk.java.net> > > > >>>> On > > > >>>>>> Behalf Of Volker Simonis > > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > > >>>>>> To: Michael Rasmussen > > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > > >>>>>> > > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > > >>>>>> wrote: > > > >>>>>>> Hi, > > > >>>>>>> > > > >>>>>>> I was wondering if there are any plans to backport > > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > > >> been > > > >>>>>> created, but don't know if there are any active plans to > actually do > > it? > > > >>>>>> Hi Michael, > > > >>>>>> > > > >>>>>> I actually don't really understand what this means. Usually, > you do > > a > > > >>>>>> down-port by first requesting it on the original bug by > applying a > > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > > approved > > > >>>>>> (by application of a "jdku-fix-yes" tag), the > > corresponding > > > >>>>>> fix can be pushed to the updates repository. This push > > automatically > > > >>>>>> triggers the creation of the corresponding backport issue in > JBS. > > > >>>>>> > > > >>>>>> I don't know what it means for the downport process [1] if > > > somebody > > > >>>>>> (apparently manually) creates a backport issue like > > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Volker > > > >>>>>> > > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > > >>>>>> > > > >>>>>>> Kind regards > > > >>>>>>> /Michael > > From jianglizhou at google.com Tue Jun 18 22:48:46 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 18 Jun 2019 15:48:46 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: https://bugs.openjdk.java.net/browse/JDK-8210926 can be applied cleanly with no dependencies. I've added jdk11u-fix-request. Best regards, Jiangli On Tue, Jun 18, 2019 at 3:25 PM Jiangli Zhou wrote: > Hi Christoph and others, > > I did investigations for backporting the JDK-8212200 and JDK-8213250 changes. > There are some dependencies on Java object archiving work. The cleanest way > to handle the backports is to pull in all the dependencies one by one to > OpenJDK 11. It helps minimize the merge changes. It also helps JVM startup > time in JDK 11 by pulling in the additional optimizations. Thoughts from > anyone? > > Best regards, > Jiangli > > On Tue, Jun 18, 2019 at 6:20 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > >> Hi Jiangli, >> >> >> >> thanks for taking this over. I tried to pick a few of the dependent fixes >> but it got too much for me. ?? >> >> >> >> Best regards >> >> Christoph >> >> >> >> *From:* Jiangli Zhou >> *Sent:* Dienstag, 18. Juni 2019 01:14 >> *To:* Langer, Christoph >> *Cc:* Michael Rasmussen ; >> jdk-updates-dev at openjdk.java.net; Ioi Lam >> *Subject:* Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> >> >> >> Hi Christoph, >> >> >> >> I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that >> needs to be backported first, but most can be done cleanly. >> >> >> >> There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, >> which I think should be backported to JDK 11 as well. The issue can surface >> up when the default CDS is used with JVMTI. >> >> >> >> I'll start from the easy ones first. >> >> >> >> Best regards, >> >> >> >> Jiangli >> >> >> >> On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph < >> christoph.langer at sap.com> wrote: >> >> Hi Michael, >> >> I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able >> to do them. The code level between current JDK11u hotspot and the jdk/jdk >> repository at the time the patches were pushed (JDK12) has diverged too >> much. So, it's not a simple resolve and test thing. People with more >> experience in that area will have to do it. I don't have the required >> expertise and also no time to dig deeper into it. >> >> So, maybe somebody is willing to step up here - otherwise I'm afraid >> these bugs need to remain unfixed in OpenJDK 11 for the time being. >> >> Best regards >> Christoph >> >> > -----Original Message----- >> > From: Langer, Christoph >> > Sent: Mittwoch, 20. M?rz 2019 16:13 >> > To: 'Ioi Lam' >> > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> > >> > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> > >> > Hi Ioi, >> > >> > thanks again for the update. I'll take care of these backports then. >> > >> > Thanks >> > Christoph >> > >> > > -----Original Message----- >> > > From: Ioi Lam >> > > Sent: Dienstag, 19. M?rz 2019 22:38 >> > > To: Langer, Christoph >> > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> > > >> > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> > > >> > > The 3 issues that I wanted to backport were: >> > > >> > > Issue BP-of Synopsis >> > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped >> > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace >> object >> > > allocation failure >> > > JDK-8213164 8212200 assert(on_stack()) failed when shared >> > > java.lang.object is redefined by JVMTI agent >> > > >> > > They are all backport issues related to CDS with (fixVersion = >> 11-pool). >> > > Only the last one is related to JVMTI, but the other 2 are kind of >> > > serious as well. But due to reassignment, I wasn't able to do the >> > > backport :-( >> > > >> > > Thanks >> > > - Ioi >> > > >> > > On 3/18/19 2:08 PM, Langer, Christoph wrote: >> > > > Hi Ioi, >> > > > >> > > > ok, thanks for that information. >> > > > >> > > > Can you let us know, what exactly these 3 bugs were, that should be >> > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a >> build >> > > failure after the former one. And what's the 3rd issue? >> > > > >> > > > Thanks >> > > > Christoph >> > > > >> > > >> -----Original Message----- >> > > >> From: Ioi Lam >> > > >> Sent: Montag, 18. M?rz 2019 19:27 >> > > >> To: Langer, Christoph >> > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> > > >> >> > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> > > >> >> > > >> Hi Christoph, I have been reassigned (and I've removed myself as >> the >> > > >> assigned engineer for those bugs) so I think it's best for the >> openjdk >> > > >> community to pick up these backports. >> > > >> >> > > >> Thanks >> > > >> >> > > >> - Ioi >> > > >> >> > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: >> > > >>> Hi Ioi, >> > > >>> >> > > >>> I'd like to ping you again on this one. What are your current >> plans on >> > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and >> > > >> whatever needs to go with it? Ideally you still want to do it, but >> if not I'd >> > > >> appreciate if you could let us know. >> > > >>> Thanks a lot in advance >> > > >>> Christoph >> > > >>> >> > > >>> >> > > >>>> -----Original Message----- >> > > >>>> From: jdk-updates-dev > > > bounces at openjdk.java.net> >> > > >> On >> > > >>>> Behalf Of Ioi Lam >> > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 >> > > >>>> To: jdk-updates-dev at openjdk.java.net >> > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >> > > >>>> >> > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to >> post the >> > > >>>> requests this week. >> > > >>>> >> > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 >> > > >>>> >> > > >>>> Thanks >> > > >>>> >> > > >>>> - Ioi >> > > >>>> >> > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: >> > > >>>>> Hi, >> > > >>>>> >> > > >>>>> The fact a downport bug was opened does not matter, >> > > >>>>> you could still flag jdk11u-fix-request and just push it >> > > >>>>> if approved. This bug will then be closed as it is flagged >> 11-pool. >> > > >>>>> >> > > >>>>> More gentle it would be to ask Ioi what's going on ... >> > > >>>>> >> > > >>>>> Best regards, >> > > >>>>> Goetz. >> > > >>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: jdk-updates-dev > > > >> bounces at openjdk.java.net> >> > > >>>> On >> > > >>>>>> Behalf Of Volker Simonis >> > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM >> > > >>>>>> To: Michael Rasmussen >> > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net >> > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >> > > >>>>>> >> > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen >> > > >>>>>> wrote: >> > > >>>>>>> Hi, >> > > >>>>>>> >> > > >>>>>>> I was wondering if there are any plans to backport >> > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. >> > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 >> has >> > > >> been >> > > >>>>>> created, but don't know if there are any active plans to >> actually do >> > it? >> > > >>>>>> Hi Michael, >> > > >>>>>> >> > > >>>>>> I actually don't really understand what this means. Usually, >> you do >> > a >> > > >>>>>> down-port by first requesting it on the original bug by >> applying a >> > > >>>>>> "jdku-fix-request" tag. Once the downport will be >> > > approved >> > > >>>>>> (by application of a "jdku-fix-yes" tag), the >> > corresponding >> > > >>>>>> fix can be pushed to the updates repository. This push >> > automatically >> > > >>>>>> triggers the creation of the corresponding backport issue in >> JBS. >> > > >>>>>> >> > > >>>>>> I don't know what it means for the downport process [1] if >> > > somebody >> > > >>>>>> (apparently manually) creates a backport issue like >> > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? >> > > >>>>>> >> > > >>>>>> Regards, >> > > >>>>>> Volker >> > > >>>>>> >> > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html >> > > >>>>>> >> > > >>>>>>> Kind regards >> > > >>>>>>> /Michael >> >> From goetz.lindenmaier at sap.com Wed Jun 19 07:19:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 19 Jun 2019 07:19:07 +0000 Subject: Reminder: jdk11u 11.0.4 closed starting next week, Tuesday June 25 Message-ID: Hi, I'd like to remind that repository jdk-updates/jdk11u containing update 11.0.4 will be frozen starting Tuesday, June 25 18:00 CET for preparation of the closed security fixes. https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u Please work on your critical changes that must make jdk11u in time. Please remember changes going to jdk11u must be tagged jdk11u-critical-request and must be approved with jdk11u-critical-yes before being pushed. Best regards, Goetz (This is not about jdk11u-dev. In jdk11u-dev update 11.0.*5* is prepared, and it remains open). From christoph.langer at sap.com Wed Jun 19 07:26:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Jun 2019 07:26:29 +0000 Subject: CSR process for OpenJDK 11 and 8 Updates Message-ID: Hi Joe, Andrew, I?m currently wondering about the status of the CSR process for JDK updates. Do we use the CSR process or not? As per previous mailing list discussions [1], I read that that the project lead of 8u and 11u is under the assumption that we are using CSR. However, as per the latest CSRs in that area [2], [3], I understand that the CSR group lead is under the assumption that Open JDK updates doesn?t use this process and hence these CSRs were pended. Obviously there?s some disconnect here? ?? So, what is the current status? Did you already sort this out? My personal view is that a CSR process would be beneficial to the JDK updates projects, too. In any case, thanks in advance for some guidance on how to handle backports with attached CSRs! /Christoph [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009401.html [2] https://bugs.openjdk.java.net/browse/JDK-8224770 [3] https://bugs.openjdk.java.net/browse/JDK-8224766 From aph at redhat.com Wed Jun 19 14:41:10 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Jun 2019 15:41:10 +0100 Subject: RFR: jdk11u: Revised patch for 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding Message-ID: Upstream patch applies cleanly: http://cr.openjdk.java.net/~aph/8225716-4/ OK? This is for openjdk.java.net/jdk-updates/jdk11u, i.e. its a critical patch. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jianglizhou at google.com Wed Jun 19 14:44:11 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 19 Jun 2019 07:44:11 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: My pleasure??. Best regards, Jiangli On Wed, Jun 19, 2019 at 12:43 AM Langer, Christoph wrote: > Hi Jiangli, > > > > sounds good to me. Thanks for your effort with this ?? > > > > Cheers > > Christoph > > > > *From:* Jiangli Zhou > *Sent:* Mittwoch, 19. Juni 2019 00:49 > *To:* Langer, Christoph > *Cc:* Michael Rasmussen ; > jdk-updates-dev at openjdk.java.net; Ioi Lam > *Subject:* Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > https://bugs.openjdk.java.net/browse/JDK-8210926 can be applied cleanly > with no dependencies. I've added jdk11u-fix-request. > > > > Best regards, > > Jiangli > > > > On Tue, Jun 18, 2019 at 3:25 PM Jiangli Zhou > wrote: > > Hi Christoph and others, > > > > I did investigations for backporting the JDK-8212200 and JDK-8213250 changes. > There are some dependencies on Java object archiving work. The cleanest way > to handle the backports is to pull in all the dependencies one by one to > OpenJDK 11. It helps minimize the merge changes. It also helps JVM startup > time in JDK 11 by pulling in the additional optimizations. Thoughts from > anyone? > > > > Best regards, > > Jiangli > > > > On Tue, Jun 18, 2019 at 6:20 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > > Hi Jiangli, > > > > thanks for taking this over. I tried to pick a few of the dependent fixes > but it got too much for me. ?? > > > > Best regards > > Christoph > > > > *From:* Jiangli Zhou > *Sent:* Dienstag, 18. Juni 2019 01:14 > *To:* Langer, Christoph > *Cc:* Michael Rasmussen ; > jdk-updates-dev at openjdk.java.net; Ioi Lam > *Subject:* Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > Hi Christoph, > > > > I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that > needs to be backported first, but most can be done cleanly. > > > > There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, which > I think should be backported to JDK 11 as well. The issue can surface up > when the default CDS is used with JVMTI. > > > > I'll start from the easy ones first. > > > > Best regards, > > > > Jiangli > > > > On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > > Hi Michael, > > I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able > to do them. The code level between current JDK11u hotspot and the jdk/jdk > repository at the time the patches were pushed (JDK12) has diverged too > much. So, it's not a simple resolve and test thing. People with more > experience in that area will have to do it. I don't have the required > expertise and also no time to dig deeper into it. > > So, maybe somebody is willing to step up here - otherwise I'm afraid these > bugs need to remain unfixed in OpenJDK 11 for the time being. > > Best regards > Christoph > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Mittwoch, 20. M?rz 2019 16:13 > > To: 'Ioi Lam' > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > Hi Ioi, > > > > thanks again for the update. I'll take care of these backports then. > > > > Thanks > > Christoph > > > > > -----Original Message----- > > > From: Ioi Lam > > > Sent: Dienstag, 19. M?rz 2019 22:38 > > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > > > The 3 issues that I wanted to backport were: > > > > > > Issue BP-of Synopsis > > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > > allocation failure > > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > > java.lang.object is redefined by JVMTI agent > > > > > > They are all backport issues related to CDS with (fixVersion = > 11-pool). > > > Only the last one is related to JVMTI, but the other 2 are kind of > > > serious as well. But due to reassignment, I wasn't able to do the > > > backport :-( > > > > > > Thanks > > > - Ioi > > > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > > Hi Ioi, > > > > > > > > ok, thanks for that information. > > > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a > build > > > failure after the former one. And what's the 3rd issue? > > > > > > > > Thanks > > > > Christoph > > > > > > > >> -----Original Message----- > > > >> From: Ioi Lam > > > >> Sent: Montag, 18. M?rz 2019 19:27 > > > >> To: Langer, Christoph > > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > >> > > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > >> > > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > > >> assigned engineer for those bugs) so I think it's best for the > openjdk > > > >> community to pick up these backports. > > > >> > > > >> Thanks > > > >> > > > >> - Ioi > > > >> > > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > > >>> Hi Ioi, > > > >>> > > > >>> I'd like to ping you again on this one. What are your current > plans on > > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > > >> whatever needs to go with it? Ideally you still want to do it, but > if not I'd > > > >> appreciate if you could let us know. > > > >>> Thanks a lot in advance > > > >>> Christoph > > > >>> > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: jdk-updates-dev > > bounces at openjdk.java.net> > > > >> On > > > >>>> Behalf Of Ioi Lam > > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > > >>>> To: jdk-updates-dev at openjdk.java.net > > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > > >>>> > > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to > post the > > > >>>> requests this week. > > > >>>> > > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > > >>>> > > > >>>> Thanks > > > >>>> > > > >>>> - Ioi > > > >>>> > > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> The fact a downport bug was opened does not matter, > > > >>>>> you could still flag jdk11u-fix-request and just push it > > > >>>>> if approved. This bug will then be closed as it is flagged > 11-pool. > > > >>>>> > > > >>>>> More gentle it would be to ask Ioi what's going on ... > > > >>>>> > > > >>>>> Best regards, > > > >>>>> Goetz. > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: jdk-updates-dev > > >> bounces at openjdk.java.net> > > > >>>> On > > > >>>>>> Behalf Of Volker Simonis > > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > > >>>>>> To: Michael Rasmussen > > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > > >>>>>> > > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > > >>>>>> wrote: > > > >>>>>>> Hi, > > > >>>>>>> > > > >>>>>>> I was wondering if there are any plans to backport > > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > > >> been > > > >>>>>> created, but don't know if there are any active plans to > actually do > > it? > > > >>>>>> Hi Michael, > > > >>>>>> > > > >>>>>> I actually don't really understand what this means. Usually, > you do > > a > > > >>>>>> down-port by first requesting it on the original bug by > applying a > > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > > approved > > > >>>>>> (by application of a "jdku-fix-yes" tag), the > > corresponding > > > >>>>>> fix can be pushed to the updates repository. This push > > automatically > > > >>>>>> triggers the creation of the corresponding backport issue in > JBS. > > > >>>>>> > > > >>>>>> I don't know what it means for the downport process [1] if > > > somebody > > > >>>>>> (apparently manually) creates a backport issue like > > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Volker > > > >>>>>> > > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > > >>>>>> > > > >>>>>>> Kind regards > > > >>>>>>> /Michael > > From shade at redhat.com Wed Jun 19 14:59:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Jun 2019 16:59:58 +0200 Subject: RFR: jdk11u: Revised patch for 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding In-Reply-To: References: Message-ID: On 6/19/19 4:41 PM, Andrew Haley wrote: > Upstream patch applies cleanly: > > http://cr.openjdk.java.net/~aph/8225716-4/ > > OK? This is for openjdk.java.net/jdk-updates/jdk11u, i.e. its a critical patch. Looks good. -Aleksey From thomas.stuefe at gmail.com Thu Jun 20 06:09:15 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 20 Jun 2019 08:09:15 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Ping.. On Thu, Jun 13, 2019, 18:29 Thomas St?fe wrote: > Hi all, > > I would like to backport to 11u > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > It is a precondition to backport three other fixes surrounding > stringStream: > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > not use Resource Area) > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream does > not honor size limit) > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal > buffer should always be zero terminated) > > Original RFR discussion: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038208.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > Full patch (with 11u corrections): > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable.patch > Delta to original patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable-11u-changes.patch > > The patch disables copy and assignment on outputStream child classes, > since this has been a source of errors (unintended sharing of the stream > backing buffer between two instances of stringStream, for instance). It > fixes all resulting build errors - which mostly indicate real errors. > > Patch did not apply cleanly since 11u misses some work in the event log > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > printer. > > Thanks for the review. > > Cheers, Thomas > > From christoph.langer at sap.com Fri Jun 21 13:20:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Jun 2019 13:20:41 +0000 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: References: Message-ID: Hi Matthias, thanks for your careful review of this tedious change. I think the change in jdk.internal.module.Checks.java is ok to backport. It is no public interface and regression tests show no issue. So I wouldn't modify the patch in this place. Any other opinions? Best regards Christoph From: Baesken, Matthias Sent: Dienstag, 18. Juni 2019 15:16 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net Cc: Java Core Libs Subject: RE: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base Hello Christoph, looks good with the exception of src/java.base/share/classes/jdk/internal/module/Checks.java http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/share/classes/jdk/internal/module/Checks.java.frames.html /** - * Returns {@code true} if the given name is a legal module name. - */ - public static boolean isModuleName(String name) { .... - private static boolean isJavaIdentifier(CharSequence cs) { - if (cs.length() == 0 || RESERVED.contains(cs)) + private static boolean isJavaIdentifier(String str) { + if (str.isEmpty() || RESERVED.contains(str)) ... where I am a bit unsure - should we really remove a method in jdk11 (and change signature of another) ? I know , it is from jdk/internal , but still I have a bad feeling about this . This was probably fine for the higher release but for jdk11 it might be better to keep what we have . Best regards, Matthias From: Langer, Christoph Sent: Dienstag, 18. Juni 2019 10:59 To: jdk-updates-dev at openjdk.java.net Cc: Java Core Libs >; Baesken, Matthias > Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base Hi, please review the backport of the String.isEmpty() cleanups in java.base. The main reason to bring this down to JDK11u is that it'll ease backporting of later changes which otherwise run into conflicts and won't resolve. Furthermore, the original change is a nice cleanup and improves performance. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Change in jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/8bf9268df0e2 The original patch merely applies (with a little fuzz in some places). There were 4 rejects: src/java.base/share/classes/java/lang/VersionProps.java.template --- VersionProps.java.template +++ VersionProps.java.template @@ -95,7 +95,7 @@ props.put("java.version.date", java_version_date); props.put("java.runtime.version", java_runtime_version); props.put("java.runtime.name", java_runtime_name); - if (VENDOR_VERSION_STRING.length() > 0) + if (!VENDOR_VERSION_STRING.isEmpty()) props.put("java.vendor.version", VENDOR_VERSION_STRING); props.put("java.class.version", CLASSFILE_MAJOR_MINOR); -> manually resolved that to the right location src/java.base/share/classes/java/text/CompactNumberFormat.java -> file does not exist in 11u, so dropping src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java --- CheckMethodAdapter.java +++ CheckMethodAdapter.java @@ -1314,7 +1314,7 @@ * @param message the message to use in case of error. */ static void checkMethodIdentifier(final int version, final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + MUST_NOT_BE_NULL_OR_EMPTY); } if ((version & 0xFFFF) >= Opcodes.V1_5) { @@ -1347,7 +1347,7 @@ * @param message the message to use in case of error. */ static void checkInternalName(final int version, final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + MUST_NOT_BE_NULL_OR_EMPTY); } if (name.charAt(0) == '[') { @@ -1457,7 +1457,7 @@ * @param descriptor the string to be checked. */ static void checkMethodDescriptor(final int version, final String descriptor) { - if (descriptor == null || descriptor.length() == 0) { + if (descriptor == null || descriptor.isEmpty()) { throw new IllegalArgumentException("Invalid method descriptor (must not be null or empty)"); } if (descriptor.charAt(0) != '(' || descriptor.length() < 3) { -> file looks different in 11u due to a missing change. So, modified the right places in the 11u version src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java --- CheckSignatureAdapter.java +++ CheckSignatureAdapter.java @@ -365,7 +365,7 @@ } private void checkClassName(final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + " (must not be null or empty)"); } for (int i = 0; i < name.length(); ++i) { @@ -377,7 +377,7 @@ } private void checkIdentifier(final String name, final String message) { - if (name == null || name.length() == 0) { + if (name == null || name.isEmpty()) { throw new IllegalArgumentException(INVALID + message + " (must not be null or empty)"); } for (int i = 0; i < name.length(); ++i) { -> file looks different in 11u due to a missing change. So, modified the right places in the 11u version Thanks Christoph From joe.darcy at oracle.com Fri Jun 21 16:45:30 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 21 Jun 2019 09:45:30 -0700 Subject: CSR process for OpenJDK 11 and 8 Updates In-Reply-To: References: Message-ID: Hello, On 6/19/2019 12:26 AM, Langer, Christoph wrote: > > Hi Joe, Andrew, > > I?m currently wondering about the status of the CSR process for JDK > updates. Do we use the CSR process or not? > > As per previous mailing list discussions [1], I read that that the > project lead of 8u and 11u is under the assumption that we are using > CSR. However, as per the latest CSRs in that area [2], [3], ?I > understand that the CSR group lead is under the assumption that Open > JDK updates doesn?t use this process and hence these CSRs were pended. > Obviously there?s some disconnect here? ??So, what is the current > status? Did you already sort this out? > > My personal view is that a CSR process would be beneficial to the JDK > updates projects, too. > > In any case, thanks in advance for some guidance on how to handle > backports with attached CSRs! > > While discussion are on-going, the CSR FAQ does address a common situation of how to handle backports and CSRs: > Q: How should I get CSR review for multiple release trains? > A: Say you want to get an interface change into JDK N and later decide > the change is also desirable and appropriate for the JDK (N-1) update > release and that update release is using the CSR process. First a CSR > should be created from the main bug targeted at JDK N. Afterward, if a > backport of the main bug covering JDK (N-1) does not already exist, a > backport of the main bug covering JDK (N-1) should be created. Then, a > CSR can be created from that backport. https://wiki.openjdk.java.net/display/csr/CSR+FAQs HTH, -Joe From christoph.langer at sap.com Fri Jun 21 18:21:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Jun 2019 18:21:17 +0000 Subject: CSR process for OpenJDK 11 and 8 Updates In-Reply-To: References: Message-ID: Hi, thanks for that hint, Joe. I think you also said some time ago, that if there already existed a CSR for an Oracle JDK11 backport of a certain bug, we can also use it and link it to the OpenJDK backport item. Is that correct? Cheers Christoph From: Joe Darcy Sent: Freitag, 21. Juni 2019 18:46 To: Langer, Christoph ; Andrew Haley Cc: jdk-updates-dev at openjdk.java.net; jdk8u-dev ; Hohensee, Paul Subject: Re: CSR process for OpenJDK 11 and 8 Updates Hello, On 6/19/2019 12:26 AM, Langer, Christoph wrote: Hi Joe, Andrew, I?m currently wondering about the status of the CSR process for JDK updates. Do we use the CSR process or not? As per previous mailing list discussions [1], I read that that the project lead of 8u and 11u is under the assumption that we are using CSR. However, as per the latest CSRs in that area [2], [3], I understand that the CSR group lead is under the assumption that Open JDK updates doesn?t use this process and hence these CSRs were pended. Obviously there?s some disconnect here? ?? So, what is the current status? Did you already sort this out? My personal view is that a CSR process would be beneficial to the JDK updates projects, too. In any case, thanks in advance for some guidance on how to handle backports with attached CSRs! While discussion are on-going, the CSR FAQ does address a common situation of how to handle backports and CSRs: Q: How should I get CSR review for multiple release trains? A: Say you want to get an interface change into JDK N and later decide the change is also desirable and appropriate for the JDK (N-1) update release and that update release is using the CSR process. First a CSR should be created from the main bug targeted at JDK N. Afterward, if a backport of the main bug covering JDK (N-1) does not already exist, a backport of the main bug covering JDK (N-1) should be created. Then, a CSR can be created from that backport. https://wiki.openjdk.java.net/display/csr/CSR+FAQs HTH, -Joe From christoph.langer at sap.com Sat Jun 22 21:25:37 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 22 Jun 2019 21:25:37 +0000 Subject: OpenJDK 11u backport of JDK-8148188: Enhance the security libraries to record events of interest Message-ID: Hi, I pushed the backport of JDK-8148188 [0] to jdk11u-dev [1] on Friday. I was wondering why no 11.0.5 backport JBS item was created. I then manually created JDK-8226636 [2], but the minute I had created it I got an idea what the reason for that strange JBS/hgupdater behavior was (all other pushes around this commit seem to have correct backport bugs). I now suspect that there existed a confidential 11-pool backport item already which was resolved by my push. Can anybody within Oracle please check this and if I?m correct, please also check whether the backport bug can be made public? I?d then close JDK-8226636 as duplicate. But maybe I?m wrong with that guess? please enlighten me ?? Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8148188 [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5f98a6a92842 [2] https://bugs.openjdk.java.net/browse/JDK-8226636 From christoph.langer at sap.com Sat Jun 22 21:57:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 22 Jun 2019 21:57:14 +0000 Subject: Backporting JDK-8222914 to OpenJDK 11u Message-ID: Hi, while looking through backport items for 11.0.5, I came across JDK-8222914 [0]. It talks about JDK-8215505 had been backported to 11u and now parts of JDK-8218266 would be needed, too. Unfortunately, JDK-8215505 is a closed bug. The commit for this bug is visible [1] and looking at the code it seems to be worth considering for OpenJDK 11 Updates, too. However, it would be beneficial if JDK-8215505 could be opened up then. Can anybody within Oracle please check and let me know whether this could be done or whether this patch needs to remain closed? Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8222914 [1] http://hg.openjdk.java.net/jdk/jdk/rev/112ad164d26c From david.holmes at oracle.com Sat Jun 22 22:14:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 Jun 2019 15:14:58 -0700 Subject: OpenJDK 11u backport of JDK-8148188: Enhance the security libraries to record events of interest In-Reply-To: References: Message-ID: <29e48f22-5966-385c-acde-8bdb4ddc10b4@oracle.com> Hi Christoph, On 22/06/2019 2:25 pm, Langer, Christoph wrote: > Hi, > > I pushed the backport of JDK-8148188 [0] to jdk11u-dev [1] on Friday. I was wondering why no 11.0.5 backport JBS item was created. I then manually created JDK-8226636 [2], but the minute I had created it I got an idea what the reason for that strange JBS/hgupdater behavior was (all other pushes around this commit seem to have correct backport bugs). I now suspect that there existed a confidential 11-pool backport item already which was resolved by my push. > > Can anybody within Oracle please check this and if I?m correct, please also check whether the backport bug can be made public? I?d then close JDK-8226636 as duplicate. But maybe I?m wrong with that guess? please enlighten me ?? No there was no confidential issue resolved by your push. I would have to suspect hgupdater may be down, or else some other hgupdater configuration problem. David ------ > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8148188 > [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5f98a6a92842 > [2] https://bugs.openjdk.java.net/browse/JDK-8226636 > From christoph.langer at sap.com Sat Jun 22 22:18:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 22 Jun 2019 22:18:51 +0000 Subject: OpenJDK 11u backport of JDK-8148188: Enhance the security libraries to record events of interest In-Reply-To: <29e48f22-5966-385c-acde-8bdb4ddc10b4@oracle.com> References: <29e48f22-5966-385c-acde-8bdb4ddc10b4@oracle.com> Message-ID: Thanks, David. Then I probably did the right thing by manually creating the backport bug. cc-ing ops at o.j.n: Maybe you want to have a look why hgupdater failed in this case? Cheers Christoph > -----Original Message----- > From: David Holmes > Sent: Sonntag, 23. Juni 2019 00:15 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; security-dev > Subject: Re: OpenJDK 11u backport of JDK-8148188: Enhance the security > libraries to record events of interest > > Hi Christoph, > > On 22/06/2019 2:25 pm, Langer, Christoph wrote: > > Hi, > > > > I pushed the backport of JDK-8148188 [0] to jdk11u-dev [1] on Friday. I was > wondering why no 11.0.5 backport JBS item was created. I then manually > created JDK-8226636 [2], but the minute I had created it I got an idea what > the reason for that strange JBS/hgupdater behavior was (all other pushes > around this commit seem to have correct backport bugs). I now suspect that > there existed a confidential 11-pool backport item already which was > resolved by my push. > > > > Can anybody within Oracle please check this and if I?m correct, please also > check whether the backport bug can be made public? I?d then close JDK- > 8226636 as duplicate. But maybe I?m wrong with that guess? please > enlighten me ?? > > No there was no confidential issue resolved by your push. I would have > to suspect hgupdater may be down, or else some other hgupdater > configuration problem. > > David > ------ > > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8148188 > > [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5f98a6a92842 > > [2] https://bugs.openjdk.java.net/browse/JDK-8226636 > > From david.holmes at oracle.com Sat Jun 22 22:22:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 22 Jun 2019 15:22:36 -0700 Subject: Backporting JDK-8222914 to OpenJDK 11u In-Reply-To: References: Message-ID: <16d1942b-858f-9604-134b-4772dca86df3@oracle.com> Hi Christoph, On 22/06/2019 2:57 pm, Langer, Christoph wrote: > Hi, > > while looking through backport items for 11.0.5, I came across JDK-8222914 [0]. > > It talks about JDK-8215505 had been backported to 11u and now parts of JDK-8218266 would be needed, too. Unfortunately, JDK-8215505 is a closed bug. The commit for this bug is visible [1] and looking at the code it seems to be worth considering for OpenJDK 11 Updates, too. However, it would be beneficial if JDK-8215505 could be opened up then. Can anybody within Oracle please check and let me know whether this could be done or whether this patch needs to remain closed? The bug can't be opened - you already have the patch. It was a follow up cleanup to this changeset: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/be3e24cca6f8 HTH. David > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8222914 > [1] http://hg.openjdk.java.net/jdk/jdk/rev/112ad164d26c > From christoph.langer at sap.com Sat Jun 22 22:24:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 22 Jun 2019 22:24:58 +0000 Subject: Backporting JDK-8222914 to OpenJDK 11u In-Reply-To: <16d1942b-858f-9604-134b-4772dca86df3@oracle.com> References: <16d1942b-858f-9604-134b-4772dca86df3@oracle.com> Message-ID: OK. We'll live with what we have then. Thank you, David. > -----Original Message----- > From: David Holmes > Sent: Sonntag, 23. Juni 2019 00:23 > To: Langer, Christoph ; Hotspot dev runtime > ; jdk-updates- > dev at openjdk.java.net; coleen.phillimore at oracle.com > Subject: Re: Backporting JDK-8222914 to OpenJDK 11u > > Hi Christoph, > > On 22/06/2019 2:57 pm, Langer, Christoph wrote: > > Hi, > > > > while looking through backport items for 11.0.5, I came across JDK-8222914 > [0]. > > > > It talks about JDK-8215505 had been backported to 11u and now parts of > JDK-8218266 would be needed, too. Unfortunately, JDK-8215505 is a closed > bug. The commit for this bug is visible [1] and looking at the code it seems to > be worth considering for OpenJDK 11 Updates, too. However, it would be > beneficial if JDK-8215505 could be opened up then. Can anybody within > Oracle please check and let me know whether this could be done or whether > this patch needs to remain closed? > > The bug can't be opened - you already have the patch. It was a follow up > cleanup to this changeset: > > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/be3e24cca6f8 > > HTH. > > David > > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8222914 > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/112ad164d26c > > From jianglizhou at google.com Sun Jun 23 20:33:37 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Sun, 23 Jun 2019 13:33:37 -0700 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Christoph, Just an update on this effort: https://bugs.openjdk.java.net/browse/JDK-8210926 has been backported to 11u. I've also labeled all dependencies (with google-interest) related to JDK-8212200 and JDK-8213250, including additional bug fixes and enhancements pulled in for the dependencies. There are total 33 bug fixes and enhances. I'll go through them to backport to 11u. Please feel free to take any of them if you can. With this set of fixes and enhancements, it will bring in the startup performance improvements using Java object archiving (enabled with the default CDS) to OpenJDK 11 update. Users will see a nice speedup with the JVM startup time. Best regards, Jiangli On Wed, Jun 19, 2019 at 7:44 AM Jiangli Zhou wrote: > My pleasure??. > > Best regards, > Jiangli > > On Wed, Jun 19, 2019 at 12:43 AM Langer, Christoph < > christoph.langer at sap.com> wrote: > >> Hi Jiangli, >> >> >> >> sounds good to me. Thanks for your effort with this ?? >> >> >> >> Cheers >> >> Christoph >> >> >> >> *From:* Jiangli Zhou >> *Sent:* Mittwoch, 19. Juni 2019 00:49 >> *To:* Langer, Christoph >> *Cc:* Michael Rasmussen ; >> jdk-updates-dev at openjdk.java.net; Ioi Lam >> *Subject:* Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8210926 can be applied cleanly >> with no dependencies. I've added jdk11u-fix-request. >> >> >> >> Best regards, >> >> Jiangli >> >> >> >> On Tue, Jun 18, 2019 at 3:25 PM Jiangli Zhou >> wrote: >> >> Hi Christoph and others, >> >> >> >> I did investigations for backporting the JDK-8212200 and JDK-8213250 changes. >> There are some dependencies on Java object archiving work. The cleanest way >> to handle the backports is to pull in all the dependencies one by one to >> OpenJDK 11. It helps minimize the merge changes. It also helps JVM startup >> time in JDK 11 by pulling in the additional optimizations. Thoughts from >> anyone? >> >> >> >> Best regards, >> >> Jiangli >> >> >> >> On Tue, Jun 18, 2019 at 6:20 AM Langer, Christoph < >> christoph.langer at sap.com> wrote: >> >> Hi Jiangli, >> >> >> >> thanks for taking this over. I tried to pick a few of the dependent fixes >> but it got too much for me. ?? >> >> >> >> Best regards >> >> Christoph >> >> >> >> *From:* Jiangli Zhou >> *Sent:* Dienstag, 18. Juni 2019 01:14 >> *To:* Langer, Christoph >> *Cc:* Michael Rasmussen ; >> jdk-updates-dev at openjdk.java.net; Ioi Lam >> *Subject:* Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> >> >> >> Hi Christoph, >> >> >> >> I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that >> needs to be backported first, but most can be done cleanly. >> >> >> >> There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, >> which I think should be backported to JDK 11 as well. The issue can surface >> up when the default CDS is used with JVMTI. >> >> >> >> I'll start from the easy ones first. >> >> >> >> Best regards, >> >> >> >> Jiangli >> >> >> >> On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph < >> christoph.langer at sap.com> wrote: >> >> Hi Michael, >> >> I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able >> to do them. The code level between current JDK11u hotspot and the jdk/jdk >> repository at the time the patches were pushed (JDK12) has diverged too >> much. So, it's not a simple resolve and test thing. People with more >> experience in that area will have to do it. I don't have the required >> expertise and also no time to dig deeper into it. >> >> So, maybe somebody is willing to step up here - otherwise I'm afraid >> these bugs need to remain unfixed in OpenJDK 11 for the time being. >> >> Best regards >> Christoph >> >> > -----Original Message----- >> > From: Langer, Christoph >> > Sent: Mittwoch, 20. M?rz 2019 16:13 >> > To: 'Ioi Lam' >> > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> > >> > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> > >> > Hi Ioi, >> > >> > thanks again for the update. I'll take care of these backports then. >> > >> > Thanks >> > Christoph >> > >> > > -----Original Message----- >> > > From: Ioi Lam >> > > Sent: Dienstag, 19. M?rz 2019 22:38 >> > > To: Langer, Christoph >> > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> > > >> > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> > > >> > > The 3 issues that I wanted to backport were: >> > > >> > > Issue BP-of Synopsis >> > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped >> > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace >> object >> > > allocation failure >> > > JDK-8213164 8212200 assert(on_stack()) failed when shared >> > > java.lang.object is redefined by JVMTI agent >> > > >> > > They are all backport issues related to CDS with (fixVersion = >> 11-pool). >> > > Only the last one is related to JVMTI, but the other 2 are kind of >> > > serious as well. But due to reassignment, I wasn't able to do the >> > > backport :-( >> > > >> > > Thanks >> > > - Ioi >> > > >> > > On 3/18/19 2:08 PM, Langer, Christoph wrote: >> > > > Hi Ioi, >> > > > >> > > > ok, thanks for that information. >> > > > >> > > > Can you let us know, what exactly these 3 bugs were, that should be >> > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a >> build >> > > failure after the former one. And what's the 3rd issue? >> > > > >> > > > Thanks >> > > > Christoph >> > > > >> > > >> -----Original Message----- >> > > >> From: Ioi Lam >> > > >> Sent: Montag, 18. M?rz 2019 19:27 >> > > >> To: Langer, Christoph >> > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen >> > > >> >> > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? >> > > >> >> > > >> Hi Christoph, I have been reassigned (and I've removed myself as >> the >> > > >> assigned engineer for those bugs) so I think it's best for the >> openjdk >> > > >> community to pick up these backports. >> > > >> >> > > >> Thanks >> > > >> >> > > >> - Ioi >> > > >> >> > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: >> > > >>> Hi Ioi, >> > > >>> >> > > >>> I'd like to ping you again on this one. What are your current >> plans on >> > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and >> > > >> whatever needs to go with it? Ideally you still want to do it, but >> if not I'd >> > > >> appreciate if you could let us know. >> > > >>> Thanks a lot in advance >> > > >>> Christoph >> > > >>> >> > > >>> >> > > >>>> -----Original Message----- >> > > >>>> From: jdk-updates-dev > > > bounces at openjdk.java.net> >> > > >> On >> > > >>>> Behalf Of Ioi Lam >> > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 >> > > >>>> To: jdk-updates-dev at openjdk.java.net >> > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >> > > >>>> >> > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to >> post the >> > > >>>> requests this week. >> > > >>>> >> > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 >> > > >>>> >> > > >>>> Thanks >> > > >>>> >> > > >>>> - Ioi >> > > >>>> >> > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: >> > > >>>>> Hi, >> > > >>>>> >> > > >>>>> The fact a downport bug was opened does not matter, >> > > >>>>> you could still flag jdk11u-fix-request and just push it >> > > >>>>> if approved. This bug will then be closed as it is flagged >> 11-pool. >> > > >>>>> >> > > >>>>> More gentle it would be to ask Ioi what's going on ... >> > > >>>>> >> > > >>>>> Best regards, >> > > >>>>> Goetz. >> > > >>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: jdk-updates-dev > > > >> bounces at openjdk.java.net> >> > > >>>> On >> > > >>>>>> Behalf Of Volker Simonis >> > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM >> > > >>>>>> To: Michael Rasmussen >> > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net >> > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? >> > > >>>>>> >> > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen >> > > >>>>>> wrote: >> > > >>>>>>> Hi, >> > > >>>>>>> >> > > >>>>>>> I was wondering if there are any plans to backport >> > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. >> > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 >> has >> > > >> been >> > > >>>>>> created, but don't know if there are any active plans to >> actually do >> > it? >> > > >>>>>> Hi Michael, >> > > >>>>>> >> > > >>>>>> I actually don't really understand what this means. Usually, >> you do >> > a >> > > >>>>>> down-port by first requesting it on the original bug by >> applying a >> > > >>>>>> "jdku-fix-request" tag. Once the downport will be >> > > approved >> > > >>>>>> (by application of a "jdku-fix-yes" tag), the >> > corresponding >> > > >>>>>> fix can be pushed to the updates repository. This push >> > automatically >> > > >>>>>> triggers the creation of the corresponding backport issue in >> JBS. >> > > >>>>>> >> > > >>>>>> I don't know what it means for the downport process [1] if >> > > somebody >> > > >>>>>> (apparently manually) creates a backport issue like >> > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? >> > > >>>>>> >> > > >>>>>> Regards, >> > > >>>>>> Volker >> > > >>>>>> >> > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html >> > > >>>>>> >> > > >>>>>>> Kind regards >> > > >>>>>>> /Michael >> >> From thomas.stuefe at gmail.com Mon Jun 24 05:43:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 07:43:41 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Ping... no takers? On Thu, Jun 20, 2019 at 8:09 AM Thomas St?fe wrote: > Ping.. > > On Thu, Jun 13, 2019, 18:29 Thomas St?fe wrote: > >> Hi all, >> >> I would like to backport to 11u >> >> https://bugs.openjdk.java.net/browse/JDK-8224487. >> >> It is a precondition to backport three other fixes surrounding >> stringStream: >> - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should >> not use Resource Area) >> - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream does >> not honor size limit) >> - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream >> internal buffer should always be zero terminated) >> >> Original RFR discussion: >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-May/038208.html >> Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f >> >> Full patch (with 11u corrections): >> http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable.patch >> Delta to original patch: >> http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make-streams-not-copyable-11u-changes.patch >> >> The patch disables copy and assignment on outputStream child classes, >> since this has been a source of errors (unintended sharing of the stream >> backing buffer between two instances of stringStream, for instance). It >> fixes all resulting build errors - which mostly indicate real errors. >> >> Patch did not apply cleanly since 11u misses some work in the event log >> Coleen did in 12, and a small change Lutz Schmidt did for the code heap >> printer. >> >> Thanks for the review. >> >> Cheers, Thomas >> >> From thomas.stuefe at gmail.com Mon Jun 24 07:27:53 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 09:27:53 +0200 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: References: Message-ID: Hi Christoph, I looked at the changes. Mostly good - true to the original change. At various places (e.g. src/java.base/share/classes/java/lang/ClassLoader.java) one could remove the extra brackets, but since we want to keep the diff to head at a minimum where possible I would not do this. However, your patch (and the original one) contained the following part I do not understand: http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java.udiff.html static boolean isFastFileTransferRequested() { String fileTransferProp = GetPropertyAction - .privilegedGetProperty("jdk.nio.enableFastFileTransfer"); - boolean enable; - if ("".equals(fileTransferProp)) { - enable = true; - } else { - enable = Boolean.parseBoolean(fileTransferProp); - } - return enable; + .privilegedGetProperty("jdk.nio.enableFastFileTransfer", "false"); + return fileTransferProp.isEmpty() ? true : Boolean.parseBoolean(fileTransferProp); } The old version called GetPropertyAction::privilegedGetProperty() without default value. The new versions passes "false" as default value. I fail to see how this could ever return an empty string? Also, would that not change default behavior? Note that this is part of the original change. Cheers, Thomas On Tue, Jun 18, 2019 at 10:59 AM Langer, Christoph wrote: > Hi, > > please review the backport of the String.isEmpty() cleanups in java.base. > > The main reason to bring this down to JDK11u is that it'll ease > backporting of later changes which otherwise run into conflicts and won't > resolve. Furthermore, the original change is a nice cleanup and improves > performance. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > Change in jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/8bf9268df0e2 > > The original patch merely applies (with a little fuzz in some places). > There were 4 rejects: > > src/java.base/share/classes/java/lang/VersionProps.java.template > --- VersionProps.java.template > +++ VersionProps.java.template > @@ -95,7 +95,7 @@ > props.put("java.version.date", java_version_date); > props.put("java.runtime.version", java_runtime_version); > props.put("java.runtime.name", java_runtime_name); > - if (VENDOR_VERSION_STRING.length() > 0) > + if (!VENDOR_VERSION_STRING.isEmpty()) > props.put("java.vendor.version", VENDOR_VERSION_STRING); > props.put("java.class.version", CLASSFILE_MAJOR_MINOR); > > -> manually resolved that to the right location > > src/java.base/share/classes/java/text/CompactNumberFormat.java > > -> file does not exist in 11u, so dropping > > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java > --- CheckMethodAdapter.java > +++ CheckMethodAdapter.java > @@ -1314,7 +1314,7 @@ > * @param message the message to use in case of error. > */ > static void checkMethodIdentifier(final int version, final String > name, final String message) { > - if (name == null || name.length() == 0) { > + if (name == null || name.isEmpty()) { > throw new IllegalArgumentException(INVALID + message + > MUST_NOT_BE_NULL_OR_EMPTY); > } > if ((version & 0xFFFF) >= Opcodes.V1_5) { > @@ -1347,7 +1347,7 @@ > * @param message the message to use in case of error. > */ > static void checkInternalName(final int version, final String name, > final String message) { > - if (name == null || name.length() == 0) { > + if (name == null || name.isEmpty()) { > throw new IllegalArgumentException(INVALID + message + > MUST_NOT_BE_NULL_OR_EMPTY); > } > if (name.charAt(0) == '[') { > @@ -1457,7 +1457,7 @@ > * @param descriptor the string to be checked. > */ > static void checkMethodDescriptor(final int version, final String > descriptor) { > - if (descriptor == null || descriptor.length() == 0) { > + if (descriptor == null || descriptor.isEmpty()) { > throw new IllegalArgumentException("Invalid method descriptor > (must not be null or empty)"); > } > if (descriptor.charAt(0) != '(' || descriptor.length() < 3) { > > -> file looks different in 11u due to a missing change. So, modified the > right places in the 11u version > > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java > --- CheckSignatureAdapter.java > +++ CheckSignatureAdapter.java > @@ -365,7 +365,7 @@ > } > private void checkClassName(final String name, final String message) { > - if (name == null || name.length() == 0) { > + if (name == null || name.isEmpty()) { > throw new IllegalArgumentException(INVALID + message + " > (must not be null or empty)"); > } > for (int i = 0; i < name.length(); ++i) { > @@ -377,7 +377,7 @@ > } > private void checkIdentifier(final String name, final String message) > { > - if (name == null || name.length() == 0) { > + if (name == null || name.isEmpty()) { > throw new IllegalArgumentException(INVALID + message + " > (must not be null or empty)"); > } > for (int i = 0; i < name.length(); ++i) { > > -> file looks different in 11u due to a missing change. So, modified the > right places in the 11u version > > Thanks > Christoph > > From christoph.langer at sap.com Mon Jun 24 07:44:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 07:44:44 +0000 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Hi Thomas, I think this is good. Looks like you resolved the rejects correctly. Will you run it through our test system? I don't see the patch in there currently... Thanks & Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Thomas St?fe > Sent: Donnerstag, 13. Juni 2019 18:29 > To: jdk-updates-dev at openjdk.java.net > Cc: HotSpot Open Source Developers > Subject: [11u] RFR 8224487: outputStream should not be copyable > > Hi all, > > I would like to backport to 11u > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > It is a precondition to backport three other fixes surrounding > stringStream: > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > not use Resource Area) > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream > does > not honor size limit) > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal > buffer should always be zero terminated) > > Original RFR discussion: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019- > May/038208.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > Full patch (with 11u corrections): > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable.patch > Delta to original patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable-11u-changes.patch > > The patch disables copy and assignment on outputStream child classes, since > this has been a source of errors (unintended sharing of the stream backing > buffer between two instances of stringStream, for instance). It fixes all > resulting build errors - which mostly indicate real errors. > > Patch did not apply cleanly since 11u misses some work in the event log > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > printer. > > Thanks for the review. > > Cheers, Thomas From claes.redestad at oracle.com Mon Jun 24 08:24:02 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 24 Jun 2019 10:24:02 +0200 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: References: Message-ID: <9e8f235b-c9fa-b157-cdba-86a8da313002@oracle.com> Hi, On 2019-06-24 09:27, Thomas St?fe wrote: > However, your patch (and the original one) contained the following part I > do not understand: > > http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java.udiff.html > > static boolean isFastFileTransferRequested() { > String fileTransferProp = GetPropertyAction > - .privilegedGetProperty("jdk.nio.enableFastFileTransfer"); > - boolean enable; > - if ("".equals(fileTransferProp)) { > - enable = true; > - } else { > - enable = Boolean.parseBoolean(fileTransferProp); > - } > - return enable; > + .privilegedGetProperty("jdk.nio.enableFastFileTransfer", > "false"); > + return fileTransferProp.isEmpty() ? true : > Boolean.parseBoolean(fileTransferProp); > } > > The old version called GetPropertyAction::privilegedGetProperty() without > default value. The new versions passes "false" as default value. I fail to > see how this could ever return an empty string? Also, would that not change > default behavior? Behavior before and after should be the same. Both System.getProperty("jdk.nio.enableFastFileTransfer") and System.getProperty("jdk.nio.enableFastFileTransfer", "false") will return "" in case -Djdk.nio.enableFastFileTransfer is specified. The default "false" only changes so that we don't have to deal with fileTransferProp being null, which I thought made for a nice little cleanup. /Claes From christoph.langer at sap.com Mon Jun 24 09:27:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 09:27:05 +0000 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: <9e8f235b-c9fa-b157-cdba-86a8da313002@oracle.com> References: <9e8f235b-c9fa-b157-cdba-86a8da313002@oracle.com> Message-ID: Hi, thanks, Claes for chiming in and explaining. I also went through the code and concur - behavior should not have changed and code is cleaned up nicely. So I think this backport has received enough reviewer attention. Will push it then as regression tests seem all good, too. ?? Thanks to all involved, Christoph > -----Original Message----- > From: Claes Redestad > Sent: Montag, 24. Juni 2019 10:24 > To: Thomas St?fe ; Langer, Christoph > > Cc: Java Core Libs ; jdk-updates- > dev at openjdk.java.net; Baesken, Matthias > Subject: Re: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in > java.base > > Hi, > > > On 2019-06-24 09:27, Thomas St?fe wrote: > > However, your patch (and the original one) contained the following part I > > do not understand: > > > > > http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/wi > ndows/classes/sun/nio/ch/FileDispatcherImpl.java.udiff.html > > > > static boolean isFastFileTransferRequested() { > > String fileTransferProp = GetPropertyAction > > - .privilegedGetProperty("jdk.nio.enableFastFileTransfer"); > > - boolean enable; > > - if ("".equals(fileTransferProp)) { > > - enable = true; > > - } else { > > - enable = Boolean.parseBoolean(fileTransferProp); > > - } > > - return enable; > > + .privilegedGetProperty("jdk.nio.enableFastFileTransfer", > > "false"); > > + return fileTransferProp.isEmpty() ? true : > > Boolean.parseBoolean(fileTransferProp); > > } > > > > The old version called GetPropertyAction::privilegedGetProperty() without > > default value. The new versions passes "false" as default value. I fail to > > see how this could ever return an empty string? Also, would that not > change > > default behavior? > > Behavior before and after should be the same. > > Both System.getProperty("jdk.nio.enableFastFileTransfer") and > System.getProperty("jdk.nio.enableFastFileTransfer", "false") will > return "" in case -Djdk.nio.enableFastFileTransfer is specified. The > default "false" only changes so that we don't have to deal with > fileTransferProp being null, which I thought made for a nice little > cleanup. > > /Claes From thomas.stuefe at gmail.com Mon Jun 24 09:30:19 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 11:30:19 +0200 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: <9e8f235b-c9fa-b157-cdba-86a8da313002@oracle.com> References: <9e8f235b-c9fa-b157-cdba-86a8da313002@oracle.com> Message-ID: HI Claes, On Mon, Jun 24, 2019 at 10:22 AM Claes Redestad wrote: > Hi, > > > On 2019-06-24 09:27, Thomas St?fe wrote: > > However, your patch (and the original one) contained the following part I > > do not understand: > > > > > http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java.udiff.html > > > > static boolean isFastFileTransferRequested() { > > String fileTransferProp = GetPropertyAction > > - > .privilegedGetProperty("jdk.nio.enableFastFileTransfer"); > > - boolean enable; > > - if ("".equals(fileTransferProp)) { > > - enable = true; > > - } else { > > - enable = Boolean.parseBoolean(fileTransferProp); > > - } > > - return enable; > > + .privilegedGetProperty("jdk.nio.enableFastFileTransfer", > > "false"); > > + return fileTransferProp.isEmpty() ? true : > > Boolean.parseBoolean(fileTransferProp); > > } > > > > The old version called GetPropertyAction::privilegedGetProperty() without > > default value. The new versions passes "false" as default value. I fail > to > > see how this could ever return an empty string? Also, would that not > change > > default behavior? > > Behavior before and after should be the same. > > Both System.getProperty("jdk.nio.enableFastFileTransfer") and > System.getProperty("jdk.nio.enableFastFileTransfer", "false") will > return "" in case -Djdk.nio.enableFastFileTransfer is specified. The > default "false" only changes so that we don't have to deal with > fileTransferProp being null, which I thought made for a nice little > cleanup. > > Ah now I get it. Thank you! ..thomas > /Claes > From thomas.stuefe at gmail.com Mon Jun 24 09:30:38 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 11:30:38 +0200 Subject: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in java.base In-Reply-To: References: <9e8f235b-c9fa-b157-cdba-86a8da313002@oracle.com> Message-ID: Ship it. Cheers, Thomas On Mon, Jun 24, 2019 at 11:27 AM Langer, Christoph wrote: > Hi, > > thanks, Claes for chiming in and explaining. I also went through the code > and concur - behavior should not have changed and code is cleaned up nicely. > > So I think this backport has received enough reviewer attention. Will push > it then as regression tests seem all good, too. ?? > > Thanks to all involved, > Christoph > > > > -----Original Message----- > > From: Claes Redestad > > Sent: Montag, 24. Juni 2019 10:24 > > To: Thomas St?fe ; Langer, Christoph > > > > Cc: Java Core Libs ; jdk-updates- > > dev at openjdk.java.net; Baesken, Matthias > > Subject: Re: [11u]: RFR: 8215281: Use String.isEmpty() when applicable in > > java.base > > > > Hi, > > > > > > On 2019-06-24 09:27, Thomas St?fe wrote: > > > However, your patch (and the original one) contained the following > part I > > > do not understand: > > > > > > > > http://cr.openjdk.java.net/~clanger/webrevs/8215281.11u/src/java.base/wi > > ndows/classes/sun/nio/ch/FileDispatcherImpl.java.udiff.html > > > > > > static boolean isFastFileTransferRequested() { > > > String fileTransferProp = GetPropertyAction > > > - > .privilegedGetProperty("jdk.nio.enableFastFileTransfer"); > > > - boolean enable; > > > - if ("".equals(fileTransferProp)) { > > > - enable = true; > > > - } else { > > > - enable = Boolean.parseBoolean(fileTransferProp); > > > - } > > > - return enable; > > > + > .privilegedGetProperty("jdk.nio.enableFastFileTransfer", > > > "false"); > > > + return fileTransferProp.isEmpty() ? true : > > > Boolean.parseBoolean(fileTransferProp); > > > } > > > > > > The old version called GetPropertyAction::privilegedGetProperty() > without > > > default value. The new versions passes "false" as default value. I > fail to > > > see how this could ever return an empty string? Also, would that not > > change > > > default behavior? > > > > Behavior before and after should be the same. > > > > Both System.getProperty("jdk.nio.enableFastFileTransfer") and > > System.getProperty("jdk.nio.enableFastFileTransfer", "false") will > > return "" in case -Djdk.nio.enableFastFileTransfer is specified. The > > default "false" only changes so that we don't have to deal with > > fileTransferProp being null, which I thought made for a nice little > > cleanup. > > > > /Claes > From thomas.stuefe at gmail.com Mon Jun 24 09:32:37 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 11:32:37 +0200 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Thank you Christoph. Patch has been tested in 11u-dev for the last ~10 nights. Cheers, Thomas On Mon, Jun 24, 2019 at 9:44 AM Langer, Christoph wrote: > Hi Thomas, > > I think this is good. Looks like you resolved the rejects correctly. > > Will you run it through our test system? I don't see the patch in there > currently... > > Thanks & Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Thomas St?fe > > Sent: Donnerstag, 13. Juni 2019 18:29 > > To: jdk-updates-dev at openjdk.java.net > > Cc: HotSpot Open Source Developers > > Subject: [11u] RFR 8224487: outputStream should not be copyable > > > > Hi all, > > > > I would like to backport to 11u > > > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > > > It is a precondition to backport three other fixes surrounding > > stringStream: > > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > > not use Resource Area) > > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream > > does > > not honor size limit) > > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream > internal > > buffer should always be zero terminated) > > > > Original RFR discussion: > > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019- > > May/038208.html > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > > > Full patch (with 11u corrections): > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > > streams-not-copyable.patch > > Delta to original patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > > streams-not-copyable-11u-changes.patch > > > > The patch disables copy and assignment on outputStream child classes, > since > > this has been a source of errors (unintended sharing of the stream > backing > > buffer between two instances of stringStream, for instance). It fixes all > > resulting build errors - which mostly indicate real errors. > > > > Patch did not apply cleanly since 11u misses some work in the event log > > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > > printer. > > > > Thanks for the review. > > > > Cheers, Thomas > From christoph.langer at sap.com Mon Jun 24 09:36:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 09:36:50 +0000 Subject: [11u] RFR 8224487: outputStream should not be copyable In-Reply-To: References: Message-ID: Hi Thomas, thanks, I see the patch in the system ? just didn?t look right before ?? /Christoph From: Thomas St?fe Sent: Montag, 24. Juni 2019 11:33 To: Langer, Christoph Cc: jdk-updates-dev at openjdk.java.net; HotSpot Open Source Developers Subject: Re: [11u] RFR 8224487: outputStream should not be copyable Thank you Christoph. Patch has been tested in 11u-dev for the last ~10 nights. Cheers, Thomas On Mon, Jun 24, 2019 at 9:44 AM Langer, Christoph > wrote: Hi Thomas, I think this is good. Looks like you resolved the rejects correctly. Will you run it through our test system? I don't see the patch in there currently... Thanks & Best regards Christoph > -----Original Message----- > From: hotspot-dev > On Behalf Of > Thomas St?fe > Sent: Donnerstag, 13. Juni 2019 18:29 > To: jdk-updates-dev at openjdk.java.net > Cc: HotSpot Open Source Developers > > Subject: [11u] RFR 8224487: outputStream should not be copyable > > Hi all, > > I would like to backport to 11u > > https://bugs.openjdk.java.net/browse/JDK-8224487. > > It is a precondition to backport three other fixes surrounding > stringStream: > - https://bugs.openjdk.java.net/browse/JDK-8224193 (stringStream should > not use Resource Area) > - https://bugs.openjdk.java.net/browse/JDK-8220394 (bufferedStream > does > not honor size limit) > - https://bugs.openjdk.java.net/browse/JDK-8225225 (stringStream internal > buffer should always be zero terminated) > > Original RFR discussion: > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019- > May/038208.html > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0927d8c7296f > > Full patch (with 11u corrections): > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable.patch > Delta to original patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8224487-make- > streams-not-copyable-11u-changes.patch > > The patch disables copy and assignment on outputStream child classes, since > this has been a source of errors (unintended sharing of the stream backing > buffer between two instances of stringStream, for instance). It fixes all > resulting build errors - which mostly indicate real errors. > > Patch did not apply cleanly since 11u misses some work in the event log > Coleen did in 12, and a small change Lutz Schmidt did for the code heap > printer. > > Thanks for the review. > > Cheers, Thomas From christoph.langer at sap.com Mon Jun 24 09:53:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 09:53:53 +0000 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken Message-ID: I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project Reviewer. Matthias has just recently become a reviewer in the JDK project. I think the same criteria that qualified his nomination in the JDK project apply for a reviewer nomination in the JDK-Updates project as well: Matthias is a long standing member of the JVM team at SAP. His main areas of expertise are the build system, compilers/porting and security updates. He's a JDK Committer who has contributed more than 90 changes within the last two years [1]. Votes are due by 8 July 2019, 12:00 CET. Only current JDK-Updates Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [3]. Christoph Langer [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100 [2] http://openjdk.java.net/census#jdk-updates [3] http://openjdk.java.net/projects/#reviewer-vote From goetz.lindenmaier at sap.com Mon Jun 24 10:04:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 24 Jun 2019 10:04:42 +0000 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Montag, 24. Juni 2019 11:54 > To: jdk-updates-dev at openjdk.java.net > Cc: Baesken, Matthias > Subject: [CAUTION] CFV: New JDK-Updates Reviewer: Matthias Baesken > > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project > Reviewer. > > > > Matthias has just recently become a reviewer in the JDK project. I think the > same criteria that qualified his nomination in the JDK project apply for a > reviewer nomination in the JDK-Updates project as well: > > > > Matthias is a long standing member of the JVM team at SAP. His main areas of > expertise are the build system, compilers/porting and security updates. He's a > JDK Committer who has contributed more than 90 changes within the last two > years [1]. > > > > Votes are due by 8 July 2019, 12:00 CET. > > > > Only current JDK-Updates Reviewers [2] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [3]. > > > > Christoph Langer > > > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)% > 20and%20not%20desc(%22Contributed- > by%22))%20or%20desc(%22Contributed- > by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&re > vcount=100 > > [2] http://openjdk.java.net/census#jdk-updates > > [3] http://openjdk.java.net/projects/#reviewer-vote From adinn at redhat.com Mon Jun 24 10:06:36 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 24 Jun 2019 11:06:36 +0100 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: <8d6e2ef1-de1f-4c82-9143-79ffe214a210@redhat.com> Vote: yes On 24/06/2019 10:53, Langer, Christoph wrote: > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project > Reviewer. > > > > Matthias has just recently become a reviewer in the JDK project. I > think the same criteria that qualified his nomination in the JDK > project apply for a reviewer nomination in the JDK-Updates project as > well: > > > > Matthias is a long standing member of the JVM team at SAP. His main > areas of expertise are the build system, compilers/porting and > security updates. He's a JDK Committer who has contributed more than > 90 changes within the last two years [1]. > > > > Votes are due by 8 July 2019, 12:00 CET. > > > > Only current JDK-Updates Reviewers [2] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [3]. > > > > Christoph Langer > > > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100 > > [2] http://openjdk.java.net/census#jdk-updates > > [3] http://openjdk.java.net/projects/#reviewer-vote > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Mon Jun 24 10:07:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 24 Jun 2019 12:07:54 +0200 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: Vote: yes On 6/24/19 11:53 AM, Langer, Christoph wrote: > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project Reviewer. -Aleksey From christoph.langer at sap.com Mon Jun 24 13:51:51 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 13:51:51 +0000 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) Message-ID: Hi, please help me reviewing the backport of "JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported". The main reason for backporting this item is that it'll ease further backports which base on that changeset. The patch is quite extensive and hence doesn't fully apply. I had to resolve some rejects and also modify a few other places. Lots of the rejects were about copyright years (especially in the hotspot tests) which could be dropped. Find below the link for a full webrev and an incremental one which only contains my manual changes. I'm currently running it through SAP's test system to check for regressions. Though this change is large and thorough review is tedious, I think the main issue is that we need 2 additional fixes to pull in before taking 8211122: JDK-8205537: Drop of sun.applet package JDK-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization As the names already suggest, both changes remove methods/classes. I'm not 100% sure whether these removals should be done in a JDK11 update releases. I rather think they could because the one is about Java applets which aren't supported with (Open-)JDK 11 anyway and the other removed method claims to only have been added in 9.0.0.4 to be used by the meanwhile removed CORBA modules (removed with JDK11). But I'd really like to have some opinions about these. Here are the links: Original bug: https://bugs.openjdk.java.net/browse/JDK-8211122 Original review discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056397.html Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3c6aa484536c Full webrev: http://cr.openjdk.java.net/~clanger/webrevs/8211122.11u.full/ Incremental Webrev of manual changes: http://cr.openjdk.java.net/~clanger/webrevs/8211122.11u.manual/ Dependencies: JDK-8205537 Bug: https://bugs.openjdk.java.net/browse/JDK-8205537 JDK-8205537 Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/26a17d160081 JDK-8211121 Bug: https://bugs.openjdk.java.net/browse/JDK-8211121 JDK-8211121 Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/f6e15aa9c16e Thanks Christoph From tim.bell at oracle.com Mon Jun 24 14:06:39 2019 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 24 Jun 2019 07:06:39 -0700 Subject: OpenJDK 11u backport of JDK-8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <29e48f22-5966-385c-acde-8bdb4ddc10b4@oracle.com> Message-ID: <5D10D8EF.2040103@oracle.com> On 06/22/19 15:18, Langer, Christoph wrote: > Thanks, David. > > Then I probably did the right thing by manually creating the backport bug. You did the right thing. > cc-ing ops at o.j.n: Maybe you want to have a look why hgupdater failed in this case? hgupdater found a confidential backport record created for JDK 6 and closed as 'will not fix'. hgupdater should not have used that backport, but it did. I can see it in the History in JBS. I undid the changes it made, and I'll file a bug against hgupdater. Tim > > Cheers > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Sonntag, 23. Juni 2019 00:15 >> To: Langer, Christoph ; jdk-updates- >> dev at openjdk.java.net; security-dev >> Subject: Re: OpenJDK 11u backport of JDK-8148188: Enhance the security >> libraries to record events of interest >> >> Hi Christoph, >> >> On 22/06/2019 2:25 pm, Langer, Christoph wrote: >>> Hi, >>> >>> I pushed the backport of JDK-8148188 [0] to jdk11u-dev [1] on Friday. I was >> wondering why no 11.0.5 backport JBS item was created. I then manually >> created JDK-8226636 [2], but the minute I had created it I got an idea what >> the reason for that strange JBS/hgupdater behavior was (all other pushes >> around this commit seem to have correct backport bugs). I now suspect that >> there existed a confidential 11-pool backport item already which was >> resolved by my push. >>> >>> Can anybody within Oracle please check this and if I?m correct, please also >> check whether the backport bug can be made public? I?d then close JDK- >> 8226636 as duplicate. But maybe I?m wrong with that guess? please >> enlighten me ?? >> >> No there was no confidential issue resolved by your push. I would have >> to suspect hgupdater may be down, or else some other hgupdater >> configuration problem. >> >> David >> ------ >> >>> Thanks >>> Christoph >>> >>> [0] https://bugs.openjdk.java.net/browse/JDK-8148188 >>> [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5f98a6a92842 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8226636 >>> From aph at redhat.com Mon Jun 24 14:19:10 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Jun 2019 15:19:10 +0100 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) In-Reply-To: References: Message-ID: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> On 6/24/19 2:51 PM, Langer, Christoph wrote: > please help me reviewing the backport of ?JDK-8211122: Reduce the > number of internal classes made accessible to jdk.unsupported?. The > main reason for backporting this item is that it?ll ease further > backports which base on that changeset. The patch is quite extensive > and hence doesn?t fully apply. I had to resolve some rejects and > also modify a few other places. Lots of the rejects were about > copyright years (especially in the hotspot tests) which could be > dropped. Find below the link for a full webrev and an incremental > one which only contains my manual changes. I?m currently running it > through SAP?s test system to check for regressions. > > > > Though this change is large and thorough review is tedious, I think > the main issue is that we need 2 additional fixes to pull in before > taking 8211122: > > JDK-8205537: Drop of sun.applet package > > JDK-8211121: Remove sun.reflect.ReflectionFactory::newInstanceForSerialization > > As the names already suggest, both changes remove > methods/classes. I?m not 100% sure whether these removals should be > done in a JDK11 update releases. I rather think they could because > the one is about Java applets which aren?t supported with (Open-)JDK > 11 anyway and the other removed method claims to only have been > added in 9.0.0.4 to be used by the meanwhile removed CORBA modules > (removed with JDK11). But I?d really like to have some opinions > about these. > I'm nervous. Although I expect this won't cause any JCK compatibility issues, it is a behavioural change. I wonder if we should consider referring this one to the CSR team. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon Jun 24 14:23:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 14:23:21 +0000 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) In-Reply-To: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> References: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> Message-ID: > I'm nervous. Although I expect this won't cause any JCK compatibility > issues, it is a behavioural change. I wonder if we should consider > referring this one to the CSR team. +1 The original issues didn't have CSRs attached but it really feels CSRish. Let me know whether I shall create CSRs as you're still sorting out the process. Cheers Christoph From thomas.stuefe at gmail.com Mon Jun 24 14:24:33 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jun 2019 16:24:33 +0200 Subject: [11u] RFR 8222015: Small VM.metaspace improvements Message-ID: Dear all, may I please have reviews for this 11u downport fix: Original Issue: https://bugs.openjdk.java.net/browse/JDK-8222015 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/fcf83b204c27 11u dev webrev: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8222015-Small-VM.metaspace-improvements-11-full/webrev Manual changes: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8222015-Small-VM.metaspace-improvements-11-delta.patch This patch makes VM.metaspace "CDS aware" - before this patch, the printout was confusing and misleading if CDS was enabled and bootstrap classes were loaded from a shared archive. Unfortunately the patch did not apply cleanly since in head it is preceded by two larger changes: 1) "8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation" 2) "8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder" First one is a wholesale renaming change, second one reorders initializer lists across the whole VM. Again, I did not want to backport that. I was unsure though. Do you agree with the decision to leave out these two changes? -- Thanks, Thomas From aph at redhat.com Mon Jun 24 14:51:03 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Jun 2019 15:51:03 +0100 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) In-Reply-To: References: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> Message-ID: <22273201-a2df-60d2-d20a-e563bcc084d8@redhat.com> On 6/24/19 3:23 PM, Langer, Christoph wrote: > The original issues didn't have CSRs attached but it really feels CSRish. Let me know whether I shall create CSRs as you're still sorting out the process. Please go ahead. This is a small change that'll be a good test of the process. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rob.mckenna at oracle.com Mon Jun 24 15:41:30 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 24 Jun 2019 16:41:30 +0100 Subject: [13u Communication] jdk13u repo available Message-ID: <20190624154130.GB19779@vimes> I'd like to announce the availibility of the JDK 13 Updates forest at: http://hg.openjdk.java.net/jdk-updates/jdk13u/ Thanks, -Rob From aph at redhat.com Tue Jun 25 08:17:50 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Jun 2019 09:17:50 +0100 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) In-Reply-To: <09f5e50c-13f6-22b2-34a3-a4978a09f3b0@oracle.com> References: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> <09f5e50c-13f6-22b2-34a3-a4978a09f3b0@oracle.com> Message-ID: <4ce7ece3-45e9-96c0-6016-d24c5c3eebe8@redhat.com> On 6/24/19 4:12 PM, Alan Bateman wrote: > On 24/06/2019 15:23, Langer, Christoph wrote: >> : >> The original issues didn't have CSRs attached but it really feels CSRish. Let me know whether I shall create CSRs as you're still sorting out the process. > The sun.applet package was JDK internal so no CSR required to change or > remove anything in that package. That said, we've historically been > cautious about changing internal classes too much in update releases, > mostly because it was never clear what/who might be using them directly. Yes, exactly. There are indeed people providing applet support. I don't know if any of it works on 11, though. > It's a bit easier since we moved the platform to modules but we aren't > yet at the point where the standard and JDK modules are fully > encapsulated at run-time. > > As part of JEP 260 we put sun.reflect.ReflectionFactory into the > "Critical internal API" bucket (with sun.misc.Unsafe and a few others) > as it provides functionality that custom serialization libraries have > been using. I think the CORBA bridge was the main user of > newConstructorForSerialization. We neglected to remove the method in JDK > 11 when removing java.corba module. It was removed in JDK 12 and that > change should probably should have had a CSR (we wouldn't remove > anything from sun.misc.Signal or sun.misc.Unsafe without a CSR). I'm not > involved in JDK updates but I don't think it's a good idea to attempt to > remove this in an update release. I agree. It'd need a big upside to justify the risk. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Jun 25 09:22:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 25 Jun 2019 09:22:28 +0000 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) In-Reply-To: <4ce7ece3-45e9-96c0-6016-d24c5c3eebe8@redhat.com> References: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> <09f5e50c-13f6-22b2-34a3-a4978a09f3b0@oracle.com> <4ce7ece3-45e9-96c0-6016-d24c5c3eebe8@redhat.com> Message-ID: Hi, after Alan's input and contemplating a bit more about this I think we really should not pull the removals to 11. I explored amending the backport of JDK-8211122 to keep the applet classes and the ReflectionFactory method working and found out it's quite trivial. So I'll go that route. Will post a new webrev after all tests pass. Thanks, Christoph > -----Original Message----- > From: Andrew Haley > Sent: Dienstag, 25. Juni 2019 10:18 > To: Alan Bateman ; Langer, Christoph > > Cc: AWT-DEV Mailing List ; Java Core Libs > ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u]: Backport of RFR 8211122: Reduce the number of internal > classes made accessible to jdk.unsupported (and JDK-8205537 and JDK- > 8211121) > > On 6/24/19 4:12 PM, Alan Bateman wrote: > > On 24/06/2019 15:23, Langer, Christoph wrote: > >> : > >> The original issues didn't have CSRs attached but it really feels CSRish. Let > me know whether I shall create CSRs as you're still sorting out the process. > > The sun.applet package was JDK internal so no CSR required to change or > > remove anything in that package. That said, we've historically been > > cautious about changing internal classes too much in update releases, > > mostly because it was never clear what/who might be using them directly. > > Yes, exactly. There are indeed people providing applet support. > I don't know if any of it works on 11, though. > > > It's a bit easier since we moved the platform to modules but we aren't > > yet at the point where the standard and JDK modules are fully > > encapsulated at run-time. > > > > As part of JEP 260 we put sun.reflect.ReflectionFactory into the > > "Critical internal API" bucket (with sun.misc.Unsafe and a few others) > > as it provides functionality that custom serialization libraries have > > been using. I think the CORBA bridge was the main user of > > newConstructorForSerialization. We neglected to remove the method in > JDK > > 11 when removing java.corba module. It was removed in JDK 12 and that > > change should probably should have had a CSR (we wouldn't remove > > anything from sun.misc.Signal or sun.misc.Unsafe without a CSR). I'm not > > involved in JDK updates but I don't think it's a good idea to attempt to > > remove this in an update release. > > I agree. It'd need a big upside to justify the risk. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Jun 25 19:57:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Jun 2019 21:57:43 +0200 Subject: [13u Communication] jdk13u repo available In-Reply-To: <20190624154130.GB19779@vimes> References: <20190624154130.GB19779@vimes> Message-ID: On 6/24/19 5:41 PM, Rob McKenna wrote: > I'd like to announce the availibility of the JDK 13 Updates forest at: > http://hg.openjdk.java.net/jdk-updates/jdk13u/ Tarballs here: https://builds.shipilev.net/workspaces/jdk-updates-jdk13u.tar.xz https://builds.shipilev.net/source-snapshots/jdk-updates-jdk13u.tar.xz Rob, can you briefly explain the purpose of jdk-updates/jdk13u at this point? I assume we can do the usual jdk13u-fix-request dance for anything that is non-urgent and thus not going to jdk/jdk13? Thanks, -Aleksey From shade at redhat.com Tue Jun 25 19:58:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Jun 2019 21:58:57 +0200 Subject: [11u] RFR (S) 8221392: Reduce ConcurrentGCThreads spinning during start up Message-ID: Original RFE and change: https://bugs.openjdk.java.net/browse/JDK-8221392 http://hg.openjdk.java.net/jdk/jdk/rev/2f522c487791 11u patch does not apply cleanly, because there is some context around patch is different in mutexLocker.cpp. I applied the change by hand, and would like someone to eyeball it. Here: http://cr.openjdk.java.net/~shade/8221392/webrev.11u.01/ Testing: tier1 -- Thanks, -Aleksey From rob.mckenna at oracle.com Tue Jun 25 23:28:23 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 26 Jun 2019 00:28:23 +0100 Subject: [13u Communication] jdk13u repo available In-Reply-To: References: <20190624154130.GB19779@vimes> Message-ID: <20190625232823.GB3854@tecra> On 25/06/19 21:57, Aleksey Shipilev wrote: > On 6/24/19 5:41 PM, Rob McKenna wrote: > > I'd like to announce the availibility of the JDK 13 Updates forest at: > > http://hg.openjdk.java.net/jdk-updates/jdk13u/ > > Tarballs here: > https://builds.shipilev.net/workspaces/jdk-updates-jdk13u.tar.xz > https://builds.shipilev.net/source-snapshots/jdk-updates-jdk13u.tar.xz > > Rob, can you briefly explain the purpose of jdk-updates/jdk13u at this point? I assume we can do the > usual jdk13u-fix-request dance for anything that is non-urgent and thus not going to jdk/jdk13? Exactly! -Rob > > Thanks, > -Aleksey > From matthias.baesken at sap.com Wed Jun 26 06:48:42 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Jun 2019 06:48:42 +0000 Subject: RFR [jdk11u] : 8224221: add memprotect calls to event log Message-ID: Hello, please review the downport of 8224221: add memprotect calls to event log to jdk11 . The "good old" patch from jdk7jdk mostly applies nicely . However the changes to src/hotspot/share/utilities/events.hpp had to be adjusted a bit manually because Events.hpp differs a bit when you compare jdk11u and jdk/jdk . Bug/webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8224221_11udev.0/ https://bugs.openjdk.java.net/browse/JDK-8224221 Thanks and best regards, Matthias From christoph.langer at sap.com Wed Jun 26 08:15:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 08:15:56 +0000 Subject: RFR [jdk11u] : 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: Hi Matthias, I eyeballed it and it looks good to me. After it runs without regressions through our test system I guess you are good to go. /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Baesken, Matthias > Sent: Mittwoch, 26. Juni 2019 08:49 > To: 'hotspot-dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Subject: [CAUTION] RFR [jdk11u] : 8224221: add memprotect calls to event > log > > Hello, please review the downport of 8224221: add memprotect calls to > event log to jdk11 . > The "good old" patch from jdk7jdk mostly applies nicely . > However the changes to src/hotspot/share/utilities/events.hpp had to be > adjusted a bit manually because > Events.hpp differs a bit when you compare jdk11u and jdk/jdk . > > > Bug/webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224221_11udev.0/ > > https://bugs.openjdk.java.net/browse/JDK-8224221 > > > Thanks and best regards, Matthias From christoph.langer at sap.com Wed Jun 26 08:20:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 08:20:01 +0000 Subject: [11u] RFR (S) 8221392: Reduce ConcurrentGCThreads spinning during start up In-Reply-To: References: Message-ID: Hi Aleksey, I eyeballed it and could not discover any mistakes. So, good to go from my end. /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Dienstag, 25. Juni 2019 21:59 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR (S) 8221392: Reduce ConcurrentGCThreads spinning > during start up > > Original RFE and change: > https://bugs.openjdk.java.net/browse/JDK-8221392 > http://hg.openjdk.java.net/jdk/jdk/rev/2f522c487791 > > 11u patch does not apply cleanly, because there is some context around > patch is different in > mutexLocker.cpp. I applied the change by hand, and would like someone to > eyeball it. Here: > http://cr.openjdk.java.net/~shade/8221392/webrev.11u.01/ > > Testing: tier1 > > -- > Thanks, > -Aleksey From shade at redhat.com Wed Jun 26 08:37:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Jun 2019 10:37:08 +0200 Subject: [11u] RFR (S) 8221392: Reduce ConcurrentGCThreads spinning during start up In-Reply-To: References: Message-ID: On 6/26/19 10:20 AM, Langer, Christoph wrote: > I eyeballed it and could not discover any mistakes. So, good to go from my end. Thanks. I forgot to put jdk11u-fix-request on it, fixed now! -Aleksey From christoph.langer at sap.com Wed Jun 26 08:56:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 08:56:06 +0000 Subject: [11u] RFR 8222015: Small VM.metaspace improvements In-Reply-To: References: Message-ID: Hi Thomas, thanks for backporting this item down to JDK11. I agree with your decision not to take JDK-8209301 and JDK-8208671 at this point because they are really large and could potentially cause trouble. As far as I could see during your review your changes also fit to the current JDK11u source level but just need some manual shuffle in printCLDMetaspaceInfoClosure.cpp to find the right spot in the file. So, after testing runs without regressions, I'm fine with this ?? Best regards Christoph > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Thomas St?fe > Sent: Montag, 24. Juni 2019 16:25 > To: jdk-updates-dev at openjdk.java.net; Hotspot dev runtime runtime-dev at openjdk.java.net> > Subject: [11u] RFR 8222015: Small VM.metaspace improvements > > Dear all, > > may I please have reviews for this 11u downport fix: > > Original Issue: https://bugs.openjdk.java.net/browse/JDK-8222015 > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/fcf83b204c27 > > 11u dev webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8222015-Small- > VM.metaspace-improvements-11-full/webrev > Manual changes: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8222015-Small- > VM.metaspace-improvements-11-delta.patch > > This patch makes VM.metaspace "CDS aware" - before this patch, the > printout > was confusing and misleading if CDS was enabled and bootstrap classes were > loaded from a shared archive. > > Unfortunately the patch did not apply cleanly since in head it is preceded > by two larger changes: > > 1) "8209301: JVM rename is_anonymous, host_klass to unsafe specific > terminology ahead of Unsafe.defineAnonymousClass deprecation" > 2) "8208671: Runtime, JFR, Serviceability changes to allow enabling > -Wreorder" > First one is a wholesale renaming change, second one reorders initializer > lists across the whole VM. Again, I did not want to backport that. I was > unsure though. Do you agree with the decision to leave out these two > changes? > > -- > > Thanks, Thomas From goetz.lindenmaier at sap.com Wed Jun 26 08:59:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Jun 2019 08:59:54 +0000 Subject: jdk11u closed. Don't push to jdk11u. Message-ID: Hi, The jdk11u repository is closed now. Don't push to jdk11u any more please. On top of tag jdk-11.0.4+9 the closed security changes will be prepared. These will become available after Tuesday, July 16. See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u jdk11u-dev remains open for changes targeted to 11.0.5. Best regards, Goetz. From christoph.langer at sap.com Wed Jun 26 09:10:34 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 09:10:34 +0000 Subject: CFV: New JDK-Updates Committer: Gustavo Romero Message-ID: I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. Votes are due by 19:00 CET July 10, 2019. Only current JDK Updates 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]. Thank you and best regards, Christoph [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() From adinn at redhat.com Wed Jun 26 09:12:13 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 26 Jun 2019 10:12:13 +0100 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: <3519abbb-d6e9-1363-0b8c-4f23babce1b2@redhat.com> Vote: yes On 26/06/2019 10:10, Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From shade at redhat.com Wed Jun 26 09:12:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Jun 2019 11:12:14 +0200 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote: yes On 6/26/19 11:10 AM, Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. From thomas.stuefe at gmail.com Wed Jun 26 09:23:07 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 26 Jun 2019 11:23:07 +0200 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote: yes On Wed, Jun 26, 2019 at 11:11 AM Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK > committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also > reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting > hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a > committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] > http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > > From thomas.stuefe at gmail.com Wed Jun 26 09:23:49 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 26 Jun 2019 11:23:49 +0200 Subject: [11u] RFR 8222015: Small VM.metaspace improvements In-Reply-To: References: Message-ID: Great thanks! On Wed, Jun 26, 2019 at 10:56 AM Langer, Christoph wrote: > Hi Thomas, > > thanks for backporting this item down to JDK11. > > I agree with your decision not to take JDK-8209301 and JDK-8208671 at this > point because they are really large and could potentially cause trouble. As > far as I could see during your review your changes also fit to the current > JDK11u source level but just need some manual shuffle in > printCLDMetaspaceInfoClosure.cpp to find the right spot in the file. > > So, after testing runs without regressions, I'm fine with this ?? > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-runtime-dev > bounces at openjdk.java.net> On Behalf Of Thomas St?fe > > Sent: Montag, 24. Juni 2019 16:25 > > To: jdk-updates-dev at openjdk.java.net; Hotspot dev runtime > runtime-dev at openjdk.java.net> > > Subject: [11u] RFR 8222015: Small VM.metaspace improvements > > > > Dear all, > > > > may I please have reviews for this 11u downport fix: > > > > Original Issue: https://bugs.openjdk.java.net/browse/JDK-8222015 > > Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/fcf83b204c27 > > > > 11u dev webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8222015-Small- > > VM.metaspace-improvements-11-full/webrev > > Manual changes: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8222015-Small- > > VM.metaspace-improvements-11-delta.patch > > > > This patch makes VM.metaspace "CDS aware" - before this patch, the > > printout > > was confusing and misleading if CDS was enabled and bootstrap classes > were > > loaded from a shared archive. > > > > Unfortunately the patch did not apply cleanly since in head it is > preceded > > by two larger changes: > > > > 1) "8209301: JVM rename is_anonymous, host_klass to unsafe specific > > terminology ahead of Unsafe.defineAnonymousClass deprecation" > > 2) "8208671: Runtime, JFR, Serviceability changes to allow enabling > > -Wreorder" > > First one is a wholesale renaming change, second one reorders initializer > > lists across the whole VM. Again, I did not want to backport that. I was > > unsure though. Do you agree with the decision to leave out these two > > changes? > > > > -- > > > > Thanks, Thomas > From sgehwolf at redhat.com Wed Jun 26 09:26:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 Jun 2019 11:26:29 +0200 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: <5a34ff5368890b8b413f34fd43a5ae549ecc4d30.camel@redhat.com> Vote: yes On Wed, 2019-06-26 at 09:10 +0000, Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. Thanks, Severin From matthias.baesken at sap.com Wed Jun 26 10:19:32 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Jun 2019 10:19:32 +0000 Subject: RFR [jdk11u] : 8224221: add memprotect calls to event log In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review ! Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 26. Juni 2019 10:16 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; jdk-updates- > dev at openjdk.java.net > Subject: RE: RFR [jdk11u] : 8224221: add memprotect calls to event log > > Hi Matthias, > > I eyeballed it and it looks good to me. After it runs without regressions > through our test system I guess you are good to go. > > /Christoph > From shade at redhat.com Wed Jun 26 10:34:09 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Jun 2019 12:34:09 +0200 Subject: [11u] RFR 8209186: Rename SimpleThresholdPolicy to TieredThresholdPolicy Message-ID: <6539471b-ca99-a4f4-47f2-a1aa73b85eea@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8209186 http://hg.openjdk.java.net/jdk/jdk/rev/f32e61253792 Patch does not apply to 11u cleanly, because JDK-8222670 backport went in first. This actually highlights the benefit for making the rename early, to fit any future backports (notably JDK-8076988 and JDK-8216375). So, I had to recreate the patch by hand. As in original patch, we move .inline.hpp into .cpp, along with includes. Then we rename SimpleThresholdPolicy -> TieredThresholdPolicy. 11u webrev: http://cr.openjdk.java.net/~shade/8209186/webrev.11u.01/ Testing: tier1 -- Thanks, -Aleksey From zgu at redhat.com Wed Jun 26 11:46:33 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 26 Jun 2019 07:46:33 -0400 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: <48e7e338-d38c-b3d7-4375-31abe1f4d779@redhat.com> Vote: yes. -Zhengyu On 6/26/19 5:10 AM, Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > From christoph.langer at sap.com Wed Jun 26 12:59:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 12:59:41 +0000 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf Message-ID: I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: Severin has contributed ~60 changesets[1] to OpenJDK since 2015. Backporting work exceeds 10. This includes jdk11u and jdk8u[2]. Some backports were non-trivial. These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. Votes are due by 10 July 2019, 18:00 CET. Only current JDK-Updates Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Christoph Langer [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() [3] http://openjdk.java.net/census#jdk-updates [4] http://openjdk.java.net/projects/#reviewer-vote From thomas.stuefe at gmail.com Wed Jun 26 13:05:20 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 26 Jun 2019 15:05:20 +0200 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes On Wed, Jun 26, 2019 at 3:00 PM Langer, Christoph wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project > Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his > nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the > call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > > From zgu at redhat.com Wed Jun 26 13:06:35 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 26 Jun 2019 09:06:35 -0400 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: <7448c875-c645-5038-1d53-bdb3524316ed@redhat.com> Vote: yes. -Zhengyu On 6/26/19 8:59 AM, Langer, Christoph wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > From christoph.langer at sap.com Wed Jun 26 13:13:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 13:13:10 +0000 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes From: Langer, Christoph Sent: Mittwoch, 26. Juni 2019 15:00 To: jdk-updates-dev at openjdk.java.net Cc: Severin Gehwolf Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: Severin has contributed ~60 changesets[1] to OpenJDK since 2015. Backporting work exceeds 10. This includes jdk11u and jdk8u[2]. Some backports were non-trivial. These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. Votes are due by 10 July 2019, 18:00 CET. Only current JDK-Updates Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Christoph Langer [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() [3] http://openjdk.java.net/census#jdk-updates [4] http://openjdk.java.net/projects/#reviewer-vote From christoph.langer at sap.com Wed Jun 26 13:13:49 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 13:13:49 +0000 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote: yes From: Langer, Christoph Sent: Mittwoch, 26. Juni 2019 11:11 To: jdk-updates-dev at openjdk.java.net Cc: Gustavo Romero Subject: CFV: New JDK-Updates Committer: Gustavo Romero I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. Votes are due by 19:00 CET July 10, 2019. Only current JDK Updates 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]. Thank you and best regards, Christoph [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() From christoph.langer at sap.com Wed Jun 26 13:14:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 13:14:15 +0000 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: Vote: yes From: Langer, Christoph Sent: Montag, 24. Juni 2019 11:54 To: jdk-updates-dev at openjdk.java.net Cc: Baesken, Matthias Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project Reviewer. Matthias has just recently become a reviewer in the JDK project. I think the same criteria that qualified his nomination in the JDK project apply for a reviewer nomination in the JDK-Updates project as well: Matthias is a long standing member of the JVM team at SAP. His main areas of expertise are the build system, compilers/porting and security updates. He's a JDK Committer who has contributed more than 90 changes within the last two years [1]. Votes are due by 8 July 2019, 12:00 CET. Only current JDK-Updates Reviewers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [3]. Christoph Langer [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100 [2] http://openjdk.java.net/census#jdk-updates [3] http://openjdk.java.net/projects/#reviewer-vote From daniel.daugherty at oracle.com Wed Jun 26 13:22:39 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 26 Jun 2019 09:22:39 -0400 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote: yes Dan On 6/26/19 5:10 AM, Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > > From adinn at redhat.com Wed Jun 26 13:34:42 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 26 Jun 2019 14:34:42 +0100 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes On 26/06/2019 13:59, Langer, Christoph wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.stuefe at gmail.com Wed Jun 26 13:35:09 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 26 Jun 2019 15:35:09 +0200 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: Vote: yes On Mon, Jun 24, 2019 at 11:54 AM Langer, Christoph wrote: > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project > Reviewer. > > > > Matthias has just recently become a reviewer in the JDK project. I think > the same criteria that qualified his nomination in the JDK project apply > for a reviewer nomination in the JDK-Updates project as well: > > > > Matthias is a long standing member of the JVM team at SAP. His main areas > of expertise are the build system, compilers/porting and security updates. > He's a JDK Committer who has contributed more than 90 changes within the > last two years [1]. > > > > Votes are due by 8 July 2019, 12:00 CET. > > > > Only current JDK-Updates Reviewers [2] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [3]. > > > > Christoph Langer > > > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100 > > [2] http://openjdk.java.net/census#jdk-updates > > [3] http://openjdk.java.net/projects/#reviewer-vote > > From christoph.langer at sap.com Wed Jun 19 07:43:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 19 Jun 2019 07:43:03 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Jiangli, sounds good to me. Thanks for your effort with this ?? Cheers Christoph From: Jiangli Zhou Sent: Mittwoch, 19. Juni 2019 00:49 To: Langer, Christoph Cc: Michael Rasmussen ; jdk-updates-dev at openjdk.java.net; Ioi Lam Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? https://bugs.openjdk.java.net/browse/JDK-8210926 can be applied cleanly with no dependencies. I've added jdk11u-fix-request. Best regards, Jiangli On Tue, Jun 18, 2019 at 3:25 PM Jiangli Zhou > wrote: Hi Christoph and others, I did investigations for backporting the JDK-8212200 and JDK-8213250 changes. There are some dependencies on Java object archiving work. The cleanest way to handle the backports is to pull in all the dependencies one by one to OpenJDK 11. It helps minimize the merge changes. It also helps JVM startup time in JDK 11 by pulling in the additional optimizations. Thoughts from anyone? Best regards, Jiangli On Tue, Jun 18, 2019 at 6:20 AM Langer, Christoph > wrote: Hi Jiangli, thanks for taking this over. I tried to pick a few of the dependent fixes but it got too much for me. ?? Best regards Christoph From: Jiangli Zhou > Sent: Dienstag, 18. Juni 2019 01:14 To: Langer, Christoph > Cc: Michael Rasmussen >; jdk-updates-dev at openjdk.java.net; Ioi Lam > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? Hi Christoph, I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that needs to be backported first, but most can be done cleanly. There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, which I think should be backported to JDK 11 as well. The issue can surface up when the default CDS is used with JVMTI. I'll start from the easy ones first. Best regards, Jiangli On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph > wrote: Hi Michael, I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able to do them. The code level between current JDK11u hotspot and the jdk/jdk repository at the time the patches were pushed (JDK12) has diverged too much. So, it's not a simple resolve and test thing. People with more experience in that area will have to do it. I don't have the required expertise and also no time to dig deeper into it. So, maybe somebody is willing to step up here - otherwise I'm afraid these bugs need to remain unfixed in OpenJDK 11 for the time being. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 20. M?rz 2019 16:13 > To: 'Ioi Lam' > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > Hi Ioi, > > thanks again for the update. I'll take care of these backports then. > > Thanks > Christoph > > > -----Original Message----- > > From: Ioi Lam > > > Sent: Dienstag, 19. M?rz 2019 22:38 > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > The 3 issues that I wanted to backport were: > > > > Issue BP-of Synopsis > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > allocation failure > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > java.lang.object is redefined by JVMTI agent > > > > They are all backport issues related to CDS with (fixVersion = 11-pool). > > Only the last one is related to JVMTI, but the other 2 are kind of > > serious as well. But due to reassignment, I wasn't able to do the > > backport :-( > > > > Thanks > > - Ioi > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > Hi Ioi, > > > > > > ok, thanks for that information. > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build > > failure after the former one. And what's the 3rd issue? > > > > > > Thanks > > > Christoph > > > > > >> -----Original Message----- > > >> From: Ioi Lam > > > >> Sent: Montag, 18. M?rz 2019 19:27 > > >> To: Langer, Christoph > > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > >> > > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > >> > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > >> assigned engineer for those bugs) so I think it's best for the openjdk > > >> community to pick up these backports. > > >> > > >> Thanks > > >> > > >> - Ioi > > >> > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > >>> Hi Ioi, > > >>> > > >>> I'd like to ping you again on this one. What are your current plans on > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > >> whatever needs to go with it? Ideally you still want to do it, but if not I'd > > >> appreciate if you could let us know. > > >>> Thanks a lot in advance > > >>> Christoph > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: jdk-updates-dev > bounces at openjdk.java.net> > > >> On > > >>>> Behalf Of Ioi Lam > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > >>>> To: jdk-updates-dev at openjdk.java.net > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>> > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to post the > > >>>> requests this week. > > >>>> > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > >>>> > > >>>> Thanks > > >>>> > > >>>> - Ioi > > >>>> > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > >>>>> Hi, > > >>>>> > > >>>>> The fact a downport bug was opened does not matter, > > >>>>> you could still flag jdk11u-fix-request and just push it > > >>>>> if approved. This bug will then be closed as it is flagged 11-pool. > > >>>>> > > >>>>> More gentle it would be to ask Ioi what's going on ... > > >>>>> > > >>>>> Best regards, > > >>>>> Goetz. > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: jdk-updates-dev > >> bounces at openjdk.java.net> > > >>>> On > > >>>>>> Behalf Of Volker Simonis > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > >>>>>> To: Michael Rasmussen > > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>>>> > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > >>>>>> > wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I was wondering if there are any plans to backport > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > >> been > > >>>>>> created, but don't know if there are any active plans to actually do > it? > > >>>>>> Hi Michael, > > >>>>>> > > >>>>>> I actually don't really understand what this means. Usually, you do > a > > >>>>>> down-port by first requesting it on the original bug by applying a > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > approved > > >>>>>> (by application of a "jdku-fix-yes" tag), the > corresponding > > >>>>>> fix can be pushed to the updates repository. This push > automatically > > >>>>>> triggers the creation of the corresponding backport issue in JBS. > > >>>>>> > > >>>>>> I don't know what it means for the downport process [1] if > > somebody > > >>>>>> (apparently manually) creates a backport issue like > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > >>>>>> > > >>>>>> Regards, > > >>>>>> Volker > > >>>>>> > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > >>>>>> > > >>>>>>> Kind regards > > >>>>>>> /Michael From christoph.langer at sap.com Mon Jun 24 05:58:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jun 2019 05:58:46 +0000 Subject: [11u] Backport of fix for CDS and JVM-TI agent crash ? In-Reply-To: References: <2d9733c7-f629-1838-856e-dc06e908a20f@oracle.com> Message-ID: Hi Jiangli, thank you very much for this update and all the effort in this. Seems like a lot of work but for sure the gain will be nice. ?? I hope all of the dependent items are appropriate for JDK11 u backport. I guess I won?t be able to help you too much with these as I?m currently focusing on the stuff that Oracle has brought to 11.0.5. This also contains quite some non-trivial ones? Best regards Christoph From: Jiangli Zhou Sent: Sonntag, 23. Juni 2019 22:34 To: Langer, Christoph Cc: Michael Rasmussen ; jdk-updates-dev at openjdk.java.net; Ioi Lam Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? Hi Christoph, Just an update on this effort: https://bugs.openjdk.java.net/browse/JDK-8210926 has been backported to 11u. I've also labeled all dependencies (with google-interest) related to JDK-8212200 and JDK-8213250, including additional bug fixes and enhancements pulled in for the dependencies. There are total 33 bug fixes and enhances. I'll go through them to backport to 11u. Please feel free to take any of them if you can. With this set of fixes and enhancements, it will bring in the startup performance improvements using Java object archiving (enabled with the default CDS) to OpenJDK 11 update. Users will see a nice speedup with the JVM startup time. Best regards, Jiangli On Wed, Jun 19, 2019 at 7:44 AM Jiangli Zhou > wrote: My pleasure??. Best regards, Jiangli On Wed, Jun 19, 2019 at 12:43 AM Langer, Christoph > wrote: Hi Jiangli, sounds good to me. Thanks for your effort with this ?? Cheers Christoph From: Jiangli Zhou > Sent: Mittwoch, 19. Juni 2019 00:49 To: Langer, Christoph > Cc: Michael Rasmussen >; jdk-updates-dev at openjdk.java.net; Ioi Lam > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? https://bugs.openjdk.java.net/browse/JDK-8210926 can be applied cleanly with no dependencies. I've added jdk11u-fix-request. Best regards, Jiangli On Tue, Jun 18, 2019 at 3:25 PM Jiangli Zhou > wrote: Hi Christoph and others, I did investigations for backporting the JDK-8212200 and JDK-8213250 changes. There are some dependencies on Java object archiving work. The cleanest way to handle the backports is to pull in all the dependencies one by one to OpenJDK 11. It helps minimize the merge changes. It also helps JVM startup time in JDK 11 by pulling in the additional optimizations. Thoughts from anyone? Best regards, Jiangli On Tue, Jun 18, 2019 at 6:20 AM Langer, Christoph > wrote: Hi Jiangli, thanks for taking this over. I tried to pick a few of the dependent fixes but it got too much for me. ?? Best regards Christoph From: Jiangli Zhou > Sent: Dienstag, 18. Juni 2019 01:14 To: Langer, Christoph > Cc: Michael Rasmussen >; jdk-updates-dev at openjdk.java.net; Ioi Lam > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? Hi Christoph, I'll help out (maybe slow). JDK-8213250 has quite a few dependencies that needs to be backported first, but most can be done cleanly. There is also the https://bugs.openjdk.java.net/browse/JDK-8210926, which I think should be backported to JDK 11 as well. The issue can surface up when the default CDS is used with JVMTI. I'll start from the easy ones first. Best regards, Jiangli On Mon, Jun 17, 2019 at 8:17 AM Langer, Christoph > wrote: Hi Michael, I looked into backports for JDK-8212200 and JDK-8213250 but I'm not able to do them. The code level between current JDK11u hotspot and the jdk/jdk repository at the time the patches were pushed (JDK12) has diverged too much. So, it's not a simple resolve and test thing. People with more experience in that area will have to do it. I don't have the required expertise and also no time to dig deeper into it. So, maybe somebody is willing to step up here - otherwise I'm afraid these bugs need to remain unfixed in OpenJDK 11 for the time being. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 20. M?rz 2019 16:13 > To: 'Ioi Lam' > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > Subject: RE: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > Hi Ioi, > > thanks again for the update. I'll take care of these backports then. > > Thanks > Christoph > > > -----Original Message----- > > From: Ioi Lam > > > Sent: Dienstag, 19. M?rz 2019 22:38 > > To: Langer, Christoph > > > Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > > > > Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > > > The 3 issues that I wanted to backport were: > > > > Issue BP-of Synopsis > > JDK-8212991 8212205 VM asserts after CDS archive has been unmapped > > JDK-8213273 8213250 CDS archive creation aborts due to metaspace object > > allocation failure > > JDK-8213164 8212200 assert(on_stack()) failed when shared > > java.lang.object is redefined by JVMTI agent > > > > They are all backport issues related to CDS with (fixVersion = 11-pool). > > Only the last one is related to JVMTI, but the other 2 are kind of > > serious as well. But due to reassignment, I wasn't able to do the > > backport :-( > > > > Thanks > > - Ioi > > > > On 3/18/19 2:08 PM, Langer, Christoph wrote: > > > Hi Ioi, > > > > > > ok, thanks for that information. > > > > > > Can you let us know, what exactly these 3 bugs were, that should be > > backported? I guess it's about JDK-8212200, JDK-8213182 which fixes a build > > failure after the former one. And what's the 3rd issue? > > > > > > Thanks > > > Christoph > > > > > >> -----Original Message----- > > >> From: Ioi Lam > > > >> Sent: Montag, 18. M?rz 2019 19:27 > > >> To: Langer, Christoph > > > >> Cc: jdk-updates-dev at openjdk.java.net; Michael Rasmussen > > >> > > > >> Subject: Re: [11u] Backport of fix for CDS and JVM-TI agent crash ? > > >> > > >> Hi Christoph, I have been reassigned (and I've removed myself as the > > >> assigned engineer for those bugs) so I think it's best for the openjdk > > >> community to pick up these backports. > > >> > > >> Thanks > > >> > > >> - Ioi > > >> > > >> On 3/17/19 11:46 PM, Langer, Christoph wrote: > > >>> Hi Ioi, > > >>> > > >>> I'd like to ping you again on this one. What are your current plans on > > >> backporting https://bugs.openjdk.java.net/browse/JDK-8212200 and > > >> whatever needs to go with it? Ideally you still want to do it, but if not I'd > > >> appreciate if you could let us know. > > >>> Thanks a lot in advance > > >>> Christoph > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: jdk-updates-dev > bounces at openjdk.java.net> > > >> On > > >>>> Behalf Of Ioi Lam > > >>>> Sent: Dienstag, 29. Januar 2019 01:33 > > >>>> To: jdk-updates-dev at openjdk.java.net > > >>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>> > > >>>> There are CDS 3 bugs that I plan to backport to 11. I hope to post the > > >>>> requests this week. > > >>>> > > >>>> https://bugs.openjdk.java.net/issues/?filter=36209 > > >>>> > > >>>> Thanks > > >>>> > > >>>> - Ioi > > >>>> > > >>>> On 1/28/19 8:35 AM, Lindenmaier, Goetz wrote: > > >>>>> Hi, > > >>>>> > > >>>>> The fact a downport bug was opened does not matter, > > >>>>> you could still flag jdk11u-fix-request and just push it > > >>>>> if approved. This bug will then be closed as it is flagged 11-pool. > > >>>>> > > >>>>> More gentle it would be to ask Ioi what's going on ... > > >>>>> > > >>>>> Best regards, > > >>>>> Goetz. > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: jdk-updates-dev > >> bounces at openjdk.java.net> > > >>>> On > > >>>>>> Behalf Of Volker Simonis > > >>>>>> Sent: Monday, January 28, 2019 5:02 PM > > >>>>>> To: Michael Rasmussen > > > >>>>>> Cc: jdk-updates-dev at openjdk.java.net > > >>>>>> Subject: Re: Backport of fix for CDS and JVM-TI agent crash ? > > >>>>>> > > >>>>>> On Mon, Jan 28, 2019 at 4:17 PM Michael Rasmussen > > >>>>>> > wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> I was wondering if there are any plans to backport > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 to jdk11u. > > >>>>>>> I can see https://bugs.openjdk.java.net/browse/JDK-8213164 has > > >> been > > >>>>>> created, but don't know if there are any active plans to actually do > it? > > >>>>>> Hi Michael, > > >>>>>> > > >>>>>> I actually don't really understand what this means. Usually, you do > a > > >>>>>> down-port by first requesting it on the original bug by applying a > > >>>>>> "jdku-fix-request" tag. Once the downport will be > > approved > > >>>>>> (by application of a "jdku-fix-yes" tag), the > corresponding > > >>>>>> fix can be pushed to the updates repository. This push > automatically > > >>>>>> triggers the creation of the corresponding backport issue in JBS. > > >>>>>> > > >>>>>> I don't know what it means for the downport process [1] if > > somebody > > >>>>>> (apparently manually) creates a backport issue like > > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213164 ? > > >>>>>> > > >>>>>> Regards, > > >>>>>> Volker > > >>>>>> > > >>>>>> [1] http://openjdk.java.net/projects/jdk-updates/approval.html > > >>>>>> > > >>>>>>> Kind regards > > >>>>>>> /Michael From Alan.Bateman at oracle.com Mon Jun 24 15:12:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Jun 2019 16:12:40 +0100 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121) In-Reply-To: References: <77fea22c-c701-7965-0b7a-067a7a5cb102@redhat.com> Message-ID: <09f5e50c-13f6-22b2-34a3-a4978a09f3b0@oracle.com> On 24/06/2019 15:23, Langer, Christoph wrote: > : > The original issues didn't have CSRs attached but it really feels CSRish. Let me know whether I shall create CSRs as you're still sorting out the process. The sun.applet package was JDK internal so no CSR required to change or remove anything in that package. That said, we've historically been cautious about changing internal classes too much in update releases, mostly because it was never clear what/who might be using them directly. It's a bit easier since we moved the platform to modules but we aren't yet at the point where the standard and JDK modules are fully encapsulated at run-time. As part of JEP 260 we put sun.reflect.ReflectionFactory into the "Critical internal API" bucket (with sun.misc.Unsafe and a few others) as it provides functionality that custom serialization libraries have been using. I think the CORBA bridge was the main user of newConstructorForSerialization. We neglected to remove the method in JDK 11 when removing java.corba module. It was removed in JDK 12 and that change should probably should have had a CSR (we wouldn't remove anything from sun.misc.Signal or sun.misc.Unsafe without a CSR). I'm not involved in JDK updates but I don't think it's a good idea to attempt to remove this in an update release. -Alan From neugens at redhat.com Wed Jun 26 13:53:57 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 26 Jun 2019 15:53:57 +0200 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Wed, Jun 26, 2019 at 11:11 AM Langer, Christoph wrote: > > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From vladimir.kozlov at oracle.com Wed Jun 26 14:22:17 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2019 07:22:17 -0700 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote yes. Thanks Vladimir > On Jun 26, 2019, at 2:10 AM, Langer, Christoph wrote: > > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > From vladimir.kozlov at oracle.com Wed Jun 26 14:24:51 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2019 07:24:51 -0700 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: <2151DF47-1B66-46B5-B1E4-3A466BFD3446@oracle.com> Vote yes. Thanks Vladimir > On Jun 24, 2019, at 2:53 AM, Langer, Christoph wrote: > > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project Reviewer. > > > > Matthias has just recently become a reviewer in the JDK project. I think the same criteria that qualified his nomination in the JDK project apply for a reviewer nomination in the JDK-Updates project as well: > > > > Matthias is a long standing member of the JVM team at SAP. His main areas of expertise are the build system, compilers/porting and security updates. He's a JDK Committer who has contributed more than 90 changes within the last two years [1]. > > > > Votes are due by 8 July 2019, 12:00 CET. > > > > Only current JDK-Updates Reviewers [2] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [3]. > > > > Christoph Langer > > > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100 > > [2] http://openjdk.java.net/census#jdk-updates > > [3] http://openjdk.java.net/projects/#reviewer-vote > From vladimir.kozlov at oracle.com Wed Jun 26 14:25:28 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Jun 2019 07:25:28 -0700 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote yes. Thanks Vladimir > On Jun 26, 2019, at 5:59 AM, Langer, Christoph wrote: > > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > From christoph.langer at sap.com Wed Jun 26 15:03:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 15:03:38 +0000 Subject: [11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported Message-ID: Hi, next try, here we go again... I'd like to backport "JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported". The main reason for backporting this item is that it'll ease further backports which base on that changeset (e.g. JDK-8216039). The patch is quite extensive and so doesn't fully apply. I had to resolve some rejects and also modify a few other places. Lots of the rejects were about copyright years (especially in the hotspot tests) which could be dropped. Find below the link for a full webrev and an incremental one which only contains my manual changes. Testing in SAP's test system does not show regressions. My initial proposal for the backport of this change assumed that we could take JDK-8205537 and JDK-8211121 as prerequisites [0]. I have to step back from that idea because both changes would remove stuff which you probably don't want to remove in an update release. The modifications to this patch to accommodate for the missing prerequisites are quite minor, though. In java.desktop's sun.applet.AppletSecurity.java we only have to include the SharedSecrets from the new package jdk.internal.access instead of jdk.internal.misc. To keep jdk.unsupported's sun.reflect.ReflectionFactory::newInstanceForSerialization method working without having to open up jdk.internal.access for jdk.unsupported (which was the whole purpose of this change) we need to keep little wrapper stubs for jdk.internal.misc.JavaSecurityAccess and jdk.internal.misc.SharedSecrets. Here are the links: Original bug: https://bugs.openjdk.java.net/browse/JDK-8211122 Original review discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056397.html Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3c6aa484536c Full webrev: http://cr.openjdk.java.net/~clanger/webrevs/8211122.11u.full.1/ Incremental Webrev of manual changes: http://cr.openjdk.java.net/~clanger/webrevs/8211122.11u.manual.1/ Rejects of the original apply: http://cr.openjdk.java.net/~clanger/webrevs/8211122.rejects.patch Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001316.html From vladimir.x.ivanov at oracle.com Wed Jun 26 15:06:37 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Jun 2019 18:06:37 +0300 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: <3edac569-4ef4-0427-8a03-ebdde4a9f0a8@oracle.com> Vote: yes On 26/06/2019 12:10, Langer, Christoph wrote: > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. From vladimir.x.ivanov at oracle.com Wed Jun 26 15:06:53 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Jun 2019 18:06:53 +0300 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: Vote: yes On 24/06/2019 12:53, Langer, Christoph wrote: > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project Reviewer. From vladimir.x.ivanov at oracle.com Wed Jun 26 15:07:09 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Jun 2019 18:07:09 +0300 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: <659e93ce-5270-606d-ebf6-7189eaa94b21@oracle.com> Vote: yes On 26/06/2019 15:59, Langer, Christoph wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. From hohensee at amazon.com Wed Jun 26 15:12:50 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 Jun 2019 15:12:50 +0000 Subject: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: <86F9BE17-D810-461A-90A3-DD06E411B301@amazon.com> Vote: yes ?On 6/26/19, 6:00 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: Severin has contributed ~60 changesets[1] to OpenJDK since 2015. Backporting work exceeds 10. This includes jdk11u and jdk8u[2]. Some backports were non-trivial. These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. Votes are due by 10 July 2019, 18:00 CET. Only current JDK-Updates Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Christoph Langer [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() [3] http://openjdk.java.net/census#jdk-updates [4] http://openjdk.java.net/projects/#reviewer-vote From hohensee at amazon.com Wed Jun 26 15:14:32 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 Jun 2019 15:14:32 +0000 Subject: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: <1F95C18A-1F4D-479F-8EB5-6B498E2A534D@amazon.com> Vote: yes ?On 6/26/19, 2:11 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. Votes are due by 19:00 CET July 10, 2019. Only current JDK Updates 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]. Thank you and best regards, Christoph [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() From christoph.langer at sap.com Wed Jun 26 15:30:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Jun 2019 15:30:12 +0000 Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates Message-ID: Hi, please help reviewing the backport of JDK- 8215694: keytool cannot generate RSASSA-PSS certificates. The patch doesn't apply cleanly but the rejects are only minor. The Item is needed as prerequisite to apply JDK-8216039. Bug: https://bugs.openjdk.java.net/browse/JDK-8215694 Original Change: http://hg.openjdk.java.net/jdk/jdk12/rev/bdb29aa5fd31 Rejects when applying original change: http://cr.openjdk.java.net/~clanger/webrevs/8215694.rejects.patch Full Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ Incremental Webrev of added modifications: http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ Thanks Christoph From adinn at redhat.com Wed Jun 26 15:36:40 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 26 Jun 2019 16:36:40 +0100 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: <07120763-fe54-0700-adc9-7c34a44cb47c@redhat.com> Vote: yes On 26/06/2019 13:59, Langer, Christoph wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From neugens at redhat.com Wed Jun 26 15:38:04 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 26 Jun 2019 17:38:04 +0200 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario On Wed, Jun 26, 2019 at 3:00 PM Langer, Christoph wrote: > > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jianglizhou at google.com Wed Jun 26 18:33:25 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 26 Jun 2019 11:33:25 -0700 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: Yes Best Regards, Jiangli On Wed, Jun 26, 2019 at 6:00 AM Langer, Christoph wrote: > > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote > From jianglizhou at google.com Wed Jun 26 18:34:27 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 26 Jun 2019 11:34:27 -0700 Subject: New JDK-Updates Committer: Gustavo Romero In-Reply-To: <1F95C18A-1F4D-479F-8EB5-6B498E2A534D@amazon.com> References: <1F95C18A-1F4D-479F-8EB5-6B498E2A534D@amazon.com> Message-ID: Vote: Yes Best Regards, Jiangli On Wed, Jun 26, 2019 at 8:15 AM Hohensee, Paul wrote: > > Vote: yes > > ?On 6/26/19, 2:11 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: > > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk-updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gromero at linux.vnet.ibm.com%22))+and+not+merge() > > > > From jianglizhou at google.com Wed Jun 26 18:37:22 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 26 Jun 2019 11:37:22 -0700 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: Vote: Yes Best Regards, Jiangli On Mon, Jun 24, 2019 at 2:54 AM Langer, Christoph wrote: > > I hereby nominate Matthias Baesken (mbaesken) to JDK Updates Project Reviewer. > > > > Matthias has just recently become a reviewer in the JDK project. I think the same criteria that qualified his nomination in the JDK project apply for a reviewer nomination in the JDK-Updates project as well: > > > > Matthias is a long standing member of the JVM team at SAP. His main areas of expertise are the build system, compilers/porting and security updates. He's a JDK Committer who has contributed more than 90 changes within the last two years [1]. > > > > Votes are due by 8 July 2019, 12:00 CET. > > > > Only current JDK-Updates Reviewers [2] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [3]. > > > > Christoph Langer > > > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100 > > [2] http://openjdk.java.net/census#jdk-updates > > [3] http://openjdk.java.net/projects/#reviewer-vote > From serguei.spitsyn at oracle.com Wed Jun 26 21:42:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 14:42:30 -0700 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: <34c32b67-1167-4a98-a28a-0183b23ae31e@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Wed Jun 26 21:43:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 14:43:20 -0700 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes From serguei.spitsyn at oracle.com Wed Jun 26 21:44:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Jun 2019 14:44:30 -0700 Subject: CFV: New JDK-Updates Reviewer: Matthias Baesken In-Reply-To: References: Message-ID: <1986f87a-e0c3-eb30-4beb-ee710d0d6012@oracle.com> Vote: yes From gnu.andrew at redhat.com Thu Jun 27 04:09:15 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 27 Jun 2019 05:09:15 +0100 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: References: Message-ID: <14d0ce75-b26c-4993-9b96-c11681b4629c@redhat.com> On 28/05/2019 08:21, Langer, Christoph wrote: > Hi, > > please review this backport of JDK-8208698: Improved ECC Implementation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ > > The patch did not apply cleanly because there were conflicts in src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. Unfortunately, JDK-8205476 can not be downported as prerequisite because it brings a behavioral change and is associated with a CSR. So I resolved the rejects manually. I add the rejects below. > > Thanks > Christoph > > I'm just looking over this in backporting to 8u. You mention not being able to include the JDK-8205476 change, but then it is included in the patch. JDK-8205476 is essentially: @@ -127,7 +127,9 @@ try { - return deriveKey(s, publicValue, encodedParams); + byte[] result = deriveKey(s, publicValue, encodedParams); + publicValue = null; + return result; } catch (GeneralSecurityException e) { throw new ProviderException("Could not derive key", e); The same change is made in 11u by adopting the line in the 8208698 patch verbatim: - try { - - return deriveKey(s, publicValue, encodedParams); - - } catch (GeneralSecurityException e) { - throw new ProviderException("Could not derive key", e); - } - + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); + byte[] result = resultOpt.orElseGet( + () -> deriveKeyNative(privateKey, publicKey) + ); + publicKey = null; + return result; I think this should actually be: return resultOpt.orElseGet(() -> deriveKeyNative(privateKey, publicKey)); if we want to avoid the JDK-8205476 change of nulling publicKey. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Thu Jun 27 07:11:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 27 Jun 2019 07:11:07 +0000 Subject: CFV: New JDK Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: Vote: yes Best regards, goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Wednesday, June 26, 2019 3:00 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] CFV: New JDK Updates Reviewer: Severin Gehwolf > > I hereby nominate Severin Gehwolf (sgehwolf) to JDK Updates Project > Reviewer. > > > > Severin has just recently become a reviewer in the JDK project. I cite his > nomination mail [0]: > > > > Severin has contributed ~60 changesets[1] to OpenJDK since 2015. > > Backporting work exceeds 10. This includes jdk11u and > > jdk8u[2]. Some backports were non-trivial. > > > > These references and his engagement in the JDK Updates project justify the > call to make him a JDK Updates reviewer as well. > > > > Votes are due by 10 July 2019, 18:00 CET. > > > > Only current JDK-Updates Reviewers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Three-Vote Consensus voting instructions, see [4]. > > > > Christoph Langer > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002872.html > > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(sgehw > olf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [2] > https://hg.openjdk.java.net/jdk8u/jdk8u/log?revcount=200&rev=(author(sg > ehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(auth > or(sgehwolf)+or+desc(%22sgehwolf at redhat.com%22))+and+not+merge() > > [3] http://openjdk.java.net/census#jdk-updates > > [4] http://openjdk.java.net/projects/#reviewer-vote From goetz.lindenmaier at sap.com Thu Jun 27 07:13:24 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 27 Jun 2019 07:13:24 +0000 Subject: CFV: New JDK-Updates Committer: Gustavo Romero In-Reply-To: References: Message-ID: Vote: yes Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Wednesday, June 26, 2019 11:11 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] CFV: New JDK-Updates Committer: Gustavo Romero > > I hereby nominate Gustavo Romero (gromero) to JDK Updates Committer. > > > > Gustavo works for the Linux on Power team at IBM and has been a JDK > committer for quite a while now. > > He has contributed more than 30 changes to the OpenJDK which have also > reached JDK Updates [3]. > > His work is mostly related to the IBM power platform, e.g. supporting > hardware transactional memory and NUMA support. > > As he's also working on backporting fixes to JDK Updates he should be a > committer in that project, too. > > > > Votes are due by 19:00 CET July 10, 2019. > > > > Only current JDK Updates 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]. > > > > Thank you and best regards, > > Christoph > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk- > updates/jdk13u/log?revcount=200&rev=(author(gromero)+or+desc(%22gro > mero at linux.vnet.ibm.com%22))+and+not+merge() > From christoph.langer at sap.com Thu Jun 27 09:30:09 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 27 Jun 2019 09:30:09 +0000 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: <14d0ce75-b26c-4993-9b96-c11681b4629c@redhat.com> References: <14d0ce75-b26c-4993-9b96-c11681b4629c@redhat.com> Message-ID: Dang, you're right! I'll open an issue and put it out for review. I guess you'll want to push it in your closed repository? BTW: I just reported another regression which affects 11.0.4 as well: https://bugs.openjdk.java.net/browse/JDK-8226876 It's "just" a Java level assert but maybe we'll need to take some (backout?) action here for 11.0.4, too... Thanks Christoph > -----Original Message----- > From: Andrew John Hughes > Sent: Donnerstag, 27. Juni 2019 06:09 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: security-dev > Subject: Re: [11u] RFR: 8208698: Improved ECC Implementation > > On 28/05/2019 08:21, Langer, Christoph wrote: > > Hi, > > > > please review this backport of JDK-8208698: Improved ECC > Implementation. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208698 > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/ > > > > The patch did not apply cleanly because there were conflicts in > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java > due to JDK-8205476 which is part of jdk/jdk but not of jdk11u-dev. > Unfortunately, JDK-8205476 can not be downported as prerequisite because > it brings a behavioral change and is associated with a CSR. So I resolved the > rejects manually. I add the rejects below. > > > > Thanks > > Christoph > > > > > > I'm just looking over this in backporting to 8u. You mention not being > able to include the JDK-8205476 change, but then it is included in the > patch. > > JDK-8205476 is essentially: > > @@ -127,7 +127,9 @@ > > try { > > - return deriveKey(s, publicValue, encodedParams); > + byte[] result = deriveKey(s, publicValue, encodedParams); > + publicValue = null; > + return result; > > } catch (GeneralSecurityException e) { > throw new ProviderException("Could not derive key", e); > > The same change is made in 11u by adopting the line in the 8208698 patch > verbatim: > > - try { > - > - return deriveKey(s, publicValue, encodedParams); > - > - } catch (GeneralSecurityException e) { > - throw new ProviderException("Could not derive key", e); > - } > - > + Optional resultOpt = deriveKeyImpl(privateKey, publicKey); > + byte[] result = resultOpt.orElseGet( > + () -> deriveKeyNative(privateKey, publicKey) > + ); > + publicKey = null; > + return result; > > I think this should actually be: > > return resultOpt.orElseGet(() -> deriveKeyNative(privateKey, publicKey)); > > if we want to avoid the JDK-8205476 change of nulling publicKey. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From christoph.langer at sap.com Thu Jun 27 10:12:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 27 Jun 2019 10:12:28 +0000 Subject: [11u] RFR (S): 8226880: Backport of JDK-8208698 (Improved ECC Implementation) should not bring parts of JDK-8205476 (KeyAgreement#generateSecret is not reset for ECDH based algorithm) Message-ID: Hi, I made a mistake when bringing JDK-8226880 to 11u. The patch introduced coding of JDK-8205476 that should not be there. Here is a patch to fix this. Bug: https://bugs.openjdk.java.net/browse/JDK-8226880 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226880.11u.0/ As the backport is in 11.0.4, this fix needs to be applied there during closed rampdown. Thanks Christoph From sgehwolf at redhat.com Thu Jun 27 16:38:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 27 Jun 2019 18:38:21 +0200 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: References: <14d0ce75-b26c-4993-9b96-c11681b4629c@redhat.com> Message-ID: <8cfe5370d20d8ef96661bcf2e5cb108893dd3670.camel@redhat.com> Dropping security-dev... On Thu, 2019-06-27 at 09:30 +0000, Langer, Christoph wrote: > > BTW: I just reported another regression which affects 11.0.4 as > well: https://bugs.openjdk.java.net/browse/JDK-8226876 It's "just" a > Java level assert but maybe we'll need to take some (backout?) action > here for 11.0.4, too... There is still some time to get critical fixes into 11.0.4. Perhaps it makes sense to wait a bit longer and re-assess as we are getting closer? Either way, we shouldn't discuss this in a sub-thread as this issue might result in this issue being lost in traffic :) Thanks, Severin From gnu.andrew at redhat.com Thu Jun 27 16:43:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 27 Jun 2019 17:43:31 +0100 Subject: [11u] RFR: 8208698: Improved ECC Implementation In-Reply-To: <8cfe5370d20d8ef96661bcf2e5cb108893dd3670.camel@redhat.com> References: <14d0ce75-b26c-4993-9b96-c11681b4629c@redhat.com> <8cfe5370d20d8ef96661bcf2e5cb108893dd3670.camel@redhat.com> Message-ID: <0181c5cb-4555-9b42-90f8-29a4f45d753d@redhat.com> On 27/06/2019 17:38, Severin Gehwolf wrote: > Dropping security-dev... > > On Thu, 2019-06-27 at 09:30 +0000, Langer, Christoph wrote: >> >> BTW: I just reported another regression which affects 11.0.4 as >> well: https://bugs.openjdk.java.net/browse/JDK-8226876 It's "just" a >> Java level assert but maybe we'll need to take some (backout?) action >> here for 11.0.4, too... > > There is still some time to get critical fixes into 11.0.4. Er, no there isn't. The code freeze was on Tuesday [0]. > Perhaps it > makes sense to wait a bit longer and re-assess as we are getting > closer? Either way, we shouldn't discuss this in a sub-thread as this > issue might result in this issue being lost in traffic :) I think a freeze exception should be made for these two fixes, given how close it is to the freeze. I'll post a separate thread. > > Thanks, > Severin> [0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Jun 27 16:44:59 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 27 Jun 2019 17:44:59 +0100 Subject: [11u] RFR (S): 8226880: Backport of JDK-8208698 (Improved ECC Implementation) should not bring parts of JDK-8205476 (KeyAgreement#generateSecret is not reset for ECDH based algorithm) In-Reply-To: References: Message-ID: On 27/06/2019 11:12, Langer, Christoph wrote: > Hi, > > ? > > I made a mistake when bringing JDK-8226880 to 11u. The patch introduced > coding of JDK-8205476 that should not be there. Here is a patch to fix this. > > ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226880 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226880.11u.0/ > > ? > > As the backport is in 11.0.4, this fix needs to be applied there during > closed rampdown. > > ? > > Thanks > > Christoph > > ? > Looks good to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Jun 27 16:48:35 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 27 Jun 2019 17:48:35 +0100 Subject: [11u] Code Freeze Exception Message-ID: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> Although 11.0.4 is now frozen for the July CPU, I would suggest making an exception for the following two regressions: 1. Roll back a behavioural change accidentally introduced in backporting JDK-8226880: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001378.html 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted as 11.0.5 for Oracle anyway. https://bugs.openjdk.java.net/browse/JDK-8226876 Thoughts? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Thu Jun 27 20:26:36 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Jun 2019 21:26:36 +0100 Subject: [11u] Code Freeze Exception In-Reply-To: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> References: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> Message-ID: On 6/27/19 5:48 PM, Andrew John Hughes wrote: > 1. Roll back a behavioural change accidentally introduced in backporting > JDK-8226880: > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001378.html > > 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted > as 11.0.5 for Oracle anyway. > https://bugs.openjdk.java.net/browse/JDK-8226876 > > Thoughts? I'm happy if we back them out. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Thu Jun 27 21:01:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 27 Jun 2019 21:01:01 +0000 Subject: [11u] Code Freeze Exception In-Reply-To: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> References: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> Message-ID: Hi, > Although 11.0.4 is now frozen for the July CPU, I would suggest making > an exception for the following two regressions: > > 1. Roll back a behavioural change accidentally introduced in backporting > JDK-8226880: > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-June/001378.html +1 > 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted > as 11.0.5 for Oracle anyway. > https://bugs.openjdk.java.net/browse/JDK-8226876 Seems, there is a simple fix upcoming for the regression: https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002870.html I'd vote for taking the fix over to 11.0.4. Then we don't need to care for re-applying the fix and the patch. Andrew, shall I push both things to jdk11u? When is your deadline to not unduly hold up your CPU work? Cheers Christoph From goetz.lindenmaier at sap.com Fri Jun 28 06:22:50 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 28 Jun 2019 06:22:50 +0000 Subject: [11u] Code Freeze Exception In-Reply-To: References: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> Message-ID: Hi, Yes, we should fix these issues. Andrew, should I add another tag once the changes are in? > > 1. Roll back a behavioural change accidentally introduced in backporting > > JDK-8226880: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > June/001378.html > > +1 +1 > > 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted > > as 11.0.5 for Oracle anyway. > > https://bugs.openjdk.java.net/browse/JDK-8226876 > > Seems, there is a simple fix upcoming for the regression: > https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002870.html > I'd vote for taking the fix over to 11.0.4. Then we don't need to care for re- > applying the fix and the patch. > > Andrew, shall I push both things to jdk11u? When is your deadline to not > unduly hold up your CPU work? To me, it seems more simple to roll back 8218960, as we can do this right now. Or do you expect other follow up issues if we roll it back, Christoph? But if your schedule admits it, Andrew, we can also go for the fix. Best regards, Goetz. > > Cheers > Christoph From christoph.langer at sap.com Fri Jun 28 06:41:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Jun 2019 06:41:57 +0000 Subject: [11u] Code Freeze Exception In-Reply-To: References: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> Message-ID: Hi, > Yes, we should fix these issues. > Andrew, should I add another tag once the changes are in? That would be preferrable because we can then merge it down to jdk11u-dev and have the fixes there, too. Otherwise they'd be missing for another 2-3 weeks. > > > 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted > > > as 11.0.5 for Oracle anyway. > > > https://bugs.openjdk.java.net/browse/JDK-8226876 > > > > Seems, there is a simple fix upcoming for the regression: > > https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002870.html > > I'd vote for taking the fix over to 11.0.4. Then we don't need to care for re- > > applying the fix and the patch. > > > > Andrew, shall I push both things to jdk11u? When is your deadline to not > > unduly hold up your CPU work? > To me, it seems more simple to roll back 8218960, as we can do this > right now. Or do you expect other follow up issues if we roll it back, > Christoph? But if your schedule admits it, Andrew, we can also > go for the fix. Naoto plans to push the fix to jdk13 tonight as per https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002875.html So, we could run another testcycle with both fixes here during the weekend and then push and tag Monday morning. Andrew, is that the plan we should go for? /Christoph From christoph.langer at sap.com Fri Jun 28 07:31:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 28 Jun 2019 07:31:39 +0000 Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: References: Message-ID: Hi again, I had to make some additions to get the test sun/security/tools/keytool/PSS.java to work. Firstly, I had to include the testlibrary utility class 'test/lib/jdk/test/lib/security/DerUtils.java' from the change for JDK-8076190. Then I had to add some code to src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java from JDK-8213400 to tolerate a keyBits value of -1. This is exercised in the PSS test when keytool is called with "-genkeypair -keyalg RSASSA-PSS -sigalg RSASSA-PSS" without specifying the -keysize parameter. Backporting JDK-8076190 or JDK-8213400 over to JDK11 is not possible due to their nature (CSR attached, behavioral change). The webrevs were updated in-place: http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Mittwoch, 26. Juni 2019 17:30 > To: jdk-updates-dev at openjdk.java.net > Cc: security-dev > Subject: [CAUTION] [11u]: RFR: Backport of 8215694: keytool cannot > generate RSASSA-PSS certificates > > Hi, > > please help reviewing the backport of JDK- 8215694: keytool cannot generate > RSASSA-PSS certificates. The patch doesn't apply cleanly but the rejects are > only minor. The Item is needed as prerequisite to apply JDK-8216039. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215694 > Original Change: http://hg.openjdk.java.net/jdk/jdk12/rev/bdb29aa5fd31 > Rejects when applying original change: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.rejects.patch > Full Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ > Incremental Webrev of added modifications: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ > > Thanks > Christoph From hohensee at amazon.com Fri Jun 28 20:07:02 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 28 Jun 2019 20:07:02 +0000 Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: References: Message-ID: <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com> In CertAndKeyGen.java, does generate() need a throws declaration? Otherwise looks good. We've been talking about backporting patches with CSRs and have done at least one. Imo, 8076190 and 8213400 are good backport candidates since the spec changes are minor. Thanks, Paul ?On 6/28/19, 12:33 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi again, I had to make some additions to get the test sun/security/tools/keytool/PSS.java to work. Firstly, I had to include the testlibrary utility class 'test/lib/jdk/test/lib/security/DerUtils.java' from the change for JDK-8076190. Then I had to add some code to src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java from JDK-8213400 to tolerate a keyBits value of -1. This is exercised in the PSS test when keytool is called with "-genkeypair -keyalg RSASSA-PSS -sigalg RSASSA-PSS" without specifying the -keysize parameter. Backporting JDK-8076190 or JDK-8213400 over to JDK11 is not possible due to their nature (CSR attached, behavioral change). The webrevs were updated in-place: http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ /Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Mittwoch, 26. Juni 2019 17:30 > To: jdk-updates-dev at openjdk.java.net > Cc: security-dev > Subject: [CAUTION] [11u]: RFR: Backport of 8215694: keytool cannot > generate RSASSA-PSS certificates > > Hi, > > please help reviewing the backport of JDK- 8215694: keytool cannot generate > RSASSA-PSS certificates. The patch doesn't apply cleanly but the rejects are > only minor. The Item is needed as prerequisite to apply JDK-8216039. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215694 > Original Change: http://hg.openjdk.java.net/jdk/jdk12/rev/bdb29aa5fd31 > Rejects when applying original change: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.rejects.patch > Full Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.full.0/ > Incremental Webrev of added modifications: > http://cr.openjdk.java.net/~clanger/webrevs/8215694.11u.manual.0/ > > Thanks > Christoph From stooke at redhat.com Fri Jun 28 20:45:04 2019 From: stooke at redhat.com (Simon Tooke) Date: Fri, 28 Jun 2019 16:45:04 -0400 Subject: [11u] RFR: Backport 8216354: Syntax error in toolchain_windows.m4 Message-ID: <0fb822e7-d78e-fcc9-0be2-8bccb520d908@redhat.com> This is a request to backport the changes required to fix 8216354.? It's been sitting on my TODO pile for too long. The actual 8216354 was fixed as part of a later commit, but I have webrevs to just backport the relevant change (one line) to jdk8u and 11u.? I'll be sending out this identical RFR on both lists as separate threads. Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 Webrev (jdk8u): http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk8/ Webrev (jdk11u): http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk11/ Thank you for your time, -Simon. From christoph.langer at sap.com Sun Jun 30 06:22:33 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 30 Jun 2019 06:22:33 +0000 Subject: [11u] RFR: Backport 8216354: Syntax error in toolchain_windows.m4 In-Reply-To: <0fb822e7-d78e-fcc9-0be2-8bccb520d908@redhat.com> References: <0fb822e7-d78e-fcc9-0be2-8bccb520d908@redhat.com> Message-ID: Hi Simon, the 11u fix looks good to me. Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Simon Tooke > Sent: Freitag, 28. Juni 2019 22:45 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: Backport 8216354: Syntax error in toolchain_windows.m4 > > This is a request to backport the changes required to fix 8216354. It's > been sitting on my TODO pile for too long. > > The actual 8216354 was fixed as part of a later commit, but I have > webrevs to just backport the relevant change (one line) to jdk8u and > 11u. I'll be sending out this identical RFR on both lists as separate > threads. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216354 > > Webrev (jdk8u): http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354- > jdk8/ > > Webrev (jdk11u): > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8216354-jdk11/ > > Thank you for your time, > > -Simon. > From gnu.andrew at redhat.com Sun Jun 30 23:24:33 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 1 Jul 2019 00:24:33 +0100 Subject: [11u] Code Freeze Exception In-Reply-To: References: <473a0340-60f3-3b27-de62-784c8f8b4978@redhat.com> Message-ID: <6c423d3c-7d46-505f-cb48-dea54730ee0d@redhat.com> On 28/06/2019 07:41, Langer, Christoph wrote: > Hi, > >> Yes, we should fix these issues. >> Andrew, should I add another tag once the changes are in? > > That would be preferrable because we can then merge it down to jdk11u-dev and have the fixes there, too. Otherwise they'd be missing for another 2-3 weeks. > >>>> 2. Roll back JDK-8218960 backport due to JDK-8226876. This is targeted >>>> as 11.0.5 for Oracle anyway. >>>> https://bugs.openjdk.java.net/browse/JDK-8226876 >>> >>> Seems, there is a simple fix upcoming for the regression: >>> https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002870.html >>> I'd vote for taking the fix over to 11.0.4. Then we don't need to care for re- >>> applying the fix and the patch. >>> >>> Andrew, shall I push both things to jdk11u? When is your deadline to not >>> unduly hold up your CPU work? >> To me, it seems more simple to roll back 8218960, as we can do this >> right now. Or do you expect other follow up issues if we roll it back, >> Christoph? But if your schedule admits it, Andrew, we can also >> go for the fix. > > Naoto plans to push the fix to jdk13 tonight as per https://mail.openjdk.java.net/pipermail/i18n-dev/2019-June/002875.html > > So, we could run another testcycle with both fixes here during the weekend and then push and tag Monday morning. Andrew, is that the plan we should go for? > > /Christoph > Sorry for the late reply. I've been busy wrapping up 8u. Yes, that sounds good to me. I'll keep an eye out for the new tag. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew